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

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

Zendesk Support

Attributs de gestion des incidents(23) Activités de gestion des incidents(13) Guides d’extraction(4)

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

Ce modèle présente les données essentielles à réunir pour analyser efficacement votre processus de gestion des incidents. Il répertorie les principaux attributs à collecter et les activités importantes à suivre, et vous guide dans l’extraction de ces données depuis Zendesk Support. Utilisez-le pour démarrer votre projet de Process Mining avec un jeu de données complet et fiable.

Attributs recommandés à collecter
Activités clés à suivre pour cartographier le processus
Conseils pratiques pour extraire les données

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 incidents

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus de gestion des incidents.

5 Obligatoire 7 Recommandé 11 Facultatif

	Nom	Description
	Horodatage de l’événement EventTimestamp	Date et heure exactes auxquelles l’activité a eu lieu.
Description Cet horodatage indique le moment précis où un événement s’est produit dans le cycle de vie de l’incident, par exemple l’ajout d’un commentaire ou la modification du statut. Il établit l’ordre chronologique des activités de chaque dossier. Cet attribut est indispensable à toute analyse du processus fondée sur le temps. Il sert à calculer les temps de cycle entre les activités, à repérer les temps d’attente, à mesurer la durée totale des dossiers et à étudier les performances du processus sur différentes périodes. Des horodatages précis sont nécessaires pour créer une carte animée montrant l’évolution des dossiers dans le temps et pour élaborer des Dashboards de performance qui suivent des indicateurs clés, comme le délai moyen de résolution. Pourquoi est-ce important ? Les horodatages situent les activités dans le temps. Ils permettent de calculer les durées, de repérer les goulots d’étranglement et d’analyser l’évolution des performances du processus. Où trouver ces données API Zendesk Ticket Audits (/api/v2/tickets/{ticket_id}/audits), champ created_at pour chaque événement d’audit. Exemples 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Identifiant de l’incident TicketId	Identifiant unique généré par le système pour chaque ticket d’incident.
Description L’identifiant de l’incident est la clé primaire qui distingue chaque dossier d’incident dans Zendesk Support. Il sert de CaseId pour le Process Mining et relie toutes les activités, les modifications de statut et les communications associées, de la création de l’incident à sa clôture. Cet identifiant est essentiel pour reconstituer le parcours complet de chaque incident. Il permet de regrouper les données d’événements afin de suivre, pour chaque dossier, des indicateurs tels que le délai total de résolution, le nombre de transferts et le respect des accords de niveau de service. En regroupant les événements par identifiant, les analystes peuvent représenter les flux de processus, repérer les parcours fréquents et détecter les écarts par rapport à la procédure standard. Pourquoi est-ce important ? Cet identifiant essentiel relie tous les événements à un même incident. Il permet d’en retracer tout le cycle de vie et d’analyser précisément les performances du processus. Où trouver ces données API Zendesk Tickets (/api/v2/tickets/{id}), champ id. Exemples 19428230113521941055
	Activité ActivityName	Nom de l’activité métier ou de l’événement survenu à un moment précis du cycle de vie de l’incident.
Description Cet attribut décrit une étape ou une action précise du processus de gestion des incidents, par exemple « Incident créé », « Ticket affecté à un agent » ou « Incident résolu ». Ces activités sont déduites du journal d’événements ou des données de piste d’audit de Zendesk, qui consignent les modifications apportées au système. Dans le Process Mining, la séquence de ces activités forme la carte du processus, base de toute analyse. L’étude de leur enchaînement permet aux organisations de découvrir les parcours réellement suivis par les incidents, de repérer les goulots d’étranglement entre les étapes, de mesurer les boucles de reprise, par exemple lorsqu’un ticket résolu est rouvert, et de vérifier la conformité à un processus standard défini. Pourquoi est-ce important ? La séquence des activités définit le flux du processus, au cœur de l’analyse par Process Mining pour repérer les inefficacités, les écarts et les possibilités d’amélioration. Où trouver ces données Déduit des événements de l’API Zendesk Ticket Audits. Par exemple, un événement Change concernant le champ de statut peut être associé à « Statut modifié ». Exemples Incident crééTicket affecté à un agentStatut passé à en attenteIncident résoluIncident clôturé
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la date de la dernière actualisation des données de ce processus.
Description Cet attribut indique la date et l’heure de la dernière extraction ou mise à jour des données depuis le système source. Il s’agit généralement d’une valeur unique appliquée à l’ensemble du jeu de données lors de chaque actualisation. Cette information est essentielle à la gouvernance des données et aux utilisateurs de l’analyse par Process Mining. Elle précise l’actualité des données et aide les analystes à savoir s’ils consultent les informations les plus récentes. C’est particulièrement important pour suivre les performances opérationnelles et prendre des décisions en temps utile à partir de l’analyse. Pourquoi est-ce important ? Précise l’actualité des données afin que les utilisateurs sachent à quelle date elles ont été extraites et dans quelle mesure l’analyse est à jour. Où trouver ces données Horodatage généré par le processus ETL ou le pipeline de données à la fin de l’actualisation. Exemples 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Système source SourceSystem	Système d’où proviennent les données d’incidents extraites.
Description Cet attribut indique l’origine des données du processus. Dans cette vue, sa valeur serait fixe, par exemple « Zendesk Support », pour indiquer que tous les événements et attributs proviennent de ce système. Lorsque des données issues de plusieurs systèmes sont regroupées, ce champ permet de distinguer les différentes sources. Il contribue à l’intégrité des données et permet des analyses par source, par exemple pour comparer le processus de gestion des incidents dans Zendesk à celui d’un autre outil ITSM. Pourquoi est-ce important ? Indique l’origine des données, ce qui est essentiel à leur gouvernance et aux analyses qui regroupent des données de plusieurs systèmes sources. Où trouver ces données Valeur fixe définie lors de la transformation des données pour en indiquer l’origine. Exemples Zendesk SupportZendesk
	Agent affecté Assignee	L’agent d’assistance actuellement chargé de traiter l’incident.
Description Cet attribut identifie l’agent chargé de l’incident à un moment donné. Un changement d’agent constitue un événement important, car il marque le transfert du travail d’une personne à une autre. L’analyse des agents affectés permet de comprendre la répartition de la charge de travail, les performances individuelles et les modes de collaboration. Il est essentiel de suivre les changements de ce champ pour calculer l’indicateur « Nombre moyen de transferts par incident » et repérer les incidents fréquemment réattribués, ce qui peut révéler des lacunes dans les connaissances ou une affectation inefficace. Pourquoi est-ce important ? Identifie l’agent responsable et permet d’analyser la charge de travail et de suivre les transferts, afin de repérer les inefficacités du processus. Où trouver ces données API Zendesk Tickets, champ assignee_id. Les changements sont consignés dans l’API Ticket Audits. Exemples John SmithJane DoeAutomatisation du centre de services
	Canal de signalement Channel	Canal utilisé pour signaler l’incident initialement, par exemple « E-mail », « Web » ou « API ».
Description Cet attribut indique comment l’utilisateur final ou le système a créé le ticket d’incident. Connaître le canal permet d’analyser l’origine des incidents et d’adapter le processus d’assistance en conséquence. L’analyse des incidents par canal peut faire apparaître des différences de parcours. Par exemple, les incidents signalés par téléphone peuvent être résolus plus rapidement que ceux reçus par e-mail. Ces informations alimentent le Dashboard « Volume de traitement des incidents » et contribuent à la planification des ressources et à l’optimisation des canaux. Pourquoi est-ce important ? Permet d’analyser le volume d’incidents et les performances du processus selon leur origine, afin d’améliorer les processus propres à chaque canal et de répartir les ressources. Où trouver ces données API Zendesk Tickets, champ via.channel. Exemples webe-mailapitéléphone
	Groupe affecté AssignedGroup	L’équipe ou le groupe d’assistance actuellement chargé de l’incident.
Description Cet attribut indique quelle équipe est responsable de l’incident. Les incidents passent souvent d’un niveau d’assistance à un autre ou entre des groupes spécialisés, par exemple de « Assistance de niveau 1 » à « Équipe réseau ». Il s’agit d’une dimension importante pour analyser les transferts entre équipes et repérer les goulots d’étranglement. En suivant le parcours des incidents entre les groupes, les analystes peuvent mesurer les dépendances entre équipes, calculer les temps d’attente dans les files de chaque équipe et optimiser les règles d’affectation. Cet attribut alimente directement le Dashboard « Analyse des transferts et des reprises ». Pourquoi est-ce important ? Suit l’équipe responsable, ce qui permet d’analyser les transferts entre équipes, de repérer les goulots d’étranglement propres à chaque équipe et de mesurer les temps d’attente. Où trouver ces données API Zendesk Tickets, champ group_id. Les changements sont consignés dans l’API Ticket Audits. Exemples Assistance de niveau 1Équipe réseau de niveau 2Infrastructure de niveau 3Facturation
	Heure de fin de l’événement EventEndTime	Horodatage indiquant la fin d’une activité.
Description L’heure de fin de l’événement marque la fin d’une activité. Dans les données du journal d’événements, l’heure de fin d’une activité est souvent déduite de l’heure de début de l’activité suivante dans le même cas. Pour la dernière activité d’un cas, l’heure de fin peut être identique à l’heure de début. Cet attribut est essentiel pour calculer la durée des activités individuelles (ProcessingTime) et les temps d’attente entre les activités. Ces informations sont à la base de l’analyse des goulots d’étranglement : elles permettent de voir non seulement combien de temps dure une étape, mais aussi combien de temps le cas est resté inactif avant son démarrage. Pourquoi est-ce important ? Permet de calculer la durée des activités et les temps d’attente, indispensables à l’analyse détaillée des goulots d’étranglement et des retards du processus. Où trouver ces données Calculée à partir de l’heure de début de l’événement suivant dans le même cas. L’heure de fin du dernier événement peut correspondre à son heure de début ou à l’heure de clôture du cas. Exemples 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Priorité TicketPriority	Niveau de priorité attribué à l’incident, par exemple « Faible », « Normale », « Élevée » ou « Urgente ».
Description La priorité d’un incident détermine le degré d’urgence de la réponse et de la résolution. Elle joue un rôle important dans la hiérarchisation du travail et l’affectation des ressources au sein de l’équipe d’assistance. Dans l’analyse des processus, la priorité sert à segmenter les incidents afin de comparer leurs parcours et leurs performances. Les analystes peuvent, par exemple, vérifier si les incidents « Urgents » sont effectivement résolus plus rapidement que ceux de priorité « Faible ». Elle permet aussi de suivre le respect des SLA, souvent définis selon le niveau de priorité. L’indicateur « Taux de changement de priorité » repose sur le suivi des modifications de ce champ. Pourquoi est-ce important ? Cet attribut est essentiel pour segmenter les analyses, évaluer l’efficacité de la hiérarchisation et suivre le respect des SLA selon le degré d’urgence. Où trouver ces données API Zendesk Tickets, champ priority. Les changements sont consignés dans l’API Ticket Audits. Exemples faiblenormaleélevéeurgente
	Statut du SLA SlaStatus	Statut actuel du contrat de niveau de service (SLA) associé à l’incident.
Description Cet attribut indique si l’incident respecte les objectifs du SLA, si ceux-ci ont déjà été dépassés ou si les délais du SLA sont suspendus. Zendesk suit automatiquement les métriques du SLA en fonction des politiques configurées. Cet attribut est essentiel au Dashboard « Suivi du respect des SLA ». Il mesure directement les performances au regard des engagements de service. L’analyse des dépassements de SLA et de leurs causes permet aux organisations de repérer les faiblesses du processus et d’améliorer la fiabilité du service. Cet attribut alimente directement l’indicateur « Taux de respect des SLA pour les incidents ». Pourquoi est-ce important ? Mesure directement le respect des engagements de service et permet d’analyser les dépassements de SLA et de suivre la conformité de manière préventive. Où trouver ces données API Zendesk Ticket Metrics (/api/v2/ticket_metrics.json), calculé à partir de champs tels que sla_policy, breached_at, etc. Exemples ActifEn pauseDépasséRespecté
	Statut du ticket TicketStatus	Statut du ticket d’incident au moment de l’événement, par exemple « Ouvert », « En attente » ou « Résolu ».
Description Cet attribut indique l’état du ticket d’incident à différents moments de son cycle de vie. Les statuts Zendesk standard comprennent new, open, pending, on-hold, solved et closed. Le suivi des modifications de ce champ est l’un des principaux moyens de générer des activités pour le Process Mining. L’analyse du statut du ticket est essentielle pour comprendre le processus. Elle permet de mesurer le temps passé par les incidents dans certains états, comme 'Pending', qui indique souvent une attente de réponse du client. Elle sert également à définir la fin du dossier et à calculer les délais de résolution. Pourquoi est-ce important ? Le suivi des changements de statut permet de comprendre l’avancement du processus, de repérer les temps d’attente et de définir le début et la fin du cycle de vie d’un incident. Où trouver ces données API Zendesk Tickets, champ status. Les changements sont consignés dans l’API Ticket Audits. Exemples nouveauouverten attenterésolufermé
	Auteur du signalement Submitter	L’utilisateur final ou le système à l’origine du signalement de l’incident.
Description Cet attribut identifie la personne ou l’entité qui a créé le ticket. Il ne s’agit pas nécessairement du demandeur : un agent peut créer un ticket au nom d’une autre personne. L’analyse de l’auteur du signalement permet de comprendre qui signale les problèmes. Associée aux données sur les organisations, elle peut aider à repérer les clients ou les groupes d’utilisateurs confrontés à un volume élevé d’incidents. Ces constats peuvent orienter les actions d’assistance préventive ou de formation. Pourquoi est-ce important ? Identifie l’origine du signalement de l’incident et permet de repérer des tendances liées à certains utilisateurs, services ou systèmes automatisés. Où trouver ces données API Zendesk Tickets, champ submitter_id. Exemples alice.jones@example.combob.williams@example.comSurveillance système
	Automatisé IsAutomated	Indicateur booléen précisant si une activité a été effectuée par un système automatisé ou par un agent humain.
Description Cet attribut calculé permet de distinguer les événements déclenchés par des utilisateurs de ceux exécutés par des automatisations système, des déclencheurs ou des intégrations API. Il est généralement déterminé en vérifiant si l’auteur de l’événement est un utilisateur système connu. Comprendre le degré d’automatisation est essentiel à l’analyse des processus actuels. Cela permet d’évaluer l’efficacité des règles d’automatisation, de repérer les tâches manuelles qui pourraient être automatisées et de mesurer l’effet de l’automatisation sur l’efficacité et les délais de résolution. Cet attribut permet de comparer les parcours des activités automatisées à ceux des activités manuelles. Pourquoi est-ce important ? Distingue les actions humaines des actions système, ce qui permet d’analyser l’effet de l’automatisation sur l’efficacité du processus et de repérer de nouvelles possibilités d’automatisation. Où trouver ces données Déterminé en vérifiant si l’auteur de l’événement (author_id dans l’API Ticket Audits) correspond à un utilisateur système ou d’automatisation connu. Exemples truefalse
	Catégorie de la cause racine RootCauseCategory	Catégorie générale de la cause profonde de l’incident.
Description Cet attribut sert à classer la cause fondamentale d’un incident. Il est généralement renseigné vers la fin du cycle de vie de l’incident, souvent dans le cadre d’une analyse après incident ou d’un processus de Gestion des problèmes, puis enregistré dans un champ personnalisé. Ces données sont essentielles au Dashboard « Précision de l’identification des causes racines » et à l’indicateur « Couverture de l’analyse des causes racines ». L’analyse des incidents par cause racine aide à repérer les problèmes récurrents et à orienter les efforts vers des corrections durables qui réduisent le nombre d’incidents futurs. Elle permet de passer d’une gestion réactive des incidents à la prévention des problèmes. Pourquoi est-ce important ? Soutient la Gestion des problèmes préventive en classant les causes des incidents, afin de repérer les tendances et d’éviter qu’ils ne se reproduisent. Où trouver ces données Il s’agit généralement d’un champ de ticket personnalisé. Consultez la configuration des champs de ticket dans le Centre d’administration Zendesk. Exemples Bug logicielPanne matérielleErreur utilisateurPanne réseau
	Durée du cas CaseDuration	Temps total écoulé entre la création de l’incident et sa clôture définitive.
Description Cette métrique calculée représente le temps de cycle de bout en bout d’un incident. Elle correspond à la différence entre l’horodatage du tout premier événement (par exemple, « Incident créé ») et celui du dernier (par exemple, « Incident clôturé »). La durée du cas est un indicateur clé de performance (KPI) de l’efficacité globale du processus. Elle est largement utilisée dans les Dashboards pour afficher les temps de cycle moyens, repérer les cas qui s’éternisent et analyser les tendances au fil du temps. Elle donne une mesure globale de la rapidité avec laquelle le processus traite et résout les incidents. Pourquoi est-ce important ? Cet indicateur clé de performance mesure la rapidité globale du processus et permet de repérer les facteurs qui allongent les délais de résolution. Où trouver ces données Calculée en déterminant, pour chaque ID d’incident, la différence entre l’horodatage du dernier événement et celui du premier. Exemples 25920060480086400
	Étiquettes Tags	Liste des étiquettes appliquées à l’incident pour le classer et en préciser le contexte.
Description Les étiquettes sont des libellés flexibles qui peuvent être ajoutés aux tickets pour apporter du contexte, faciliter leur classement ou orienter leur affectation. Les agents peuvent les ajouter manuellement, ou elles peuvent être appliquées automatiquement par des déclencheurs et des automatisations. Les étiquettes constituent une source de données riche pour l’analyse en Process Mining. Elles permettent de créer des segments précis, par exemple pour filtrer les incidents liés au lancement d’un produit (« launch_q4 ») ou à une panne connue (« outage_20231027 »). Cette souplesse permet d’étudier des situations en détail, au-delà des champs de ticket standard. Pourquoi est-ce important ? Permet de classer et de filtrer les incidents avec souplesse, pour mener des analyses détaillées adaptées au contexte, même lorsque les champs standard ne suffisent pas. Où trouver ces données API Zendesk Tickets, champ tags. Exemples vip_usernetwork_issueoutage_20231027billing_related
	Évaluation de la satisfaction SatisfactionRating	Évaluation de la satisfaction donnée par l’utilisateur final après la résolution de l’incident.
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 la résolution du ticket. Dans Zendesk, les évaluations courantes sont « Bon » et « Mauvais ». Même si elles ne mesurent pas directement l’efficacité du processus, les évaluations de satisfaction constituent un indicateur important du résultat. En Process Mining, elles peuvent être mises en relation avec les variantes du processus pour déterminer quels parcours de résolution sont associés à une meilleure satisfaction client. Par exemple, les incidents qui nécessitent davantage de transferts reçoivent-ils de moins bonnes évaluations ? Pourquoi est-ce important ? Fournit un indicateur important du résultat, qui peut être mis en relation avec les caractéristiques du processus pour comprendre l’effet des performances sur la satisfaction des utilisateurs. Où trouver ces données API Zendesk Ticket Metrics (/api/v2/ticket_metrics.json), champ satisfaction_rating.score. Exemples bonmauvaisproposénon proposé
	Gravité Severity	Niveau d’impact de l’incident sur l’activité de l’entreprise.
Description La gravité indique l’impact d’un incident sur l’activité de l’entreprise. Elle est souvent associée à la priorité pour déterminer le degré d’urgence global. Dans Zendesk, elle est généralement définie dans un champ personnalisé. L’analyse de la gravité permet de comprendre l’importance des incidents traités. C’est une dimension utile pour segmenter les données dans des Dashboards tels que « Suivi du respect des SLA » et « Mesure de l’efficacité de la hiérarchisation ». La comparaison des parcours selon le niveau de gravité peut montrer si les incidents les plus graves sont traités avec la rapidité et les ressources nécessaires. Pourquoi est-ce important ? Indique l’impact d’un incident sur l’activité de l’entreprise et permet de concentrer l’analyse sur les problèmes les plus importants pour veiller à leur résolution rapide. Où trouver ces données Il s’agit généralement d’un champ personnalisé. Consultez la configuration des champs de ticket dans le Centre d’administration Zendesk. Exemples 1 - Critique2 - Élevée3 - Moyenne4 - Faible
	Nombre de transferts HandoffCount	Nombre total de fois où l’incident a été réaffecté à un autre agent ou groupe.
Description Cette métrique calculée quantifie le nombre de transferts de responsabilité pour un incident. Chaque changement du champ Assignee ou AssignedGroup augmente ce nombre pour le cas concerné. Les transferts sont une source fréquente d’inefficacité et de retard dans la Gestion des incidents. Un nombre élevé peut révéler des règles d’affectation imprécises, des lacunes dans les connaissances des équipes d’assistance ou des processus trop complexes. Cette métrique sert de base à l’indicateur « Nombre moyen de transferts par incident » et joue un rôle essentiel dans le Dashboard « Analyse des transferts et des reprises ». Pourquoi est-ce important ? Quantifie les difficultés du processus liées aux transferts et aide à repérer les problèmes d’affectation et les lacunes dans les connaissances qui allongent les délais de résolution. Où trouver ces données Calculé en comptant le nombre de changements des champs AssignedGroup ou Assignee pour un incident. Exemples 0135
	Organisation du client Organization	L’organisation ou l’entreprise à laquelle appartient le demandeur de l’incident.
Description Cet attribut associe un incident à l’organisation du client. Il est essentiel dans les environnements d’assistance B2B, où les niveaux de service et les processus d’assistance peuvent varier d’un client à l’autre. L’analyse des incidents par organisation aide les équipes d’assistance à suivre la qualité de service, à repérer les problèmes récurrents chez certains clients et à vérifier le respect des engagements contractuels. Cette dimension permet aussi de filtrer les Dashboards et les rapports pour obtenir une vue des performances centrée sur le client. Pourquoi est-ce important ? Permet d’analyser les données par client, de suivre les niveaux de service, de repérer les tendances concernant les comptes clés et de gérer efficacement les relations clients. Où trouver ces données API Zendesk Tickets, champ organization_id. Exemples Global Tech Inc.Innovate SolutionsData Corp
	Résolution dès le premier contact IsFirstContactResolution	Indicateur booléen vrai si l’incident a été résolu par le premier agent ou groupe affecté, sans aucun transfert.
Description La résolution dès le premier contact (FCR) est une métrique importante pour mesurer l’efficacité du centre d’assistance et la satisfaction client. Cet attribut calculé signale les incidents résolus sans réaffectation à un autre agent ou à une autre équipe. La logique vérifie généralement si le ticket a atteint le statut « Résolu » tout en restant affecté à l’agent et au groupe initiaux. En Process Mining, cela permet de calculer directement le taux de résolution dès le premier contact et de comparer les parcours des incidents résolus ainsi à ceux qui ont nécessité une escalade. L’analyse aide à repérer les possibilités de donner davantage de moyens aux équipes d’assistance de première ligne. Pourquoi est-ce important ? Mesure directement l’efficacité du premier point de contact avec l’assistance et aide à repérer les possibilités de résoudre les incidents plus tôt dans le processus. Où trouver ces données Indicateur booléen calculé. Vrai si le statut du ticket est « résolu » ou « fermé » et si un seul agent ou groupe a été affecté pendant tout le cycle de vie de l’incident. Exemples truefalse
	Type de ticket TicketType	Classification du ticket, par exemple « Incident », « Problème », « Question » ou « Tâche ».
Description Ce champ classe le ticket selon la nature de la demande. Le processus de Gestion des incidents porte spécifiquement sur les tickets de type « Incident », qui correspondent à une interruption imprévue ou à une dégradation de la qualité d’un service informatique. Dans l’analyse, cet attribut sert principalement de filtre pour n’inclure que les incidents dans la vue du processus. Il peut également servir à des analyses ITSM plus larges, afin de comparer le traitement des incidents à celui des problèmes ou des demandes de service. Pourquoi est-ce important ? Permet de filtrer les données pour se concentrer sur les incidents et de veiller à ce que l’analyse porte bien sur leur cycle de vie. Où trouver ces données API Zendesk Tickets, champ type. Exemples incidentproblèmequestiontâche

Obligatoire Recommandé Facultatif

Activités de gestion des incidents

Voici les étapes et les jalons importants à consigner dans votre journal d’événements pour découvrir et analyser le processus avec précision.

6 Recommandé 7 Facultatif

	Activité	Description
	Incident clôturé	Marque la fin du cycle de vie de l’incident, lorsque le ticket est définitivement clôturé. Dans Zendesk, cela se produit souvent automatiquement après un délai défini suivant sa résolution et est enregistré comme un changement de statut final.
Pourquoi est-ce important ? Il s’agit de l’activité finale du processus. La durée totale est calculée entre « Incident créé » et cet événement, ce qui donne une vue de bout en bout du temps de cycle. Où trouver ces données Enregistré dans le journal d’audit du ticket par un événement 'Change' où la nouvelle valeur du champ 'status' devient 'closed'. Données à recueillir Repéré par un événement 'Change' du champ 'status' vers 'closed'. Type d’événement explicit
	Incident créé	Marque le début du cycle de vie de l’incident, au moment où un nouveau ticket est créé dans Zendesk. Cet événement est enregistré explicitement dans le journal d’audit de création des tickets Zendesk et constitue le point de départ de chaque dossier.
Pourquoi est-ce important ? Il s’agit de l’activité initiale principale. Le temps écoulé entre cet événement et les suivants est essentiel pour mesurer la durée totale du cycle de vie du ticket et le délai de première réponse. Où trouver ces données Cet événement explicite figure dans les journaux d’audit des tickets Zendesk. Chaque nouveau ticket génère un événement « Create » accompagné d’un horodatage. Données à recueillir Directement à partir de l’événement de création du ticket dans le journal d’audit. Type d’événement explicit
	Incident résolu	Cette étape clé a lieu lorsqu’un agent a mis en œuvre une solution et marque le ticket comme 'solved'. Il s’agit d’une action explicite, enregistrée comme un changement de statut dans le journal d’audit du ticket.
Pourquoi est-ce important ? Il s’agit de l’activité principale de résolution et d’un repère essentiel pour mesurer le délai de résolution. Le temps entre cet événement et « Incident clôturé » correspond à la période d’attente d’une confirmation de l’utilisateur ou à la clôture automatique. Où trouver ces données Enregistré dans le journal d’audit du ticket par un événement 'Change' où la nouvelle valeur du champ 'status' devient 'solved'. Données à recueillir Repéré par un événement 'Change' du champ 'status' vers 'solved'. Type d’événement explicit
	Statut passé à ouvert	Indique qu’un agent a commencé à traiter activement l’incident. Cette activité est généralement déduite du passage du champ 'status' du ticket de 'new' à 'open', qui marque le début de l’enquête et du diagnostic.
Pourquoi est-ce important ? Cet événement marque le passage de la file d’attente au traitement actif. Le temps passé par les tickets au statut 'new' avant leur passage à 'open' est un indicateur clé du délai de première réponse. Où trouver ces données Déduit du journal d’audit du ticket en repérant un événement 'Change' où la nouvelle valeur du champ 'status' est 'open' et l’ancienne valeur était 'new'. Données à recueillir Déduit d’une modification du champ de statut, de 'new' à 'open'. Type d’événement inferred
	Ticket affecté à un agent	Cette activité a lieu lorsqu’un ticket est confié à un agent précis. Elle est enregistrée explicitement dans l’historique d’audit du ticket et indique qu’une personne en a pris la responsabilité.
Pourquoi est-ce important ? Cette étape est essentielle pour mesurer le délai avant la première affectation et sert de base à l’analyse des transferts, des reprises et du taux de résolution dès le premier contact. Où trouver ces données Enregistré dans le journal d’audit du ticket lorsque le champ 'assignee_id' est renseigné ou modifié. La première affectation constitue une étape clé dans le calcul des indicateurs de performance. Données à recueillir Repéré par un événement 'Change' concernant le champ 'assignee_id' dans le journal d’audit du ticket. Type d’événement explicit
	Ticket réaffecté	Se produit lorsque la responsabilité du ticket est transférée d’un agent ou d’un groupe à un autre après l’affectation initiale. Cet événement explicite figure dans l’historique d’audit du ticket.
Pourquoi est-ce important ? Les réaffectations sont importantes pour analyser les transferts et les reprises. Leur fréquence élevée indique souvent un mauvais acheminement initial, des problèmes complexes ou des goulots d’étranglement dans le processus. Où trouver ces données Repéré dans le journal d’audit du ticket par un événement 'Change' concernant le champ 'assignee_id' ou 'group_id', après son premier renseignement. Données à recueillir Repéré par un événement 'Change' ultérieur concernant le champ 'assignee_id' ou 'group_id'. Type d’événement explicit
	Note interne ajoutée	Cette activité correspond à une collaboration interne : un agent ajoute une note privée au ticket à l’intention des autres membres de l’équipe. Elle est enregistrée explicitement lorsqu’un commentaire est marqué comme non public.
Pourquoi est-ce important ? L’analyse des notes internes peut révéler les problèmes complexes qui nécessitent une collaboration. Leur nombre excessif peut toutefois signaler des lacunes dans les connaissances ou des inefficacités du processus. Où trouver ces données Extrait des commentaires du ticket. Un commentaire est considéré comme une note interne lorsque son attribut 'public' est défini sur false. Données à recueillir Événement enregistré lorsqu’un nouveau commentaire avec 'public : false' est ajouté au ticket. Type d’événement explicit
	Objectif de SLA non respecté	Marque le moment où un ticket ne respecte pas un accord de niveau de service défini, par exemple le délai de première réponse ou de résolution. Cet événement est calculé à partir des règles de SLA et des horodatages de mise à jour du ticket.
Pourquoi est-ce important ? Cet événement contribue directement au suivi de la conformité aux SLA. Repérer le moment et les raisons des manquements est essentiel pour améliorer la fiabilité du service et la confiance des clients. Où trouver ces données Il s’agit d’un événement calculé. Il peut être déduit de l’analyse des données 'sla_policy_metrics' associées au ticket, à partir de l’horodatage 'breached_at' de chaque objectif de SLA. Données à recueillir Déduit de l’horodatage 'breached_at' dans les données des indicateurs de SLA du ticket. Type d’événement calculated
	Priorité définie	Le niveau de priorité de l’incident, par exemple faible, normal, élevé ou urgent, est défini. Cette modification explicite est enregistrée et détermine le degré d’urgence ainsi que le délai de réponse requis pour le ticket.
Pourquoi est-ce important ? Le suivi du moment et de la manière dont la priorité est définie est essentiel au Dashboard « Indicateurs d’efficacité de la priorisation », afin que les problèmes critiques soient traités rapidement. Où trouver ces données Enregistré à partir d’un événement 'Change' concernant le champ 'priority' dans le journal d’audit du ticket. Les modifications ultérieures peuvent également être suivies pour mesurer l’indicateur de performance du taux de changement de priorité. Données à recueillir Repéré par un événement 'Change' concernant le champ 'priority' dans le journal d’audit du ticket. Type d’événement explicit
	Réponse publique envoyée	Correspond à un message envoyé par un agent d’assistance à l’utilisateur final. Zendesk enregistre explicitement cet événement lorsqu’un commentaire public est ajouté au ticket.
Pourquoi est-ce important ? Le suivi des réponses publiques permet de comprendre la fréquence des échanges et de reconstituer la chronologie des délais d’attente d’une confirmation de l’utilisateur. Où trouver ces données Extrait des commentaires du ticket. Un commentaire est considéré comme public lorsque son attribut 'public' est défini sur true. Données à recueillir Événement enregistré lorsqu’un nouveau commentaire avec 'public : true' est ajouté au ticket. Type d’événement explicit
	Satisfaction de l’utilisateur évaluée	Correspond au moment où l’utilisateur final évalue l’assistance reçue. Zendesk enregistre explicitement cet événement après la résolution d’un ticket.
Pourquoi est-ce important ? L’analyse des évaluations de satisfaction fournit un retour important sur le travail des agents et l’efficacité du processus. Elle permet de relier les indicateurs du processus aux résultats pour les clients. Où trouver ces données Extrait des données d’évaluation de satisfaction associées au ticket. Elles comprennent généralement une note ('good' ou 'bad') et un commentaire facultatif. Données à recueillir Événement enregistré lorsqu’une évaluation de satisfaction est envoyée pour le ticket. Type d’événement explicit
	Statut passé à en attente	Indique que le processus est suspendu dans l’attente d’une réponse du demandeur. Cet événement est déduit du passage du champ 'status' du ticket à 'pending'.
Pourquoi est-ce important ? Cette activité est essentielle au calcul du délai d’attente d’une confirmation de l’utilisateur. Une longue attente dans cet état peut allonger considérablement le délai total de résolution et révéler des retards de communication. Où trouver ces données Déduit du journal d’audit du ticket en repérant un événement 'Change' où la nouvelle valeur du champ 'status' est 'pending'. Données à recueillir Déduit d’une modification du champ de statut vers 'pending'. Type d’événement inferred
	Ticket affecté à un groupe	Correspond à l’acheminement initial ou au triage d’un incident vers un groupe d’assistance précis. Il s’agit généralement de la première étape d’attribution des responsabilités, enregistrée comme un événement de modification explicite dans l’historique d’audit du ticket.
Pourquoi est-ce important ? Le suivi des affectations aux groupes permet d’évaluer l’efficacité du triage initial et de repérer les retards avant l’acheminement du ticket vers la bonne équipe. Où trouver ces données Enregistré dans le journal d’audit du ticket lorsque le champ 'group_id' est renseigné ou modifié. La première modification après la création correspond à l’affectation initiale. Données à recueillir Repéré par un événement 'Change' concernant le champ 'group_id' dans le journal d’audit du ticket. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Zendesk Support

Étapes

Accédez à Zendesk Explore : Connectez-vous à votre instance Zendesk Support avec un compte autorisé à créer et gérer des rapports dans Zendesk Explore.
Créez un rapport : Accédez au module Explore. Cliquez sur l’icône « Reports » dans la barre de navigation à gauche, puis sur le bouton « New report ».
Sélectionnez le jeu de données : Dans la fenêtre « Choose a dataset », sélectionnez le jeu de données Support : Ticket updates [default]. Il contient l’historique détaillé des modifications de chaque ticket, indispensable à la création d’un journal d’événements.
Ajoutez les premiers attributs (colonnes) : Dans le générateur de rapports, accédez à la section « Rows ». Cliquez sur « Add » et sélectionnez les attributs suivants. Ils formeront les colonnes de votre journal d’événements : Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Créez les attributs calculés : Cette étape est particulièrement importante. Dans le menu « Calculations » (icône en forme de fiole), sélectionnez « Standard calculated attribute ». Créez les trois attributs indiqués dans la section « Query » ci-dessous : ActivityName, SourceSystem et LastDataUpdate. Copiez exactement les formules fournies.
Ajustez les colonnes du rapport : Ajoutez les attributs calculés que vous venez de créer (ActivityName, SourceSystem, LastDataUpdate) à la section « Rows ». Vous pouvez ensuite retirer les champs bruts utilisés pour créer ActivityName (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) afin d’alléger l’affichage.
Ajoutez des filtres au rapport : Accédez à la section « Filters » et cliquez sur « Add ». Ajoutez un filtre sur Update - Date et sélectionnez une période adaptée, par exemple les trois derniers mois. Ajoutez un autre filtre sur l’attribut calculé ActivityName et excluez les valeurs nulles pour écarter les mises à jour de tickets qui ne correspondent pas à une activité recherchée.
Exécutez et vérifiez le rapport : Zendesk Explore met automatiquement le rapport à jour à mesure que vous ajoutez des attributs et des filtres. Vérifiez le tableau de données et assurez-vous que les lignes et les colonnes s’affichent comme prévu. Le rapport doit présenter une ligne par événement.
Exportez les données au format CSV : Une fois le rapport finalisé, cliquez sur le bouton « Export » en haut à droite et sélectionnez « CSV ». Zendesk génère et télécharge le fichier CSV.
Préparez l’importation : Ouvrez le fichier CSV exporté. Renommez les en-têtes de colonnes pour qu’ils correspondent aux noms d’attributs requis par votre outil de Process Mining, par exemple, remplacez « Ticket ID » par TicketId et « Update - Timestamp » par EventTimestamp. Vérifiez que les horodatages respectent le format ISO 8601. Le fichier est alors prêt à être importé.

Configuration

Jeu de données Zendesk : Le rapport doit s’appuyer sur le jeu de données Support : Ticket updates [default]. C’est le seul jeu de données standard qui fournit l’historique détaillé nécessaire pour reconstituer le processus événement par événement.
Filtrage par période : Il est important d’appliquer un filtre de date pour limiter le volume de données. Utilisez l’attribut Update - Date comme filtre principal. Pour une première analyse, il est généralement recommandé de couvrir une période de trois à six mois.
Filtre sur les activités : Après avoir créé l’attribut calculé ActivityName, filtrez le rapport pour exclure les lignes où sa valeur est nulle. Vous écarterez ainsi les modifications de tickets sans pertinence, comme les mises à jour système ou les changements d’étiquettes, de votre journal d’événements.
Attributs calculés : Cette extraction repose en grande partie sur un attribut calculé standard qui convertit les modifications brutes des champs de ticket en noms d’activités compréhensibles. La formule doit être exacte.
Prérequis : La personne qui exécute le rapport doit disposer au minimum du rôle « Viewer » dans Zendesk Explore. Pour créer et enregistrer le rapport, les autorisations « Editor » ou « Admin » sont nécessaires.

Exemple de requête config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Étapes

Prérequis : Vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système, ainsi que les bibliothèques requests et pandas. Vous pouvez les installer avec pip : pip install requests pandas.
Générez un jeton d’API Zendesk : Connectez-vous à votre instance Zendesk Support en tant qu’administrateur. Accédez à Admin Center > Apps and integrations > APIs > Zendesk APIs. Dans la section « API Tokens », ajoutez un nouveau jeton d’API actif et enregistrez-le en lieu sûr.
Configurez le script Python : Créez un fichier Python, par exemple extract_zendesk_logs.py, et copiez-y le script fourni. Remplacez les variables fictives en haut du script, ZENDESK_SUBDOMAIN, ZENDESK_EMAIL et ZENDESK_API_TOKEN, par vos identifiants. Définissez START_TIMESTAMP pour indiquer le début de la période d’extraction souhaitée, sous la forme d’un horodatage Unix.
Repérez les points de terminaison de l’API : Le script utilise principalement deux points de terminaison de l’API Zendesk. Le point incremental/tickets/cursor.json permet de récupérer efficacement tous les tickets mis à jour depuis START_TIMESTAMP. Pour chaque ticket, le script appelle ensuite tickets/{ticket_id}/audits.json afin d’obtenir l’historique détaillé de chaque modification et événement.
Exécutez le script : Lancez le script depuis votre terminal avec la commande : python extract_zendesk_logs.py. Le script commence alors à récupérer les données depuis l’API Zendesk.
Suivez l’avancement du script : Le script affiche dans la console le nombre de tickets traités, ce qui vous permet de suivre sa progression. Selon la période et le volume de tickets, l’opération peut prendre un certain temps.
Récupération des données et pagination : Le script gère automatiquement la pagination de l’API. Il commence par l’URL d’exportation initiale des tickets, puis suit la valeur after_url fournie dans chaque réponse de l’API jusqu’à la récupération de tous les tickets de la période.
Transformation des événements : Pour chaque ticket, le script parcourt son historique d’audit. Il analyse chaque événement et associe les types d’événements internes de Zendesk, comme Create, Change et Comment, aux activités métier requises, comme Incident Created, Status Changed to Open et Public Reply Sent.
Traitement des données SLA : Le script comprend une fonction dédiée, get_sla_breach_events, qui récupère les métriques SLA de chaque ticket résolu. Cette étape est nécessaire, car les dépassements de SLA ne sont pas des événements standard du journal d’audit. La fonction effectue un appel supplémentaire à l’API pour obtenir les détails d’application de la politique SLA.
Générez le journal d’événements : Une fois tous les tickets traités, le script rassemble les événements dans un DataFrame pandas et enregistre le journal d’événements final dans un fichier CSV nommé zendesk_incident_event_log.csv, dans le répertoire depuis lequel le script a été exécuté.
Préparez l’importation : Vérifiez que le fichier CSV généré est correct. Il est désormais au format requis pour être importé directement dans ProcessMind à des fins d’analyse.

Configuration

Identifiants de l’API Zendesk : Vous devez fournir le sous-domaine Zendesk, l’adresse e-mail associée à un compte administrateur ou agent, ainsi qu’un jeton d’API valide. Conservez ces identifiants en lieu sûr et ne les inscrivez pas en dur dans des scripts suivis par un système de gestion de versions en environnement de production.
Horodatage de début (START_TIMESTAMP) : Cette valeur entière définit le début de l’extraction des données. Elle doit correspondre à un horodatage Unix. Il est recommandé de remonter de trois à six mois afin de recueillir suffisamment de données sans surcharger le système. Utilisez un convertisseur en ligne pour obtenir l’horodatage correspondant à une date précise.
Limitation du débit de l’API : Le script effectue de nombreux appels à l’API. Zendesk applique des limites de débit qui varient selon l’offre. Le script convient à des volumes de données modérés, mais pour les très grandes instances, vous devrez peut-être ajouter des appels à time.sleep() dans les boucles afin d’éviter de dépasser la limite et de recevoir une erreur 429.
Bibliothèques Python requises : Le script utilise la bibliothèque requests pour les appels à l’API et pandas pour manipuler les données et exporter les fichiers CSV. Vérifiez que ces bibliothèques sont installées dans votre environnement Python.
Autorisations utilisateur : Le compte associé au jeton d’API doit disposer des autorisations nécessaires pour lire les données des tickets, y compris les audits et les métriques des tickets.

Exemple de requête python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
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.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Étapes

Créez un client d’API Zendesk autorisé à lire les tickets, les audits de tickets, les utilisateurs, les groupes, les évaluations de satisfaction et les exportations incrémentielles. Utilisez un jeton d’API ou des identifiants OAuth configurés pour votre instance Zendesk Support. Stockez le sous-domaine, les identifiants et le point de reprise de l’extraction dans des paramètres de configuration sécurisés.
Utilisez l’API d’exportation incrémentielle des tickets Zendesk pour récupérer les tickets mis à jour depuis le dernier point de reprise traité avec succès. Le script ci-dessous utilise le modèle de point de terminaison documenté, https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json, et suit la pagination par curseur jusqu’à ce que l’API indique que tous les résultats ont été renvoyés.
Pour chaque ticket récupéré, demandez son historique d’audit via le point de terminaison des audits de tickets. Ces enregistrements sont indispensables, car ProcessMind lit le journal d’événements tel quel et ne déduit pas les activités à partir de l’état final du ticket. Conservez l’horodatage de l’audit, l’acteur, l’identifiant du ticket et les événements d’audit.
Convertissez les événements d’audit en lignes d’événement explicites. Extrayez la création du ticket, l’affectation à un groupe ou à un agent, les changements de priorité, les passages au statut ouvert, les réponses publiques, les notes internes, les réaffectations, les passages au statut en attente, les résolutions et les clôtures. Ajoutez les évaluations de satisfaction dans des lignes distinctes lorsqu’elles sont disponibles. Calculez les dépassements de SLA uniquement si la cible SLA et les horodatages requis sont disponibles, et consignez les éléments utilisés pour le calcul.
Conservez le dernier horodatage de mise à jour ou le dernier curseur traité avec succès. Ne faites pas avancer le point de reprise tant que toutes les pages, tous les audits de tickets et les éventuels enregistrements de satisfaction n’ont pas été écrits correctement. Pour la première exécution, définissez une période de départ limitée, par exemple [Start date in ISO 8601 format], couvrant généralement trois à six mois.
Renseignez les colonnes obligatoires TicketId, ActivityName, EventTimestamp, SourceSystem et LastDataUpdate. Renseignez également les colonnes recommandées TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus et EventEndTime lorsque les données sources le permettent. Laissez une valeur vide uniquement si Zendesk ne fournit pas l’attribut pour l’événement concerné.
Dédupliquez les données à l’aide de TicketId, ActivityName, EventTimestamp et, lorsqu’il est disponible, d’un identifiant d’événement source stable. Conservez les occurrences légitimes répétées d’une même activité, comme plusieurs réponses publiques, notes internes, affectations ou changements de statut.
Écrivez les lignes obtenues dans un fichier CSV ou dans un autre format de journal d’événements pris en charge par ProcessMind. Vérifiez que les horodatages respectent le format ISO 8601 avec un décalage UTC explicite, que TicketId conserve un type cohérent, que les valeurs ActivityName correspondent exactement aux noms d’activités documentés et que LastDataUpdate est identique pour toutes les lignes d’un même lot d’extraction.
Importez le journal d’événements dans ProcessMind et configurez Incident ID comme identifiant de cas, Activity comme colonne d’activité et Event Timestamp comme colonne d’horodatage. Vérifiez que chaque activité requise est représentée par des lignes explicites et n’est pas déduite lors de la visualisation.

Configuration

Méthode d’API : utilisez l’API d’exportation incrémentielle des tickets Zendesk avec pagination par curseur. Pour extraire les événements, utilisez le point de terminaison des audits de tickets. Utilisez celui des évaluations de satisfaction si ces évaluations sont activées et accessibles.
Configuration requise : sous-domaine Zendesk, authentification à l’API, date de début initiale, point de reprise de l’extraction, délai d’expiration des requêtes, stratégie de nouvelle tentative et emplacement de sortie. Remplacez [Your Zendesk subdomain], [Your API email] et [Your API token] par les valeurs sécurisées de votre environnement de déploiement.
Période : pour un premier chargement, utilisez trois à six mois, sauf si l’historique requis est plus long. Pour les chargements récurrents, demandez les enregistrements postérieurs au dernier point de reprise traité avec succès et prévoyez une courte période de chevauchement pour tenir compte des mises à jour tardives, puis dédupliquez les données.
Filtres : appliquez des filtres sur l’entreprise, la marque, le groupe, l’organisation, le formulaire de ticket, le canal ou les champs personnalisés uniquement si le périmètre du processus l’exige explicitement. Zendesk Support n’utilise pas de filtres de type code société ou type de document SAP, sauf si ces notions correspondent à des champs Zendesk configurés.
Sémantique des événements : considérez les événements d’audit comme la source de référence pour les modifications explicites. Ne créez pas d’événement de changement de statut simplement parce que le ticket a un statut actuel. Un événement de statut doit provenir d’un événement d’audit ou d’une autre source documentée.
Configuration SLA : pour déterminer un dépassement de cible SLA, vous devez avoir accès à la politique SLA applicable, à la durée cible, au calendrier des heures ouvrées et aux horodatages nécessaires à l’évaluation. Si Zendesk fournit un événement ou une métrique de dépassement, utilisez cette source. Sinon, effectuez le calcul uniquement à partir des données de politique documentées et conservez les éléments qui le justifient.
Configuration de la satisfaction : l’activité User Satisfaction Rated nécessite que les évaluations de satisfaction soient activées et que l’enregistrement correspondant soit accessible via l’API. N’ajoutez pas d’événement d’évaluation fictif pour un ticket résolu sans évaluation.
Performances : utilisez la pagination par curseur, un parallélisme limité pour les requêtes d’audit de tickets, la réutilisation des connexions, un délai exponentiel entre les nouvelles tentatives en cas de limitation du débit et des points de contrôle après chaque lot traité avec succès. Évitez de redemander tous les audits de tickets à chaque exécution.
Exhaustivité : les exportations incrémentielles peuvent inclure des tickets mis à jour après l’heure demandée, mais la récupération des audits et le traitement des mises à jour tardives doivent être gérés séparément. Prévoyez une période de chevauchement et des clés de déduplication stables.
Prérequis : accès à l’API, autorisation de lire les tickets et les audits, accès aux utilisateurs et aux groupes pour résoudre les noms, accès aux données de satisfaction si nécessaire et accès aux données SLA si le calcul des dépassements est requis. La disponibilité de certains types d’événements d’audit peut varier selon la configuration et l’abonnement Zendesk.

Exemple de requête python

import csv
import json
import os
import time
from datetime import datetime, timezone, timedelta
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

ZENDESK_SUBDOMAIN = os.getenv(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Your Zendesk subdomain]")
API_EMAIL = os.getenv(class="hl-string">"ZENDESK_API_EMAIL", class="hl-string">"[Your API email]")
API_TOKEN = os.getenv(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Your API token]")
START_DATE = os.getenv(class="hl-string">"START_DATE", class="hl-string">"[Start date in ISO 8601 format]")
OUTPUT_FILE = os.getenv(class="hl-string">"OUTPUT_FILE", class="hl-string">"incident_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

if class="hl-string">"[" in ZENDESK_SUBDOMAIN or class="hl-string">"[" in API_EMAIL or class="hl-string">"[" in API_TOKEN or class="hl-string">"[" in START_DATE:
    raise ValueError(class="hl-string">"Set ZENDESK_SUBDOMAIN, ZENDESK_API_EMAIL, ZENDESK_API_TOKEN, and START_DATE before running")

BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
SESSION = requests.Session()
SESSION.auth = (fclass="hl-string">"{API_EMAIL}/token", API_TOKEN)
SESSION.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})

FIELDS = [
    class="hl-string">"TicketId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"SourceSystem", class="hl-string">"LastDataUpdate",
    class="hl-string">"TicketStatus", class="hl-string">"Assignee", class="hl-string">"AssignedGroup", class="hl-string">"TicketPriority", class="hl-string">"Channel",
    class="hl-string">"SlaStatus", class="hl-string">"EventEndTime"
]


def parse_time(value: Optional[str]) -> Optional[datetime]:
    if not value:
        return None
    return datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00"))


def iso(value: Any) -> str:
    if isinstance(value, datetime):
        return value.astimezone(timezone.utc).isoformat()
    if value is None:
        return class="hl-string">""
    return str(value)


def get_json(url: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    for attempt in range(6):
        response = SESSION.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 2 ** attempt))
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError(fclass="hl-string">"Request failed after retries: {url}")


def incremental_tickets(start_time: str) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json"
    params: Optional[Dict[str, Any]] = {class="hl-string">"start_time": int(parse_time(start_time).timestamp())}
    while url:
        payload = get_json(url, params)
        for ticket in payload.get(class="hl-string">"tickets", []):
            yield ticket
        if payload.get(class="hl-string">"end_of_stream"):
            break
        url = payload.get(class="hl-string">"after_url")
        params = None


def ticket_audits(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    while url:
        payload = get_json(url)
        for audit in payload.get(class="hl-string">"audits", []):
            yield audit
        url = payload.get(class="hl-string">"next_page")


def satisfaction_for_ticket(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/satisfaction_ratings.json"
    try:
        payload = get_json(url)
    except requests.HTTPError as error:
        if error.response is not None and error.response.status_code in (403, 404):
            return
        raise
    for rating in payload.get(class="hl-string">"satisfaction_ratings", []):
        yield rating


def user_name(user_id: Any, cache: Dict[str, str]) -> str:
    if not user_id:
        return class="hl-string">""
    key = str(user_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/users/{user_id}.json")
        user = payload.get(class="hl-string">"user", {})
        cache[key] = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
    return cache[key]


def group_name(group_id: Any, cache: Dict[str, str]) -> str:
    if not group_id:
        return class="hl-string">""
    key = str(group_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/groups/{group_id}.json")
        cache[key] = payload.get(class="hl-string">"group", {}).get(class="hl-string">"name") or key
    return cache[key]


def ticket_context(ticket: Dict[str, Any], users: Dict[str, str], groups: Dict[str, str]) -> Dict[str, str]:
    assignee = user_name(ticket.get(class="hl-string">"assignee_id"), users)
    group = group_name(ticket.get(class="hl-string">"group_id"), groups)
    return {
        class="hl-string">"TicketStatus": str(ticket.get(class="hl-string">"status") or class="hl-string">""),
        class="hl-string">"Assignee": assignee,
        class="hl-string">"AssignedGroup": group,
        class="hl-string">"TicketPriority": str(ticket.get(class="hl-string">"priority") or class="hl-string">""),
        class="hl-string">"Channel": str((ticket.get(class="hl-string">"via") or {}).get(class="hl-string">"channel") or class="hl-string">""),
        class="hl-string">"SlaStatus": class="hl-string">"",
    }


def make_row(ticket_id: Any, activity: str, event_time: Any, context: Dict[str, str], end_time: Any = class="hl-string">"") -> Dict[str, str]:
    row = {
        class="hl-string">"TicketId": str(ticket_id),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": iso(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": LAST_DATA_UPDATE,
        class="hl-string">"TicketStatus": context.get(class="hl-string">"TicketStatus", class="hl-string">""),
        class="hl-string">"Assignee": context.get(class="hl-string">"Assignee", class="hl-string">""),
        class="hl-string">"AssignedGroup": context.get(class="hl-string">"AssignedGroup", class="hl-string">""),
        class="hl-string">"TicketPriority": context.get(class="hl-string">"TicketPriority", class="hl-string">""),
        class="hl-string">"Channel": context.get(class="hl-string">"Channel", class="hl-string">""),
        class="hl-string">"SlaStatus": context.get(class="hl-string">"SlaStatus", class="hl-string">""),
        class="hl-string">"EventEndTime": iso(end_time),
    }
    return row


def audit_value(audit_event: Dict[str, Any], field: str) -> Any:
    for change in audit_event.get(class="hl-string">"changes", []):
        if change.get(class="hl-string">"field") == field:
            return change
    return None


def append_audit_rows(ticket: Dict[str, Any], audit: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    ticket_id = ticket.get(class="hl-string">"id")
    event_time = audit.get(class="hl-string">"created_at")
    context = ticket_context(ticket, users, groups)
    author = user_name(audit.get(class="hl-string">"author_id"), users)
    for change in audit.get(class="hl-string">"events", []):
        event_type = change.get(class="hl-string">"type")
        field = change.get(class="hl-string">"field")
        value = change.get(class="hl-string">"value")
        previous = change.get(class="hl-string">"previous_value")
        if event_type == class="hl-string">"Create" or field == class="hl-string">"created_at":
            rows.append(make_row(ticket_id, class="hl-string">"Incident Created", event_time, context))
        if field == class="hl-string">"group_id" and value is not None:
            context[class="hl-string">"AssignedGroup"] = group_name(value, groups)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Group", event_time, context))
        if field == class="hl-string">"assignee_id" and value is not None:
            context[class="hl-string">"Assignee"] = user_name(value, users)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Agent", event_time, context))
        if field == class="hl-string">"priority" and value is not None:
            context[class="hl-string">"TicketPriority"] = str(value)
            rows.append(make_row(ticket_id, class="hl-string">"Priority Set", event_time, context))
        if field == class="hl-string">"status":
            context[class="hl-string">"TicketStatus"] = str(value or class="hl-string">"")
            if value == class="hl-string">"open":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Open", event_time, context))
            if value == class="hl-string">"pending":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Pending", event_time, context))
            if value == class="hl-string">"solved":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Resolved", event_time, context))
            if value == class="hl-string">"closed":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Closed", event_time, context))
        if event_type == class="hl-string">"Comment":
            if bool(change.get(class="hl-string">"public")):
                rows.append(make_row(ticket_id, class="hl-string">"Public Reply Sent", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Internal Note Added", event_time, context))


def append_satisfaction_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    for rating in satisfaction_for_ticket(ticket.get(class="hl-string">"id")):
        rated_at = rating.get(class="hl-string">"created_at") or rating.get(class="hl-string">"updated_at")
        if rated_at:
            rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"User Satisfaction Rated", rated_at, context))


def append_sla_breach_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    sla_breach_time = ticket.get(class="hl-string">"sla_breach_at")
    if sla_breach_time:
        context[class="hl-string">"SlaStatus"] = class="hl-string">"Breached"
        rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"SLA Target Breached", sla_breach_time, context))


def extract() -> List[Dict[str, str]]:
    rows: List[Dict[str, str]] = []
    users: Dict[str, str] = {}
    groups: Dict[str, str] = {}
    seen = set()
    for ticket in incremental_tickets(START_DATE):
        for audit in ticket_audits(ticket.get(class="hl-string">"id")):
            append_audit_rows(ticket, audit, rows, users, groups)
        append_satisfaction_rows(ticket, rows, users, groups)
        append_sla_breach_rows(ticket, rows, users, groups)
    unique_rows: List[Dict[str, str]] = []
    for row in rows:
        key = (row[class="hl-string">"TicketId"], row[class="hl-string">"ActivityName"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"Assignee"], row[class="hl-string">"AssignedGroup"])
        if key not in seen:
            seen.add(key)
            unique_rows.append(row)
    unique_rows.sort(key=lambda item: (item[class="hl-string">"TicketId"], item[class="hl-string">"EventTimestamp"], item[class="hl-string">"ActivityName"]))
    return unique_rows


if __name__ == class="hl-string">"__main__":
    event_rows = extract()
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=FIELDS)
        writer.writeheader()
        writer.writerows(event_rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(event_rows), class="hl-string">"last_data_update": LAST_DATA_UPDATE}))

Étapes

Choisissez un outil commercial d’ETL ou d’intégration de données doté d’un connecteur Zendesk Support vérifié, capable de récupérer l’historique des audits de tickets et les commentaires, et d’écrire dans l’entrepôt de données ou le système de fichiers cible. Vérifiez que le connecteur prend en charge l’extraction incrémentielle, la pagination, la gestion des limites de débit et la conservation des horodatages sources.
Créez la connexion Zendesk dans l’outil choisi. Saisissez le sous-domaine Zendesk, la méthode d’authentification, les identifiants ou le jeton, ainsi que les paramètres de connexion requis, dans l’interface de configuration de l’outil. Accordez l’accès aux tickets, aux audits de tickets, aux commentaires, aux utilisateurs, aux groupes, aux évaluations de satisfaction et aux données SLA, lorsque ces objets sont disponibles dans votre offre Zendesk et votre version du connecteur.
Configurez la période d’extraction. Pour le chargement initial, utilisez une période glissante de trois à six mois, puis configurez les chargements incrémentiels à partir de l’horodatage de mise à jour ou d’audit pris en charge par le connecteur. Stockez le dernier point de reprise d’extraction réussi en dehors du journal d’événements afin d’éviter les doublons ou les omissions lors des exécutions suivantes.
Extrayez les données nécessaires au contexte des cas, notamment l’identifiant du ticket, son statut actuel ou au moment de l’événement, l’agent responsable, le groupe, la priorité, le canal de signalement, le statut SLA et les horodatages de mise à jour pertinents. Extrayez les audits de tickets, car les changements d’affectation, de priorité, de statut et d’autres champs doivent apparaître sous forme de lignes d’événement explicites.
Extrayez les commentaires des tickets et distinguez les commentaires publics des notes internes à l’aide de l’indicateur de visibilité ou de caractère public du connecteur. Récupérez les horodatages des commentaires, les identifiants des tickets et des auteurs, ainsi que toute heure de fin ou tout horodatage d’achèvement disponible. Créez des lignes Public Reply Sent pour les commentaires publics et Internal Note Added pour les notes privées.
Extrayez les évaluations de satisfaction et les enregistrements de dépassement SLA lorsque le connecteur les expose. S’il ne fournit pas directement les événements de dépassement SLA, configurez l’outil ETL pour les calculer à partir de la cible SLA, de la politique, des heures ouvrées et des horodatages d’événement disponibles. Ne créez pas de ligne de dépassement si les données sources ou le calcul configuré ne confirment pas que la cible a été dépassée.
Transformez les enregistrements sources extraits en un journal d’événements normalisé. Créez une ligne pour chaque occurrence d’activité explicite. Associez la création d’un ticket à Incident Created, les changements d’affectation à un groupe à Ticket Assigned to Group ou Ticket Reassigned, les changements d’affectation à un agent à Ticket Assigned to Agent ou Ticket Reassigned, les changements de priorité à Priority Set, les transitions de statut à l’activité de statut correspondante, les commentaires à Public Reply Sent ou Internal Note Added, la résolution à Incident Resolved, les évaluations de satisfaction à User Satisfaction Rated et la clôture à Incident Closed.
Appliquez les règles de classification des événements dans un ordre déterministe. Utilisez les valeurs précédentes et nouvelles de l’historique d’audit lorsqu’elles sont disponibles. Classez la première affectation à un groupe comme Ticket Assigned to Group, la première affectation à un agent comme Ticket Assigned to Agent et les changements ultérieurs de responsable comme Ticket Reassigned. Créez une ligne pour chaque changement répondant aux critères, et pas uniquement pour le dernier état du ticket.
Renseignez les colonnes obligatoires TicketId, ActivityName, EventTimestamp, SourceSystem et LastDataUpdate. Renseignez les colonnes recommandées TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus et EventEndTime à partir du contexte de l’événement ou de l’enregistrement source valide le plus proche. Conservez les horodatages sources dans un fuseau horaire cohérent, de préférence UTC, et gardez la précision d’origine prise en charge par le connecteur.
Vérifiez les données transformées : chaque TicketId doit comporter une ligne Incident Created, les horodatages des événements doivent se situer dans la période d’extraction lorsque cela s’applique, les 13 noms d’activités requis doivent être présents lorsque les données sources existent, et les doublons doivent être traités à partir de l’identifiant d’audit source ou d’une clé composite documentée.
Écrivez le journal d’événements dans la table de l’entrepôt cible ou dans un fichier au format tabulaire compatible avec ProcessMind, par exemple CSV ou un format pris en charge par le connecteur de l’entrepôt. Utilisez une ligne d’en-tête, des noms de colonnes stables, l’encodage UTF-8, des horodatages ISO 8601 et aucune donnée JSON imbriquée dans les colonnes finales du journal d’événements. Importez le journal d’événements dans ProcessMind ou connectez-le à la plateforme sans vous appuyer sur des activités déduites, car ProcessMind lit les lignes extraites telles quelles.

Configuration

Connecteur et licence : utilisez un outil commercial d’ETL ou d’intégration de données doté d’un connecteur Zendesk Support qui expose les tickets, les audits de tickets, les commentaires, les utilisateurs, les groupes, les évaluations de satisfaction et les informations SLA prises en charge par l’offre Zendesk et la version du connecteur.
Authentification et autorisations : configurez le sous-domaine Zendesk et une méthode d’authentification approuvée. Accordez uniquement les autorisations nécessaires à l’extraction des tickets, des audits, des commentaires, des utilisateurs, des groupes, des évaluations de satisfaction et des données SLA. Vérifiez que le compte d’intégration peut lire les enregistrements historiques.
Période : commencez par trois à six mois pour la validation et le chargement initial. N’étendez la période qu’après avoir vérifié le nombre de lignes, la pagination et le comportement face aux limites de débit. Utilisez un point de reprise incrémentiel pour les exécutions planifiées.
Filtres requis : appliquez uniquement les filtres propres à l’entreprise qui sont confirmés dans la configuration source, par exemple un sous-domaine Zendesk, une marque, une organisation, un groupe ou un périmètre de tickets sélectionné. N’appliquez pas de filtres sur le code société ou le type de document, sauf si ces champs existent dans le modèle de données Zendesk configuré.
Historique d’audit : activez l’extraction des événements d’audit des tickets et conservez l’identifiant d’audit source, lorsqu’il est disponible, afin d’éviter les doublons lors des chargements incrémentiels.
Commentaires : extrayez les commentaires publics et privés. Utilisez l’indicateur de visibilité source pour les classer comme Public Reply Sent ou Internal Note Added. Ne déduisez pas leur visibilité à partir du texte du commentaire.
Classification des affectations : comparez les valeurs précédentes et nouvelles du groupe ou de l’agent responsable. Classez séparément la première affectation répondant aux critères, puis créez un événement Ticket Reassigned pour les changements ultérieurs de responsable.
Classification des statuts : créez des lignes uniquement pour les transitions de statut explicites. Associez les valeurs new, open, pending, solved et closed aux activités correspondantes selon le modèle de statuts Zendesk configuré. Si des statuts personnalisés sont utilisés, documentez leur correspondance avant le chargement.
Traitement des SLA : privilégiez les événements de dépassement SLA provenant de la source. S’ils ne sont pas disponibles, configurez un calcul documenté à partir de la cible SLA, de la politique, des heures ouvrées et des horodatages d’événement disponibles. Consignez les éléments utilisés pour le calcul dans les métadonnées ETL, sans inventer de champs sources.
Gestion des horodatages : normalisez EventTimestamp et EventEndTime en UTC ou dans un autre fuseau horaire documenté. Conservez l’horodatage source et ne le remplacez pas par l’heure d’extraction.
LastDataUpdate : définissez LastDataUpdate sur l’horodatage de l’actualisation ETL réussie et utilisez la même valeur pour toutes les lignes de ce chargement.
Performances : utilisez la pagination, l’extraction incrémentielle, le partitionnement par horodatage de mise à jour ou d’audit du ticket, un parallélisme maîtrisé, la gestion des nouvelles tentatives et un délai d’attente progressif en cas de limitation du débit. Évitez de réextraire tout l’historique des tickets à chaque exécution planifiée.
Schéma cible : configurez une table d’événements à plat ou un fichier contenant les colonnes obligatoires TicketId, ActivityName, EventTimestamp, SourceSystem et LastDataUpdate, ainsi que les attributs recommandés lorsqu’ils sont disponibles.
Fonctionnement de ProcessMind : ne comptez pas sur ProcessMind pour déduire les changements de statut, les affectations, les réponses, les notes, les dépassements SLA ou les jalons du cycle de vie. Chaque activité doit déjà figurer dans une ligne d’événement avant l’importation.

Exemple de requête config

-- Configure this transformation in the selected ETL tool using its Zendesk connector.
-- Replace bracketed connection, credential, date, and company-specific values in the tool configuration.
-- The connector source objects and field mappings must be selected from the tool's verified Zendesk schema.

WITH
source_tickets AS (
    SELECT
        ticket_id,
        created_at,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        updated_at
    FROM [Your Zendesk tickets source]
    WHERE updated_at >= [Start date parameter]
      AND updated_at < [End date parameter]
),
source_audits AS (
    SELECT
        ticket_id,
        audit_id,
        event_timestamp,
        event_type,
        previous_value,
        new_value,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket audits source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_comments AS (
    SELECT
        ticket_id,
        comment_id,
        event_timestamp,
        is_public,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket comments source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_sla_breaches AS (
    SELECT
        ticket_id,
        breach_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk SLA breach source]
    WHERE breach_timestamp >= [Start date parameter]
      AND breach_timestamp < [End date parameter]
),
source_satisfaction AS (
    SELECT
        ticket_id,
        rating_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk satisfaction rating source]
    WHERE rating_timestamp >= [Start date parameter]
      AND rating_timestamp < [End date parameter]
),
classified_audits AS (
    SELECT
        a.*,
        ROW_NUMBER() OVER (
            PARTITION BY a.ticket_id, a.event_type
            ORDER BY a.event_timestamp, a.audit_id
        ) AS event_sequence
    FROM source_audits a
),
event_log AS (
    SELECT
        CAST(t.ticket_id AS VARCHAR(255)) AS TicketId,
        'Incident Created' AS ActivityName,
        t.created_at AS EventTimestamp,
        'Zendesk Support' AS SourceSystem,
        [ETL refresh timestamp] AS LastDataUpdate,
        t.status AS TicketStatus,
        t.assignee AS Assignee,
        t.assigned_group AS AssignedGroup,
        t.priority AS TicketPriority,
        t.channel AS Channel,
        t.sla_status AS SlaStatus,
        CAST(NULL AS TIMESTAMP) AS EventEndTime
    FROM source_tickets t

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Group',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'group_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Agent',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'assignee_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Priority Set',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.new_value,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'priority_change'
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Open',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.previous_value = 'new'
      AND a.new_value = 'open'

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Public Reply Sent',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = TRUE

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Internal Note Added',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = FALSE

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Reassigned',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type IN ('group_assignment', 'assignee_assignment')
      AND a.event_sequence > 1
      AND COALESCE(a.previous_value, '') <> COALESCE(a.new_value, '')

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Pending',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'pending'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'SLA Target Breached',
        s.breach_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_sla_breaches s
    WHERE s.breach_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Resolved',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'solved'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'User Satisfaction Rated',
        s.rating_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_satisfaction s
    WHERE s.rating_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Closed',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'closed'
)
SELECT
    TicketId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    TicketStatus,
    Assignee,
    AssignedGroup,
    TicketPriority,
    Channel,
    SlaStatus,
    EventEndTime
FROM event_log
WHERE TicketId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY TicketId, EventTimestamp, ActivityName;

Prêt à commencer ?

Utilisez ce modèle pour préparer vos données plus simplement et mieux comprendre les performances de votre gestion des incidents. Commencez dès aujourd’hui à optimiser votre processus.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez la gestion des incidents et résolvez-les plus vite dès aujourd’hui

Réduisez le MTTR de 35 %, éliminez les incidents récurrents et améliorez la satisfaction.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Commencez à vous améliorer en quelques minutes.

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

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

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d’extraction

Export d’un rapport Zendesk Explore au format CSV

Étapes

Configuration

Exemple de requête config

Script Python utilisant l’API REST de Zendesk Support

Étapes

Configuration

Exemple de requête python

API d’exportation incrémentielle Zendesk pour la synchronisation de données en masse

Étapes

Configuration

Exemple de requête python

Outil ETL tiers avec connecteur API Zendesk

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

Optimisez la gestion des incidents et résolvez-les plus vite dès aujourd’hui

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

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

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d’extraction

Export d’un rapport Zendesk Explore au format CSV

Étapes

Configuration

Exemple de requête config

Script Python utilisant l’API REST de Zendesk Support

Étapes

Configuration

Exemple de requête python

API d’exportation incrémentielle Zendesk pour la synchronisation de données en masse

Étapes

Configuration

Exemple de requête python

Outil ETL tiers avec connecteur API Zendesk

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

Optimisez la gestion des incidents et résolvez-les plus vite dès aujourd’hui

Prêt à commencer ?