> 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 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 vous guide dans l’extraction des données nécessaires à l’analyse de votre processus de gestion des demandes de service dans Zendesk Support. Il présente les attributs à recueillir, les principales activités à suivre et des conseils pratiques pour extraire ces informations directement de votre système. Appuyez-vous sur cette ressource pour constituer un journal d’événements adapté à vos initiatives de Process Mining.

Attributs recommandés pour une analyse complète
Activités clés de gestion des demandes de service à suivre
Guide d’extraction des données Zendesk Support

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de gestion des demandes de service

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser en détail 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 survenu pour une demande de service.
Description L’activité correspond à une étape ou à un événement distinct du cycle de vie d’une demande de service, comme « Demande de service créée », « Demande affectée à un agent » ou « Demande de service résolue ». Ces activités sont déduites des changements consignés dans le journal d’audit du ticket Zendesk, qui suit les modifications de champs tels que le statut, le responsable et la priorité, ainsi que l’ajout de commentaires. L’analyse des activités est au cœur du Process Mining. Elle permet de visualiser la cartographie du processus, de repérer les goulots d’étranglement entre les étapes et d’analyser les boucles de reprise. En comprenant l’ordre et la fréquence des activités, les organisations peuvent repérer les inefficacités et les possibilités d’amélioration du processus. Pourquoi est-ce important ? Cet attribut définit les étapes du processus. Il permet de visualiser les cartographies de processus et d’analyser les flux, les variantes et la conformité du processus. Où trouver ces données Cet attribut est déduit des événements consignés dans l’API Zendesk Ticket Audits. Par exemple, le changement du champ « status » de « new » à « open » peut être associé à une activité telle que « Demande triée ». 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é a eu lieu.
Description L’horodatage de l’événement, ou heure de début, indique le moment exact où une activité a eu lieu. Il permet, par exemple, de savoir 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 indispensable à toute analyse temporelle. Il sert à classer les événements par ordre chronologique, à calculer le temps écoulé entre les activités, à mesurer les temps d’attente et à analyser le temps de cycle global du cas. Il est essentiel pour repérer les goulots d’étranglement et évaluer les résultats au regard d’objectifs temporels tels que les SLA. Pourquoi est-ce important ? Cet horodatage classe les événements par ordre chronologique et est indispensable à l’analyse des durées, des performances et des goulots d’étranglement. Où trouver ces données API Zendesk Ticket Audits, champ « created_at » de chaque événement d’audit. Exemples 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	ID de la demande de service ServiceRequestId	Identifiant unique de chaque ticket de demande de service dans Zendesk.
Description L’ID de la demande de service, souvent appelé ID de ticket dans Zendesk, sert de clé principale 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 suivre intégralement le parcours d’une demande. Dans l’analyse de Process Mining, cet attribut est fondamental. Il définit le cas et permet de reconstituer les flux de processus, de repérer les variantes et de calculer des métriques à l’échelle du cas, comme le temps de cycle. Chaque événement du jeu de données doit être associé à un ID de demande de service pour être replacé dans le contexte du processus global. Pourquoi est-ce important ? Cet identifiant essentiel relie tous les événements du parcours d’une demande de service et permet d’analyser le processus de bout en bout. Où trouver ces données API Zendesk Tickets, champ « id ». Exemples 102451024610247
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation des données depuis le système source.
Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis Zendesk Support. Il renseigne sur leur fraîcheur et permet de savoir si la vue du processus est à jour. Cette information est essentielle pour le suivi continu et les Dashboards. Elle permet aux analystes et aux utilisateurs métier de savoir 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 est-ce important ? Indique si les données sont à jour et permet de savoir à quel point l’analyse est récente. Où trouver ces données Champ de métadonnées généré et ajouté au jeu de données lors de l’extraction des données. Exemples 2023-10-27T08:00:00Z
	Système source SourceSystem	Indique le système dont les données ont été extraites.
Description Cet attribut précise l’origine des données de demande de service. Dans cette vue du processus, sa valeur est toujours « Zendesk Support », le système de référence pour toutes les activités de gestion des services. Dans un environnement où plusieurs systèmes sont intégrés, ce champ est essentiel pour retracer l’origine des données et résoudre les problèmes. Il garantit que les analyses portent sur le système prévu et aide à distinguer les données provenant de différentes sources lorsqu’elles sont regroupées. Pourquoi est-ce important ? Indique le système d’origine des données, ce qui permet d’en retracer la provenance et d’éviter toute confusion lorsque des données issues de plusieurs systèmes sont regroupées. Où trouver ces données 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 utilisé pour envoyer la demande de service, par exemple par e-mail, formulaire Web ou téléphone.
Description Cet attribut indique par quel canal la demande de service a été envoyée. Zendesk enregistre le mode de création du ticket : e-mail, portail Web, intégration API, chat ou autre canal. Il précise ainsi le mode d’interaction du client. Le canal de la demande est une dimension utile pour l’analyse. Il alimente le Dashboard sur l’efficacité des canaux de demande, qui permet de comparer les délais de résolution, les notes de satisfaction et les taux de reprise selon le canal. Ces comparaisons peuvent aider les entreprises à optimiser leurs canaux d’assistance et à orienter les utilisateurs vers les plus efficaces. Pourquoi est-ce important ? Permet d’analyser l’efficacité et les résultats des différents canaux d’assistance client et de cibler les améliorations. Où trouver ces données API Zendesk Tickets, objet « via » et propriété « channel ». Exemples WebE-mailAPIChat
	Équipe affectée AssignedTeam	Équipe ou groupe d’assistance chargé de la demande de service.
Description Cet attribut indique quelle équipe ou quel groupe de l’organisation d’assistance est chargé de la demande de service. Dans Zendesk, ces équipes 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 les performances et la charge de travail de chaque équipe. Elle permet de déterminer quels types de demandes sont traités par chaque équipe, quels sont leurs délais moyens de résolution et leur taux de respect des SLA. C’est une dimension principale du Dashboard sur les performances des agents et des équipes. Pourquoi est-ce important ? Permet d’analyser les performances des équipes, de répartir la charge de travail et d’évaluer l’efficacité de l’orientation entre les groupes d’assistance. Où trouver ces données API Zendesk Groups, en reliant le champ « group_id » de la réponse de l’API Tickets. Exemples Assistance de niveau 1Assistance techniqueFacturation
	Étiquettes du ticket TicketTags	Liste des étiquettes appliquées à la demande de service pour la catégoriser et l’orienter.
Description Les étiquettes sont des libellés flexibles que les agents peuvent ajouter manuellement aux tickets ou qui peuvent être appliqués automatiquement par des règles métier. Elles apportent un contexte ou une catégorie précise que les champs standard, comme le type ou la priorité, ne couvrent pas nécessairement. Les étiquettes sont très polyvalentes pour l’analyse de Process Mining. Elles permettent de filtrer des situations précises, de suivre des flux de travail personnalisés ou de repérer les causes profondes. Par exemple, l’étiquette « VIP » peut servir à analyser le processus pour les clients importants, tandis que « product_bug » peut aider à suivre le cycle de vie des signalements de défauts. Pourquoi est-ce important ? Permet de segmenter les données avec souplesse et d’analyser en détail des sous-processus ou des attributs de ticket spécifiques qui ne figurent pas dans les autres champs. Où trouver ces données API Zendesk Tickets, champ « tags ». Il s’agit d’un tableau de chaînes de caractères. Exemples demande_commercialeproblème_facturationdemande_fonctionnalitéclient_vip
	Nom de l’agent AgentName	Nom de l’agent responsable de la demande de service au moment de l’événement.
Description Cet attribut identifie l’agent d’assistance chargé de traiter la demande de service. L’agent affecté peut changer plusieurs fois au cours du cycle de vie du ticket ; ce champ indique qui en était responsable à chaque étape. Le nom de l’agent est essentiel à l’analyse des performances. Il permet de filtrer et de segmenter les données pour évaluer la répartition de la charge de travail, les délais de résolution par agent et la fréquence des réaffectations. Ces informations alimentent le Dashboard sur les performances des agents et des équipes et permettent de comprendre la contribution de chacun à l’efficacité globale du processus. Pourquoi est-ce important ? Cet attribut est essentiel pour analyser les performances des agents, la répartition de la charge de travail et l’incidence des réaffectations sur les délais de résolution. Où trouver ces données API Zendesk Users, en reliant le champ « assignee_id » de 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 indique son degré d’urgence. Elle détermine souvent les délais de résolution visés et les règles de SLA appliquées au ticket. Le système ou l’utilisateur peut définir la priorité initiale, puis un agent peut la modifier au cours du cycle de vie du ticket. Cet attribut est essentiel à la segmentation et à l’analyse des causes profondes. Il permet de vérifier si les tickets prioritaires sont résolus plus rapidement que les autres. Il joue également un rôle important dans les Dashboards « Tendances des escalades de demandes de service » et « Respect des SLA ». Pourquoi est-ce important ? Permet de segmenter les demandes selon leur degré d’urgence, ce qui est essentiel pour analyser le respect des SLA et veiller à ce que les problèmes critiques soient traités rapidement. Où trouver ces données API Zendesk Tickets, 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 nouvelle, ouverte ou en attente.
Description Le statut de la demande indique l’état du ticket à un moment donné. Zendesk propose plusieurs statuts standard, comme New, Open, Pending, On-hold, Solved et Closed, qui marquent la progression de la demande au fil de son cycle de vie. Les changements de ce champ déclenchent principalement la création d’activités dans le journal d’événements. L’analyse du temps passé dans chaque statut est au cœur de l’analyse des goulots d’étranglement. Elle permet de repérer les tickets qui restent bloqués, par exemple trop longtemps à l’état « Pending » ou « On-hold ». Comprendre les transitions entre les statuts est également essentiel pour repérer les boucles de reprise. Pourquoi est-ce important ? Le suivi du statut est essentiel pour comprendre l’avancement de la demande et déterminer le temps passé en attente ou en traitement. Où trouver ces données API Zendesk Tickets, champ « status ». Exemples NouveauOuvertEn attenteRésoluClôturé
	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. Zendesk utilise un champ « type » pour distinguer les différents types d’interactions avec l’assistance. Cette classification initiale permet d’orienter le ticket vers la bonne équipe et d’appliquer le processus approprié. Cet attribut est essentiel au 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. C’est une dimension importante du Dashboard sur les performances des agents et des équipes, qui permet de voir qui traite le mieux chaque type de demande. Pourquoi est-ce important ? Permet de catégoriser les demandes et d’analyser séparément les différents processus, par exemple les incidents et les questions, qui suivent des parcours distincts. Où trouver ces données API Zendesk Tickets, champ « type ». Exemples QuestionIncidentProblèmeTâche
	Dépassement du SLA IsSlaBreached	Indique si la demande de service a dépassé l’un de ses objectifs de SLA.
Description Cet attribut booléen ou catégoriel indique le résultat du SLA pour un ticket. Il peut prendre des valeurs telles que « Respecté », « Dépassé » ou « Actif ». Le résultat est déterminé en comparant les délais réels de réponse ou de résolution aux objectifs de la politique de SLA appliquée. Cet attribut est essentiel au Dashboard « Analyse du respect et des dépassements des SLA ». Il permet de compter et de représenter facilement les tickets conformes et non conformes. Vous pouvez ensuite examiner les caractéristiques des tickets ayant dépassé leur SLA pour en déterminer les causes, par exemple des temps d’attente prolongés ou des réaffectations trop nombreuses. Pourquoi est-ce important ? Mesure directement le respect des engagements de niveau de service, un indicateur important de la qualité du service et de la satisfaction client. Où trouver ces données Issu de l’API Zendesk Ticket Metrics, qui fournit des informations sur le statut du SLA de chaque ticket. Exemples RespectéDépasséActif
	Heure de fin EndTime	Date et heure précises auxquelles l’activité s’est 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 liées à un état, comme « Demande mise en attente », l’heure de fin correspond au moment où le ticket sort de cet état. Cet attribut est essentiel au calcul de la durée de chaque activité, nécessaire à l’analyse des goulots d’étranglement. En comparant l’heure de début et l’heure de fin d’une activité, vous pouvez mesurer directement sa durée de traitement et repérer les étapes qui prennent le plus de temps. Pourquoi est-ce important ? Permet de calculer la durée de chaque activité, ce qui est essentiel pour repérer les goulots d’étranglement et mesurer l’efficacité à chaque étape. Où trouver ces données Pour les événements ponctuels, cette valeur est souvent identique à StartTime. Pour les durées de statut, 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 personne à l’origine de la demande RequestorName	Nom de l’utilisateur final ou du client qui a envoyé la demande de service.
Description Cet attribut identifie la personne à l’origine de la demande de service. Associer la demande à un client précis permet d’analyser le processus d’assistance du point de vue de l’utilisateur. Dans l’analyse des processus, cet attribut permet d’étudier les tendances propres à certains clients ou segments de clientèle. Vous pouvez, par exemple, vérifier si certains clients connaissent des délais de résolution plus longs ou davantage de reprises, ce qui peut révéler des problèmes liés au produit ou au service qu’ils utilisent. Pourquoi est-ce 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ù trouver ces données API Zendesk Users, en reliant le champ « requester_id » de la réponse de l’API Tickets. Exemples Alice JohnsonBob WilliamsCharlie Brown
	Nom de la règle de SLA SlaPolicyName	Nom de la règle d’accord de niveau de service (SLA) appliquée à la demande.
Description Cet attribut identifie la politique de SLA qui définit les délais de réponse et de résolution visés pour la demande de service. La politique applicable dépend généralement de facteurs tels que la priorité et le type de la demande, ou le niveau d’abonnement du client. Connaître la politique de SLA appliquée est essentiel pour le Dashboard « Analyse du respect et des dépassements des SLA ». Elle fournit le contexte nécessaire à l’évaluation des performances, car les objectifs varient d’une politique à l’autre. Vous pouvez ainsi déterminer avec précision et équité si un ticket a atteint les objectifs de niveau de service qui lui étaient associés. Pourquoi est-ce important ? Cet attribut fournit le contexte nécessaire à l’analyse des SLA : il indique les objectifs auxquels la demande a été comparée et permet d’établir des rapports de conformité précis. Où trouver ces données API Zendesk Ticket Metrics. Les données de SLA sont souvent associées aux métriques du ticket. Exemples Urgent : réponse sous 1 heureStandard : résolution sous 24 heuresSLA client premium
	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 compte chaque modification du champ « assignee_id » d’un ticket. Un nombre élevé de réaffectations pour un même ticket peut révéler différents problèmes de processus : mauvaise affectation initiale, connaissances insuffisantes de l’agent ou demande trop complexe pour être traitée par une seule personne. Cette métrique permet de mesurer l’efficacité du processus et contribue directement au KPI « Taux de réaffectation à un agent ». L’analyse des demandes fréquemment réaffectées peut faire ressortir des pistes d’amélioration des règles d’acheminement, de la formation des agents ou des ressources de la base de connaissances, afin que les tickets parviennent plus rapidement à la bonne personne. Pourquoi est-ce important ? Cet attribut quantifie les transferts internes et met en évidence les difficultés du processus, car les réaffectations fréquentes entraînent souvent des retards et une perte d’efficacité. Où trouver ces données Calculé en comptant, pour chaque ticket, les modifications de « assignee_id » dans l’API Zendesk Ticket Audits. Exemples 013
	Note de satisfaction SatisfactionRating	Note de satisfaction attribuée par la personne à l’origine de la demande après la résolution du ticket.
Description Cet attribut recueille l’avis du client sur son expérience avec l’assistance, généralement au moyen d’une enquête envoyée après le passage du ticket au statut « solved ». Les réponses courantes sont « Bon » ou « Mauvais », parfois accompagnées d’un commentaire. La note de satisfaction est une mesure essentielle des résultats. La mise en relation des parcours de processus et des notes de satisfaction peut révéler quels comportements contribuent à la satisfaction ou à l’insatisfaction des clients. L’analyse peut, par exemple, montrer que les réaffectations fréquentes ou les longs délais de résolution sont étroitement liés à des notes de satisfaction négatives. Pourquoi est-ce important ? Relie directement le déroulement du processus aux résultats pour les clients et permet de repérer les pratiques qui contribuent à leur satisfaction. Où trouver ces données API Zendesk Tickets, champ « satisfaction_rating.score » ou « satisfaction_rating.reason ». Exemples BonMauvaisProposé
	Organisation de la personne à l’origine de la demande RequestorOrganization	Organisation ou entreprise à laquelle appartient la personne à l’origine de la demande.
Description Cet attribut relie la demande de service à une organisation cliente précise. Il est particulièrement pertinent dans les contextes B2B, où les accords de niveau de service et les contrats d’assistance sont souvent définis à l’échelle de l’organisation. L’analyse des données par organisation donne une vue des performances de l’assistance à l’échelle de l’entreprise. Elle peut aider à repérer les organisations qui génèrent un grand nombre de tickets, rencontrent des problèmes récurrents ou affichent de faibles notes de satisfaction. Ces informations sont utiles à la gestion des comptes et au suivi de la relation client. Pourquoi est-ce important ? Permet d’analyser les services B2B en regroupant les demandes par entreprise, ce qui est essentiel pour gérer les relations client et les SLA à l’échelle de l’organisation. Où trouver ces données API Zendesk Organizations, en reliant le champ « organization_id » de la réponse de l’API Tickets. Exemples Acme CorporationGlobal Tech Inc.Innovate Solutions
	Reprise IsRework	Indique si la demande de service a été rouverte après avoir été résolue.
Description Cet attribut booléen identifie les demandes qui ont nécessité des reprises. 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 signifie que la résolution initiale n’a pas suffi 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 reprises et des réouvertures ». En repérant ces demandes, les analystes peuvent isoler les flux de travail inefficaces, rechercher les causes des réouvertures et améliorer la résolution dès le premier contact. Pourquoi est-ce important ? Met en évidence les échecs du processus lorsque la résolution n’est pas définitive, et révèle des problèmes de qualité et d’efficacité qui nuisent directement à la satisfaction client. Où trouver ces données Calculé à partir de la séquence des statuts d’un ticket dans l’API Zendesk Ticket Audits. Le passage de « solved » à « open » indique une reprise. Exemples truefalse
	Résolution au premier contact IsFirstContactResolution	Indique si le premier agent affecté a résolu la demande, sans réaffectation ni réponse du demandeur.
Description La résolution au premier contact (FCR) indique qu’un problème client a été résolu en une seule interaction. Cet attribut calculé est un indicateur booléen qui prend la valeur vraie si le ticket a été résolu par le premier agent auquel il a été affecté, sans réaffectation et avec une seule réponse de l’agent. Cet attribut contribue directement au KPI « Taux de résolution au premier contact ». L’analyse des demandes résolues dès le premier contact peut servir de référence pour améliorer le processus. À l’inverse, l’étude des demandes qui n’atteignent pas cet objectif peut révéler des besoins en matière de formation des agents, d’amélioration des articles de la base de connaissances ou de tri initial plus efficace. Pourquoi est-ce important ? Mesure la capacité à résoudre un problème en une seule interaction, un facteur déterminant pour la satisfaction client et l’efficacité opérationnelle. Où trouver ces données Cet attribut calculé est complexe. Il faut analyser le journal d’événements du ticket pour vérifier les réaffectations à des agents et compter les réponses publiques des agents. Exemples truefalse

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir avec précision le processus de traitement des demandes de service.

7 Recommandé 6 Facultatif

	Activité	Description
	Demande affectée à un agent	Cette activité a lieu 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 » passe de null ou d’un identifiant de groupe à un identifiant d’agent.
Pourquoi est-ce important ? Cette étape marque le début du travail actif de l’agent. Elle est essentielle pour mesurer le délai de première réponse, le temps écoulé avant la première affectation et la répartition de la charge de travail entre les agents. Où trouver ces données Déduit du premier événement « Change » portant sur le champ « assignee_id » dans le journal d’audit du ticket, lorsqu’un identifiant d’utilisateur précis est défini. Données à recueillir Déduit du premier événement de modification qui affecte un agent au champ « assignee_id ». Type d’événement inferred
	Demande de service clôturée	Correspond à la clôture définitive de la demande de service. Après une période déterminée à l’état « solved », le ticket passe automatiquement à l’état « closed » et ne peut plus être rouvert.
Pourquoi est-ce important ? Cette activité marque la fin définitive du processus de demande de service. Elle constitue le point final pour calculer la durée totale du cas. Où trouver ces données Déduit d’un événement « Change » sur le champ « status » dans le journal d’audit du ticket, lorsque la nouvelle valeur est « closed ». Données à recueillir Déduit d’un événement « Change » dans le journal d’audit, lorsque le statut passe à « closed ». Type d’événement inferred
	Demande de service créée	Marque le début du parcours d’une demande de service, lorsqu’un demandeur soumet un nouveau ticket par l’un des canaux disponibles. Cet événement est enregistré sous le type « Create » dans le journal d’audit du ticket Zendesk et fournit une heure de début précise pour le processus.
Pourquoi est-ce important ? Cette activité constitue l’événement de début de chaque demande de service. Elle est donc essentielle pour calculer les temps de cycle de bout en bout et analyser le volume de demandes reçues. Où trouver ces données Cet événement est enregistré sous le type « Create » dans le journal d’audit du ticket Zendesk. Son horodatage correspond à l’heure de création du ticket de demande de service. Données à recueillir Récupéré 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 apporté une solution et fait passer le statut du ticket à « solved ». Du point de vue de l’agent, la demande est terminée, mais la personne à l’origine de celle-ci peut encore la rouvrir.
Pourquoi est-ce important ? Cette étape importante marque la fin du travail actif de l’agent. Le temps nécessaire pour l’atteindre est une mesure essentielle de l’efficacité de la résolution. Où trouver ces données Déduit d’un événement « Change » sur le champ « status » dans le journal d’audit du ticket, lorsque la nouvelle valeur est « solved ». Données à recueillir Déduit d’un événement « Change » dans le journal d’audit, lorsque le statut passe à « solved ». Type d’événement inferred
	Demande de service rouverte	Cette activité se produit lorsque la personne à l’origine de la demande répond alors que celle-ci est à l’état « solved », ce qui fait automatiquement repasser son statut à « open ». Cela indique que la solution proposée n’était pas suffisante.
Pourquoi est-ce important ? Cette activité est le principal indicateur de reprises. Sa fréquence permet d’évaluer la qualité des résolutions et de repérer les causes d’insatisfaction des clients. Où trouver ces données 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 valeur est « open ». Données à recueillir Déduit d’un changement de statut de « solved » à « open ». Type d’événement inferred
	Objectif de SLA non respecté	Cette activité marque le moment où une demande de service ne respecte pas un objectif de SLA défini, par exemple le délai de première réponse ou le délai de résolution. Zendesk enregistre un événement explicite lorsque l’objectif n’est pas atteint.
Pourquoi est-ce important ? Cet événement est essentiel au suivi de la conformité et entre dans le calcul du KPI de taux de respect des SLA. Il indique précisément les engagements de service qui n’ont pas été tenus. Où trouver ces données Extrait de l’événement « SLABreach » dans les événements du ticket Zendesk ou dans son journal d’audit. L’événement précise la métrique de SLA qui n’a pas été respectée. Données à recueillir Repéré grâce à l’événement explicite « SLABreach » dans les données du ticket. Type d’événement explicit
	Réponse publique envoyée	Cette activité correspond à tout message envoyé par un agent à la personne à l’origine de la demande. 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 est-ce important ? Ces événements sont essentiels pour analyser la fréquence des échanges, mesurer les délais de réponse des agents et déterminer le nombre d’interactions nécessaires à la résolution. Où trouver ces données 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. Données à recueillir Extrait des événements « Comment » du ticket lorsque l’indicateur « public » est défini sur true. Type d’événement explicit
	Agent réaffecté	Correspond au 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 sur le champ « assignee_id », après la première affectation.
Pourquoi est-ce important ? Le suivi des réaffectations est essentiel au calcul du KPI de taux de réaffectation des agents. Il permet de repérer les inefficacités du processus, les erreurs d’orientation ou les lacunes de connaissances. Où trouver ces données Déduit des événements « Change » portant sur le champ « assignee_id » dans le journal d’audit du ticket, à l’exception de la toute première affectation. Données à recueillir Déduit du deuxième événement « Change » et des suivants portant sur le champ « assignee_id ». Type d’événement inferred
	Demande mise en attente	Cette activité se produit lorsque le statut de la demande de service passe à « on-hold ». Cela signifie généralement que l’agent attend des informations de la personne à l’origine de la demande ou d’un tiers. L’activité est déduite d’un changement de statut.
Pourquoi est-ce important ? Cela permet d’isoler et de mesurer les temps d’attente qui échappent au contrôle direct de l’équipe d’assistance, afin d’évaluer plus précisément le temps de traitement par les agents. Où trouver ces données 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 ». Données à recueillir Déduit d’un événement « Change » dans le journal d’audit, lorsque le statut passe à « on-hold ». Type d’événement inferred
	Demande transmise à un niveau supérieur	Correspond au transfert officiel d’une demande de service vers un niveau d’assistance supérieur, une autre équipe ou la direction. L’événement est généralement déduit d’un changement du groupe auquel le ticket est affecté ou d’une modification d’un champ personnalisé servant à suivre les escalades.
Pourquoi est-ce important ? Le suivi des escalades permet de repérer les demandes complexes, les besoins de formation des agents de première ligne et les problèmes systémiques qui nécessitent une intervention à un niveau supérieur. Où trouver ces données 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 chargé des escalades, ou d’une modification d’un champ personnalisé du ticket utilisé pour les suivre. Données à recueillir Déduit d’un changement de « group_id » ou d’un champ personnalisé « escalation ». Type d’événement inferred
	Note interne ajoutée	Un agent a ajouté une note ou un commentaire interne à la demande de service. Seuls les autres agents peuvent le voir. L’ajout est enregistré comme un événement « Comment » lorsque l’attribut « public » est défini sur false.
Pourquoi est-ce important ? Le suivi des notes internes permet de mieux comprendre la collaboration entre agents ou équipes, qui peut être une source de retard ou contribuer à résoudre les problèmes efficacement. Où trouver ces données 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 », qui indique qu’il s’agit d’une note interne. Données à recueillir Extrait des événements « Comment » du ticket lorsque l’indicateur « public » est défini sur false. Type d’événement explicit
	Objectif SLA appliqué	Indique le moment où une politique d’accord de niveau de service (SLA) est appliquée au ticket de demande de service. L’événement est explicitement enregistré lorsque les propriétés du ticket correspondent aux conditions d’une politique SLA active.
Pourquoi est-ce important ? Le suivi de l’application d’un SLA est essentiel pour surveiller la conformité, analyser les manquements éventuels et comprendre les délais de service prévus pour les différents types de demandes. Où trouver ces données Récupéré à partir de l’événement « SLAPolicyApplied » dans les événements du ticket Zendesk ou dans son journal d’audit. Cet événement indique la politique correspondante. Données à recueillir Repéré grâce à l’événement explicite « SLAPolicyApplied » dans les données du ticket. 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é. Cette modification est enregistrée sous la forme d’un événement « Change » portant sur le champ « priority » dans le journal d’audit du ticket.
Pourquoi est-ce important ? L’analyse des changements de priorité permet de repérer les demandes dont l’urgence augmente au fil du temps et d’évaluer si leur priorisation est bien gérée. Où trouver ces données Enregistré comme événement « Change » sur le champ « priority » dans le journal d’audit du ticket Zendesk, avec les valeurs précédente et nouvelle. Données à recueillir 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 : Dans la barre supérieure, ouvrez l’icône des produits Zendesk, puis sélectionnez Explore. Dans Explore, cliquez sur l’icône Queries à gauche, puis sur New query. 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. Dans la section Rows, ajoutez les attributs suivants : Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Group name, 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 compréhensibles, créez un attribut calculé standard. Ouvrez le menu Calculations (icône de calculatrice), sélectionnez Standard calculated attribute et nommez l’attribut ActivityName. Collez dans le champ de formule la logique fournie dans la section Query. Cette formule associe les différents événements de mise à jour des tickets aux noms d’activité requis.
Affinez et filtrez le rapport principal : Ajoutez le nouvel attribut ActivityName à la section Rows. Créez un filtre sur cet attribut pour exclure les valeurs (null) et les valeurs système indésirables, afin de nettoyer le jeu de données. Ajoutez également un filtre sur Ticket created - Date pour limiter la requête à une période raisonnable, par exemple les six derniers mois.
Créez un deuxième rapport pour les événements de SLA : Créez une nouvelle requête et sélectionnez cette fois le jeu de données Support : SLAs. Cette étape est nécessaire, car les événements de SLA ne figurent pas dans le jeu de données Ticket updates.
Configurez le rapport sur les SLA : Dans la requête sur les SLA, ajoutez COUNT(SLA tickets) à Metrics. Dans la section Rows, ajoutez Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status et Updater name. L’activité sera déduite du SLA status lors de la 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 Export et choisissez le format CSV. Vous obtiendrez deux fichiers CSV distincts.
Fusionnez et transformez les données : Combinez les deux fichiers CSV à l’aide d’un tableur comme Microsoft Excel ou d’un langage de script comme Python. L’objectif est de créer un journal d’événements unique. Pour le fichier sur les SLA, créez la colonne ActivityName. Si SLA status est Active, l’activité est SLA Target Applied. Si SLA status est Breached, l’activité est SLA Target Breached. Utilisez SLA updated - Timestamp comme valeur de EventTimestamp.
Uniformisez les en-têtes de colonnes : Dans le fichier fusionné final, 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 colonnes à votre fichier CSV final. Dans SourceSystem, indiquez « Zendesk ». Dans LastDataUpdate, indiquez la date et l’heure de l’exportation. Le fichier est alors prêt à être importé.

Configuration

Offre Zendesk : Vous devez disposer d’une offre Zendesk Support comprenant Zendesk Explore Professional ou Enterprise 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 deux rapports distincts, fondés sur deux jeux de données : Support : Ticket updates pour les événements généraux et Support : SLAs pour les événements propres aux SLA.
Filtre sur la période : Il est essentiel d’appliquer un filtre de dates, par exemple sur Ticket created - Date, afin de limiter le volume de données. Pour une première analyse, une période de trois à six mois est recommandée.
Attributs calculés : La logique de création des noms d’activité repose sur un attribut calculé personnalisé complexe dans Explore. Vérifiez que la formule est correctement créée pour éviter les erreurs dans les résultats.
Volume de données : L’interface Zendesk Explore et sa fonction d’exportation peuvent être lentes ou expirer lorsque les jeux de données sont très volumineux. Pour les extractions portant sur plus d’un an de données ou des millions de tickets, envisagez de répartir l’exportation en périodes plus courtes.

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 devez également disposer d’un accès administrateur à votre instance Zendesk Support pour générer un jeton d’API.
Installez les bibliothèques Python : Ouvrez votre terminal ou votre invite de commandes, puis installez les bibliothèques Python nécessaires avec pip. La bibliothèque requests sert à effectuer les appels d’API et pandas à manipuler les données et à les exporter au format CSV.
```
pip install requests pandas
```
Générez un jeton d’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 », et copiez le jeton généré. Vous ne pourrez plus l’afficher par la suite.
Configurez le script Python : Ouvrez le script Python fourni dans un éditeur de texte. Renseignez les variables de configuration en haut du fichier : ZENDESK_SUBDOMAIN (le nom de domaine Zendesk de votre entreprise), ZENDESK_EMAIL (l’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.
Comprenez le fonctionnement du script : Le script commence par récupérer la liste des tickets mis à jour pendant la période définie, à l’aide de l’API Incremental Tickets, qui est conçue pour limiter les appels inutiles. Pour chaque ticket, il récupère ensuite l’historique complet des modifications, les commentaires et les métriques de SLA. Il traite ces événements par ordre chronologique pour reconstituer l’historique détaillé.
Associez 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 » portant sur le champ « status » est associé à des activités telles que « Demande de service résolue » ou « Demande mise en attente ». Les événements de commentaire sont examinés pour déterminer s’il s’agit d’une « Réponse publique envoyée » ou d’une « Note interne ajoutée ».
Exécutez le script d’extraction : Depuis votre terminal, lancez le script avec la commande python your_script_name.py. Il affiche l’avancement 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, l’opération peut prendre un certain temps.
Vérifiez le fichier de sortie : Une fois l’exécution terminée, un fichier CSV nommé zendesk_event_log.csv est créé dans le même répertoire. Il contient le journal d’événements extrait, avec toutes les activités et tous les attributs indiqués.
Préparez l’importation : Ouvrez le fichier CSV pour vérifier son format. Les en-têtes de colonnes doivent correspondre aux attributs requis : ServiceRequestId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, entre autres. Le fichier est alors prêt à être importé dans ProcessMind.

Configuration

Accès à l’API Zendesk : Le script nécessite un jeton d’API actif associé à un administrateur ou à un agent disposant des autorisations suffisantes. L’adresse e-mail configurée dans le script doit être celle de la personne qui a créé le jeton d’API.
Paramètres du script : Avant l’exécution, configurez les variables suivantes dans le script : ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN et START_TIME_STR. La valeur de START_TIME_STR doit respecter le format « YYYY-MM-DD ».
Période : Pour commencer, nous recommandons d’extraire les données des trois à six derniers mois (START_TIME_STR). Vous obtiendrez ainsi un jeu de données représentatif sans allonger excessivement l’exécution ni atteindre trop souvent les limites de l’API. Une période plus longue augmentera considérablement la durée de l’extraction.
API Incremental Exports : Le script utilise le point de terminaison Incremental Exports (/api/v2/incremental/tickets/cursor.json) pour récupérer efficacement les tickets mis à jour depuis la dernière exécution ou depuis une date de début spécifiée. Cette méthode est bien plus performante que l’analyse de tous les tickets.
Limitation du débit : Zendesk impose des limites de débit à son API. Le script prévoit une pause élémentaire en cas d’atteinte de ces limites, mais l’extraction peut prendre beaucoup de temps sur les instances très volumineuses. Il est préférable de l’exécuter en dehors des heures de pointe.
Règle d’escalade : L’activité « Demande escaladée » est déduite d’une modification du champ group_id. Si votre organisation utilise un autre mécanisme, comme un champ de ticket personnalisé, vous devrez modifier la logique du script pour repérer correctement les escalades.

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 de l’intégralité du compte, à l’aide de la fonction d’exportation disponible avec votre abonnement et votre compte Zendesk. Le chemin d’accès aux menus et les autorisations requises varient selon la configuration du compte. Utilisez l’option d’exportation proposée dans Admin Center et suivez la procédure d’approbation de votre organisation.
Sélectionnez une période couvrant l’analyse souhaitée, de préférence trois à six mois. Si l’exportation native ne permet pas de filtrer les dates, téléchargez l’exportation complète du compte et appliquez le filtre de dates lors de la transformation.
Téléchargez et conservez tous les fichiers JSON générés par l’exportation. Gardez les fichiers d’origine, l’horodatage de l’exportation, l’identifiant du compte ainsi que tout fichier manifeste ou de métadonnées. Ne remplacez pas les fichiers source pendant le traitement.
Analysez les enregistrements de tickets, les historiques de modifications, les événements d’audit, les commentaires, les utilisateurs, les organisations, les groupes, les enregistrements liés aux SLA et les champs personnalisés inclus dans l’exportation. Les noms de fichiers et la structure JSON pouvant varier selon la version de l’exportation Zendesk, configurez les chemins d’accès aux sources et les associations de propriétés JSON dans les paramètres du script avant son exécution.
Normalisez chaque événement d’audit de ticket dans une structure commune comprenant 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’acteur, l’indicateur public, le statut du ticket, l’agent affecté, le groupe, la priorité, le canal, le type de service, les étiquettes, le système source et LastDataUpdate.
Créez une ligne du journal d’événements pour chaque activité admissible. L’extraction doit créer explicitement des lignes pour les activités suivantes : Demande de service créée, Objectif de SLA appliqué, Demande affectée à un agent, Priorité modifiée, Agent réaffecté, Réponse publique envoyée, Note interne ajoutée, Demande mise en attente, Demande escaladée, Objectif de SLA dépassé, Demande de service rouverte, Demande de service résolue et Demande de service clôturée. ProcessMind lit ces lignes telles quelles et ne déduit pas d’autres événements.
Associez, lorsque les données le permettent, les identifiants des agents, des groupes, des organisations et des demandeurs aux enregistrements correspondants des utilisateurs, groupes et organisations exportés. Renseignez AgentName et AssignedTeam en fonction de l’affectation au moment de l’événement. Si le nom d’affichage ne peut pas être déterminé, conservez l’identifiant ou laissez la valeur vide.
Appliquez des règles d’événement déterministes. Utilisez l’événement d’audit Create du ticket pour Demande de service créée, les événements d’audit explicites de SLA pour Objectif de SLA appliqué et Objectif de SLA dépassé, le premier changement d’agent admissible pour Demande affectée à un agent, les changements suivants pour Agent réaffecté, les indicateurs de commentaire public ou privé pour les réponses et les notes, les changements de statut pour les mises en attente, réouvertures, résolutions et clôtures, et les changements de groupe ou du champ d’escalade configuré pour Demande escaladée.
Triez les lignes obtenues par ServiceRequestId et EventTimestamp, en utilisant l’ordre stable des événements source pour départager les horodatages identiques. Ne supprimez pas des événements au seul motif qu’ils ont le même horodatage : plusieurs commentaires ou événements d’audit peuvent survenir au même moment.
Vérifiez la présence de toutes les colonnes requises et assurez-vous que chaque activité comporte au moins une ligne admissible lorsque les données source 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 de l’intégralité du compte Zendesk Support et conservez tous les fichiers JSON générés. L’export doit inclure les données des tickets ainsi que les données d’audit ou d’événements des tickets. 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 l’extraction et la validation initiales, privilégiez une période de trois à six mois. Si l’export natif couvre l’ensemble du compte et ne peut pas être limité à une période, filtrez EventTimestamp après l’analyse des données, tout en conservant l’archive source complète.
Règles relatives aux activités : configurez des associations 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 d’événements ou les propriétés réellement exportés et utilisés par le compte pour l’application des objectifs de SLA et les événements de dépassement. Si l’export ne contient pas d’événements de SLA explicites, n’en créez pas. Configurez les chemins sources correspondants dans les espaces réservés et documentez toute activité indisponible.
Configuration de l’escalade : identifiez le champ de groupe propre au compte, ou le champ personnalisé, qui représente l’escalade. Avant l’exécution, définissez ESCALATION_FIELD_ID ou le paramètre équivalent sur l’identifiant réel du champ exporté.
Chemins sources : définissez dans le script les chemins des fichiers JSON et les associations avec les propriétés JSON. Les noms des fichiers d’export Zendesk et leur structure imbriquée peuvent varier selon la version de l’export et la configuration du compte.
Champs de sortie obligatoires : 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 reposant sur des noms de champs non pris en charge ou non vérifiés.
Performances : traitez les fichiers JSON de manière incrémentielle dans la mesure du possible, évitez de charger l’export complet du compte en mémoire, indexez les identifiants des tickets et des 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 permettant de demander ou de 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 pour l’export complet et environnement capable d’analyser du JSON et de créer des fichiers CSV en 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 l’organisation en matière de conservation, de contrôle des accès et de protection de la vie privée.

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 repérer les goulots d’étranglement et gagner en 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 retards dès maintenant.

Mettez fin aux délais de traitement et à la frustration des utilisateurs. Atteignez 70 % d’automatisation.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration 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 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

Exemple de requête config

Extraction de Zendesk via l’API REST avec un script Python

Étapes

Configuration

Exemple de requête python

Export JSON natif de l’intégralité du compte Zendesk Support

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

Optimisez la gestion des demandes de service. Réduisez les retards 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 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

Exemple de requête config

Extraction de Zendesk via l’API REST avec un script Python

Étapes

Configuration

Exemple de requête python

Export JSON natif de l’intégralité du compte Zendesk Support

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

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

Prêt à commencer ?