> Amélioration continue des processus > Gestion des demandes de service > Zendesk Support > Modèle de données

Votre modèle de données pour la gestion des demandes de service

Zendesk Support

Attributs de la gestion des demandes de service (21) Activités de gestion des demandes de service (13) Guides d’extraction (3)

Votre modèle de données pour la gestion des demandes de service

Ce modèle fournit un guide complet pour extraire les données nécessaires à l’analyse de votre processus de gestion des demandes de service dans Zendesk Support. Il présente les attributs de données essentiels à collecter, les activités clés à suivre et des recommandations pratiques pour extraire directement ces informations de votre système. Utilisez cette ressource pour constituer un journal d’événements fiable destiné à vos initiatives de Process Mining.

Attributs recommandés pour une analyse complète
Principales activités de demande de service à suivre
Guide d’extraction des données de Zendesk Support

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la gestion des demandes de service

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète la gestion des demandes de service dans Zendesk Support.

5 Obligatoire 7 Recommandé 9 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l’activité métier ou de l’événement qui s’est produit pour une demande de service.
Description L’activité représente une étape ou un événement distinct du cycle de vie d’une demande de service, comme « Service Request Created », « Request Assigned to Agent » ou « Service Request Resolved ». Ces activités sont dérivées des changements enregistrés dans le journal d’audit du ticket Zendesk, qui suit les modifications apportées à des champs tels que le statut, le responsable, la priorité et l’ajout de commentaires. L’analyse des activités constitue le cœur du Process Mining. Elle permet de visualiser la cartographie du processus, d’identifier les goulots d’étranglement entre les étapes et d’analyser les boucles de reprise. En comprenant la séquence et la fréquence des activités, les organisations peuvent repérer les inefficacités et les possibilités d’amélioration des processus. Pourquoi c’est important Cet attribut définit les étapes du processus et permet de visualiser les cartographies de processus ainsi que d’analyser le flux, les variations et la conformité du processus. Où les obtenir Cet attribut est dérivé conceptuellement des événements enregistrés dans l’API Zendesk Ticket Audits. Par exemple, une modification du champ « status » de « new » à « open » peut être associée à une activité telle que « Request Triaged ». Exemples Demande de service crééeAgent réaffectéDemande de service résolue
	Heure de début EventTimestamp	Date et heure précises auxquelles l’activité s’est produite.
Description L’horodatage de l’événement, ou heure de début, enregistre le moment exact où une activité a eu lieu. Il indique par exemple quand un agent a été affecté, quand une réponse publique a été envoyée ou quand le statut du ticket est passé à « Resolved ». Ces données temporelles proviennent du journal d’audit de chaque ticket Zendesk. Cet attribut est essentiel pour toute analyse fondée sur le temps. Il sert à classer les événements par ordre chronologique, à calculer la durée entre les activités, à mesurer les temps d’attente et à analyser le temps de cycle global du cas. Il est indispensable pour identifier les goulots d’étranglement et évaluer la performance par rapport à des objectifs temporels tels que les SLA. Pourquoi c’est important Cet horodatage classe les événements par ordre chronologique et est essentiel pour toutes les analyses de durée, de performance et de goulots d’étranglement. Où les obtenir API Zendesk Ticket Audits, champ « created_at » pour chaque événement d’audit. Exemples 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Identifiant de la demande de service ServiceRequestId	Identifiant unique de chaque ticket de demande de service dans Zendesk.
Description L’identifiant de la demande de service, souvent appelé Ticket ID dans Zendesk, sert de clé primaire pour chaque cas. Il relie toutes les activités, tous les commentaires et tous les changements de statut associés, de la création de la demande jusqu’à sa clôture. Il permet ainsi de retracer intégralement le cycle de vie d’une demande. Dans une analyse de Process Mining, cet attribut est fondamental. Il définit le cas, permet de reconstituer les flux de processus, d’identifier les variantes et de calculer des indicateurs au niveau du cas, comme le temps de cycle. Chaque événement du jeu de données doit être associé à un identifiant de demande de service afin d’en comprendre le contexte dans le processus global. Pourquoi c’est important Il s’agit de l’identifiant essentiel du cas, qui relie tous les événements du parcours d’une demande de service et permet d’analyser le processus de bout en bout. Où les obtenir API Zendesk Tickets, champ « id ». Exemples 102451024610247
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation des données depuis le système source.
Description Cet attribut enregistre la date et l’heure de l’extraction la plus récente des données depuis Zendesk Support. Il fournit un contexte sur l’actualité des données analysées et permet aux utilisateurs de savoir à quel point la vue du processus est récente. Pour le suivi continu et la création de Dashboards, cette information est essentielle. Elle permet aux analystes et aux utilisateurs métier de déterminer s’ils consultent des données presque en temps réel ou un instantané d’une période antérieure, ce qui influe sur la validité de leurs conclusions. Pourquoi c’est important Fournit un contexte important sur l’actualité des données et permet aux utilisateurs de savoir dans quelle mesure l’analyse est à jour. Où les obtenir Il s’agit d’un champ de métadonnées généré et horodaté dans le jeu de données au moment de l’extraction des données. Exemples 2023-10-27T08:00:00Z
	Système source SourceSystem	Indique le système à partir duquel les données ont été extraites.
Description Cet attribut précise l’origine des données relatives aux demandes de service. Pour cette vue de processus, sa valeur sera toujours « Zendesk Support », qui identifie le système de référence pour toutes les activités de gestion des services. Dans les environnements comprenant plusieurs systèmes intégrés, ce champ est essentiel pour assurer la traçabilité des données et faciliter le diagnostic. Il garantit que les analyses portent bien sur le système prévu et aide à distinguer les données lorsqu’elles sont fusionnées à partir de plusieurs sources. Pourquoi c’est important Identifie le système d’origine des données, garantit leur traçabilité et évite toute confusion lorsque des données provenant de plusieurs systèmes sont combinées. Où les obtenir Il s’agit d’une valeur statique (« Zendesk Support ») ajoutée lors de l’extraction et de la transformation des données. Exemples Zendesk Support
	Canal de la demande RequestChannel	Canal par lequel la demande de service a été soumise, par exemple e-mail, formulaire web ou téléphone.
Description Cet attribut identifie la source de soumission de la demande de service. Zendesk enregistre le mode de création du ticket, qu’il s’agisse d’un e-mail, d’un portail web, d’une intégration API, d’un chat ou d’un autre canal. Il fournit ainsi un contexte sur le mode d’interaction du client. Le canal de la demande constitue une dimension d’analyse particulièrement utile. Il alimente le Dashboard « Efficacité des canaux de demande » en permettant de comparer les délais de résolution, les niveaux de satisfaction et les taux de reprise entre les différents canaux. Ces analyses peuvent aider les entreprises à optimiser leurs canaux de support et à orienter les utilisateurs vers les plus efficaces. Pourquoi c’est important Aide à analyser l’efficacité et les résultats des différents canaux de support client afin de cibler les améliorations. Où les obtenir Zendesk Tickets API, objet « via » et propriété « channel ». Exemples WebE-mailAPIChat
	Équipe affectée AssignedTeam	Équipe ou groupe de support affecté à la demande de service.
Description Cet attribut indique quelle équipe ou quel groupe de l’organisation de support est responsable de la demande de service. Dans Zendesk, ces entités sont appelées « Groups ». Les tickets sont souvent affectés à un groupe avant d’être pris en charge par un agent. L’analyse par équipe affectée est essentielle pour comprendre la performance et la charge de travail au niveau de l’équipe. Elle permet notamment de déterminer quelles équipes traitent quels types de demandes, quels sont leurs délais moyens de résolution et quels sont leurs taux de respect des SLA. Il s’agit d’une dimension principale du Dashboard de performance des agents et des équipes. Pourquoi c’est important Permet d’analyser les performances des équipes, de répartir la charge de travail et d’évaluer l’efficacité du routage entre les différents groupes de support. Où les obtenir Zendesk Groups API, en reliant le « group_id » de la réponse de l’API Tickets. Exemples Support, niveau 1Support techniqueFacturation
	Nom de l’agent AgentName	Nom de l’agent affecté à la demande de service au moment de l’événement.
Description Cet attribut identifie l’agent de support responsable du traitement de la demande de service. L’agent affecté peut changer plusieurs fois au cours du cycle de vie du ticket, et ce champ indique la personne responsable à chaque étape. Le nom de l’agent est essentiel pour analyser la performance. Il permet de filtrer et de segmenter les données afin d’évaluer la répartition de la charge de travail, les délais de résolution par agent et la fréquence des réaffectations. Il contribue à créer le Dashboard de performance des agents et des équipes et à comprendre la contribution de chacun à l’efficacité globale du processus. Pourquoi c’est important Cet attribut est essentiel pour analyser la performance des agents, la répartition de la charge de travail et l’impact des réaffectations sur les délais de résolution. Où les obtenir API Zendesk Users, en reliant « assignee_id » dans la réponse de l’API Tickets. Exemples Jane DoeJohn SmithEmily Jones
	Priorité de la demande RequestPriority	Niveau de priorité attribué à la demande de service, par exemple Faible, Normale, Élevée ou Urgente.
Description La priorité de la demande est une classification qui indique le degré d’urgence d’une demande de service. Elle détermine souvent les délais de résolution cibles et les règles de SLA appliquées au ticket. La priorité peut être définie initialement par le système ou par l’utilisateur, puis modifiée par un agent au cours du cycle de vie du ticket. Cet attribut est essentiel pour la segmentation et l’analyse des causes racines. Il permet de vérifier si les tickets hautement prioritaires sont résolus plus rapidement que les tickets faiblement prioritaires. Il constitue également un facteur clé des Dashboards « Tendances des escalades de demandes de service » et « Respect des SLA ». Pourquoi c’est important Permet de segmenter les demandes selon leur degré d’urgence, ce qui est essentiel pour analyser le respect des SLA et garantir le traitement rapide des problèmes critiques. Où les obtenir Zendesk Tickets API, champ « priority ». Exemples FaibleNormaleÉlevéeUrgente
	Statut de la demande RequestStatus	Statut de la demande de service au moment de l’événement, par exemple Nouveau, Ouvert ou En attente.
Description Le statut de la demande représente l’état du ticket à un moment précis. Zendesk propose plusieurs statuts standard, tels que New, Open, Pending, On-hold, Solved et Closed, qui indiquent la progression d’une demande au cours de son cycle de vie. Les modifications de ce champ déclenchent principalement la création d’activités dans le journal d’événements. L’analyse du temps passé dans les différents statuts constitue un élément essentiel de l’analyse des goulots d’étranglement. Elle permet d’identifier les tickets qui restent bloqués, par exemple lorsqu’ils passent trop de temps dans l’état « Pending » ou « On-hold ». La compréhension des transitions entre statuts est également essentielle pour détecter les boucles de reprises. Pourquoi c’est important Le suivi du statut est fondamental pour comprendre l’avancement de la demande et déterminer le temps passé dans les états d’attente ou d’activité. Où les obtenir Zendesk Tickets API, champ « status ». Exemples NouveauOuvertEn attenteRésoluClôturé
	Tags du ticket TicketTags	Liste des tags appliqués à la demande de service à des fins de catégorisation et de routage.
Description Les étiquettes sont des libellés flexibles que les agents peuvent ajouter manuellement aux tickets ou qui peuvent être ajoutés automatiquement par des règles métier. Elles servent à apporter à un ticket un contexte ou une catégorie précise qui ne figurent pas nécessairement dans les champs standard tels que Type ou Priority. Les étiquettes constituent un attribut particulièrement polyvalent pour l’analyse en Process Mining. Elles peuvent servir à filtrer des scénarios très précis, à suivre des flux de travail personnalisés ou à identifier les causes profondes. Par exemple, l’étiquette « VIP » peut servir à analyser le processus applicable aux clients stratégiques, tandis que l’étiquette « product_bug » peut être utilisée pour suivre le cycle de vie des signalements de défauts. Pourquoi c’est important Offre une méthode flexible pour segmenter et analyser les données en détail, notamment les sous-processus ou les attributs de tickets qui ne sont pas enregistrés dans les autres champs. Où les obtenir Zendesk Tickets API, champ « tags ». Il s’agit d’un tableau de chaînes de caractères. Exemples sales_inquirybilling_issuefeature_requestvip_customer
	Type de service ServiceType	Catégorie ou type de la demande de service, par exemple Incident, Question, Problème ou Tâche.
Description Le type de service catégorise la nature de la demande de service. Zendesk utilise un champ « type » pour distinguer les différents types d’interactions avec le support. Cette classification initiale aide à orienter le ticket vers l’équipe appropriée et à appliquer les processus correspondants. Cet attribut est essentiel pour le filtrage et la comparaison. Il permet aux analystes d’examiner les flux de processus associés aux différents types de demandes, qui suivent souvent des parcours de résolution et des SLA très différents. Il constitue une dimension clé du Dashboard « Performances des agents et des équipes », qui permet d’identifier les personnes les plus efficaces pour traiter certains types de demandes. Pourquoi c’est important Catégorise les demandes afin de permettre une analyse distincte des différents processus, par exemple des incidents et des questions, qui suivent des parcours spécifiques. Où les obtenir Zendesk Tickets API, champ « type ». Exemples QuestionIncidentProblèmeTâche
	Évaluation de la satisfaction SatisfactionRating	Score de satisfaction fourni par le demandeur après la résolution du ticket.
Description Cet attribut recueille l’avis du client sur son expérience avec le support, généralement au moyen d’une enquête envoyée après le passage du ticket au statut Résolu. Les évaluations courantes sont « Bonne » ou « Mauvaise », parfois accompagnées d’un commentaire. L’évaluation de la satisfaction est un indicateur de résultat important. La mise en relation des schémas de processus avec les scores de satisfaction peut révéler les comportements qui conduisent à une expérience positive ou négative. L’analyse peut par exemple montrer que des taux élevés de réaffectation ou des délais de résolution longs sont fortement corrélés à des évaluations négatives. Pourquoi c’est important Établit un lien direct entre l’exécution du processus et les résultats obtenus auprès des clients, afin d’identifier les comportements qui influencent leur satisfaction. Où les obtenir Zendesk Tickets API, champ « satisfaction_rating.score » ou « satisfaction_rating.reason ». Exemples BonMauvaisProposé
	Heure de fin EndTime	Date et heure précises auxquelles l’activité a été achevée.
Description L’heure de fin marque l’achèvement d’une activité. Pour de nombreux événements dans Zendesk, la durée est instantanée : l’heure de fin est donc identique à l’heure de début. En revanche, pour les activités fondées sur un état, comme « Request Placed On-Hold », l’heure de fin correspond au moment où le ticket sort de l’attente. Cet attribut est essentiel pour calculer la durée d’activités précises, ce qui est indispensable à l’analyse des goulots d’étranglement. En comparant l’heure de début et l’heure de fin d’une activité, il est possible de mesurer directement son temps de traitement et de repérer les étapes qui consomment le plus de temps. Pourquoi c’est important Permet de calculer la durée de chaque activité, ce qui est essentiel pour identifier les goulots d’étranglement du processus et mesurer l’efficacité à chaque étape. Où les obtenir Elle est souvent identique à StartTime pour les événements discrets. Pour les durées associées aux statuts, elle correspond à l’horodatage de l’événement suivant qui modifie le statut. Exemples 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Nom de la politique de SLA SlaPolicyName	Nom de la politique d’accord de niveau de service (SLA) appliquée à la demande.
Description Cet attribut identifie la politique de SLA précise qui définit les délais cibles de réponse et de résolution de la demande de service. Une politique est généralement déterminée par des facteurs tels que la priorité ou le type de la demande, ainsi que le niveau d’abonnement du client. La connaissance de la politique de SLA appliquée est essentielle au Dashboard « Analyse du respect et des violations des SLA ». Elle fournit le contexte nécessaire à l’évaluation des performances, puisque chaque politique peut définir des objectifs différents. Il est ainsi possible de déterminer de manière juste et précise si un ticket a atteint ses objectifs de niveau de service spécifiques. Pourquoi c’est important Fournit le contexte nécessaire à l’analyse des SLA en identifiant l’ensemble d’objectifs auquel la demande a été comparée, ce qui permet d’établir des rapports de conformité précis. Où les obtenir Zendesk Ticket Metrics API. Les données relatives aux SLA sont souvent associées aux métriques du ticket. Exemples Urgent, réponse sous 1 heureStandard, résolution sous 24 heuresSLA client Premium
	Nom du demandeur RequestorName	Nom de l’utilisateur final ou du client ayant soumis la demande de service.
Description Cet attribut identifie la personne à l’origine de la demande de service. L’association de la demande à un client précis offre une vision du processus de support centrée sur l’utilisateur. Dans l’analyse des processus, le demandeur peut servir à étudier les tendances propres à certains clients ou segments de clientèle. Il est par exemple possible de vérifier si certains clients connaissent des délais de résolution plus longs ou des taux de reprise plus élevés, ce qui peut révéler des problèmes liés au produit ou au service qu’ils utilisent. Pourquoi c’est important Relie le processus au client et permet d’analyser les problèmes propres à certains clients, les demandes répétées et les niveaux de satisfaction. Où les obtenir Zendesk Users API, en reliant le « requester_id » de la réponse de l’API Tickets. Exemples Alice JohnsonBob WilliamsCharlie Brown
	Nombre de réaffectations à un agent AgentReassignmentCount	Nombre total de fois où une demande a été réaffectée d’un agent à un autre.
Description Cet attribut est un compteur qui s’incrémente chaque fois que le champ « assignee_id » d’un ticket est modifié. Un nombre élevé de réaffectations pour un même ticket peut révéler différents problèmes de processus, tels qu’un routage initial incorrect, un manque de connaissances de l’agent ou une demande trop complexe pour être traitée par une seule personne. Il s’agit d’une métrique clé pour mesurer l’efficacité du processus, qui alimente directement le KPI « Taux de réaffectation des agents ». L’analyse des cas présentant un nombre élevé de réaffectations peut révéler des possibilités d’amélioration des règles de routage, de la formation des agents ou des ressources de la base de connaissances, afin que les tickets parviennent plus rapidement à la bonne personne. Pourquoi c’est important Aide à quantifier les transferts internes et à identifier les points de friction du processus, car des taux élevés de réaffectation entraînent souvent des retards et une perte d’efficacité. Où les obtenir Calculé en comptant, pour chaque ticket, le nombre de modifications de « assignee_id » dans la Zendesk Ticket Audits API. Exemples 013
	Organisation du demandeur RequestorOrganization	Organisation ou entreprise à laquelle appartient le demandeur.
Description Cet attribut relie la demande de service à une organisation cliente précise. Il est particulièrement pertinent dans les scénarios de support B2B, où les accords de niveau de service et les contrats de support sont souvent définis au niveau de l’organisation. L’analyse des données par organisation offre une vision des performances du support à l’échelle de l’entreprise. Elle peut aider à identifier les organisations qui créent un volume élevé de tickets, rencontrent des problèmes récurrents ou affichent de faibles scores de satisfaction. Ces informations sont utiles pour la gestion des comptes et l’identification des tendances générales liées à la santé de la relation client. Pourquoi c’est important Permet d’analyser les services B2B en regroupant les demandes par entreprise, ce qui est essentiel pour gérer les relations clients et les SLA au niveau de l’organisation. Où les obtenir Zendesk Organizations API, en reliant le « organization_id » de la réponse de l’API Tickets. Exemples Acme CorporationGlobal Tech Inc.Innovate Solutions
	Reprise IsRework	Indicateur vrai si la demande de service a été rouverte après avoir été résolue.
Description Cet indicateur booléen identifie les cas ayant fait l’objet d’une reprise. Une demande de service est généralement considérée comme une reprise lorsque son statut passe de « Résolu » à un état ouvert, ce qui indique que la résolution initiale n’était pas suffisante et que le client a dû revenir sur le même problème. Cet attribut est essentiel au calcul du KPI « Taux de reprise des demandes de service » et au Dashboard « Analyse des activités de reprise et de réouverture ». En identifiant les cas de reprise, les analystes peuvent isoler les flux de processus inefficaces, déterminer les causes racines des réouvertures et améliorer la résolution dès le premier contact. Pourquoi c’est important Identifie les défaillances de processus lorsque la résolution n’est pas définitive et met en évidence les problèmes de qualité et d’efficacité qui ont une incidence directe sur la satisfaction client. Où les obtenir Calculé en analysant la séquence des statuts d’un ticket dans la Zendesk Ticket Audits API. Une transition de « solved » à « open » indique une reprise. Exemples truefalse
	Résolution dès le premier contact IsFirstContactResolution	Indicateur précisant si la demande a été résolue par le premier agent désigné, sans réaffectation ni réponse du demandeur.
Description La résolution dès le premier contact (FCR) est une métrique importante qui indique qu’un problème client a été résolu au cours d’une seule interaction. Cet attribut calculé est un indicateur booléen vrai lorsque le ticket a été résolu par le premier agent auquel il a été attribué, sans réaffectation et avec une seule réponse d’agent. Cet attribut alimente directement le KPI « Taux de résolution dès le premier contact ». L’analyse des caractéristiques des cas FCR peut servir de référence pour améliorer les processus. À l’inverse, l’analyse des cas qui n’atteignent pas le FCR peut révéler des possibilités d’amélioration de la formation des agents, des articles de la base de connaissances ou du triage initial. Pourquoi c’est important Mesure la capacité à résoudre efficacement un problème en une seule interaction, ce qui contribue fortement à la satisfaction client et à l’efficacité opérationnelle. Où les obtenir Il s’agit d’un attribut calculé complexe. Son calcul nécessite d’analyser le journal d’événements d’un ticket afin de vérifier les réaffectations à des agents et le nombre de réponses publiques envoyées par les agents. Exemples truefalse
	SLA non respecté IsSlaBreached	Indicateur précisant si la demande de service a dépassé l’un de ses objectifs de SLA.
Description Cet attribut est un indicateur booléen ou catégoriel qui présente le résultat du SLA pour un ticket. Il peut indiquer des états tels que « Respecté », « Non respecté » ou « Actif ». Ce résultat est déterminé en comparant les délais réels de réponse ou de résolution aux objectifs définis dans la politique de SLA appliquée. Cet attribut est essentiel au Dashboard « Analyse du respect et des violations des SLA ». Il permet de compter et de visualiser facilement les tickets conformes et non conformes. L’analyse peut ensuite porter sur les caractéristiques des tickets en violation afin d’identifier les causes racines, telles que des temps d’attente longs ou des réaffectations excessives. Pourquoi c’est important Mesure directement les performances par rapport aux engagements de niveau de service, un indicateur clé de la qualité du service et de la satisfaction client. Où les obtenir Dérivé de la Zendesk Ticket Metrics API, qui fournit des informations sur le statut des SLA pour chaque ticket. Exemples RespectéEn infractionActif

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Voici les principales étapes du processus et les jalons à enregistrer dans votre journal d’événements pour découvrir précisément le processus de vos demandes de service.

7 Recommandé 6 Facultatif

	Activité	Description
	Cible SLA non respectée	Cette activité marque le moment où une demande de service ne respecte pas une cible SLA définie, comme le délai de première réponse ou le délai de résolution. Zendesk enregistre explicitement cet événement lorsqu’une cible n’est pas atteinte.
Pourquoi c’est important Il s’agit d’un événement essentiel pour le suivi de la conformité et d’une donnée importante pour le KPI de taux de respect des SLA. Il permet de repérer les manquements aux engagements de service. Où les obtenir Capturé à partir de l’événement « SLABreach » dans les événements du ticket Zendesk ou dans son journal d’audit. L’événement précise l’indicateur SLA concerné. Collecte Identifié grâce à l’événement explicite « SLABreach » dans les données du ticket. Type d’événement explicit
	Demande affectée à un agent	Cette activité se produit lorsqu’une demande de service est affectée pour la première fois à un agent précis. Elle est déduite d’un événement « Change » dans le journal d’audit du ticket, lorsque le champ « assignee_id » est renseigné alors qu’il était nul ou contenait l’identifiant d’un groupe.
Pourquoi c’est important Elle marque le début du travail actif d’un agent et est essentielle pour mesurer le délai de première réponse, le délai avant la première affectation et la répartition de la charge de travail entre les agents. Où les obtenir Déduit du premier événement « Change » portant sur le champ « assignee_id » dans le journal d’audit du ticket, lorsqu’un identifiant utilisateur précis est défini. Collecte Déduit du premier événement de changement qui affecte le champ « assignee_id » à un agent. Type d’événement inferred
	Demande de service clôturée	Représente la clôture finale et définitive de la demande de service. Un ticket passe automatiquement à l’état « closed » après être resté « solved » pendant une période définie et ne peut alors plus être rouvert.
Pourquoi c’est important Cette activité marque la fin définitive du processus de demande de service. Elle fournit le point final nécessaire au calcul de la durée complète du cas. Où les obtenir Déduit d’un événement « Change » sur le champ « status » dans le journal d’audit du ticket, lorsque la nouvelle valeur est « closed ». Collecte Déduit d’un événement « Change » dans le journal d’audit lorsque le statut devient « closed ». Type d’événement inferred
	Demande de service créée	Marque le début du cycle de vie d’une demande de service, lorsqu’un demandeur soumet un nouveau ticket par l’intermédiaire de l’un des canaux disponibles. Cet événement est enregistré sous la forme d’un événement « Create » dans le journal d’audit du ticket Zendesk, ce qui fournit une heure de début précise pour le processus.
Pourquoi c’est important Cette activité constitue l’événement de début principal de chaque demande de service. Elle est donc essentielle pour calculer les délais de cycle de bout en bout et analyser le volume des demandes reçues. Où les obtenir Cet événement est enregistré comme type d’événement « Create » dans le journal d’audit du ticket Zendesk. Son horodatage correspond à l’heure de création du ticket de demande de service. Collecte Capturé directement à partir de l’événement « Create » dans le journal d’audit du ticket. Type d’événement explicit
	Demande de service résolue	Cette activité marque le moment où un agent a fourni une solution et fait passer le statut du ticket à « solved ». La demande est considérée comme terminée du point de vue de l’agent, mais le demandeur peut encore la rouvrir.
Pourquoi c’est important Il s’agit d’une étape importante qui marque la fin du travail actif de l’agent. Le temps nécessaire pour atteindre cet état constitue un indicateur principal de l’efficacité de la résolution. Où les obtenir Déduit d’un événement « Change » sur le champ « status » dans le journal d’audit du ticket, lorsque la nouvelle valeur est « solved ». Collecte Déduit d’un événement « Change » dans le journal d’audit lorsque le statut devient « solved ». Type d’événement inferred
	Demande de service rouverte	Se produit lorsqu’un demandeur répond à une demande dont le statut est « solved », ce qui fait automatiquement repasser son statut à « open ». Cela signifie que la solution proposée n’était pas suffisante.
Pourquoi c’est important Cette activité est le principal indicateur de reprise. L’analyse de sa fréquence permet de mesurer la qualité de la résolution et d’identifier les causes de l’insatisfaction client. Où les obtenir Déduit d’un événement « Change » sur le champ « status » dans le journal d’audit du ticket, lorsque l’ancienne valeur était « solved » et la nouvelle « open ». Collecte Déduit d’un changement de statut de « solved » à « open ». Type d’événement inferred
	Réponse publique envoyée	Cette activité correspond à toute communication envoyée par un agent au demandeur. Elle est enregistrée comme un événement « Comment » explicite dans les données du ticket Zendesk, lorsque l’attribut « public » est défini sur true.
Pourquoi c’est important Ces événements sont essentiels pour analyser la fréquence des communications, mesurer les délais de réponse des agents et déterminer le nombre d’échanges nécessaires à la résolution. Où les obtenir Il s’agit d’un événement « Comment » explicite dans les données du ticket. Les détails de l’événement comprennent l’attribut « public: true », qui le distingue des notes internes. Collecte Capturé à partir des événements « Comment » du ticket lorsque l’indicateur « public » est défini sur true. Type d’événement explicit
	Agent réaffecté	Représente le transfert de la responsabilité d’une demande de service d’un agent à un autre. Cet événement est déduit de tout événement « Change » ultérieur portant sur le champ « assignee_id », après l’affectation initiale.
Pourquoi c’est important Le suivi des réaffectations est essentiel pour calculer le KPI de taux de réaffectation des agents. Cet indicateur aide à repérer les inefficacités du processus, les erreurs d’orientation ou les lacunes en matière de connaissances. Où les obtenir Déduit des événements « Change » portant sur le champ « assignee_id » dans le journal d’audit du ticket, à l’exclusion du tout premier événement d’affectation du ticket. Collecte Déduit du deuxième événement « Change » et des événements suivants portant sur le champ « assignee_id ». Type d’événement inferred
	Cible SLA appliquée	Représente le moment où une politique de niveau de service (SLA) est appliquée au ticket de demande de service. Cet événement est enregistré explicitement lorsque les propriétés du ticket correspondent aux conditions d’une politique SLA active.
Pourquoi c’est important Le suivi de l’application d’un SLA est essentiel pour contrôler la conformité, analyser les violations potentielles et comprendre le délai de service attendu pour chaque type de demande. Où les obtenir Capturé à partir de l’événement « SLAPolicyApplied » dans les événements du ticket Zendesk ou dans son journal d’audit. Cet événement précise la politique correspondante. Collecte Identifié grâce à l’événement explicite « SLAPolicyApplied » dans les données du ticket. Type d’événement explicit
	Demande escaladée	Représente l’escalade officielle d’une demande de service vers un niveau de support supérieur, une autre équipe ou la direction. Elle est généralement déduite d’un changement du groupe affecté au ticket ou d’une modification d’un champ personnalisé destiné à suivre les escalades.
Pourquoi c’est important Le suivi des escalades aide à identifier les demandes complexes, les besoins de formation des agents de première ligne et les problèmes systémiques nécessitant une intervention de niveau supérieur. Où les obtenir Il ne s’agit pas d’un événement standard. Il doit être déduit d’un événement « Change » sur le champ « group_id » vers un groupe d’escalade, ou d’une modification d’un champ personnalisé du ticket utilisé pour suivre les escalades. Collecte Déduit d’une modification de « group_id » ou d’un champ personnalisé « escalation ». Type d’événement inferred
	Demande mise en attente	Cette activité se produit lorsque le statut de la demande de service passe à « on-hold », ce qui indique généralement que l’agent attend des informations du demandeur ou d’un tiers. Elle est déduite d’un événement de changement de statut.
Pourquoi c’est important Elle permet d’isoler et de mesurer les temps d’attente qui ne dépendent pas directement de l’équipe de support, afin d’obtenir une vision plus précise du temps de traitement par les agents. Où les obtenir Déduit d’un événement « Change » sur le champ « status » dans le journal d’audit du ticket, lorsque la nouvelle valeur est « on-hold ». Collecte Déduit d’un événement « Change » dans le journal d’audit lorsque le statut devient « on-hold ». Type d’événement inferred
	Note interne ajoutée	Une note ou un commentaire interne a été ajouté à la demande de service par un agent. Il n’est visible que par les autres agents. Cet événement est enregistré comme un événement « Comment » lorsque l’attribut « public » est défini sur false.
Pourquoi c’est important Le suivi des notes internes donne une visibilité sur la collaboration entre les agents ou les équipes, qui peut être une source de retard ou contribuer à résoudre efficacement les problèmes. Où les obtenir Il s’agit d’un événement « Comment » explicite dans les données du ticket. Les détails de l’événement comprennent l’attribut « public: false », indiquant qu’il s’agit d’une note interne. Collecte Capturé à partir des événements « Comment » du ticket lorsque l’indicateur « public » est défini sur false. Type d’événement explicit
	Priorité modifiée	Indique que le niveau de priorité de la demande de service, par exemple « Low », « Normal », « High » ou « Urgent », a été modifié. Cet événement est enregistré comme un événement « Change » sur le champ « priority » dans le journal d’audit du ticket.
Pourquoi c’est important L’analyse des changements de priorité permet d’identifier les demandes dont l’urgence augmente au fil du temps et d’évaluer l’efficacité de la gestion des priorités. Où les obtenir Enregistré comme événement « Change » sur le champ « priority » dans le journal d’audit du ticket Zendesk, avec les anciennes et les nouvelles valeurs. Collecte Déduit des événements « Change » portant sur le champ « priority » dans le journal d’audit. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis Zendesk Support

Étapes

Accédez à Zendesk Explore et créez le rapport principal : accédez à l’icône des produits Zendesk dans la barre supérieure droite, puis sélectionnez Explore. Dans Explore, cliquez sur l’icône des requêtes à gauche, puis sur Nouvelle requête. Sélectionnez le jeu de données Support : Ticket updates comme source.
Configurez les métriques et les attributs des événements de ticket : dans le générateur de requêtes, ajoutez une métrique telle que COUNT(Tickets) pour visualiser les données. Accédez ensuite à la section Lignes et ajoutez les attributs suivants : Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Nom du groupe, Ticket priority, Ticket status, Submission channel, Ticket type et Ticket tags.
Créez un attribut calculé pour ActivityName : pour convertir les mises à jour brutes en activités significatives, créez un attribut calculé standard. Accédez au menu Calculs, représenté par l’icône de calculatrice, sélectionnez Attribut calculé standard et nommez-le ActivityName. Collez la logique fournie dans la section Query dans la zone de formule. Cette formule associe les différents événements de mise à jour des tickets aux noms d’activités requis.
Affinez et filtrez le rapport principal : ajoutez le nouvel attribut ActivityName à la section Lignes. Créez un filtre sur cet attribut afin d’exclure les valeurs (null) ou celles générées automatiquement par le système qui ne sont pas souhaitées, pour nettoyer le jeu de données. Ajoutez également un filtre sur Ticket created - Date afin de limiter la requête à une période raisonnable, par exemple les six derniers mois.
Créez le deuxième rapport pour les événements SLA : créez une nouvelle requête en sélectionnant cette fois le jeu de données Support : SLAs. Cette étape est nécessaire, car les événements SLA ne sont pas disponibles dans le jeu de données Ticket updates.
Configurez le rapport SLA : dans la requête SLA, ajoutez COUNT(SLA tickets) à la section Métriques. Dans la section Lignes, ajoutez Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status et Updater name. L’activité sera déduite de SLA status lors de l’étape de transformation.
Exportez les deux jeux de données : exécutez les deux requêtes dans l’interface Explore. Une fois les tableaux générés, cliquez sur le bouton Exporter et choisissez le format CSV. Vous disposez alors de deux fichiers CSV distincts.
Fusionnez et transformez les données : combinez les deux fichiers CSV à l’aide d’un tableur tel que Microsoft Excel ou d’un langage de script tel que Python. L’objectif est de créer un journal d’événements unique. Pour le fichier SLA, vous devez créer la colonne ActivityName. Si SLA status est Actif, l’activité est SLA Target Applied. Si SLA status est Breached, l’activité est SLA Target Breached. Utilisez SLA updated - Timestamp comme EventTimestamp.
Standardisez les en-têtes de colonnes : dans le fichier final fusionné, renommez les colonnes pour respecter le format requis par le Process Mining. Par exemple, renommez Ticket ID en ServiceRequestId, Update - Timestamp en EventTimestamp et Updater name en AgentName.
Ajoutez les colonnes statiques et finalisez le fichier : ajoutez deux nouvelles colonnes à votre fichier CSV final. Renseignez SourceSystem avec la valeur « Zendesk ». Renseignez LastDataUpdate avec l’horodatage correspondant au moment de l’exportation. Le fichier est maintenant prêt à être importé.

Configuration

Offre Zendesk : une offre Zendesk Support incluant Zendesk Explore Professional ou Enterprise est nécessaire pour créer des requêtes et des attributs personnalisés.
Autorisations : vous devez être Agent et disposer des autorisations nécessaires pour créer et modifier des requêtes dans Explore. Il s’agit généralement d’un administrateur ou d’un agent doté d’un rôle personnalisé.
Sélection des jeux de données : cette méthode nécessite la création de deux rapports distincts à partir de deux jeux de données différents : Support: Ticket updates pour les événements généraux et Support: SLAs pour les événements propres aux SLA.
Filtre de période : il est essentiel d’appliquer un filtre de période, par exemple sur Ticket created - Date, afin de conserver un volume de données raisonnable. Pour une première analyse, une période de trois à six mois est recommandée.
Attributs calculés : la logique de déduction des noms d’activité est gérée par un attribut calculé personnalisé complexe dans Explore. Vérifiez que la formule est correctement créée afin d’éviter les erreurs dans le résultat.
Volume de données : l’interface Zendesk Explore et sa fonction d’exportation peuvent ralentir ou expirer avec des jeux de données très volumineux. Pour les extractions couvrant plus d’un an de données ou plusieurs millions de tickets, envisagez de répartir l’exportation en périodes plus courtes.

a Exemple de requête config

This method uses the Zendesk Explore UI, where queries are built visually. The following describes the configuration for the two required reports.

**Report 1: Ticket Events Configuration**
* **Dataset**: `Support: Ticket updates`
* **Metrics**: `COUNT(Tickets)`
* **Rows**:
  * `Ticket ID`
  * `ActivityName` (This is the custom calculated attribute defined below)
  * `Update - Timestamp`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
  * `Ticket status`
  * `Submission channel`
  * `Ticket type`
  * `Ticket tags`
* **Standard Calculated Attribute (`ActivityName`) Formula**:
```
IF [Update - Field name] = "assignee_id" AND ([Update - Previous value] = "" OR [Update - Previous value] = NULL) THEN
    "Request Assigned to Agent"
ELIF [Update - Field name] = "assignee_id" AND [Update - Previous value] != "" AND [Update - Previous value] != NULL THEN
    "Agent Reassigned"
ELIF [Update - Field name] = "group_id" THEN
    "Request Escalated"
ELIF [Update - Field name] = "priority" AND [Update - New value] != [Update - Previous value] THEN
    "Priority Changed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "hold" THEN
    "Request Placed On-Hold"
ELIF [Update - Field name] = "status" AND [Update - New value] = "solved" THEN
    "Service Request Resolved"
ELIF [Update - Field name] = "status" AND [Update - New value] = "closed" THEN
    "Service Request Closed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "open" AND [Update - Previous value] = "solved" THEN
    "Service Request Reopened"
ELIF [Update - Field name] = "requester_id" AND [Update - Previous value] = NULL THEN
    "Service Request Created"
ELSE
    NULL
ENDIF
```
* **Note on Comment Activities**: Capturing `Public Reply Sent` and `Internal Note Added` from the `Ticket updates` dataset is not reliably possible as the public vs. internal distinction is often missing. For these events, creating a third report on the `Support: Comments` dataset and merging it is the recommended, though more complex, approach.

**Report 2: SLA Events Configuration**
* **Dataset**: `Support: SLAs`
* **Metrics**: `COUNT(SLA tickets)`
* **Rows**:
  * `Ticket ID`
  * `SLA updated - Timestamp`
  * `SLA status`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
* **Note**: The `ActivityName` for this report (`SLA Target Applied`, `SLA Target Breached`) must be generated after export based on the value in the `SLA status` column.

Étapes

Prérequis : vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système. Vous aurez également besoin d’un accès administrateur à votre instance Zendesk Support pour générer un jeton API.
Installer les bibliothèques Python : ouvrez votre terminal ou votre invite de commandes et installez les bibliothèques Python nécessaires avec pip. La bibliothèque requests sert à effectuer les appels API et pandas à manipuler les données et à les exporter dans un fichier CSV.
```
pip install requests pandas
```
Générer un jeton API Zendesk : connectez-vous à Zendesk en tant qu’administrateur. Accédez à Admin Center > Apps and integrations > APIs > Zendesk API. Dans la section Token Access, activez l’accès s’il ne l’est pas déjà, puis cliquez sur « Add API token ». Saisissez une description, par exemple « ProcessMind Extraction », puis copiez le jeton généré. Ce jeton ne sera plus affiché.
Configurer le script Python : ouvrez le script Python fourni dans un éditeur de texte. Renseignez les variables de configuration situées en haut du fichier : ZENDESK_SUBDOMAIN (nom de domaine Zendesk de votre entreprise), ZENDESK_EMAIL (adresse e-mail de l’administrateur associé au jeton) et ZENDESK_API_TOKEN. Définissez également START_TIME_STR pour indiquer le début de la période d’extraction, généralement trois à six mois auparavant.
Comprendre la logique du script : le script récupère d’abord la liste des tickets mis à jour pendant la période indiquée à l’aide de l’Incremental Tickets API. Pour chaque ticket, il récupère ensuite l’historique complet des audits, les commentaires et les métriques SLA. Il traite ces événements par ordre chronologique afin de reconstituer un historique détaillé.
Associer les événements Zendesk aux activités : le script contient la logique nécessaire pour convertir les événements Zendesk bruts en activités métier. Par exemple, un événement « Change » sur le champ « status » est associé à des activités telles que « Service Request Resolved » ou « Request Placed On-Hold ». Les événements de commentaire sont examinés afin de déterminer s’il s’agit de « Public Reply Sent » ou de « Internal Note Added ».
Exécuter le script d’extraction : exécutez le script depuis votre terminal avec la commande python your_script_name.py. Le script affichera l’avancement au fur et à mesure de la récupération des données depuis l’API Zendesk. Selon le volume de données et les limites de débit de l’API, cette opération peut prendre un certain temps.
Vérifier le fichier de sortie : une fois le script terminé, il génère un fichier CSV nommé zendesk_event_log.csv dans le même répertoire. Ce fichier contient le journal d’événements extrait, avec toutes les activités et tous les attributs indiqués.
Préparer l’importation : ouvrez le fichier CSV pour vérifier que son format est correct. Les en-têtes de colonnes doivent correspondre aux attributs requis : ServiceRequestId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, entre autres. Le fichier est maintenant prêt à être importé dans ProcessMind.

Configuration

Accès à l’API Zendesk : le script nécessite un jeton API actif associé à un administrateur ou à un agent disposant d’autorisations suffisantes. L’adresse e-mail configurée dans le script doit être celle de l’utilisateur qui a créé le jeton API.
Paramètres du script : avant l’exécution, vous devez configurer les variables clés suivantes dans le script : ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN et START_TIME_STR. START_TIME_STR doit respecter le format « YYYY-MM-DD ».
Période : nous vous recommandons de commencer par une extraction couvrant les trois à six derniers mois de données (START_TIME_STR). Vous disposerez ainsi d’un jeu de données représentatif pour l’analyse, sans allonger excessivement la durée d’exécution ni atteindre trop fréquemment les limites de l’API. Une période plus longue augmentera sensiblement le temps d’extraction.
API Incremental Exports : le script utilise le point de terminaison Incremental Exports (/api/v2/incremental/tickets/cursor.json) pour récupérer efficacement uniquement les tickets mis à jour depuis la dernière exécution ou depuis une heure de début donnée. Cette méthode est beaucoup plus performante qu’une analyse de l’ensemble des tickets.
Limitation du débit : Zendesk applique des limites de débit à son API. Le script prévoit une gestion de base pour interrompre temporairement l’exécution lorsqu’une limite est atteinte, mais l’extraction peut prendre beaucoup de temps dans les instances très volumineuses. Il est préférable de l’exécuter en dehors des heures de pointe.
Logique d’escalade : l’activité « Request Escalated » est déduite d’une modification du champ group_id. Si votre organisation utilise un autre mécanisme, par exemple un champ de ticket personnalisé, vous devrez modifier la logique du script afin d’identifier correctement les escalades.

a Exemple de requête python

import requests
import pandas as pd
import time
from datetime import datetime, timezone
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, admin email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[Your Subdomain]'
ZENDESK_EMAIL = class="hl-string">'[Your Zendesk Admin Email]'
ZENDESK_API_TOKEN = class="hl-string">'[Your Zendesk API Token]'

class=class="hl-string">"hl-comment"># Set the start date for the data extraction (YYYY-MM-DD)
START_TIME_STR = class="hl-string">'2023-01-01'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

class=class="hl-string">"hl-comment"># Set up constants and session
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

session = requests.Session()
session.auth = AUTH

class=class="hl-string">"hl-comment"># Caches for user and group names to reduce API calls
user_cache = {}
group_cache = {}

def get_user_name(user_id):
    if not user_id:
        return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'User ID {user_id}'

def get_group_name(group_id):
    if not group_id:
        return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'Group ID {group_id}'

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
        print(fclass="hl-string">'Rate limit reached. Waiting for {retry_after} seconds...')
        time.sleep(retry_after)
        return True
    response.raise_for_status()
    return False

def fetch_paginated_data(url):
    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            yield data
            url = data.get(class="hl-string">'next_page')
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'Error fetching data from {url}: {e}')
            break

def process_ticket(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    print(fclass="hl-string">'Processing Ticket ID: {ticket_id}')

    class=class="hl-string">"hl-comment"># --- 1. Fetch Ticket Audits ---
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    all_events = [] class=class="hl-string">"hl-comment"># A temporary list to hold all events for sorting

    for audit_page in fetch_paginated_data(audits_url):
        for audit in audit_page.get(class="hl-string">'audits', []):
            author_id = audit.get(class="hl-string">'author_id')
            timestamp = audit[class="hl-string">'created_at']

            class=class="hl-string">"hl-comment"># Store ticket state at the time of the audit
            ticket_state = {}
            for event in audit.get(class="hl-string">'events', []):
                if event.get(class="hl-string">'field_name') in [class="hl-string">'assignee_id', class="hl-string">'group_id', class="hl-string">'priority', class="hl-string">'status', class="hl-string">'channel', class="hl-string">'type', class="hl-string">'tags']:
                    ticket_state[event[class="hl-string">'field_name']] = event.get(class="hl-string">'value')

            for event in audit.get(class="hl-string">'events', []):
                event[class="hl-string">'timestamp'] = timestamp
                event[class="hl-string">'author_id'] = author_id
                event[class="hl-string">'ticket_state'] = ticket_state
                all_events.append(event)

    class=class="hl-string">"hl-comment"># --- 2. Fetch Comments (which are not fully detailed in audits) ---
    comments_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/comments.json'
    for comment_page in fetch_paginated_data(comments_url):
        for comment in comment_page.get(class="hl-string">'comments', []):
            comment[class="hl-string">'type'] = class="hl-string">'Comment'
            comment[class="hl-string">'timestamp'] = comment[class="hl-string">'created_at']
            class=class="hl-string">"hl-comment"># Add ticket_state placeholder, though it's less relevant for comments
            comment[class="hl-string">'ticket_state'] = {}
            all_events.append(comment)

    class=class="hl-string">"hl-comment"># --- 3. Fetch SLA Metrics ---
    metrics_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json'
    try:
        response = session.get(metrics_url)
        if not handle_rate_limit(response):
            metrics_data = response.json().get(class="hl-string">'ticket_metric', {})
            if metrics_data.get(class="hl-string">'sla_policy'):
                for sla in metrics_data[class="hl-string">'sla_policy'][class="hl-string">'policy_metrics']:
                    all_events.append({
                        class="hl-string">'type': class="hl-string">'SlaApply',
                        class="hl-string">'timestamp': metrics_data[class="hl-string">'created_at'],
                        class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                        class="hl-string">'ticket_state': {}
                    })
                    if sla.get(class="hl-string">'breach_at') and datetime.fromisoformat(sla[class="hl-string">'breach_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00')) < datetime.now(timezone.utc):
                        all_events.append({
                            class="hl-string">'type': class="hl-string">'SlaBreach',
                            class="hl-string">'timestamp': sla[class="hl-string">'breach_at'],
                            class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                            class="hl-string">'metric': sla[class="hl-string">'metric'],
                            class="hl-string">'ticket_state': {}
                        })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Could not fetch SLA metrics for ticket {ticket_id}: {e}')


    class=class="hl-string">"hl-comment"># --- 4. Sort all collected events by timestamp ---
    all_events.sort(key=lambda x: x[class="hl-string">'timestamp'])

    class=class="hl-string">"hl-comment"># --- 5. Process sorted events to create event log rows ---
    last_assignee = None

    for event in all_events:
        activity_name = None
        timestamp = event[class="hl-string">'timestamp']

        event_type = event.get(class="hl-string">'type')
        field_name = event.get(class="hl-string">'field_name')

        if event_type == class="hl-string">'Create':
            activity_name = class="hl-string">'Service Request Created'
            last_assignee = event.get(class="hl-string">'value') if field_name == class="hl-string">'assignee_id' else None

        elif event_type == class="hl-string">'Change':
            prev_value = event.get(class="hl-string">'previous_value')
            new_value = event.get(class="hl-string">'value')

            if field_name == class="hl-string">'status':
                if new_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Resolved'
                elif new_value == class="hl-string">'closed': activity_name = class="hl-string">'Service Request Closed'
                elif new_value == class="hl-string">'hold': activity_name = class="hl-string">'Request Placed On-Hold'
                elif new_value == class="hl-string">'open' and prev_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Reopened'
            elif field_name == class="hl-string">'priority': activity_name = class="hl-string">'Priority Changed'
            elif field_name == class="hl-string">'assignee_id':
                if prev_value is None and new_value is not None:
                    activity_name = class="hl-string">'Request Assigned to Agent'
                elif prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Agent Reassigned'
                last_assignee = new_value
            elif field_name == class="hl-string">'group_id':
                if prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Request Escalated'

        elif event_type == class="hl-string">'Comment':
            if event.get(class="hl-string">'public', False):
                activity_name = class="hl-string">'Public Reply Sent'
            else:
                activity_name = class="hl-string">'Internal Note Added'

        elif event_type == class="hl-string">'SlaApply':
            activity_name = class="hl-string">'SLA Target Applied'
        elif event_type == class="hl-string">'SlaBreach':
            activity_name = class="hl-string">'SLA Target Breached'

        if activity_name:
            class=class="hl-string">"hl-comment"># Get attribute values from the ticket object itself as a baseline
            agent_id = ticket.get(class="hl-string">'assignee_id')
            group_id = ticket.get(class="hl-string">'group_id')
            priority = ticket.get(class="hl-string">'priority')
            status = ticket.get(class="hl-string">'status')
            
            class=class="hl-string">"hl-comment"># Override with values at the time of the event if available
            state = event.get(class="hl-string">'ticket_state', {})
            agent_id = state.get(class="hl-string">'assignee_id', agent_id)
            group_id = state.get(class="hl-string">'group_id', group_id)
            priority = state.get(class="hl-string">'priority', priority)
            status = state.get(class="hl-string">'status', status)
            
            event_log.append({
                class="hl-string">'ServiceRequestId': ticket_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTimestamp': timestamp,
                class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                class="hl-string">'AgentName': get_user_name(agent_id),
                class="hl-string">'AssignedTeam': get_group_name(group_id),
                class="hl-string">'RequestPriority': priority,
                class="hl-string">'RequestStatus': status,
                class="hl-string">'RequestChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'type'),
                class="hl-string">'TicketTags': class="hl-string">', '.join(ticket.get(class="hl-string">'tags', [])),
            })


def main():
    print(class="hl-string">'Starting Zendesk data extraction...')
    event_log = []
    start_unix_time = int(datetime.strptime(START_TIME_STR, class="hl-string">'%Y-%m-%d').timestamp())
    
    class=class="hl-string">"hl-comment"># Use the incremental export endpoint for efficiency
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={start_unix_time}'

    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])
            print(fclass="hl-string">'Fetched {len(tickets)} tickets...')
            for ticket in tickets:
                process_ticket(ticket, event_log)
            
            if not data.get(class="hl-string">'after_cursor'):
                break
            url = data[class="hl-string">'next_page']

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'A critical error occurred: {e}')
            break

    print(fclass="hl-string">'Extraction complete. Total events found: {len(event_log)}')
    
    if not event_log:
        print(class="hl-string">'No events were extracted. Please check your configuration and date range.')
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Reorder columns to match requirements
    columns = [
        class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AgentName', class="hl-string">'AssignedTeam', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus',
        class="hl-string">'RequestChannel', class="hl-string">'ServiceType', class="hl-string">'TicketTags'
    ]
    df = df[columns]
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTimestamp']).reset_index(drop=True)

    class=class="hl-string">"hl-comment"># Save to CSV
    output_filename = class="hl-string">'zendesk_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">'Event log saved to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

Étapes

Dans Zendesk Admin Center, demandez ou lancez l’export JSON natif complet du compte à l’aide de la fonctionnalité d’export disponible dans votre abonnement et votre compte Zendesk. Le chemin exact dans les menus et les autorisations requises varient selon la configuration du compte. Utilisez donc l’option d’export proposée dans votre Admin Center et suivez le processus d’approbation de votre organisation.
Sélectionnez une période couvrant celle requise pour l’analyse, de préférence trois à six mois. Si l’export natif ne permet pas de filtrer par date, téléchargez l’export complet du compte et appliquez le filtre de période lors de la transformation.
Téléchargez et conservez tous les fichiers JSON produits par l’export. Préservez les fichiers d’origine, l’horodatage de l’export, l’identifiant du compte ainsi que tout fichier manifeste ou de métadonnées. Ne remplacez pas les fichiers sources pendant le traitement.
Analysez les enregistrements de tickets, les audits de tickets, les événements d’audit, les commentaires, les utilisateurs, les organisations, les groupes, les enregistrements liés aux SLA et les champs personnalisés contenus dans l’export. Les noms de fichiers et les structures JSON pouvant varier selon la version de l’export Zendesk, configurez les chemins sources et les correspondances de propriétés JSON dans les variables prévues à cet effet avant l’exécution.
Normalisez chaque événement d’audit de ticket dans une structure commune contenant ServiceRequestId, l’horodatage de l’audit, le type d’événement, le nom du champ, la valeur précédente, la nouvelle valeur, l’identifiant de l’auteur, l’indicateur public, le statut du ticket, l’agent assigné, le groupe, la priorité, le canal, le type de service, les tags, le système source et LastDataUpdate.
Générez une ligne du journal d’événements pour chaque activité admissible. L’extraction doit créer explicitement des lignes pour Service Request Created, SLA Target Applied, Request Assigned to Agent, Priority Changed, Agent Reassigned, Public Reply Sent, Internal Note Added, Request Placed On-Hold, Request Escalated, SLA Target Breached, Service Request Reopened, Service Request Resolved et Service Request Closed. ProcessMind lit ces lignes telles quelles et ne déduit aucun événement supplémentaire.
Lorsque cela est possible, faites correspondre les identifiants des agents, des groupes, des organisations et des demandeurs aux enregistrements exportés correspondants des utilisateurs, des groupes et des organisations. Renseignez AgentName et AssignedTeam à partir de l’état d’affectation au moment de l’événement. Conservez l’identifiant ou laissez la valeur vide lorsqu’aucun nom d’affichage ne peut être déterminé.
Appliquez des règles d’événement déterministes. Utilisez l’événement d’audit Create du ticket pour Service Request Created, les événements d’audit SLA explicites pour SLA Target Applied et SLA Target Breached, le premier changement d’agent admissible pour Request Assigned to Agent, les changements d’agent ultérieurs pour Agent Reassigned, les indicateurs de commentaires publics et privés pour les événements de réponse et de note, les transitions de statut pour les événements de mise en attente, de réouverture, de résolution et de clôture, ainsi que les changements de groupe ou du champ d’escalade configuré pour Request Escalated.
Triez les lignes obtenues par ServiceRequestId et EventTimestamp, en conservant une séquence stable de l’événement source comme critère de départage. Ne dédupliquez pas les événements uniquement parce que leurs horodatages sont identiques, car plusieurs commentaires ou événements d’audit peuvent survenir au même moment.
Vérifiez que toutes les colonnes requises sont présentes et que chaque activité possède au moins une ligne admissible lorsque les données sources contiennent l’événement correspondant. Exportez le résultat final au format CSV UTF-8 ou dans un autre format de journal d’événements pris en charge par ProcessMind, avec une ligne par événement et les noms de colonnes requis ServiceRequestId, ActivityName, EventTimestamp, SourceSystem et LastDataUpdate.

Configuration

Périmètre de l’export : utilisez l’export JSON natif complet du compte Zendesk Support et conservez chaque fichier JSON généré par l’export. Celui-ci doit inclure les données des tickets ainsi que leurs données d’audit ou d’événement. Si les données relatives aux SLA, aux commentaires, aux utilisateurs, aux organisations, aux groupes ou aux champs personnalisés sont fournies séparément, ajoutez ces fichiers aux données d’entrée de la transformation.
Période : pour une première extraction et validation, privilégiez trois à six mois. Si l’export natif couvre l’ensemble du compte et ne peut pas être limité par date, filtrez EventTimestamp après l’analyse tout en conservant l’archive source complète.
Règles d’activité : configurez des correspondances explicites pour les 13 activités. Ne comptez pas sur ProcessMind pour déduire les événements d’affectation, d’escalade, de SLA, de statut ou de commentaire à partir d’autres lignes.
Configuration des SLA : associez les noms ou propriétés d’événement réellement exportés par le compte aux événements d’application et de dépassement de la cible SLA. Si l’export ne contient pas d’événements SLA explicites, n’en créez pas artificiellement. Configurez les chemins sources correspondants dans les variables prévues à cet effet et documentez toute activité indisponible.
Configuration de l’escalade : identifiez le champ de groupe ou le champ personnalisé propre au compte qui représente une escalade. Définissez ESCALATION_FIELD_ID, ou le paramètre équivalent, avec l’identifiant réel du champ exporté avant l’exécution.
Chemins sources : définissez les chemins des fichiers JSON et les correspondances de propriétés JSON dans le script. Les noms de fichiers et la structure imbriquée des exports Zendesk peuvent varier selon la version de l’export et la configuration du compte.
Résultat requis : ServiceRequestId, ActivityName, EventTimestamp, SourceSystem et LastDataUpdate doivent être renseignés pour chaque ligne d’événement. Les colonnes recommandées sont AgentName, AssignedTeam, RequestPriority, RequestStatus, RequestChannel, ServiceType et TicketTags.
Filtres : appliquez la période d’analyse requise, le périmètre du compte ou de la marque ainsi que les filtres propres à l’entreprise uniquement après avoir confirmé la propriété exportée correspondante. N’appliquez pas de filtres fondés sur des noms de champs non pris en charge ou non vérifiés.
Performances : traitez les fichiers JSON progressivement lorsque cela est possible, évitez de charger l’export complet du compte en mémoire, indexez les identifiants de tickets et d’audits, puis écrivez des fichiers intermédiaires normalisés avant de produire le journal d’événements final. Les exports volumineux peuvent nécessiter un partitionnement par date ou par identifiant de ticket.
Prérequis : accès administrateur pour demander ou télécharger l’export natif du compte, autorisation d’accéder aux audits des tickets et aux données de référence des utilisateurs ou des groupes, abonnement Zendesk prenant en charge la fonctionnalité d’export, espace de stockage local suffisant pour l’export complet et environnement capable d’analyser du JSON et d’écrire des fichiers CSV UTF-8.
Protection des données : considérez les données relatives aux demandeurs, aux agents, aux organisations, aux commentaires et aux tickets comme potentiellement sensibles. Stockez les fichiers sources et transformés conformément aux exigences de votre organisation en matière de conservation, de contrôle des accès et de protection de la vie privée.

a Exemple de requête config

import csv
import json
import os
from datetime import datetime, timezone
from pathlib import Path

SOURCE_DIRECTORY = "[Path to extracted Zendesk JSON directory]"
OUTPUT_FILE = "[Path to ProcessMind event log CSV]"
START_DATE = "[YYYY-MM-DD or blank]"
END_DATE = "[YYYY-MM-DD or blank]"
SOURCE_SYSTEM = "Zendesk Support"
LAST_DATA_UPDATE = "[ISO-8601 timestamp of source refresh]"
ESCALATION_FIELD_ID = "[Zendesk custom field identifier used for escalation, or blank]"


def load_json_files(directory):
    documents = []
    for path in Path(directory).rglob("*.json"):
        with path.open("r", encoding="utf-8") as handle:
            documents.append((path.name, json.load(handle)))
    return documents


def as_list(value):
    if isinstance(value, list):
        return value
    if isinstance(value, dict):
        for key in ("tickets", "ticket", "audits", "events", "comments", "users", "groups", "organizations", "data", "results"):
            if isinstance(value.get(key), list):
                return value[key]
    return []


def parse_timestamp(value):
    if not value:
        return None
    text = str(value).replace("Z", "+00:00")
    try:
        parsed = datetime.fromisoformat(text)
        if parsed.tzinfo is None:
            parsed = parsed.replace(tzinfo=timezone.utc)
        return parsed.astimezone(timezone.utc)
    except ValueError:
        return None


def in_range(timestamp):
    if timestamp is None:
        return False
    if START_DATE and timestamp.date().isoformat() < START_DATE:
        return False
    if END_DATE and timestamp.date().isoformat() > END_DATE:
        return False
    return True


def value(record, *keys):
    for key in keys:
        if isinstance(record, dict) and record.get(key) is not None:
            return record.get(key)
    return None


def identifier(record):
    return value(record, "id", "user_id", "group_id", "organization_id", "ticket_id")


def normalize_id(value_to_normalize):
    if value_to_normalize is None or value_to_normalize == "":
        return None
    return str(value_to_normalize)


def audit_events(audit):
    events = value(audit, "events", "audit_events")
    return events if isinstance(events, list) else []


def event_type(event):
    return str(value(event, "type", "event_type", "action") or "").lower()


def event_field(event):
    return str(value(event, "field_name", "field", "property") or "").lower()


def event_value(event, key):
    return value(event, key, key.replace("_", ""))


def status_value(ticket, event, new=True):
    if new:
        return value(event, "value", "new_value", "to") or value(ticket, "status")
    return value(event, "previous_value", "old_value", "from")


def comment_public(event):
    public_value = value(event, "public", "is_public")
    return public_value is True or str(public_value).lower() == "true"


def add_row(rows, ticket, activity, timestamp, agent_name=None, assigned_team=None, priority=None, status=None, channel=None, service_type=None, tags=None, sequence=0):
    parsed = parse_timestamp(timestamp)
    if not in_range(parsed):
        return
    rows.append({
        "ServiceRequestId": str(value(ticket, "id", "ticket_id")),
        "ActivityName": activity,
        "EventTimestamp": parsed.isoformat(),
        "SourceSystem": SOURCE_SYSTEM,
        "LastDataUpdate": LAST_DATA_UPDATE,
        "AgentName": agent_name or "",
        "AssignedTeam": assigned_team or "",
        "RequestPriority": priority or "",
        "RequestStatus": status or "",
        "RequestChannel": channel or "",
        "ServiceType": service_type or "",
        "TicketTags": ",".join(tags) if isinstance(tags, list) else (tags or ""),
        "SourceSequence": sequence
    })


def main():
    documents = load_json_files(SOURCE_DIRECTORY)
    tickets = {}
    audits_by_ticket = {}
    users = {}
    groups = {}
    organizations = {}
    standalone_comments = []
    standalone_sla_events = []

    for filename, document in documents:
        records = as_list(document)
        lower_name = filename.lower()
        for record in records:
            if not isinstance(record, dict):
                continue
            record_id = normalize_id(identifier(record))
            if any(token in lower_name for token in ("user", "agent")) and record_id:
                users[record_id] = record
            elif "group" in lower_name and record_id:
                groups[record_id] = record
            elif "organization" in lower_name and record_id:
                organizations[record_id] = record
            elif "audit" in lower_name and value(record, "ticket_id") is not None:
                audits_by_ticket.setdefault(normalize_id(value(record, "ticket_id")), []).append(record)
            elif "comment" in lower_name:
                standalone_comments.append(record)
            elif "sla" in lower_name:
                standalone_sla_events.append(record)
            elif value(record, "ticket_id") is not None and value(record, "type", "event_type") is not None:
                standalone_sla_events.append(record)
            elif value(record, "id") is not None and any(key in record for key in ("status", "priority", "assignee_id", "group_id", "tags")):
                tickets[record_id] = record

    rows = []
    for ticket_id, ticket in tickets.items():
        if not ticket_id:
            continue
        ticket_audits = audits_by_ticket.get(ticket_id, [])
        ticket_audits.sort(key=lambda item: (parse_timestamp(value(item, "created_at", "timestamp", "time")) or datetime.min.replace(tzinfo=timezone.utc), str(value(item, "id") or "")))
        current_assignee = normalize_id(value(ticket, "assignee_id"))
        current_group = normalize_id(value(ticket, "group_id"))
        assignment_seen = False
        sequence = 0
        base_priority = value(ticket, "priority")
        base_status = value(ticket, "status")
        base_channel = value(ticket, "via", "channel")
        base_service_type = value(ticket, "type", "service_type")
        base_tags = value(ticket, "tags") or []

        for audit in ticket_audits:
            audit_time = value(audit, "created_at", "timestamp", "time")
            actor_id = normalize_id(value(audit, "author_id", "actor_id", "user_id"))
            actor = users.get(actor_id, {})
            agent_name = value(actor, "name", "display_name", "email") or ""
            audit_group = groups.get(current_group, {})
            assigned_team = value(audit_group, "name", "display_name") or ""
            for event in audit_events(audit):
                sequence += 1
                kind = event_type(event)
                field = event_field(event)
                timestamp = value(event, "created_at", "timestamp", "time") or audit_time
                new_value = event_value(event, "value") or event_value(event, "new_value") or event_value(event, "to")
                old_value = event_value(event, "previous_value") or event_value(event, "old_value") or event_value(event, "from")
                event_agent = agent_name
                event_team = assigned_team
                if field in ("assignee_id", "assignee"):
                    new_assignee = normalize_id(new_value)
                    old_assignee = normalize_id(old_value)
                    if new_assignee and not assignment_seen and new_assignee != current_group:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Request Assigned to Agent", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                        assignment_seen = True
                    elif new_assignee and assignment_seen and new_assignee != old_assignee:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Agent Reassigned", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_assignee = new_assignee or current_assignee
                elif field in ("priority",):
                    add_row(rows, ticket, "Priority Changed", timestamp, event_agent, event_team, new_value, base_status, base_channel, base_service_type, base_tags, sequence)
                    base_priority = new_value or base_priority
                elif field in ("group_id", "group"):
                    new_group = normalize_id(new_value)
                    new_group_record = groups.get(new_group, {})
                    new_team = value(new_group_record, "name", "display_name") or event_team
                    if new_group and new_group != current_group:
                        add_row(rows, ticket, "Request Escalated", timestamp, event_agent, new_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_group = new_group or current_group
                elif field in ("status", "status_category"):
                    status_text = str(new_value or "").lower()
                    old_status_text = str(old_value or "").lower()
                    if status_text == "on-hold":
                        add_row(rows, ticket, "Request Placed On-Hold", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "solved":
                        add_row(rows, ticket, "Service Request Resolved", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "closed":
                        add_row(rows, ticket, "Service Request Closed", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if old_status_text == "solved" and status_text in ("open", "pending", "on-hold"):
                        add_row(rows, ticket, "Service Request Reopened", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    base_status = new_value or base_status
                elif kind in ("comment", "comment_created", "comment_added") or field in ("comment", "comment_body"):
                    if comment_public(event):
                        add_row(rows, ticket, "Public Reply Sent", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    else:
                        add_row(rows, ticket, "Internal Note Added", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif "sla" in kind or "sla" in field:
                    sla_text = str(value(event, "target_status", "status", "action", "event_type", "type") or "").lower()
                    if any(token in sla_text for token in ("breach", "breached", "missed", "failed")):
                        add_row(rows, ticket, "SLA Target Breached", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    elif any(token in sla_text for token in ("applied", "active", "started", "target")):
                        add_row(rows, ticket, "SLA Target Applied", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif ESCALATION_FIELD_ID and field == ESCALATION_FIELD_ID.lower():
                    add_row(rows, ticket, "Request Escalated", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

            if str(value(audit, "action", "type", "event_type") or "").lower() == "create":
                add_row(rows, ticket, "Service Request Created", audit_time, agent_name, assigned_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

        for record in standalone_sla_events:
            if normalize_id(value(record, "ticket_id")) != ticket_id:
                continue
            timestamp = value(record, "created_at", "timestamp", "time")
            text = str(value(record, "event_type", "type", "status", "action") or "").lower()
            if "breach" in text or "missed" in text or "failed" in text:
                add_row(rows, ticket, "SLA Target Breached", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
            elif "sla" in text or "applied" in text or "active" in text:
                add_row(rows, ticket, "SLA Target Applied", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

    rows.sort(key=lambda row: (row["ServiceRequestId"], row["EventTimestamp"], int(row["SourceSequence"])))
    output_columns = ["ServiceRequestId", "ActivityName", "EventTimestamp", "SourceSystem", "LastDataUpdate", "AgentName", "AssignedTeam", "RequestPriority", "RequestStatus", "RequestChannel", "ServiceType", "TicketTags"]
    with open(OUTPUT_FILE, "w", encoding="utf-8", newline="") as handle:
        writer = csv.DictWriter(handle, fieldnames=output_columns)
        writer.writeheader()
        for row in rows:
            writer.writerow({column: row.get(column, "") for column in output_columns})


if __name__ == "__main__":
    main()

Prêt à commencer ?

Commencez dès aujourd’hui à optimiser votre processus de gestion des demandes de service. Utilisez ce modèle de données pour révéler les goulots d’étranglement et améliorer l’efficacité dans Zendesk Support.

Retour au guide d’amélioration Télécharger le modèle

Optimisez la gestion des demandes de service. Réduisez les délais dès maintenant.

Mettez fin aux traitements lents et à la frustration des utilisateurs. Atteignez 70 % d’automatisation.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Mise en place rapide.

Votre modèle de données pour la gestion des demandes de service

Votre modèle de données pour la gestion des demandes de service

Attributs de la gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Interface Zendesk Explore pour les rapports et l’exportation des données

Étapes

Configuration

a Exemple de requête config

Extraction via l’API REST Zendesk à l’aide d’un script Python

Étapes

Configuration

a Exemple de requête python

Export JSON natif complet du compte Zendesk Support

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Optimisez la gestion des demandes de service. Réduisez les délais dès maintenant.

Votre modèle de données pour la gestion des demandes de service

Votre modèle de données pour la gestion des demandes de service

Attributs de la gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Interface Zendesk Explore pour les rapports et l’exportation des données

Étapes

Configuration

a Exemple de requête config

Extraction via l’API REST Zendesk à l’aide d’un script Python

Étapes

Configuration

a Exemple de requête python

Export JSON natif complet du compte Zendesk Support

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Optimisez la gestion des demandes de service. Réduisez les délais dès maintenant.

Nous attachons de l’importance à votre confidentialité