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

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

Zendesk Support

Attributs de gestion des incidents (24) Activités de gestion des incidents (13) Guides d'extraction (4)

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

Ce modèle offre une vue d'ensemble structurée des données essentielles requises pour analyser efficacement votre processus de gestion des incidents. Il décrit les attributs clés à collecter, les activités critiques à suivre, et inclut 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 dataset robuste et complet.

Attributs recommandés à collecter
Activités clés à suivre pour la cartographie des processus
Guide pratique d'extraction de données

Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs de gestion des incidents

Voici les champs de données recommandés à inclure dans votre journal d'événements pour une analyse approfondie de votre processus de gestion des incidents.

5 Obligatoire 7 Recommandé 12 Facultatif

	Nom	Description
	ID d'incident TicketId	L'identifiant unique généré par le système pour chaque ticket d'incident.
Description L'ID d'incident est la clé primaire qui identifie de manière unique chaque cas d'incident dans Zendesk Support. Il sert de CaseId pour le process mining, liant toutes les activités, changements de statut et communications associées depuis la création de l'incident jusqu'à sa clôture.\n\nEn analyse, cet ID est crucial pour reconstituer le parcours de bout en bout de chaque incident. Il permet l'agrégation des données d'événements pour suivre des métriques comme le temps de résolution total, le nombre de transferts et le respect des accords de niveau de service pour les cas individuels. En regroupant les événements par cet ID, les analystes peuvent visualiser les flux de processus, identifier les chemins courants et détecter les déviations par rapport à la procédure standard. Pourquoi c'est important C'est l'identifiant essentiel qui connecte tous les événements à un seul incident, permettant de tracer l'intégralité du cycle de vie et d'analyser précisément la performance du processus. Où obtenir API de tickets Zendesk (/api/v2/tickets/{id}), champ id. Exemples 19428230113521941055
	Timestamp de l'événement EventTimestamp	La date et l'heure exactes de l'activité.
Description Cet horodatage enregistre le moment précis où un événement s'est produit dans le cycle de vie de l'incident, comme l'ajout d'un commentaire ou le changement de statut. Il fournit l'ordre chronologique de toutes les activités au sein d'un cas.\n\nCet attribut est fondamental pour toute analyse par process mining basée sur le temps. Il est utilisé pour calculer les temps de cycle entre les activités, identifier les temps d'attente, mesurer la durée globale du cas et analyser la performance du processus sur différentes périodes. Des horodatages précis sont essentiels pour créer une carte de processus animée qui montre le flux des cas au fil du temps et pour construire des dashboards de performance qui suivent les KPI comme le temps de résolution moyen. Pourquoi c'est important Les horodatages fournissent le contexte chronologique de toutes les activités, permettant le calcul des durées, l'identification des goulots d'étranglement et l'analyse de la performance du processus au fil du temps. Où obtenir API d'audits de tickets Zendesk (/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
	Activité ActivityName	Le nom de l'activité métier ou de l'événement qui s'est produit à un moment précis du cycle de vie de l'incident.
Description Cet attribut décrit une étape ou une action spécifique entreprise dans le processus de gestion des incidents, telle que 'Incident créé', 'Ticket assigné à un agent' ou 'Incident résolu'. Ces activités sont dérivées du journal d'événements ou des données d'audit de Zendesk, où les changements système sont enregistrés.\n\nEn process mining, la séquence de ces activités forme la carte des processus, qui est la base de toute analyse. En analysant le flux des activités, les organisations peuvent découvrir les chemins réels empruntés par les incidents, identifier les goulots d'étranglement entre les étapes, mesurer les boucles de retravail (par exemple, la réouverture d'un ticket résolu) et vérifier la conformité par rapport à un processus standard défini. Pourquoi c'est important La séquence d'activités définit le flux de processus, qui est le cœur de l'analyse par process mining pour identifier les inefficacités, les déviations et les opportunités d'amélioration. Où obtenir Dérivé des événements de l'API d'audits de tickets Zendesk. Par exemple, un événement de modification sur le champ de statut pourrait être mappé à 'Statut modifié'. Exemples Incident crééTicket Assigné à un AgentStatut changé à En attenteIncident résoluIncident fermé
	Dernière mise à jour des données LastDataUpdate	L'horodatage indiquant la dernière actualisation des données pour ce processus.
Description Cet attribut enregistre la date et l'heure de la dernière extraction ou mise à jour des données du système source. Il s'agit généralement d'une valeur unique appliquée à l'ensemble du dataset d'un cycle d'actualisation donné.\n\nCette information est vitale pour la gouvernance des données et pour les utilisateurs de l'analyse par process mining. Elle fournit un contexte sur la fraîcheur des données, aidant les analystes à comprendre s'ils consultent les informations les plus récentes disponibles. Ceci est particulièrement important pour le suivi de la performance opérationnelle et la prise de décisions opportunes basées sur l'analyse. Pourquoi c'est important Fournit un contexte crucial sur la fraîcheur des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse et la date de la dernière extraction des données. Où obtenir Horodatage généré par le processus ETL/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	Le système dont les données de l'incident ont été extraites.
Description Cet attribut identifie l'origine des données du processus. Pour cette vue, la valeur serait statique, par exemple, 'Zendesk Support', indiquant que tous les événements et attributs proviennent de ce système.\n\nDans les environnements où les données de plusieurs systèmes sont combinées, ce champ est essentiel pour distinguer les différentes sources de données. Il aide à garantir l'intégrité des données et permet une analyse spécifique à la source, comme la comparaison du processus de gestion des incidents dans Zendesk avec un autre outil ITSM. Pourquoi c'est important Identifie l'origine des données, ce qui est crucial pour la gouvernance des données et pour les analyses qui combinent des données provenant de plusieurs systèmes source. Où obtenir Valeur statique définie lors de la transformation des données pour identifier l'origine des données. Exemples Zendesk SupportZendesk
	Agent assigné Assignee	L'agent de support individuel actuellement assigné pour gérer l'incident.
Description Cet attribut identifie l'agent spécifique responsable de l'incident à un moment donné. Les changements d'assigné sont des événements critiques qui signifient un transfert de travail d'une personne à une autre.\n\nL'analyse de l'agent assigné aide à comprendre la répartition de la charge de travail, la performance individuelle et les schémas de collaboration. Le suivi des changements dans ce champ est essentiel pour calculer le KPI 'Nombre moyen de transferts par incident' et identifier les situations où les incidents sont fréquemment transférés, ce qui peut indiquer des lacunes de connaissances ou un routage inefficace. Pourquoi c'est important Identifie l'agent responsable, permettant l'analyse de la charge de travail et le suivi des transferts (handoffs), ce qui est crucial pour identifier les inefficacités des processus. Où obtenir API de tickets Zendesk, champ assignee_id. Les changements sont enregistrés dans l'API Ticket Audits. Exemples John SmithJane DoeAutomatisation du Service Desk
	Canal de signalement Channel	Le canal par lequel l'incident a été initialement signalé, tel que 'Email', 'Web' ou 'API'.
Description Cet attribut capture la méthode utilisée par l'utilisateur final ou le système pour créer le ticket d'incident. Comprendre le canal est important pour analyser les sources d'incidents et adapter le processus de support en conséquence.\n\nL'analyse des incidents par canal peut révéler différents schémas. Par exemple, les incidents signalés par téléphone pourraient avoir des temps de résolution plus courts que ceux provenant d'e-mails. Cette information soutient le dashboard 'Volume de Traitement des Incidents' et aide aux efforts de planification des ressources et d'optimisation des canaux. Pourquoi c'est important Aide à analyser les volumes d'incidents et la performance des processus par source, permettant des améliorations de processus spécifiques au canal et une allocation des ressources. Où obtenir API de tickets Zendesk, champ via.channel. Exemples webemailapiphone
	Groupe assigné AssignedGroup	L'équipe ou le groupe de support actuellement assigné à l'incident.
Description Cet attribut indique quelle équipe est responsable de l'incident. Les incidents se déplacent souvent entre différents niveaux de support ou groupes spécialisés, par exemple, du 'Support L1' à l''Équipe Réseau'.\n\nC'est une dimension critique pour l'analyse des transferts de processus et l'identification des goulots d'étranglement. En surveillant comment les incidents circulent entre les groupes, les analystes peuvent mesurer les dépendances inter-équipes, calculer les temps d'attente pour des équipes spécifiques et optimiser les règles de routage. Il prend directement en charge le dashboard 'Analyse des Transferts et du Retravail'. Pourquoi c'est important Suit la responsabilité de l'équipe, ce qui est essentiel pour analyser les transferts inter-équipes, identifier les goulots d'étranglement spécifiques à l'équipe et mesurer les temps d'attente. Où obtenir API de tickets Zendesk, champ group_id. Les changements sont enregistrés dans l'API Ticket Audits. Exemples Support L1Équipe Réseau L2Infrastructure L3Facturation
	Heure de fin de l'événement EventEndTime	L'horodatage indiquant quand une activité a été achevée.
Description L'heure de fin de l'événement marque la conclusion d'une activité. Dans les données de journal d'événements, l'heure de fin d'une activité est souvent déduite comme l'heure de début de l'activité suivante dans la séquence pour ce cas. Pour la toute dernière activité d'un cas, l'heure de fin peut être la même que son heure de début.\n\nCet attribut est essentiel pour calculer la durée des activités individuelles (ProcessingTime) et le temps d'attente entre les activités. Cette information est la base de l'analyse des goulots d'étranglement, permettant aux analystes de voir non seulement combien de temps une étape prend, mais aussi combien de temps le cas est resté inactif avant le début de cette étape. Pourquoi c'est important Permet le calcul des durées d'activité et des temps d'attente, ce qui est fondamental pour effectuer une analyse détaillée des goulots d'étranglement et identifier les retards de processus. Où obtenir Calculé comme l'heure de début de l'événement suivant au sein du même cas. L'heure de fin du dernier événement peut être la même que son heure de début ou l'heure de clôture du cas. Exemples 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Priorité TicketPriority	Le niveau de priorité assigné à l'incident, tel que 'Faible', 'Normal', 'Élevé' ou 'Urgent'.
Description La priorité d'un incident détermine l'urgence requise pour une réponse et une résolution. C'est un facteur clé dans la priorisation du travail et l'allocation des ressources au sein de l'équipe de support.\n\nDans l'analyse des processus, la priorité est utilisée pour segmenter les incidents afin de comparer leurs flux de processus et leurs performances. Par exemple, les analystes peuvent vérifier si les incidents 'Urgents' sont réellement résolus plus rapidement que ceux de faible priorité. Elle est également utilisée pour surveiller la conformité aux SLA, car les SLA sont souvent définis en fonction des niveaux de priorité. Le KPI 'Taux de changement de priorité' repose sur le suivi des modifications de ce champ. Pourquoi c'est important Cet attribut est crucial pour segmenter l'analyse, évaluer l'efficacité de la priorisation et surveiller la conformité aux SLA pour différents niveaux d'urgence. Où obtenir API de tickets Zendesk, champ priority. Les changements sont enregistrés dans l'API Ticket Audits. Exemples faiblenormalélevéurgent
	Statut du ticket TicketStatus	Le statut du ticket d'incident au moment de l'événement, tel que 'Ouvert', 'En attente' ou 'Résolu'.
Description Cet attribut reflète l'état du ticket d'incident à différents moments de son cycle de vie. Les statuts standards de Zendesk incluent nouveau, ouvert, en attente, en attente de traitement, résolu et fermé. Le suivi des changements apportés à ce champ est un moyen principal de générer des activités pour le process mining.\n\nL'analyse du statut du ticket est fondamentale pour comprendre le processus. Elle aide à identifier le temps que les incidents passent dans certains états, comme 'En attente', ce qui indique souvent une attente de réponse du client. C'est également la clé pour définir l'achèvement du cas et calculer les temps 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ù obtenir API de tickets Zendesk, champ status. Les changements sont enregistrés dans l'API Ticket Audits. Exemples nouveauopenpendingsolvedfermé
	Statut SLA SlaStatus	Le statut actuel de l'accord de niveau de service (SLA) pour l'incident.
Description Cet attribut indique si un incident est en bonne voie pour atteindre ses objectifs SLA définis, s'il les a déjà enfreints, ou si les compteurs SLA sont en pause. Zendesk suit automatiquement les métriques SLA en fonction des politiques configurées.\n\nC'est un attribut critique pour le dashboard 'Suivi de la Conformité SLA'. Il fournit une mesure directe de la performance par rapport aux engagements de service. En analysant quand et pourquoi les SLA sont enfreints, les organisations peuvent identifier les faiblesses des processus et améliorer la fiabilité du service. Il soutient directement le KPI 'Taux de respect des SLA des incidents'. Pourquoi c'est important Mesure directement les performances par rapport aux engagements de service, permettant l'analyse des violations de SLA et la surveillance proactive pour améliorer la conformité. Où obtenir API de métriques de tickets Zendesk (/api/v2/ticket_metrics.json), dérivée de champs comme sla_policy, breached_at, etc. Exemples ActifMis en PauseDépasséExécutée
	Catégorie de Cause Racine RootCauseCategory	La catégorie de haut niveau de la cause profonde sous-jacente de l'incident.
Description Cet attribut est utilisé pour classer la raison fondamentale pour laquelle un incident s'est produit. Il est généralement capturé vers la fin du cycle de vie de l'incident, souvent dans le cadre d'un processus post-mortem ou de gestion des problèmes, et stocké dans un champ personnalisé.\n\nCes données sont essentielles pour le dashboard 'Précision de l'Identification des Causes Racines' et le KPI 'Couverture RCA'. L'analyse des incidents par cause racine aide à identifier les problèmes récurrents, guidant les efforts pour mettre en œuvre des correctifs permanents et réduire le volume futur des incidents. Elle déplace l'accent de la gestion réactive des problèmes vers la prévention proactive. Pourquoi c'est important Permet une gestion proactive des problèmes en catégorisant les causes des incidents, aidant à identifier les tendances et à prévenir de futures occurrences. Où obtenir C'est généralement un champ de ticket personnalisé. Vérifiez la configuration des champs de ticket dans le Centre d'administration de Zendesk. Exemples Bogue logicielPanne MatérielleErreur utilisateurPanne réseau
	Demandeur Submitter	L'utilisateur final ou le système qui a initialement signalé l'incident.
Description Cet attribut identifie la personne ou l'entité qui a créé le ticket. Ceci est distinct du demandeur, car un agent peut créer un ticket au nom de quelqu'un d'autre.\n\nEn analyse, le soumetteur peut être utilisé pour comprendre qui signale les problèmes. Combiné aux données d'organisation, il peut aider à identifier si des clients ou des groupes d'utilisateurs spécifiques rencontrent un volume élevé d'incidents. Cela peut orienter les initiatives de support proactif ou les efforts de formation. Pourquoi c'est important Identifie la source du rapport d'incident, qui peut être analysée pour trouver des schémas liés à des utilisateurs spécifiques, des départements ou des systèmes automatisés. Où obtenir API de tickets Zendesk, champ submitter_id. Exemples alice.jones@example.combob.williams@example.comMoniteur système
	Durée du cas CaseDuration	Le temps total écoulé entre la création de l'incident et sa clôture finale.
Description Cette métrique calculée représente le temps de cycle de bout en bout pour un seul incident. Elle est calculée en prenant la différence entre l'horodatage du tout premier événement (par exemple, 'Incident créé') et le tout dernier événement (par exemple, 'Incident fermé').\n\nLa Durée du Cas est un indicateur clé de performance (KPI) primaire pour l'efficacité globale du processus. Elle est largement utilisée dans les dashboards pour montrer les temps de cycle moyens, identifier les cas de longue durée et analyser les tendances au fil du temps. Elle fournit une mesure de haut niveau de la rapidité avec laquelle le processus peut gérer et résoudre les incidents. Pourquoi c'est important C'est un KPI critique pour mesurer la vélocité globale du processus et identifier les facteurs qui contribuent aux longs temps de résolution. Où obtenir Calculé en trouvant la différence entre l'horodatage du dernier événement et du premier événement pour chaque ID d'incident. Exemples 25920060480086400
	Est Automatisé IsAutomated	Un indicateur booléen signalant si une activité a été réalisée par un système automatisé ou un agent humain.
Description Cet attribut dérivé aide à 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.\n\nComprendre le niveau d'automatisation est crucial pour l'analyse moderne des processus. Cela aide à évaluer l'efficacité des règles d'automatisation, à identifier les tâches manuelles qui pourraient être automatisées et à mesurer l'impact de l'automatisation sur l'efficacité et les temps de résolution. Cet attribut peut être utilisé pour 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é des processus et identifier de nouvelles opportunités d'automatisation. Où obtenir Dérivé en vérifiant si l'auteur de l'événement (author_id dans l'API d'audits de tickets) correspond à un système connu ou à un utilisateur d'automatisation. Exemples truefaux
	Est une résolution au premier contact IsFirstContactResolution	Un indicateur booléen qui est vrai si l'incident a été résolu par le premier agent ou groupe assigné sans aucun transfert (handoff).
Description La résolution au premier contact (FCR) est une métrique critique pour l'efficacité des centres de support et la satisfaction client. Cet attribut calculé signale les incidents qui ont été résolus sans être réaffectés à un autre agent ou équipe. La logique vérifie généralement si le ticket a atteint le statut 'Résolu' tout en étant toujours assigné à l'agent et au groupe initiaux. En Process Mining, cela permet le calcul direct du taux de FCR et la comparaison des chemins de processus des incidents FCR par rapport à ceux qui ont nécessité une escalade, aidant à identifier les opportunités de renforcer le support de première ligne. Pourquoi c'est important Mesure directement l'efficacité du point de contact de support initial et aide à identifier les opportunités de décaler la résolution plus tôt dans le processus. Où obtenir Indicateur booléen calculé. Vrai si le statut du ticket est 'résolu' ou 'fermé' et qu'il n'y a eu qu'un seul assigné ou groupe assigné unique tout au long du cycle de vie de l'incident. Exemples truefaux
	Gravité Severity	Le niveau d'impact de l'incident sur l'activité.
Description La gravité définit l'impact métier d'un incident, souvent conjointement avec la priorité pour déterminer l'urgence globale. Elle est généralement configurée comme un champ personnalisé dans Zendesk.\n\nL'analyse de la gravité aide à comprendre la criticité des incidents traités. C'est une dimension clé pour segmenter les données dans des dashboards comme 'Suivi de la Conformité SLA' et 'Mesures d'Efficacité de la Priorisation'. La comparaison des flux de processus pour différents niveaux de gravité peut révéler si les incidents de haute gravité sont traités avec la vitesse et les ressources appropriées. Pourquoi c'est important Indique l'impact commercial d'un incident, permettant une analyse axée sur les problèmes les plus critiques et assurant qu'ils sont résolus efficacement. Où obtenir C'est généralement un champ personnalisé. Vérifiez la configuration des champs de ticket dans le Centre d'administration de Zendesk. Exemples 1 - Critique2 - Élevée3 - Moyenne4 - Faible
	Nombre de transferts HandoffCount	Le nombre total de fois qu'un incident a été réaffecté à un agent ou un groupe différent.
Description Cette métrique calculée quantifie le nombre de fois où la responsabilité d'un incident a été transférée. Chaque changement dans le champ Assignee ou AssignedGroup incrémente ce compte pour le cas.\n\nLes transferts sont une source courante d'inefficacité et de retard dans la gestion des incidents. Un nombre élevé de transferts peut indiquer des règles de routage peu claires, des lacunes de connaissances dans les équipes de support ou des processus trop complexes. Cette métrique est la base du KPI 'Nombre moyen de transferts par incident' et est cruciale pour le dashboard 'Analyse des Transferts et du Retravail'. Pourquoi c'est important Quantifie la friction du processus causée par les transferts, aidant à identifier les inefficacités de routage et les lacunes de connaissances qui prolongent les temps de résolution. Où obtenir Calculé en comptant le nombre de fois où le champ AssignedGroup ou Assignee a changé pour un incident. Exemples 0135
	Note de satisfaction SatisfactionRating	La note de satisfaction fournie par l'utilisateur final après la résolution de l'incident.
Description Cet attribut saisit le feedback du client sur son expérience de support, généralement collecté via une enquête après la résolution du ticket. Les notes courantes dans Zendesk sont 'Bon' ou 'Mauvais'.\n\nBien que n'étant pas une mesure directe de l'efficacité du processus, les notes de satisfaction constituent une métrique de résultat critique. En process mining, cela peut être corrélé avec les variantes de processus pour comprendre quels chemins de résolution mènent à une plus grande satisfaction client. Par exemple, les incidents avec plus de transferts reçoivent-ils des notes inférieures ? Pourquoi c'est important Fournit une métrique de résultat clé qui peut être corrélée aux caractéristiques du processus pour comprendre comment la performance du processus impacte la satisfaction de l'utilisateur. Où obtenir API de métriques de tickets Zendesk (/api/v2/ticket_metrics.json), champ satisfaction_rating.score. Exemples bonmauvaisoffertunoffered
	Organisation cliente Organization	L'organisation ou l'entreprise à laquelle appartient le demandeur de l'incident.
Description Cet attribut lie un incident à l'organisation du client. Il est essentiel pour les environnements de support B2B où les niveaux de service et les processus de support peuvent varier selon le client.\n\nL'analyse des incidents par organisation permet aux équipes de support de surveiller la santé des clients, d'identifier les problèmes récurrents affectant des clients spécifiques et de s'assurer que les obligations contractuelles sont respectées. C'est une dimension clé pour filtrer les dashboards et les rapports afin de fournir une vue de la performance centrée sur le client. Pourquoi c'est important Permet une analyse spécifique au client, aidant à surveiller les niveaux de service, à identifier les tendances pour les comptes clés et à gérer efficacement les relations client. Où obtenir API de tickets Zendesk, champ organization_id. Exemples Global Tech Inc.Innover des SolutionsData Corp
	Tags Tags	Une liste de tags appliqués à l'incident pour la catégorisation et le contexte.
Description Les tags sont des étiquettes flexibles qui peuvent être ajoutées aux tickets pour fournir un contexte supplémentaire ou aider à la catégorisation et au routage. Ils peuvent être ajoutés manuellement par les agents ou automatiquement via des déclencheurs et des automatisations.\n\nLes tags sont une source riche de données pour l'analyse par process mining. Ils peuvent être utilisés pour créer des segments d'analyse granulaires, tels que le filtrage des incidents liés à un lancement de produit spécifique ('launch_q4') ou à une panne connue ('outage_20231027'). Cette flexibilité permet des investigations approfondies qui vont au-delà des champs de ticket standards. Pourquoi c'est important Offre une méthode flexible pour catégoriser et filtrer les incidents, permettant une analyse détaillée et contextuelle qui ne serait pas possible avec les seuls champs standards. Où obtenir API de tickets Zendesk, champ tags. Exemples vip_usernetwork_issueoutage_20231027billing_related
	Temps de traitement ProcessingTime	La durée d'une seule activité, représentant le temps passé à travailler activement sur une tâche.
Description Cette métrique mesure le temps écoulé du début d'une activité à sa fin. Elle est calculée comme la différence entre EventEndTime et EventTimestamp pour chaque ligne du journal d'événements.\n\nLe temps de traitement, également connu sous le nom de durée d'activité, aide à différencier le temps de travail actif du temps d'inactivité ou d'attente. Dans le dashboard 'Vue d'ensemble des activités goulots d'étranglement', des temps de traitement moyens élevés pour certaines activités peuvent indiquer des tâches complexes et chronophages. Ceci est distinct du temps d'attente, qui représente les retards entre les tâches. Pourquoi c'est important Mesure le temps de travail actif pour des activités spécifiques, aidant à identifier les tâches qui sont intrinsèquement chronophages et sont candidates à la simplification ou à l'automatisation. Où obtenir Calculé comme la différence entre EventEndTime et EventTimestamp pour chaque activité. Exemples 30018003600
	Type de ticket TicketType	La classification du ticket, telle que '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 se concentre spécifiquement sur les tickets dont le type est 'Incident', représentant une interruption imprévue ou une réduction de la qualité d'un service IT.\n\nEn analyse, cet attribut est principalement utilisé comme filtre pour s'assurer que seuls les incidents sont inclus 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 par rapport aux problèmes ou aux demandes de service. Pourquoi c'est important Permet de filtrer les données pour se concentrer spécifiquement sur les incidents, garantissant que l'analyse des processus est pertinente pour le cycle de vie de la gestion des incidents. Où obtenir API de tickets Zendesk, champ type. Exemples incidentproblemquestiontask

Obligatoire Recommandé Facultatif

Activités de gestion des incidents

Ce sont les étapes et les jalons critiques du processus à capturer dans votre journal d'événements pour une découverte et une analyse précises.

6 Recommandé 7 Facultatif

	Activité	Description
	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 capturé explicitement via le journal d'audit de création de ticket de Zendesk, servant de point de départ pour chaque cas.
Pourquoi c'est important C'est l'activité de démarrage primaire. L'analyse du temps entre cet événement et les autres est cruciale pour mesurer la durée globale du cycle de vie du ticket et les temps de réponse initiaux. Où obtenir C'est un événement explicite capturé dans les journaux d'audit des tickets Zendesk. Chaque nouveau ticket génère un événement 'Créer' avec un horodatage correspondant. Capture Directement à partir de l'événement de création du ticket dans le journal d'audit. Type d'événement explicit
	Incident fermé	Marque la fin finale du cycle de vie de l'incident lorsque le ticket est définitivement fermé. Dans Zendesk, cela se produit souvent automatiquement après une période définie après avoir été résolu, et est capturé comme un changement de statut final.
Pourquoi c'est important C'est l'activité finale définitive du processus. La durée totale du processus est calculée de 'Incident créé' à cet événement, offrant une vue de bout en bout du temps de cycle. Où obtenir Capturé à partir du journal d'audit du ticket via un événement de 'Changement' où la nouvelle valeur du champ 'statut' devient 'fermé'. Capture Identifié par un événement de 'Changement' pour le champ 'statut' à 'fermé'. Type d'événement explicit
	Incident résolu	Ce jalon clé se produit lorsqu'un agent a implémenté une solution et marque le ticket comme 'résolu'. Il s'agit d'une action explicite, capturée comme un changement de statut dans le journal d'audit du ticket.
Pourquoi c'est important C'est l'activité de résolution primaire et un point critique pour mesurer le temps de résolution. Le temps entre cet événement et 'Incident fermé' représente la période de confirmation utilisateur ou de clôture automatique. Où obtenir Capturé à partir du journal d'audit du ticket via un événement de 'Changement' où la nouvelle valeur du champ 'statut' devient 'résolu'. Capture Identifié par un événement de 'Changement' pour le champ 'statut' à 'résolu'. Type d'événement explicit
	Statut passé à « Ouvert »	Indique qu'un agent a commencé à travailler activement sur l'incident. Cette activité est généralement déduite du changement du champ 'statut' du ticket de 'nouveau' à 'ouvert', signifiant le début de la phase d'investigation et de diagnostic.
Pourquoi c'est important Cet événement marque la transition de la mise en file d'attente au travail actif. La durée pendant laquelle les tickets restent en statut 'nouveau' avant de passer à 'ouvert' est une métrique clé pour le temps de réponse initial. Où obtenir Déduit du journal d'audit du ticket en identifiant un événement de 'Changement' où la nouvelle valeur du champ 'statut' est 'ouvert' et la valeur précédente était 'nouveau'. Capture Déduit d'un changement de champ de statut de 'nouveau' à 'ouvert'. Type d'événement inferred
	Ticket Assigné à un Agent	Cette activité se produit lorsqu'un ticket est assigné à un agent spécifique pour traitement. Il s'agit d'un événement explicite enregistré dans l'historique d'audit du ticket et signifie qu'un individu en a pris la responsabilité.
Pourquoi c'est important Ce jalon est essentiel pour mesurer le temps de première affectation et constitue la base pour analyser les transferts, le retravail et les taux de résolution au premier contact. Où obtenir Capturé à partir du journal d'audit du ticket lorsque le champ 'assignee_id' est renseigné ou modifié. La première affectation est une étape clé pour le calcul des KPI. Capture Identifié par un événement de 'Changement' pour le champ 'assignee_id' dans le journal d'audit du ticket. Type d'événement explicit
	Ticket réaffecté	Se produit lorsque la propriété du 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 essentielles pour analyser les transferts et le retravail. Une fréquence élevée de réaffectations indique souvent un routage initial incorrect, des problèmes complexes ou des goulots d'étranglement dans le processus. Où obtenir Capturé à partir du journal d'audit du ticket en identifiant un événement de 'Changement' sur le champ 'assignee_id' ou 'group_id' après sa première saisie. Capture Identifié par un événement de 'Changement' ultérieur pour le champ 'assignee_id' ou 'group_id'. Type d'événement explicit
	Note interne ajoutée	Cette activité signifie une collaboration interne, où un agent ajoute une note privée au ticket pour les autres membres de l'équipe. Ceci est explicitement capturé lorsqu'un commentaire est marqué comme non public.
Pourquoi c'est important L'analyse des notes internes peut fournir des informations sur les problèmes complexes nécessitant une collaboration, mais un nombre excessif peut indiquer des lacunes de connaissances ou des inefficacités de processus. Où obtenir Capturé à partir des données de commentaires du ticket. Un commentaire est identifié comme une note interne lorsque son attribut 'public' est faux. Capture Événement enregistré lorsqu'un nouveau commentaire avec 'public: false' est ajouté au ticket. Type d'événement explicit
	Objectif SLA non respecté	Marque le moment où un ticket n'a pas respecté un accord de niveau de service (SLA) défini, tel que le temps de première réponse ou le temps de résolution. Cet événement est calculé sur la base des définitions de politique SLA et des horodatages de mise à jour des tickets.
Pourquoi c'est important Cet événement soutient directement le suivi de la conformité aux SLA. Identifier quand et pourquoi les non-conformités surviennent est fondamental pour améliorer la fiabilité du service et la confiance des clients. Où obtenir C'est un événement calculé. Il peut être dérivé en analysant les données 'sla_policy_metrics' associées à un ticket, en utilisant l'horodatage 'breached_at' pour chaque objectif SLA. Capture Dérivé de l'horodatage 'breached_at' dans les données de métrique SLA du ticket. Type d'événement calculated
	Priorité Définie	Le niveau de priorité d'un incident (par exemple, Faible, Normal, Élevé, Urgent) est défini. Cela est enregistré comme un événement de changement explicite et dicte l'urgence et le temps 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 vital pour le dashboard 'Mesures d'efficacité de la priorisation', garantissant que les problèmes critiques sont traités rapidement. Où obtenir Capturé à partir d'un événement de 'Changement' sur le champ 'priority' dans le journal d'audit du ticket. Les changements ultérieurs peuvent également être suivis pour mesurer le KPI (Key Performance Indicator) du Taux de changement de priorité. Capture Identifié par un événement de 'Changement' pour 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 de communication et peut être un élément clé de la chronologie lors de l'analyse des retards de confirmation de l'utilisateur. Où obtenir Capturé à partir des données de commentaires du ticket. Un commentaire est identifié comme public lorsque son attribut 'public' est vrai. Capture Événement enregistré lorsqu'un nouveau commentaire avec 'public: true' est ajouté au ticket. Type d'événement explicit
	Satisfaction utilisateur évaluée	Représente le moment où l'utilisateur final attribue une note de satisfaction pour le support reçu. Il s'agit d'un événement explicite enregistré dans Zendesk après la résolution d'un ticket.
Pourquoi c'est important L'analyse des évaluations de satisfaction fournit un retour d'information crucial sur la performance des agents et l'efficacité des processus, liant les métriques de processus aux résultats clients. Où obtenir Capturé à partir des données d'évaluation de satisfaction associées au ticket. Cela inclut généralement un score ('bon' ou 'mauvais') et un commentaire facultatif. Capture Événement enregistré lorsqu'une évaluation de satisfaction est soumise pour le ticket. Type d'événement explicit
	Statut changé à En attente	Indique que le processus est en pause en attendant une réponse du demandeur. Cet événement est déduit du changement du champ 'statut' du ticket à 'en attente'.
Pourquoi c'est important Cette activité est cruciale pour le calcul du temps d'attente de confirmation de l'utilisateur. De longues durées dans cet état peuvent augmenter considérablement le temps de résolution global et souligner les retards de communication. Où obtenir Déduit du journal d'audit du ticket en identifiant un événement de 'Changement' où la nouvelle valeur du champ 'statut' est 'en attente'. Capture Déduit d'un changement de champ de statut à 'en attente'. Type d'événement inferred
	Ticket assigné à un groupe	Représente le routage initial ou le triage d'un incident vers un groupe de support spécifique. Il s'agit généralement de la première étape d'attribution des responsabilités et est enregistré comme un événement de changement explicite dans l'historique d'audit du ticket.
Pourquoi c'est important Le suivi des affectations de groupe aide à analyser l'efficacité du processus de triage initial et à identifier les retards avant qu'un ticket ne soit acheminé vers la bonne équipe. Où obtenir Capturé à partir du journal d'audit du ticket chaque fois que le champ 'group_id' est défini ou modifié. La première occurrence de ce changement après la création est l'affectation initiale. Capture Identifié par un événement de 'Changement' pour le champ 'group_id' dans le journal d'audit du ticket. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Zendesk Support

Étapes

Accéder à Zendesk Explore: Connectez-vous à votre instance Zendesk Support avec un compte utilisateur disposant des permissions pour créer et gérer des rapports dans Zendesk Explore.
Créer un nouveau rapport: Naviguez vers le module Explore. Cliquez sur l'icône 'Rapports' dans la barre de navigation de gauche, puis sur le bouton 'Nouveau rapport'.
Sélectionner le jeu de données: Dans la fenêtre 'Choisir un jeu de données', sélectionnez le jeu de données Support: Ticket updates [default]. Ce jeu de données contient la piste d'audit pour chaque modification de ticket, ce qui est essentiel pour créer un journal d'événements.
Ajouter les attributs initiaux (Colonnes): Dans le générateur de rapports, allez à la section 'Lignes'. Cliquez sur 'Ajouter' et sélectionnez les attributs suivants. Ceux-ci formeront les colonnes de votre journal d'événements : ID du ticket, Horodatage de mise à jour, Statut du ticket, Nom de l'assigné, Groupe de tickets, Priorité du ticket, Canal du ticket, Changements - Nom du champ, Changements - Valeur précédente, Changements - Nouvelle valeur, Commentaire public.
Créer des attributs calculés: C'est l'étape la plus critique. Allez dans le menu 'Calculs' (l'icône en forme de bécher) et sélectionnez 'Attribut calculé standard'. Créez les trois attributs définis dans la section 'Requête' ci-dessous : ActivityName, SourceSystem et LastDataUpdate. Vous devrez copier les formules fournies exactement.
Affiner les colonnes du rapport: Ajoutez vos attributs calculés nouvellement créés (ActivityName, SourceSystem, LastDataUpdate) à la section 'Lignes'. Vous pouvez maintenant supprimer les champs bruts utilisés pour créer ActivityName (Changements - Nom du champ, Changements - Valeur précédente, Changements - Nouvelle valeur, Commentaire public) pour nettoyer la vue.
Ajouter des filtres de rapport: Go to the 'Filters' section and click 'Add'. Ajoutez un filtre pour Date de mise à jour et sélectionnez une plage de dates appropriée (par exemple, les 3 derniers mois). Ajoutez un autre filtre sur votre attribut calculé ActivityName et excluez les valeurs nulles pour supprimer toutes les mises à jour de ticket qui ne correspondent pas à une activité souhaitée.
Exécuter et réviser le rapport: Zendesk Explore mettra automatiquement à jour le rapport au fur et à mesure que vous ajoutez des attributs et des filtres. Examinez le tableau de données pour vous assurer que les lignes et les colonnes apparaissent comme prévu. Le rapport doit afficher une ligne par événement.
Exporter les données au format CSV: Une fois le rapport finalisé, cliquez sur le bouton 'Exporter' en haut à droite et sélectionnez 'CSV'. Zendesk générera et téléchargera le fichier CSV.
Préparer le téléchargement: Ouvrez le fichier CSV exporté. Renommez les en-têtes de colonne pour qu'ils correspondent aux noms d'attributs requis pour votre outil de Process Mining (par exemple, renommez 'Ticket ID' en TicketId, 'Update - Timestamp' en EventTimestamp). Assurez-vous que le format de date des horodatages est conforme à la norme ISO 8601. Le fichier est maintenant prêt pour le téléchargement.

Configuration

Jeu de données Zendesk: Le rapport doit être basé sur le jeu de données Support: Ticket updates [default]. C'est le 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 plage de dates: Il est crucial d'appliquer un filtre de dates pour limiter le volume de données. Utilisez l'attribut Date de mise à jour comme filtre principal. Une plage de données de 3 à 6 mois est généralement recommandée pour une analyse initiale.
Filtre d'activité: Après avoir créé l'attribut calculé ActivityName, vous devez filtrer le rapport pour exclure les lignes où cette valeur est nulle. Cela supprime les modifications de ticket non pertinentes (par exemple, les mises à jour système, les changements de tags) de votre journal d'événements.
Attributs calculés: La logique de cette extraction repose fortement sur un attribut calculé standard pour traduire les changements bruts des champs de ticket en noms d'activités lisibles par l'homme. La précision de la formule est essentielle.
Prérequis: L'utilisateur exécutant le rapport doit disposer au minimum du rôle 'Lecteur' dans Zendesk Explore. Pour créer et enregistrer le rapport, des permissions 'Éditeur' ou 'Admin' sont requises.

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: Assurez-vous d'avoir Python 3.6+ installé sur votre système ainsi que les bibliothèques requests et pandas. Vous pouvez les installer en utilisant pip: pip install requests pandas.
Générer un jeton API Zendesk: Connectez-vous à votre instance Zendesk Support en tant qu'administrateur. Naviguez vers le Centre d'administration > Applications et intégrations > APIs > Zendesk APIs. Dans la section "Jetons API", ajoutez un nouveau jeton API actif et enregistrez en toute sécurité la chaîne du jeton généré.
Configurer le script Python: Créez un nouveau fichier Python (par exemple, extract_zendesk_logs.py) et copiez-y le script fourni. Mettez à jour les variables d'espace réservé en haut du script : ZENDESK_SUBDOMAIN, ZENDESK_EMAIL et ZENDESK_API_TOKEN avec vos identifiants spécifiques. Définissez le START_TIMESTAMP pour déterminer le début de votre période d'extraction de données souhaitée (un horodatage Unix epoch).
Comprendre les points d'API: Le script utilise principalement deux points d'API Zendesk. Le point d'API incremental/tickets/cursor.json est utilisé pour extraire efficacement tous les tickets mis à jour depuis le START_TIMESTAMP. Pour chaque ticket, le script appelle ensuite le point d'API tickets/{ticket_id}/audits.json pour obtenir un historique détaillé de chaque changement et événement.
Exécuter le script: Exécutez le script depuis votre terminal en utilisant la commande : python extract_zendesk_logs.py. Le script commencera à récupérer les données de l'API Zendesk.
Surveiller la progression du script: Le script affichera le nombre de tickets traités dans la console, vous permettant de surveiller sa progression. Selon la plage de dates et le volume de tickets, cela peut prendre un temps significatif.
Récupération des données et pagination: Le script gère automatiquement la pagination de l'API. Il commence par l'URL d'exportation de ticket initiale et suit l'after_url fourni dans chaque réponse de l'API jusqu'à ce que tous les tickets pour la période aient été récupérés.
Transformation des événements: Pour chaque ticket, le script parcourt son historique d'audit. Il analyse chaque événement d'audit, mappant les types d'événements internes de Zendesk (comme Créer, Modifier, Commenter) aux activités commerciales requises (comme Incident Créé, Statut Passé à Ouvert, Réponse Publique Envoyée).
Gestion des données SLA: Le script inclut une fonction dédiée, get_sla_breach_events, pour récupérer les métriques SLA pour chaque ticket résolu. Cela est nécessaire car les violations de SLA ne sont pas des événements standard dans le journal d'audit. Cette fonction effectue un appel API supplémentaire pour obtenir les détails d'application de la politique SLA.
Générer le journal d'événements: Une fois tous les tickets traités, le script compile les événements extraits dans un DataFrame pandas et enregistre le journal d'événements final sous forme de fichier CSV nommé zendesk_incident_event_log.csv dans le même répertoire où le script a été exécuté.
Préparer le téléchargement: Vérifiez l'exactitude du fichier CSV généré. Ce fichier est maintenant au format requis pour être téléchargé directement dans ProcessMind pour analyse.

Configuration

Identifiants API Zendesk: Vous devez fournir votre sous-domaine Zendesk, l'adresse e-mail associée à un compte administrateur ou agent, et un jeton API valide. Stockez ces identifiants en toute sécurité et ne les codez pas en dur dans des scripts versionnés pour une utilisation en production.
Horodatage de début (START_TIMESTAMP): Cette valeur entière détermine le point de départ de l'extraction des données. Il doit s'agir d'un horodatage Unix epoch. Il est recommandé de choisir une période de 3 à 6 mois en arrière pour collecter une quantité de données significative sans surcharger le système. Vous pouvez utiliser un convertisseur en ligne pour obtenir l'horodatage correct pour une date spécifique.
Limitation du taux d'appels API: Le script effectue de nombreux appels API. Zendesk impose des limites de taux, qui varient selon le plan. Bien que le script soit fonctionnel pour des volumes de données modérés, pour des instances très volumineuses, vous devrez peut-être ajouter des appels time.sleep() dans les boucles pour éviter d'atteindre la limite de taux et de recevoir une erreur 429.
Bibliothèques Python requises: Le script dépend de la bibliothèque requests pour les appels API et de la bibliothèque pandas pour la manipulation des données et l'exportation CSV. Assurez-vous qu'elles sont installées dans votre environnement Python.
Permissions utilisateur: Le compte utilisateur associé au jeton API doit disposer des permissions suffisantes pour lire les données des tickets, y compris les audits et les métriques 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

Prérequis: Assurez-vous d'avoir Python 3.6+ installé sur votre système ainsi que les bibliothèques requests et pandas. Vous pouvez les installer en utilisant pip: pip install requests pandas.
Générer un jeton API Zendesk: Connectez-vous à votre instance Zendesk Support en tant qu'administrateur. Naviguez vers le Centre d'administration > Applications et intégrations > APIs > Zendesk APIs. Dans la section "Jetons API", ajoutez un nouveau jeton API actif et enregistrez en toute sécurité la chaîne du jeton généré.
Configurer le script Python: Créez un nouveau fichier Python (par exemple, extract_zendesk_logs.py) et copiez-y le script fourni. Mettez à jour les variables d'espace réservé en haut du script : ZENDESK_SUBDOMAIN, ZENDESK_EMAIL et ZENDESK_API_TOKEN avec vos identifiants spécifiques. Définissez le START_TIMESTAMP pour déterminer le début de votre période d'extraction de données souhaitée (un horodatage Unix epoch).
Comprendre les points d'API: Le script utilise principalement deux points d'API Zendesk. Le point d'API incremental/tickets/cursor.json est utilisé pour extraire efficacement tous les tickets mis à jour depuis le START_TIMESTAMP. Pour chaque ticket, le script appelle ensuite le point d'API tickets/{ticket_id}/audits.json pour obtenir un historique détaillé de chaque changement et événement.
Exécuter le script: Exécutez le script depuis votre terminal en utilisant la commande : python extract_zendesk_logs.py. Le script commencera à récupérer les données de l'API Zendesk.
Surveiller la progression du script: Le script affichera le nombre de tickets traités dans la console, vous permettant de surveiller sa progression. Selon la plage de dates et le volume de tickets, cela peut prendre un temps significatif.
Récupération des données et pagination: Le script gère automatiquement la pagination de l'API. Il commence par l'URL d'exportation de ticket initiale et suit l'after_url fourni dans chaque réponse de l'API jusqu'à ce que tous les tickets pour la période aient été récupérés.
Transformation des événements: Pour chaque ticket, le script parcourt son historique d'audit. Il analyse chaque événement d'audit, mappant les types d'événements internes de Zendesk (comme Créer, Modifier, Commenter) aux activités commerciales requises (comme Incident Créé, Statut Passé à Ouvert, Réponse Publique Envoyée).
Gestion des données SLA: Le script inclut une fonction dédiée, get_sla_breach_events, pour récupérer les métriques SLA pour chaque ticket résolu. Cela est nécessaire car les violations de SLA ne sont pas des événements standard dans le journal d'audit. Cette fonction effectue un appel API supplémentaire pour obtenir les détails d'application de la politique SLA.
Générer le journal d'événements: Une fois tous les tickets traités, le script compile les événements extraits dans un DataFrame pandas et enregistre le journal d'événements final sous forme de fichier CSV nommé zendesk_incident_event_log.csv dans le même répertoire où le script a été exécuté.
Préparer le téléchargement: Vérifiez l'exactitude du fichier CSV généré. Ce fichier est maintenant au format requis pour être téléchargé directement dans ProcessMind pour analyse.

Configuration

Identifiants API Zendesk: Vous devez fournir votre sous-domaine Zendesk, l'adresse e-mail associée à un compte administrateur ou agent, et un jeton API valide. Stockez ces identifiants en toute sécurité et ne les codez pas en dur dans des scripts versionnés pour une utilisation en production.
Horodatage de début (START_TIMESTAMP): Cette valeur entière détermine le point de départ de l'extraction des données. Il doit s'agir d'un horodatage Unix epoch. Il est recommandé de choisir une période de 3 à 6 mois en arrière pour collecter une quantité de données significative sans surcharger le système. Vous pouvez utiliser un convertisseur en ligne pour obtenir l'horodatage correct pour une date spécifique.
Limitation du taux d'appels API: Le script effectue de nombreux appels API. Zendesk impose des limites de taux, qui varient selon le plan. Bien que le script soit fonctionnel pour des volumes de données modérés, pour des instances très volumineuses, vous devrez peut-être ajouter des appels time.sleep() dans les boucles pour éviter d'atteindre la limite de taux et de recevoir une erreur 429.
Bibliothèques Python requises: Le script dépend de la bibliothèque requests pour les appels API et de la bibliothèque pandas pour la manipulation des données et l'exportation CSV. Assurez-vous qu'elles sont installées dans votre environnement Python.
Permissions utilisateur: Le compte utilisateur associé au jeton API doit disposer des permissions suffisantes pour lire les données des tickets, y compris les audits et les métriques 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

Accéder à Zendesk Explore: Connectez-vous à votre instance Zendesk Support avec un compte utilisateur disposant des permissions pour créer et gérer des rapports dans Zendesk Explore.
Créer un nouveau rapport: Naviguez vers le module Explore. Cliquez sur l'icône 'Rapports' dans la barre de navigation de gauche, puis sur le bouton 'Nouveau rapport'.
Sélectionner le jeu de données: Dans la fenêtre 'Choisir un jeu de données', sélectionnez le jeu de données Support: Ticket updates [default]. Ce jeu de données contient la piste d'audit pour chaque modification de ticket, ce qui est essentiel pour créer un journal d'événements.
Ajouter les attributs initiaux (Colonnes): Dans le générateur de rapports, allez à la section 'Lignes'. Cliquez sur 'Ajouter' et sélectionnez les attributs suivants. Ceux-ci formeront les colonnes de votre journal d'événements : ID du ticket, Horodatage de mise à jour, Statut du ticket, Nom de l'assigné, Groupe de tickets, Priorité du ticket, Canal du ticket, Changements - Nom du champ, Changements - Valeur précédente, Changements - Nouvelle valeur, Commentaire public.
Créer des attributs calculés: C'est l'étape la plus critique. Allez dans le menu 'Calculs' (l'icône en forme de bécher) et sélectionnez 'Attribut calculé standard'. Créez les trois attributs définis dans la section 'Requête' ci-dessous : ActivityName, SourceSystem et LastDataUpdate. Vous devrez copier les formules fournies exactement.
Affiner les colonnes du rapport: Ajoutez vos attributs calculés nouvellement créés (ActivityName, SourceSystem, LastDataUpdate) à la section 'Lignes'. Vous pouvez maintenant supprimer les champs bruts utilisés pour créer ActivityName (Changements - Nom du champ, Changements - Valeur précédente, Changements - Nouvelle valeur, Commentaire public) pour nettoyer la vue.
Ajouter des filtres de rapport: Go to the 'Filters' section and click 'Add'. Ajoutez un filtre pour Date de mise à jour et sélectionnez une plage de dates appropriée (par exemple, les 3 derniers mois). Ajoutez un autre filtre sur votre attribut calculé ActivityName et excluez les valeurs nulles pour supprimer toutes les mises à jour de ticket qui ne correspondent pas à une activité souhaitée.
Exécuter et réviser le rapport: Zendesk Explore mettra automatiquement à jour le rapport au fur et à mesure que vous ajoutez des attributs et des filtres. Examinez le tableau de données pour vous assurer que les lignes et les colonnes apparaissent comme prévu. Le rapport doit afficher une ligne par événement.
Exporter les données au format CSV: Une fois le rapport finalisé, cliquez sur le bouton 'Exporter' en haut à droite et sélectionnez 'CSV'. Zendesk générera et téléchargera le fichier CSV.
Préparer le téléchargement: Ouvrez le fichier CSV exporté. Renommez les en-têtes de colonne pour qu'ils correspondent aux noms d'attributs requis pour votre outil de Process Mining (par exemple, renommez 'Ticket ID' en TicketId, 'Update - Timestamp' en EventTimestamp). Assurez-vous que le format de date des horodatages est conforme à la norme ISO 8601. Le fichier est maintenant prêt pour le téléchargement.

Configuration

Jeu de données Zendesk: Le rapport doit être basé sur le jeu de données Support: Ticket updates [default]. C'est le 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 plage de dates: Il est crucial d'appliquer un filtre de dates pour limiter le volume de données. Utilisez l'attribut Date de mise à jour comme filtre principal. Une plage de données de 3 à 6 mois est généralement recommandée pour une analyse initiale.
Filtre d'activité: Après avoir créé l'attribut calculé ActivityName, vous devez filtrer le rapport pour exclure les lignes où cette valeur est nulle. Cela supprime les modifications de ticket non pertinentes (par exemple, les mises à jour système, les changements de tags) de votre journal d'événements.
Attributs calculés: La logique de cette extraction repose fortement sur un attribut calculé standard pour traduire les changements bruts des champs de ticket en noms d'activités lisibles par l'homme. La précision de la formule est essentielle.
Prérequis: L'utilisateur exécutant le rapport doit disposer au minimum du rôle 'Lecteur' dans Zendesk Explore. Pour créer et enregistrer le rapport, des permissions 'Éditeur' ou 'Admin' sont requises.

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()
```

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

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

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d'extraction

Exportation du rapport de l'interface utilisateur Zendesk Explore vers un fichier CSV

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST de Zendesk Support

Étapes

Configuration

a Exemple de requête python

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

É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(e) à démarrer ?

Optimisez la gestion des incidents, résolvez plus vite dès aujourd'hui

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

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

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d'extraction

Exportation du rapport de l'interface utilisateur Zendesk Explore vers un fichier CSV

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST de Zendesk Support

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête python

Outil ETL tiers avec connecteur API Zendesk

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimisez la gestion des incidents, résolvez plus vite dès aujourd'hui