> Amélioration Continue des Processusus > Gestion des incidents > Zendesk Support > Template de données

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

Zendesk Support

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

Votre modèle de données 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 complet et fiable.

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

Vous découvrez 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 détaillée de votre processus de gestion des incidents.

5 Obligatoire 7 Recommandé 11 Facultatif

	Nom	Descriptionn
	Horodatage de l'événement EventTimestamp	La date et l'heure exactes de l'activité.
Descriptionn 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. Elle fournit l'ordre chronologique de toutes les activités au sein d'un cas.\n\nCet attribut est indispensable 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 est-ce important ? : Les horodatages fournissent le contexte chronologique de toutes les activités, permettant le calcul des durées, l'identification des points de blocage et l'analyse de la performance du processus au fil du temps. Source des données : 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
	ID d'incident TicketId	L'identifiant unique généré par le système pour chaque ticket d'incident.
Descriptionn 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 impératif pour reconstituer le parcours complet 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 écarts par rapport à la procédure standard. Pourquoi est-ce 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. Source des données : API de tickets Zendesk (/api/v2/tickets/{id}), champ id. Exemples 19428230113521941055
	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.
Descriptionn 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 cartographie 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 points de blocage entre les étapes, mesurer les boucles de reprise (par exemple, la réouverture d'un ticket résolu) et vérifier la conformité par rapport à un processus standard défini. Pourquoi est-ce 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 écarts et les opportunités d'amélioration. Source des données : 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 modélisé à '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.
Descriptionn Cet attribut consigne 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 fondamentale pour la gouvernance des données et pour les utilisateurs de l'analyse par process mining. Elle fournit un contexte sur la la réactualisation 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 est-ce important ? : Fournit un contexte essentiel sur la la réactualisation des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse et la date de la dernière extraction des données. Source des données : 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.
Descriptionn 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 indispensable 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 est-ce important ? : Identifie l'origine des données, ce qui est impératif pour la gouvernance des données et pour les analyses qui combinent des données provenant de plusieurs systèmes source. Source des données : 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.
Descriptionn 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 indispensable 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 est-ce important ? : Identifie l'agent responsable, permettant l'analyse de la charge de travail et le suivi des transferts, ce qui est impératif pour identifier les inefficacités des processus. Source des données : API de tickets Zendesk, champ assignee_id. Les changements sont enregistrés dans l'API Ticket Audits. Exemples John SmithJane DoeAutomatisation du Centre de services
	Canal de signalement Channel	Le canal par lequel l'incident a été initialement signalé, tel que 'Email', 'Web' ou 'API'.
Descriptionn 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 tableau de bord 'Volume de Traitement des facturess factures fournisseurs factures fournisseurs Incidents' et aide aux efforts de planification des ressources et d'optimisation des canaux. Pourquoi est-ce 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. Source des données : API de tickets Zendesk, champ via.channel. Exemples webemailapiphone
	Groupe assigné AssignedGroup	L'équipe ou le groupe de support actuellement assigné à l'incident.
Descriptionn 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 majeure pour l'analyse des transferts de processus et l'identification des points de blocage. 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 tableau de bord 'Analyse des Transferts et du Retravail'. Pourquoi est-ce important ? : Suit la responsabilité de l'équipe, ce qui est indispensable pour analyser les transferts inter-équipes, identifier les points de blocage spécifiques à l'équipe et mesurer les temps d'attente. Source des données : 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.
Descriptionn 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 indispensable 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 points de blocage, 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 est-ce important ? : Permet le calcul des durées d'activité et des temps d'attente, ce qui est indispensable pour effectuer une analyse détaillée des points de blocage et identifier les retards de processus. Source des données : 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'.
Descriptionn 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 dans 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 est-ce important ? : Cet attribut est impératif pour segmenter l'analyse, évaluer l'efficacité de la priorisation et surveiller la conformité aux SLA pour différents niveaux d'urgence. Source des données : 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'.
Descriptionn 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 clée 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 est-ce important ? : Le suivi des changements de statut est indispensable 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. Source des données : 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.
Descriptionn 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 tableau de bord '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 contribue directement au le KPI 'Taux de résolutionpect des SLA des incidents'. Pourquoi est-ce 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é. Source des données : 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 profonde RootCauseCategory	La catégorie de haut niveau de la cause profonde sous-jacente de l'incident.
Descriptionn Cet attribut est utilisé pour classer la raison clée 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 indispensables pour le tableau de bord '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 est-ce 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. Source des données : 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.
Descriptionn 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 est-ce 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. Source des données : 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.
Descriptionn Cette métrique calculée représente le temps de cycle complet 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 est-ce important ? : C'est un KPI clé pour mesurer la vélocité globale du processus et identifier les facteurs qui contribuent aux longs temps de résolution. Source des données : 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.
Descriptionn 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 impératif 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 est-ce important ? : Distingue les actions humaines des actions système, ce qui est indispensable pour analyser l'impact de l'automatisation sur l'efficacité des processus et identifier de nouvelles opportunités d'automatisation. Source des données : 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-ce 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).
Descriptionn La résolution au premier contact (FCR) est une indicateur clé 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 est-ce 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. Source des données : 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é.
Descriptionn 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 est-ce 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. Source des données : 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.
Descriptionn 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 indispensablele pour le tableau de bord 'Analyse des Transferts et du Retravail'. Pourquoi est-ce 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. Source des données : Calculé en comptant le nombre de fois où le champ AssignedGroup ou Assignee a changé pour un incident. Exemples 0135
	Organisation cliente Organization	L'organisation ou l'entreprise à laquelle appartient le demandeur de l'incident.
Descriptionn Cet attribut lie un incident à l'organisation du client. Il est indispensable 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 orientée client. Pourquoi est-ce 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. Source des données : API de tickets Zendesk, champ organization_id. Exemples Global Tech Inc.Solutions InnovantesData Corp
	Tags Tags	Une liste de tags appliqués à l'incident pour la catégorisation et le contexte.
Descriptionn 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 enquêtes approfondies qui vont au-delà des champs de ticket standards. Pourquoi est-ce 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. Source des données : API de tickets Zendesk, champ tags. Exemples vip_usernetwork_issueoutage_20231027billing_related
	Taux de satisfaction SatisfactionRating	La note de satisfaction fournie par l'utilisateur final après la résolution de l'incident.
Descriptionn 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 est-ce important ? : Fournit une indicateur de résultat majeur qui peut être corrélée aux caractéristiques du processus pour comprendre comment la performance du processus impacte la satisfaction de l'utilisateur. Source des données : API de métriques de tickets Zendesk (/api/v2/ticket_metrics.json), champ satisfaction_rating.score. Exemples bonmauvaisoffertunoffered
	Type de ticket TicketType	La classification du ticket, telle que 'Incident', 'Problème', 'Question' ou 'Tâche'.
Descriptionn 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 est-ce 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. Source des données : 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é	Descriptionn
	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 est-ce important ? : C'est l'activité de démarrage primaire. L'analyse du temps entre cet événement et les autres est indispensablele pour mesurer la durée globale du cycle de vie du ticket et les temps de réponse initiaux. Source des données : 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 est-ce 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 complet du temps de cycle. Source des données : 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 est-ce 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. Source des données : 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 est-ce 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. Source des données : 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 « what-if »gnifie qu'un individu en a pris la responsabilité.
Pourquoi est-ce important ? : Ce jalon est indispensable pour mesurer le temps de première affectation et constitue la base pour analyser les transferts, les reprises et les taux de résolution au premier contact. Source des données : 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 est-ce important ? : Les réaffectations sont essentielles pour analyser les transferts et les reprises. Une fréquence élevée de réaffectations indique souvent un routage initial incorrect, des problèmes complexes ou des points de blocage dans le processus. Source des données : 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 est-ce 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. Source des données : 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 est-ce important ? : Cet événement contribue directement au le suivi de la conformité aux SLA. Identifier quand et pourquoi les non-conformités surviennent est indispensable pour améliorer la fiabilité du service et la confiance des clients. Source des données : 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 est-ce important ? : Le suivi du moment et de la manière dont la priorité est définie est indispensable à le tableau de bord 'Mesures d'efficacité de la priorisation', garantissant que les problèmes critiques sont traités rapidement. Source des données : 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 est-ce 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. Source des données : 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 est-ce 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. Source des données : 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 est-ce important ? : Cette activité est indispensablele 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. Source des données : 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 est-ce 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. Source des données : 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 indispensable 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 - Horodatage' en EventHorodatage). 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 impératif 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 indispensablele.
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, faisant correspondre 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, faisant correspondre 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 indispensable 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 - Horodatage' en EventHorodatage). 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 impératif 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 indispensablele.
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