> 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 la Gestion des incidents (23) Activités de la Gestion des incidents (13) Guides d’extraction (4)

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

Ce modèle fournit une vue structurée des données essentielles nécessaires à l’analyse efficace de votre processus de Gestion des incidents. Il présente les principaux attributs à collecter, les activités importantes à suivre et des conseils pratiques pour extraire ces données de Zendesk Support. Utilisez-le pour garantir que votre projet de Process Mining démarre avec un jeu de données complet et de qualité.

Attributs recommandés à collecter
Activités clés à suivre pour la Modélisation des processus
Conseils pratiques pour l’extraction des données

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

Télécharger le modèle

Attributs de la Gestion des 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é s’est produite.
Description Cet horodatage enregistre le moment précis où un événement s’est produit dans le cycle de vie de l’incident, par exemple lorsqu’un commentaire a été ajouté ou que le statut a été modifié. Il fournit l’ordre chronologique de toutes les activités d’un dossier. Cet attribut est fondamental pour toute analyse de Process Mining fondée sur le temps. Il sert à calculer les temps de cycle entre les activités, à identifier les temps d’attente, à mesurer la durée globale des dossiers et à analyser les performances du processus sur différentes périodes. Des horodatages précis sont indispensables pour créer une carte de processus animée montrant l’évolution des dossiers dans le temps et pour concevoir des Dashboards de performance qui suivent des KPI tels que le délai moyen de résolution. Pourquoi c’est important Les horodatages fournissent le contexte chronologique de toutes les activités. Ils permettent de calculer les durées, d’identifier les goulots d’étranglement et d’analyser les performances du processus au fil du temps. Où les obtenir 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’Incident ID est la clé primaire qui identifie de manière unique chaque dossier d’incident dans Zendesk Support. Il sert de CaseId pour le Process Mining et relie toutes les activités, modifications de statut et communications associées, de la création de l’incident à sa clôture. Dans l’analyse, cet identifiant est essentiel pour reconstituer le parcours de bout en bout de chaque incident. Il permet d’agréger les données d’événements afin de suivre des indicateurs tels que le délai total de résolution, le nombre de transferts et le respect des accords de niveau de service pour chaque dossier. En regroupant les événements par identifiant, les analystes peuvent visualiser les flux de processus, identifier les parcours fréquents et détecter les écarts par rapport à la procédure standard. Pourquoi c’est important Il s’agit de l’identifiant essentiel qui relie tous les événements à un même incident, ce qui permet de retracer l’ensemble de son cycle de vie et d’analyser précisément les performances du processus. Où les obtenir 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 donné 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 Created », « Ticket Assigned to Agent » ou « Incident Resolved ». Ces activités sont dérivées du journal d’événements ou des données de piste d’audit de Zendesk, où les modifications du système sont enregistrées. Dans le Process Mining, la séquence de ces activités forme la carte du processus, qui constitue le fondement de toute analyse. En analysant le flux des activités, les organisations peuvent découvrir les parcours réellement suivis par les incidents, identifier les goulots d’étranglement entre les étapes, mesurer les boucles de reprise, par exemple la réouverture d’un ticket résolu, et vérifier la conformité avec un processus standard défini. Pourquoi c’est important La séquence des activités définit le flux du processus, qui constitue le cœur de l’analyse par Process Mining pour identifier les inefficacités, les écarts et les possibilités d’amélioration. Où les obtenir Dérivé des événements de l’API Zendesk Ticket Audits. Par exemple, un événement Change portant sur le champ status peut être associé à « Status Changed ». Exemples Incident crééTicket affecté à un agentStatut passé à PendingIncident 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 enregistre la date et l’heure de l’extraction ou de la mise à jour la plus récente depuis le système source. Il s’agit généralement d’une valeur unique appliquée à l’ensemble des données lors d’un cycle d’actualisation donné. Cette information est essentielle pour la gouvernance des données et pour les utilisateurs de l’analyse par Process Mining. Elle indique le degré d’actualité des données et aide les analystes à déterminer s’ils consultent les informations les plus récentes disponibles. Elle est particulièrement importante pour suivre les performances opérationnelles et prendre rapidement des décisions fondées sur l’analyse. Pourquoi c’est important Fournit un contexte important sur l’actualité des données, afin que les utilisateurs sachent dans quelle mesure l’analyse est à jour et quand les données ont été extraites pour la dernière fois. Où les obtenir Horodatage généré par le processus ETL ou le pipeline de données à la fin de l’actualisation des données. Exemples 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Système source SourceSystem	Système depuis lequel les données des incidents ont été extraites.
Description Cet attribut identifie l’origine des données du processus. Dans cette vue, sa valeur serait statique, par exemple « Zendesk Support », ce qui indique que tous les événements et attributs proviennent de ce système. Lorsque des données issues de plusieurs systèmes sont combinées, ce champ est essentiel pour distinguer les différentes sources. Il contribue à garantir l’intégrité des données et permet une analyse par source, par exemple en comparant le processus de Gestion des incidents dans Zendesk avec celui d’un autre outil ITSM. Pourquoi c’est important Identifie l’origine des données, ce qui est essentiel pour la gouvernance des données et les analyses combinant plusieurs systèmes sources. Où les obtenir Valeur statique définie lors de la transformation des données afin d’identifier leur origine. Exemples Zendesk SupportZendesk
	Agent affecté Assignee	Agent de support actuellement chargé de traiter l’incident.
Description Cet attribut identifie l’agent précisément responsable de l’incident à un moment donné. Les changements de responsable constituent des événements importants, car ils signalent le transfert du travail d’une personne à une autre. L’analyse de l’agent affecté permet de comprendre la répartition de la charge, les performances individuelles et les modes de collaboration. Le suivi des modifications de ce champ est essentiel pour calculer le KPI « Average Handoffs per Incident » et identifier les situations dans lesquelles les incidents sont fréquemment transférés, ce qui peut révéler des lacunes de connaissances ou un routage inefficace. Pourquoi c’est important Identifie l’agent responsable, ce qui permet d’analyser la charge de travail et de suivre les transferts, un élément essentiel pour repérer les inefficacités du processus. Où les obtenir API Zendesk Tickets, champ assignee_id. Les modifications sont enregistrées dans l’API Ticket Audits. Exemples John SmithJane DoeAutomatisation du centre de services
	Canal de signalement Channel	Canal par lequel l’incident a été signalé initialement, par exemple « Email », « Web » ou « API ».
Description Cet attribut indique le moyen utilisé par l’utilisateur final ou le système pour créer le ticket d’incident. La compréhension du canal est importante pour analyser l’origine des incidents et adapter le processus de support en conséquence. L’analyse des incidents par canal peut révéler des schémas différents. 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 « Incident Throughput Volume » et contribuent à la planification des ressources ainsi qu’à l’optimisation des canaux. Pourquoi c’est important Permet d’analyser le volume des incidents et les performances du processus par source, afin d’améliorer les processus et d’allouer les ressources selon chaque canal. Où les obtenir API Zendesk Tickets, champ via.channel. Exemples webe-mailAPItéléphone
	État du SLA SlaStatus	État actuel du Service Level Agreement (SLA) associé à l’incident.
Description Cet attribut indique si un incident est en bonne voie pour respecter les objectifs définis dans le SLA, s’il les a déjà dépassés ou si les compteurs du SLA sont en pause. Zendesk suit automatiquement les indicateurs du SLA en fonction des politiques configurées. Cet attribut est essentiel pour le Dashboard « Suivi de la conformité aux SLA ». Il fournit une mesure directe de la performance par rapport aux engagements de service. L’analyse des moments et des causes de dépassement des SLA permet aux organisations d’identifier les faiblesses du processus et d’améliorer la fiabilité du service. Il contribue directement au KPI « Taux de respect des SLA des incidents ». Pourquoi c’est important Mesure directement la performance par rapport aux engagements de service, ce qui permet d’analyser les dépassements de SLA et d’assurer un suivi préventif afin d’améliorer la conformité. Où les obtenir API Zendesk Ticket Metrics (/api/v2/ticket_metrics.json), dérivée de champs tels que sla_policy, breached_at, etc. Exemples ActifEn pauseEn violation du SLASatisfait
	Groupe affecté AssignedGroup	Équipe ou groupe de support actuellement chargé de l’incident.
Description Cet attribut indique quelle équipe est responsable de l’incident. Les incidents passent souvent entre différents niveaux de support ou groupes spécialisés, par exemple de « L1 Support » à la « Network Team ». Il s’agit d’une dimension importante pour analyser les transferts entre équipes et identifier les goulots d’étranglement. En surveillant la circulation des incidents entre les groupes, les analystes peuvent mesurer les dépendances entre équipes, calculer les temps d’attente dans les files de groupes spécifiques et optimiser les règles de routage. Cet attribut alimente directement le Dashboard « Handoffs and Rework Analysis ». Pourquoi c’est important Suit la responsabilité des équipes, ce qui est essentiel pour analyser les transferts entre équipes, identifier les goulots d’étranglement propres à chaque équipe et mesurer les temps d’attente dans les files. Où les obtenir API Zendesk Tickets, champ group_id. Les modifications sont enregistrées dans l’API Ticket Audits. Exemples Support niveau 1Équipe réseau niveau 2Infrastructure niveau 3Facturation
	Heure de fin de l’événement EventEndTime	Horodatage indiquant le moment où une activité a été terminée.
Description L’heure de fin de l’événement marque la conclusion 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 la séquence du 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) ainsi que le temps d’attente entre les activités. Ces informations constituent le fondement 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é en attente avant son démarrage. Pourquoi c’est important Permet de calculer la durée des activités et les temps d’attente, éléments fondamentaux d’une analyse détaillée des goulots d’étranglement et de l’identification des retards dans le processus. Où les obtenir Calculée à partir de l’heure de début de l’événement suivant dans le même cas. Pour le dernier événement, l’heure de fin peut être identique à l’heure de début ou correspondre à 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 « Low », « Normal », « High » ou « Urgent ».
Description La priorité d’un incident détermine le degré d’urgence requis pour sa prise en charge et sa résolution. Il s’agit d’un facteur important pour la priorisation du travail et l’allocation des ressources au sein de l’équipe de support. Dans l’analyse des processus, la priorité sert à segmenter les incidents afin de comparer leurs flux et leurs performances. Les analystes peuvent par exemple vérifier si les incidents « Urgent » sont effectivement résolus plus rapidement que ceux de priorité « Low ». Elle sert également au suivi de la conformité aux SLA, souvent définis selon les niveaux de priorité. Le KPI « Priority Change Rate » repose sur le suivi des modifications de ce champ. Pourquoi c’est important Cet attribut est essentiel pour segmenter l’analyse, évaluer l’efficacité de la priorisation et suivre la conformité aux SLA selon les différents niveaux d’urgence. Où les obtenir API Zendesk Tickets, champ priority. Les modifications sont enregistrées dans l’API Ticket Audits. Exemples FaibleNormaleÉlevéeUrgente
	Statut du ticket TicketStatus	Statut du ticket d’incident au moment de l’événement, par exemple « Open », « Pending » ou « Solved ».
Description Cet attribut reflète 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 constitue un moyen essentiel de générer des activités pour le Process Mining. L’analyse du statut du ticket est fondamentale pour comprendre le processus. Elle permet d’identifier le temps passé par les incidents dans certains états, notamment « Pending », qui indique souvent l’attente d’une réponse du client. Elle est également essentielle pour définir la fin d’un dossier et calculer les délais de résolution. Pourquoi c’est important Le suivi des changements de statut est essentiel pour comprendre la progression du processus, identifier les temps d’attente et définir les points de début et de fin du cycle de vie de l’incident. Où les obtenir API Zendesk Tickets, champ status. Les modifications sont enregistrées dans l’API Ticket Audits. Exemples NouveauOuvertEn attenteRésoluFermé
	Catégorie de la cause racine RootCauseCategory	Catégorie générale de la cause racine sous-jacente de l’incident.
Description Cet attribut sert à classer la raison fondamentale pour laquelle un incident s’est produit. Il est généralement renseigné vers la fin du cycle de vie de l’incident, souvent dans le cadre d’une analyse post-incident ou d’un processus de Gestion des problèmes, puis enregistré dans un champ personnalisé. Ces données sont essentielles pour le Dashboard « Précision de l’identification des causes racines » et le KPI « Couverture des analyses de causes racines ». L’analyse des incidents par cause racine permet d’identifier les problèmes récurrents, d’orienter la mise en place de corrections définitives et de réduire le volume futur d’incidents. Elle déplace l’attention de la résolution réactive vers la prévention proactive des problèmes. Pourquoi c’est important Soutient une Gestion des problèmes proactive en catégorisant les causes des incidents, afin d’identifier les tendances et de prévenir leur réapparition. Où les obtenir 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
	Déclarant Submitter	Utilisateur final ou système ayant signalé l’incident à l’origine.
Description Cet attribut identifie la personne ou l’entité qui a créé le ticket. Il se distingue du demandeur, car un agent peut créer un ticket au nom d’une autre personne. Dans l’analyse, le déclarant permet de comprendre qui signale les problèmes. Associé aux données de l’organisation, il peut aider à déterminer si certains clients ou groupes d’utilisateurs rencontrent un volume élevé d’incidents. Ces informations peuvent orienter des actions de support préventif ou de formation. Pourquoi c’est important Identifie la source du signalement de l’incident, qui peut être analysée afin de repérer des tendances liées à certains utilisateurs, services ou systèmes automatisés. Où les obtenir API Zendesk Tickets, champ submitter_id. Exemples alice.jones@example.combob.williams@example.comMoniteur système
	Durée du cas CaseDuration	Temps total écoulé entre la création de l’incident et sa clôture définitive.
Description Cette mesure calculée représente le temps de cycle de bout en bout d’un incident. Elle est obtenue en calculant la différence entre l’horodatage du tout premier événement, par exemple « Incident créé », et celui du tout dernier événement, par exemple « Incident clôturé ». La durée du cas est un KPI principal de l’efficacité globale du processus. Elle est largement utilisée dans les Dashboards pour afficher les temps de cycle moyens, identifier les cas de longue durée et analyser les tendances au fil du temps. Elle fournit une mesure générale de la rapidité avec laquelle le processus traite et résout les incidents. Pourquoi c’est important Il s’agit d’un KPI important pour mesurer la vitesse globale du processus et identifier les facteurs qui contribuent aux longs délais de résolution. Où les obtenir Calculée en déterminant la différence entre l’horodatage du dernier événement et celui du premier événement pour chaque Incident ID. Exemples 25920060480086400
	Est automatisé IsAutomated	Indicateur booléen précisant si une activité a été réalisée par un système automatisé ou par un agent humain.
Description Cet attribut dérivé permet de distinguer les événements exécutés par des utilisateurs humains de ceux réalisé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 d’un événement est un utilisateur système connu. Comprendre le niveau d’automatisation est essentiel pour l’analyse moderne des processus. Cela permet d’évaluer l’efficacité des règles d’automatisation, d’identifier les tâches manuelles susceptibles d’être automatisées et de mesurer l’impact de l’automatisation sur l’efficacité et les délais de résolution. Cet attribut peut servir à comparer les flux de processus des activités automatisées et manuelles. Pourquoi c’est important Distingue les actions humaines des actions système, ce qui est essentiel pour analyser l’impact de l’automatisation sur l’efficacité du processus et identifier de nouvelles possibilités d’automatisation. Où les obtenir Dérivé de la vérification de la correspondance entre l’auteur de l’événement (author_id dans l’API Ticket Audits) et un utilisateur système ou d’automatisation connu. Exemples truefalse
	Étiquettes Tags	Liste des tags appliqués à l’incident à des fins de catégorisation et de contextualisation.
Description Les tags sont des libellés flexibles qui peuvent être ajoutés aux tickets pour fournir un contexte supplémentaire, faciliter la catégorisation ou orienter le routage. Les agents peuvent les ajouter manuellement, ou ils peuvent être ajoutés automatiquement par des déclencheurs et des automatisations. Les tags constituent une source de données riche pour l’analyse en Process Mining. Ils permettent de créer des segments détaillés, par exemple en filtrant les incidents liés au lancement d’un produit donné (« launch_q4 ») ou à une panne connue (« outage_20231027 »). Cette flexibilité autorise des analyses approfondies qui vont au-delà des champs de ticket standard. Pourquoi c’est important Offre une méthode flexible pour catégoriser et filtrer les incidents, permettant une analyse détaillée et contextualisée qui ne serait pas possible avec les seuls champs standard. Où les obtenir API Zendesk Tickets, champ tags. Exemples utilisateur_vipproblème_réseaupanne_20231027lié_à_la_facturation
	Évaluation de la satisfaction SatisfactionRating	Évaluation de la satisfaction fournie 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 le support, généralement au moyen d’une enquête envoyée après la résolution du ticket. Dans Zendesk, les évaluations courantes sont « Bonne » et « Mauvaise ». Bien qu’elles ne mesurent pas directement l’efficacité du processus, les évaluations de satisfaction constituent un indicateur important du résultat obtenu. Dans le cadre du Process Mining, elles peuvent être mises en relation avec les variantes de processus afin de déterminer quels parcours de résolution génèrent la plus grande satisfaction client. Par exemple, les incidents comportant davantage de transferts obtiennent-ils de moins bonnes évaluations ? Pourquoi c’est important Fournit un indicateur clé du résultat, qui peut être mis en relation avec les caractéristiques du processus afin de comprendre comment sa performance influence la satisfaction des utilisateurs. Où les obtenir 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é.
Description La gravité définit l’impact d’un incident sur l’activité. Elle est souvent associée à la priorité pour déterminer le niveau d’urgence global. Elle est généralement configurée comme champ personnalisé dans Zendesk. L’analyse de la gravité permet de comprendre le niveau de criticité des incidents traités. Il s’agit d’une dimension essentielle pour segmenter les données dans des Dashboards tels que « Suivi de la conformité aux SLA » et « Indicateurs d’efficacité de la priorisation ». La comparaison des flux de processus selon les niveaux de gravité peut révéler si les incidents graves sont traités avec la rapidité et les ressources appropriées. Pourquoi c’est important Indique l’impact d’un incident sur l’activité, ce qui permet de concentrer l’analyse sur les problèmes les plus importants et de garantir leur résolution efficace. Où les obtenir 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ù un incident a été réattribué à un autre agent ou groupe.
Description Cette mesure calculée quantifie le nombre de transferts de responsabilité pour un incident. Chaque modification du champ Assignee ou AssignedGroup augmente ce nombre pour le cas. Les transferts sont une source fréquente d’inefficacité et de retard dans la Gestion des incidents. Un nombre élevé de transferts peut révéler des règles de routage imprécises, des lacunes dans les connaissances des équipes de support ou des processus trop complexes. Cette mesure sert de base au KPI « Nombre moyen de transferts par incident » et est essentielle au Dashboard « Analyse des transferts et des reprises ». Pourquoi c’est important Quantifie les difficultés du processus liées aux transferts et aide à repérer les inefficacités de routage ainsi que les lacunes de connaissances qui prolongent les délais de résolution. Où les obtenir Calculé en comptant le nombre de modifications du champ AssignedGroup ou Assignee pour un incident. Exemples 0135
	Organisation du client Organization	Organisation ou entreprise à laquelle appartient le demandeur de l’incident.
Description Cet attribut relie un incident à l’organisation du client. Il est essentiel dans les environnements de support B2B, où les niveaux de service et les processus de support peuvent varier selon le client. L’analyse des incidents par organisation permet aux équipes de support de suivre la santé des clients, d’identifier les problèmes récurrents qui touchent certains comptes et de vérifier que les obligations contractuelles sont respectées. Il s’agit d’une dimension importante pour filtrer les Dashboards et les rapports et obtenir une vision des performances centrée sur le client. Pourquoi c’est important Permet une analyse propre à chaque client, en aidant à suivre les niveaux de service, à identifier les tendances concernant les comptes stratégiques et à gérer efficacement les relations clients. Où les obtenir API Zendesk Tickets, champ organization_id. Exemples Global Tech Inc.Innovate SolutionsData Corp
	Résolution au premier contact IsFirstContactResolution	Indicateur booléen vrai lorsque l’incident a été résolu par le premier agent ou groupe auquel il a été attribué, sans aucun transfert.
Description La résolution au premier contact (FCR) est un indicateur important de l’efficacité d’un centre de support et de la satisfaction client. Cet attribut calculé identifie les incidents résolus sans réattribution à un autre agent ou à une autre équipe. La logique vérifie généralement si le ticket a atteint le statut « Solved » tout en restant attribué à l’agent et au groupe initiaux. Dans le cadre du Process Mining, cela permet de calculer directement le taux de FCR et de comparer les parcours des incidents résolus au premier contact avec ceux qui ont nécessité une escalade, afin d’identifier les possibilités de renforcer l’autonomie du support de première ligne. Pourquoi c’est important Mesure directement l’efficacité du premier point de contact avec le support et aide à identifier les possibilités d’avancer la résolution dans le processus. Où les obtenir Indicateur booléen calculé. Vrai si le statut du ticket est « solved » ou « closed » et si un seul agent ou groupe attribué a été utilisé pendant tout le cycle de vie de l’incident. Exemples truefalse
	Type de ticket TicketType	La classification du ticket, par exemple « Incident », « Problème », « Question » ou « Tâche ».
Description Ce champ catégorise le ticket en fonction de la nature de la demande. Le processus de Gestion des incidents porte spécifiquement sur les tickets dont le type est « Incident », c’est-à-dire une interruption imprévue ou une dégradation de la qualité d’un service informatique. Dans le cadre de l’analyse, cet attribut sert principalement de filtre afin de n’inclure que les incidents dans la vue du processus. Il peut également être utilisé pour une analyse ITSM plus large, afin de comparer les processus de traitement des incidents, des problèmes et des demandes de service. Pourquoi c’est important Permet de filtrer les données pour se concentrer exclusivement sur les incidents et garantir la pertinence de l’analyse du cycle de vie de la Gestion des incidents. Où les obtenir API Zendesk Tickets, type de champ. Exemples incidentproblèmequestiontâche

Obligatoire Recommandé Facultatif

Activités de la Gestion des incidents

Voici les étapes essentielles et les principaux jalons du processus à enregistrer dans votre journal d’événements pour permettre une découverte et une analyse précises.

6 Recommandé 7 Facultatif

	Activité	Description
	Incident clôturé	Marque la fin définitive du cycle de vie de l’incident, lorsque le ticket est clôturé de manière permanente. Dans Zendesk, cette clôture intervient souvent automatiquement après un délai défini suivant la résolution et est enregistrée comme une dernière modification du statut.
Pourquoi c’est important Il s’agit de l’activité de fin définitive du processus. La durée totale du processus est calculée entre « Incident Created » et cet événement, ce qui fournit une vision de bout en bout du temps de cycle. Où les obtenir Enregistré dans le journal d’audit du ticket via un événement « Change » dont la nouvelle valeur du champ « status » devient « closed ». Collecte Identifié par un événement « Change » portant sur le champ « status » et le faisant passer à « closed ». Type d’événement explicit
	Incident créé	Marque le début du cycle de vie de l’incident, lorsqu’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 c’est important Il s’agit de l’activité de début principale. L’analyse du délai entre cet événement et les suivants est essentielle pour mesurer la durée globale du cycle de vie du ticket et le délai de première réponse. Où les obtenir Il s’agit d’un événement explicite enregistré dans les journaux d’audit des tickets Zendesk. Chaque nouveau ticket génère un événement « Create » avec un horodatage correspondant. Collecte 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é intervient 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 une modification du statut dans le journal d’audit du ticket.
Pourquoi c’est important Il s’agit de l’activité principale de résolution et d’un point essentiel pour mesurer le délai de résolution. Le temps écoulé entre cet événement et « Incident Closed » correspond à la période de confirmation par l’utilisateur ou de clôture automatique. Où les obtenir Enregistré dans le journal d’audit du ticket via un événement « Change » dont la nouvelle valeur du champ « status » devient « solved ». Collecte Identifié par un événement « Change » portant sur le champ « status » et le faisant passer à « solved ». Type d’événement explicit
	Statut passé à Open	Indique qu’un agent a commencé à travailler activement sur l’incident. Cette activité est généralement déduite du changement du champ « status » du ticket, de « new » à « open », ce qui marque le début de la phase d’investigation et de diagnostic.
Pourquoi c’est important Cet événement marque le passage de la file d’attente au traitement actif. La durée pendant laquelle les tickets restent au statut « new » avant de passer à « open » constitue un indicateur clé du délai de première réponse. Où les obtenir Déduit du journal d’audit du ticket en identifiant un événement « Change » dont la nouvelle valeur du champ « status » est « open » et l’ancienne valeur « new ». Collecte Déduit d’une modification du champ de statut de « new » à « open ». Type d’événement inferred
	Ticket affecté à un agent	Cette activité se produit lorsqu’un ticket est affecté à un agent donné pour traitement. Il s’agit d’un événement explicite enregistré dans l’historique d’audit du ticket, qui indique qu’une personne en a pris la responsabilité.
Pourquoi c’est 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 des taux de résolution au premier contact. Où les obtenir 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é pour le calcul des KPI. Collecte Identifié par un événement « Change » portant sur le champ « assignee_id » dans le journal d’audit du ticket. Type d’événement explicit
	Ticket réaffecté	Se produit lorsque la responsabilité d’un ticket est transférée d’un agent ou d’un groupe à un autre après l’affectation initiale. Il s’agit d’un événement explicite suivi dans l’historique d’audit du ticket.
Pourquoi c’est important Les réaffectations sont importantes pour analyser les transferts et les reprises. Une fréquence élevée de réaffectation révèle souvent un routage initial incorrect, des problèmes complexes ou des goulots d’étranglement dans le processus. Où les obtenir Extrait du journal d’audit du ticket en identifiant un événement « Change » portant sur le champ « assignee_id » ou « group_id » après son premier renseignement. Collecte Identifié par un événement « Change » ultérieur portant sur 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’attention des autres membres de l’équipe. Elle est enregistrée explicitement lorsqu’un commentaire est marqué comme non public.
Pourquoi c’est important L’analyse des notes internes peut apporter des informations utiles sur les problèmes complexes qui nécessitent une collaboration. En revanche, un nombre excessif de notes peut révéler des lacunes de connaissances ou des inefficacités dans le processus. Où les obtenir Extrait des données de commentaires du ticket. Un commentaire est identifié comme une note interne lorsque son attribut « public » vaut false. Collecte Événement enregistré lorsqu’un nouveau commentaire avec « public: false » est ajouté au ticket. Type d’événement explicit
	Objectif SLA dépassé	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 le délai de résolution. Cet événement est calculé à partir des définitions de la politique SLA et des horodatages de mise à jour du ticket.
Pourquoi c’est important Cet événement contribue directement au suivi de la conformité aux SLA. Identifier le moment et les raisons des dépassements est fondamental pour améliorer la fiabilité du service et la confiance des clients. Où les obtenir Il s’agit d’un événement calculé. Il peut être déduit de l’analyse des données « sla_policy_metrics » associées à un ticket, en utilisant l’horodatage « breached_at » de chaque objectif SLA. Collecte Dérivé de l’horodatage « breached_at » présent dans les données de métriques SLA du ticket. Type d’événement calculated
	Priorité définie	Le niveau de priorité d’un incident, par exemple Low, Normal, High ou Urgent, est défini. Cette information est enregistrée comme un événement de modification explicite et détermine le degré d’urgence ainsi que le délai de réponse requis pour le ticket.
Pourquoi c’est important Le suivi du moment et de la manière dont la priorité est définie est essentiel pour le Dashboard « Prioritization Effectiveness Metrics » et permet de traiter rapidement les problèmes importants. Où les obtenir Enregistré à partir d’un événement « Change » portant sur le champ « priority » dans le journal d’audit du ticket. Les modifications ultérieures peuvent également être suivies afin de mesurer le KPI Priority Change Rate. Collecte Identifié par un événement « Change » portant sur le champ « priority » dans le journal d’audit du ticket. Type d’événement explicit
	Réponse publique envoyée	Représente une communication envoyée par un agent de support à l’utilisateur final. Il s’agit d’un événement explicite dans Zendesk, enregistré chaque fois qu’un commentaire public est ajouté au ticket.
Pourquoi c’est important Le suivi des réponses publiques est important pour comprendre la fréquence des communications et peut constituer un élément clé de la chronologie lors de l’analyse des délais de confirmation par l’utilisateur. Où les obtenir Extrait des données de commentaires du ticket. Un commentaire est identifié comme public lorsque son attribut « public » vaut true. Collecte É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	Représente le moment où l’utilisateur final attribue une note au support reçu. Il s’agit d’un événement explicite enregistré dans Zendesk après la résolution du ticket.
Pourquoi c’est important L’analyse des notes de satisfaction fournit un retour important sur les performances des agents et l’efficacité du processus, en reliant les indicateurs de processus aux résultats obtenus pour les clients. Où les obtenir Extrait des données de satisfaction associées au ticket. Elles comprennent généralement une note (« good » ou « bad ») et un commentaire facultatif. Collecte Événement enregistré lorsqu’une note de satisfaction est envoyée pour le ticket. Type d’événement explicit
	Statut passé à Pending	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 c’est important Cette activité est essentielle pour calculer le délai d’attente de confirmation de l’utilisateur. Une durée importante dans cet état peut augmenter sensiblement le délai global de résolution et révéler des retards de communication. Où les obtenir Déduit du journal d’audit du ticket en identifiant un événement « Change » dont la nouvelle valeur du champ « status » est « pending ». Collecte Déduit d’une modification du champ de statut vers « pending ». Type d’événement inferred
	Ticket affecté à un groupe	Représente le routage initial ou le triage d’un incident vers un groupe de support donné. Il s’agit généralement de la première étape d’attribution de la responsabilité, enregistrée comme un événement de modification explicite dans l’historique d’audit du ticket.
Pourquoi c’est important Le suivi des affectations aux groupes permet d’analyser l’efficacité du triage initial et d’identifier les délais avant l’orientation du ticket vers l’équipe appropriée. Où les obtenir Enregistré dans le journal d’audit du ticket lorsque le champ « group_id » est renseigné ou modifié. La première modification de ce type après la création correspond à l’affectation initiale. Collecte Identifié par un événement « Change » portant sur le champ « group_id » dans le journal d’audit du ticket. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

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

Étapes

Accéder à Zendesk Explore : Connectez-vous à votre instance Zendesk Support avec un compte utilisateur autorisé à créer et gérer des rapports dans Zendesk Explore.
Créer un rapport : Accédez au module Explore. Cliquez sur l’icône « Reports » dans la barre de navigation de gauche, puis sur le bouton « New report ».
Sélectionner 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 la piste d’audit de chaque modification de ticket, indispensable à la création d’un Event Log.
Ajouter les attributs initiaux (colonnes) : Dans le générateur de rapports, accédez à la section « Rows ». Cliquez sur « Add » et sélectionnez les attributs suivants. Ils constitueront les colonnes de votre Event Log : 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éer les attributs calculés : Il s’agit de l’étape la plus importante. Ouvrez le menu « Calculations » (icône en forme de fiole) et sélectionnez « Standard calculated attribute ». Créez les trois attributs définis dans la section « Query » ci-dessous : ActivityName, SourceSystem et LastDataUpdate. Vous devrez copier exactement les formules fournies.
Affiner les colonnes du rapport : Ajoutez les attributs calculés que vous venez de créer (ActivityName, SourceSystem, LastDataUpdate) à la section « Rows ». Vous pouvez ensuite supprimer 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.
Ajouter les filtres du rapport : Accédez à la section « Filters » et cliquez sur « Add ». Ajoutez un filtre sur Update - Date et sélectionnez une période appropriée, par exemple les trois derniers mois. Ajoutez également un filtre sur l’attribut calculé ActivityName et excluez les valeurs nulles afin de supprimer les mises à jour de tickets qui ne correspondent pas à une activité souhaitée.
Exécuter et vérifier le rapport : Zendesk Explore met automatiquement le rapport à jour lorsque vous ajoutez des attributs et des filtres. Vérifiez le tableau de données pour vous assurer que les lignes et les colonnes s’affichent comme prévu. Le rapport doit présenter une ligne par événement.
Exporter 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éparer le chargement : 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 Ticket ID en TicketId et Update - Timestamp en EventTimestamp. Vérifiez que le format des dates et heures respecte la norme ISO 8601. Le fichier est maintenant prêt à être chargé.

Configuration

Jeu de données Zendesk : Le rapport doit être créé à partir du jeu de données Support: Ticket updates [default]. Il s’agit du seul jeu de données standard qui fournit la piste d’audit détaillée nécessaire pour reconstituer le processus événement par événement.
Filtrage par période : Il est essentiel d’appliquer un filtre de date afin de limiter le volume de données. Utilisez l’attribut Update - Date comme filtre principal. Pour une première analyse, une période de 3 à 6 mois est généralement recommandée.
Filtre d’activité : Après avoir créé l’attribut calculé ActivityName, vous devez filtrer le rapport afin d’exclure les lignes où cette valeur est nulle. Cela supprime les modifications de tickets sans intérêt, par exemple les mises à jour système ou les changements d’étiquettes, de votre Event Log.
Attributs calculés : Cette extraction repose largement sur un attribut calculé standard qui convertit les modifications brutes des champs de ticket en noms d’activités compréhensibles. La précision de la formule est déterminante.
Prérequis : L’utilisateur qui exécute le rapport doit disposer au minimum du rôle « Viewer » dans Zendesk Explore. La création et l’enregistrement du rapport nécessitent les autorisations « Editor » ou « Admin ».

a 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érer un jeton 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 API actif et enregistrez sa valeur en lieu sûr.
Configurer le script Python : Créez un fichier Python, par exemple extract_zendesk_logs.py, et copiez-y le script fourni. Remplacez les variables fictives situées 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.
Comprendre les points de terminaison de l’API : Le script utilise principalement deux points de terminaison de l’API Zendesk. Le point de terminaison incremental/tickets/cursor.json sert à récupérer efficacement tous les tickets mis à jour depuis START_TIMESTAMP. Pour chaque ticket, le script appelle ensuite le point de terminaison tickets/{ticket_id}/audits.json afin d’obtenir l’historique détaillé de chaque modification et événement.
Exécuter le script : Lancez le script depuis votre terminal avec la commande : python extract_zendesk_logs.py. Il commencera à récupérer les données depuis l’API Zendesk.
Suivre la progression 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érer les données et gérer la pagination : Le script gère automatiquement la pagination de l’API. Il commence par l’URL initiale d’export des tickets, puis suit l’after_url fourni dans chaque réponse jusqu’à la récupération de tous les tickets de la période.
Transformer les événements : Pour chaque ticket, le script parcourt l’historique d’audit. Il analyse chaque événement et associe les types d’événements internes de Zendesk, tels que Create, Change et Comment, aux activités métier requises, telles que Incident Created, Status Changed to Open et Public Reply Sent.
Gérer les données SLA : Le script comprend une fonction dédiée, get_sla_breach_events, qui récupère les indicateurs SLA pour chaque ticket résolu. Cette étape est nécessaire, car les violations de SLA ne sont pas des événements standard du journal d’audit. La fonction effectue un appel API supplémentaire pour récupérer les détails d’application de la politique SLA.
Générer l’Event Log : Une fois tous les tickets traités, le script rassemble les événements extraits dans un DataFrame pandas et enregistre l’Event Log final dans un fichier CSV nommé zendesk_incident_event_log.csv, dans le même répertoire que celui depuis lequel le script a été exécuté.
Préparer le chargement : Vérifiez le fichier CSV généré. Il est maintenant au format requis pour être chargé directement dans ProcessMind à des fins d’analyse.

Configuration

Identifiants API Zendesk : Vous devez fournir le sous-domaine Zendesk, l’adresse e-mail associée à un compte administrateur ou agent et un jeton API valide. Stockez 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 pour une utilisation en production.
Horodatage de début (START_TIMESTAMP) : Cette valeur entière détermine le début de l’extraction des données. Elle doit être exprimée sous la forme d’un horodatage Unix. Il est recommandé de commencer 3 à 6 mois auparavant afin de recueillir un volume de données pertinent sans surcharger le système. Vous pouvez utiliser un convertisseur en ligne pour obtenir l’horodatage correspondant à une date donnée.
Limitation du débit de l’API : Le script effectue de nombreux appels API. Zendesk applique des limites 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 d’atteindre la limite et de recevoir une erreur 429.
Bibliothèques Python requises : Le script dépend de la bibliothèque requests pour effectuer les appels API et de pandas pour manipuler les données et exporter les fichiers CSV. Vérifiez qu’elles sont installées dans votre environnement Python.
Autorisations utilisateur : Le compte utilisateur associé au jeton API doit disposer des autorisations suffisantes pour lire les données des tickets, notamment les audits et les indicateurs de ticket.

a 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 API Zendesk autorisé à lire les tickets, les audits de tickets, les utilisateurs, les groupes, les évaluations de satisfaction et les exports incrémentiels. Utilisez un jeton API ou un identifiant OAuth configuré pour votre instance Zendesk Support. Stockez le sous-domaine, l’identifiant et le point de reprise de l’extraction dans des paramètres de configuration sécurisés.
Utilisez l’API d’export incrémentiel des tickets Zendesk pour récupérer les tickets mis à jour après le dernier point de reprise réussi. 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 l’ensemble des résultats est complet.
Pour chaque ticket renvoyé, demandez son historique d’audit via le point de terminaison des audits de tickets. Les enregistrements d’audit sont nécessaires, car ProcessMind lit l’Event Log tel quel et ne déduit pas les activités à partir de l’état final du ticket. Conservez l’horodatage de l’audit, son auteur, l’identifiant du ticket et les événements d’audit.
Convertissez les événements d’audit en lignes d’événements explicites. Extrayez la création du ticket, l’affectation à un groupe, l’affectation à un agent, les changements de priorité, les changements de statut vers open, les réponses publiques, les notes internes, les réaffectations, les changements de statut vers pending, le statut solved et le statut closed. Extrayez les évaluations de satisfaction dans des lignes distinctes lorsque l’évaluation est disponible. Calculez les violations de SLA uniquement lorsque la cible SLA et les horodatages nécessaires sont disponibles, puis documentez les paramètres utilisés pour le calcul.
Conservez le dernier horodatage de mise à jour ou curseur traité avec succès. Ne faites progresser le point de reprise qu’après l’écriture réussie de toutes les pages, de tous les audits de tickets et des éventuels enregistrements de satisfaction. Pour la première exécution, utilisez une date de début limitée, telle que [Start date in ISO 8601 format], couvrant normalement trois à six mois.
Renseignez les colonnes obligatoires TicketId, ActivityName, EventTimestamp, SourceSystem et LastDataUpdate. Renseignez les colonnes recommandées TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus et EventEndTime lorsque les données sources le permettent. Utilisez des valeurs vides uniquement lorsque Zendesk ne fournit pas l’attribut pour l’événement concerné.
Dédupliquez les données à l’aide de TicketId, ActivityName, EventTimestamp et d’un identifiant d’événement source stable lorsqu’il est disponible. Conservez les occurrences légitimes multiples 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 d’Event Log pris en charge par ProcessMind. Vérifiez que les horodatages sont au format ISO 8601 avec un décalage UTC explicite, que TicketId conserve un type cohérent, que les valeurs d’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.
Chargez l’Event Log dans ProcessMind et configurez Incident ID comme identifiant de cas, Activity comme colonne d’activité et Event Timestamp comme colonne temporelle. Vérifiez que chaque activité requise est représentée par des lignes explicites et non générée lors de la visualisation.

Configuration

Méthode API : API d’export incrémentiel des tickets Zendesk avec pagination par curseur. Utilisez le point de terminaison des audits de tickets pour l’extraction au niveau des événements et le point de terminaison de satisfaction lorsque les évaluations de satisfaction sont activées et accessibles.
Configuration requise : sous-domaine Zendesk, authentification API, date de début initiale, point de reprise de l’extraction, délai d’expiration des requêtes, politique de nouvelle tentative et emplacement de sortie. Remplacez [Your Zendesk subdomain], [Your API email] et [Your API token] par des valeurs sécurisées lors du 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 réussi et incluez une petite période de chevauchement afin de prendre en compte les mises à jour reçues tardivement, 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 lorsqu’ils sont explicitement requis par le périmètre du processus. Zendesk Support n’utilise pas de filtres SAP de type Company Code ou Document Type, sauf si ces notions sont représentées par 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 uniquement parce que le statut actuel du ticket possède une valeur. Un événement de statut doit provenir d’un événement d’audit ou d’une autre source documentée.
Configuration SLA : SLA Target Breached nécessite l’accès à la politique SLA applicable, à la durée cible, au calendrier des heures ouvrées et aux horodatages nécessaires à l’évaluation de la cible. Si Zendesk expose un événement ou un indicateur de violation, utilisez cette source. Dans le cas contraire, effectuez le calcul uniquement à partir de données de politique documentées et conservez la base du calcul.
Configuration de la satisfaction : User Satisfaction Rated nécessite que les évaluations de satisfaction soient activées et que l’enregistrement d’évaluation soit accessible via l’API. Un ticket résolu sans évaluation ne doit pas recevoir d’événement d’évaluation créé artificiellement.
Performances : utilisez la pagination par curseur, une concurrence limitée pour les requêtes d’audit des tickets, la réutilisation des connexions, un délai exponentiel en cas de limitation du débit et des points de contrôle après les lots traités avec succès. Évitez de redemander tous les audits de tickets à chaque exécution.
Exhaustivité : les exports incrémentiels peuvent inclure des tickets mis à jour après l’heure demandée, mais la récupération des audits et les mises à jour tardives doivent être gérées séparément. Utilisez 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 violations est requis. La disponibilité de certains types d’événements d’audit peut varier selon la configuration et l’abonnement Zendesk.

a 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

Sélectionnez un outil ETL ou d’intégration de données commercial proposant un connecteur Zendesk Support vérifié, prenant en charge l’historique des audits de tickets et l’extraction des commentaires, et capable d’écrire dans votre entrepôt de données ou votre 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 sélectionné. 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 dans le connecteur.
Configurez la période d’extraction. Utilisez une période glissante de 3 à 6 mois pour le chargement initial, 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 de l’Event Log afin d’éviter les doublons ou les omissions lors des exécutions suivantes.
Extrayez les données nécessaires au contexte du cas, notamment l’identifiant du ticket, le statut actuel ou au niveau 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 enregistrements d’audit des tickets, car les changements d’affectation, de priorité, de statut et d’autres champs doivent être représentés par des lignes d’événements explicites.
Extrayez les commentaires des tickets et distinguez les commentaires publics des notes internes à l’aide de l’indicateur de visibilité public ou privé fourni par le connecteur. Extrayez les horodatages des commentaires, les identifiants des tickets, les identifiants des auteurs et tout éventuel horodatage de fin ou d’achèvement. Créez des lignes Public Reply Sent pour les commentaires publics et Internal Note Added pour les commentaires privés.
Extrayez les enregistrements d’évaluation de satisfaction et de violation de SLA lorsque le connecteur les expose. Si le connecteur n’expose pas directement les événements de violation de 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énements disponibles. Ne créez pas de ligne de violation si les données sources ou le calcul configuré n’établissent pas que la cible a été dépassée.
Transformez les enregistrements sources extraits en Event Log 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, le statut résolu à Incident Resolved, les évaluations de satisfaction à User Satisfaction Rated et le statut fermé à 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 de responsable ultérieurs comme Ticket Reassigned. Émettez une ligne pour chaque changement admissible, 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 cohérent, de préférence UTC, et préservez la précision d’origine prise en charge par le connecteur.
Validez la sortie transformée en vérifiant que chaque TicketId possède une ligne Incident Created, que les horodatages des événements se situent dans la période d’extraction lorsque cela s’applique, que les 13 noms d’activités requis sont représentés lorsque les données sources existent et que les clés d’événements en double sont traitées selon l’identifiant d’audit source ou une clé composite documentée.
Écrivez l’Event Log dans la table de l’entrepôt cible ou dans un fichier au format tabulaire compatible avec ProcessMind, tel que CSV ou le format du connecteur d’entrepôt pris en charge. Utilisez une seule ligne d’en-têtes, des noms de colonnes stables, un encodage UTF-8, des horodatages ISO 8601 et aucun objet JSON imbriqué dans les colonnes d’événements finales. Chargez l’Event Log dans ProcessMind ou connectez-le à la plateforme sans compter sur une déduction des activités, car ProcessMind lit les lignes extraites telles quelles.

Configuration

Connecteur et licence : utilisez un outil ETL ou d’intégration de données commercial doté d’un connecteur Zendesk Support exposant les tickets, les audits de tickets, les commentaires, les utilisateurs, les groupes, les évaluations de satisfaction et les informations SLA, selon les possibilités de l’offre Zendesk et de 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, audits, commentaires, utilisateurs, groupes, données de satisfaction et données SLA. Vérifiez que le compte d’intégration peut lire les enregistrements historiques.
Période : commencez par 3 à 6 mois pour la validation et le chargement initial. Élargissez la période uniquement après avoir vérifié les volumes 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, tels qu’un sous-domaine Zendesk, une marque, une organisation, un groupe ou un périmètre de tickets sélectionné. N’appliquez pas de filtres Company Code ou Document Type, 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 classer Public Reply Sent et Internal Note Added. Ne déduisez pas la 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 admissible et les changements ultérieurs, puis émettez Ticket Reassigned pour les changements de responsable suivants.
Classification des statuts : émettez des lignes uniquement pour les transitions de statut explicites. Associez les valeurs new, open, pending, solved et closed selon le modèle de statuts Zendesk configuré. Si des statuts personnalisés sont utilisés, documentez le mapping avant le chargement.
Gestion des SLA : privilégiez les événements de violation de SLA sources. 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énements disponibles. Enregistrez la base du 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 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, de manière cohérente pour toutes les lignes de ce chargement.
Performances : utilisez la pagination, l’extraction incrémentielle, le partitionnement par horodatage de mise à jour du ticket ou d’audit, un parallélisme contrôlé, la gestion des nouvelles tentatives et un délai d’attente en cas de limitation du débit. Évitez d’extraire à nouveau l’historique complet de chaque ticket lors de chaque exécution planifiée.
Schéma cible : configurez une table ou un fichier d’événements à plat 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 violations de SLA ou les jalons du cycle de vie. Chaque activité doit déjà exister sous forme de ligne d’événement avant le chargement.

a 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 simplifier la préparation de vos données et obtenir des analyses détaillées de la performance 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 rapidement dès aujourd’hui

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

Démarrer l’essai gratuit

Aucune carte bancaire requise, commencez à améliorer vos processus 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 la Gestion des incidents

Activités de la Gestion des incidents

Guides d’extraction

Export d’un rapport de l’interface Zendesk Explore vers un fichier CSV

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l’API REST Zendesk Support

Étapes

Configuration

a Exemple de requête python

API d’export incrémentiel Zendesk pour la synchronisation de données en volume

Étapes

Configuration

a Exemple de requête python

Outil ETL tiers avec connecteur API Zendesk

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Optimisez la Gestion des incidents et résolvez-les plus rapidement 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 la Gestion des incidents

Activités de la Gestion des incidents

Guides d’extraction

Export d’un rapport de l’interface Zendesk Explore vers un fichier CSV

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l’API REST Zendesk Support

Étapes

Configuration

a Exemple de requête python

API d’export incrémentiel Zendesk pour la synchronisation de données en volume

Étapes

Configuration

a Exemple de requête python

Outil ETL tiers avec connecteur API Zendesk

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

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

Nous attachons de l’importance à votre confidentialité