> Amélioration continue des processus > Gestion des problèmes > Assistance Zendesk > Modèle de données

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

Assistance Zendesk

Attributs de la Gestion des problèmes(19) Activités de la Gestion des problèmes(12) Guides d’extraction(3)

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

Ce modèle fournit un cadre complet pour cartographier le cycle de vie de la gestion des problèmes dans Zendesk Support. Il présente les attributs essentiels, les jalons du processus et la logique d’extraction nécessaires pour repérer les goulots d’étranglement dans l’analyse des causes premières. En suivant cette structure, vous pouvez créer un journal d’événements de qualité pour approfondir l’analyse de vos processus.

Attributs recommandés pour une analyse détaillée
Activités clés du processus et transitions de statut
Guide d’extraction des données Zendesk Support

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

Télécharger le modèle

Attributs de la Gestion des problèmes

Ces champs de données recommandés fournissent le contexte nécessaire pour analyser les catégories de tickets, les niveaux de priorité et les responsabilités tout au long du cycle de résolution des problèmes.

5 Obligatoire 8 Recommandé 6 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l’événement ou de l’action effectuée sur le dossier de problème.
Description Cet attribut décrit l’étape ou l’action précise réalisée au cours du cycle de vie du dossier de problème. Il peut s’agir d’un changement de statut, par exemple de « Ouvert » à « En attente », d’un changement d’affectation ou d’une étape spécifique du flux de travail, comme « Solution de contournement publiée ». Dans l’analyse, ces activités constituent les nœuds de la cartographie du processus. Leur séquence permet aux analystes de visualiser le déroulement du travail, de repérer les goulots d’étranglement et de mesurer le temps écoulé entre certaines étapes. Pourquoi est-ce important ? Il définit le « quoi » du processus et permet de visualiser son déroulement et d’analyser ses variantes. Où trouver ces données Dérivé des audits de tickets ou des métriques de tickets Zendesk Exemples Dossier de problème enregistréDébut de l’investigationSolution de contournement publiée
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière modification du dossier de problème.
Description Cet attribut indique la dernière mise à jour des données du dossier de problème dans le système source. Il se distingue de l’horodatage de l’événement, car il concerne le dossier dans son ensemble et non une activité particulière. Lors de l’analyse, il permet d’évaluer l’actualité des données. Il sert à vérifier si le jeu de données est à jour ou si la synchronisation entre le système source et l’environnement de Process Mining présente un retard. Pourquoi est-ce important ? Il suit l’actualité des données et facilite les stratégies de chargement incrémentiel. Où trouver ces données Objet Ticket de Zendesk, champ « updated_at » Exemples 2023-11-01T14:20:00Z
	Dossier de problème ProblemRecordId	Identifiant numérique unique attribué au ticket de problème dans Zendesk.
Description Cet attribut correspond à la clé unique du dossier de problème dans Zendesk Support. Il sert d’ID de cas central pour le Process Mining et permet de regrouper tous les événements, mises à jour et échanges ultérieurs dans une même instance de processus. Lors de l’analyse, cet identifiant distingue chaque parcours d’investigation, de la création à la clôture. Il permet de relier les incidents associés et de suivre le cycle de vie du problème à travers les différents niveaux d’assistance. Pourquoi est-ce important ? C’est la clé obligatoire fondamentale pour regrouper les événements en dossiers dans toute analyse de Process Mining. Où trouver ces données Objet Ticket de Zendesk, champ « id » lorsque le type est « problem » Exemples 1045293849921
	Heure de début EventTimestamp	Date et heure précises auxquelles une activité s’est produite.
Description Cet attribut enregistre le moment exact où une activité a eu lieu dans Zendesk. Il fournit la dimension temporelle nécessaire pour ordonner correctement les événements et calculer les durées entre les étapes. Dans l’analyse, il est essentiel pour calculer les temps de cycle, repérer les retards, vérifier le respect des SLA et visualiser l’évolution du processus dans le temps. Sans horodatages précis, il est impossible de comprendre la rapidité du processus de résolution des problèmes. Pourquoi est-ce important ? Il permet de trier les activités et de calculer tous les KPI liés au temps. Où trouver ces données Audits de tickets Zendesk, champ « created_at » Exemples 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Système source SourceSystem	Nom du système d’où proviennent les données.
Description Cet attribut identifie la plateforme logicielle dont les données du processus ont été extraites. Dans ce contexte, sa valeur sera toujours « Zendesk Support ». Lors de l’analyse, notamment lorsque des données issues de plusieurs systèmes sont combinées, par exemple Zendesk et Jira, ce champ permet de filtrer ou de regrouper les données selon leur origine. Il garantit leur traçabilité dans les vues de processus couvrant plusieurs systèmes. Pourquoi est-ce important ? Il garantit la traçabilité des données et facilite les configurations de Process Mining couvrant plusieurs systèmes. Où trouver ces données Renseigné en dur lors de l’extraction Exemples Assistance Zendesk
	Catégorie de la cause première RootCauseCategory	Cause sous-jacente identifiée du problème (par exemple : défaut de code, erreur de configuration).
Description Cet attribut consigne le diagnostic final de la cause du problème. Il est généralement renseigné lors de l’activité « Cause première identifiée ». Dans les analyses, il sert à produire le rapport « Exactitude de la catégorisation des problèmes » et à étudier les tendances des défaillances système. Il aide la direction à déterminer s’il convient de privilégier la qualité du code, la stabilité de l’infrastructure ou la gestion des fournisseurs. Pourquoi est-ce important ? Il permet d’analyser les schémas de défaillance et d’orienter les efforts d’amélioration à long terme. Où trouver ces données Champs personnalisés des tickets Zendesk Exemples Bug logicielErreur de configurationErreur utilisateur
	Catégorie du problème ProblemCategory	Classification du problème (par exemple : logiciel, matériel, réseau).
Description Cet attribut classe le problème selon le service ou la pile technologique concernée. Il s’agit généralement d’un champ déroulant personnalisé dans les formulaires Zendesk. Dans les analyses, il sert au Dashboard « Exactitude de la catégorisation des problèmes ». La comparaison entre la catégorie initiale et la cause première finalement identifiée permet de vérifier si le tri initial oriente correctement les problèmes vers les équipes compétentes. Pourquoi est-ce important ? Il permet de segmenter les problèmes par technologie ou par service métier. Où trouver ces données Champs personnalisés des tickets Zendesk Exemples Base de donnéesInterface utilisateur et expérience utilisateurInfrastructure réseau
	Date limite du SLA SlaDueDate	Date et heure auxquelles le problème doit être résolu au plus tard.
Description Cet attribut correspond à l’échéance de résolution définie par la configuration de l’accord de niveau de service. Elle est généralement calculée en fonction de la priorité et de l’heure de création du ticket. Lors de l’analyse, cette échéance est comparée à l’heure réelle de résolution pour calculer le taux de respect du SLA des problèmes. Le Dashboard de performance et de risque du SLA met en évidence les dossiers qui approchent de leur échéance ou l’ont dépassée. Pourquoi est-ce important ? Il est essentiel pour mesurer le respect des engagements et les résultats contractuels. Où trouver ces données Point de terminaison Zendesk Ticket Metrics ou SLA Policies Exemples 2023-12-01T17:00:00Z
	Groupe d’assistance SupportGroup	Équipe ou service auquel le dossier de problème est actuellement affecté.
Description Cet attribut identifie le groupe d’agents responsable du problème à un moment donné. Sa valeur change lorsque le ticket est transféré d’une équipe à une autre. Lors de l’analyse, il est essentiel au Dashboard d’analyse des transferts entre groupes d’assistance. Il permet de mesurer les résultats par équipe, de repérer les goulots d’étranglement lors des transferts et d’analyser la répartition de la charge de travail. Pourquoi est-ce important ? Il permet d’analyser l’organisation et de repérer les goulots d’étranglement entre les services. Où trouver ces données Objet Ticket de Zendesk, champ « group_id » (résolu en nom) Exemples Assistance de niveau 2Équipe bases de donnéesExploitation réseau
	Nom de la personne affectée AssigneeName	Agent chargé de traiter le problème.
Description Cet attribut contient le nom de la personne actuellement responsable du dossier de problème. Il permet de savoir précisément qui a effectué chaque action. Lors de l’analyse, il aide à comprendre la charge de travail et les résultats de chaque personne. Si l’analyse porte souvent sur les groupes, les données par personne affectée peuvent révéler des besoins de formation ou mettre en évidence les personnes particulièrement efficaces pour résoudre des causes profondes complexes. Pourquoi est-ce important ? Il permet d’analyser les ressources à l’échelle individuelle. Où trouver ces données Objet Ticket de Zendesk, champ « assignee_id » (résolu en nom) Exemples Jean DupontJeanne MartinSystème
	Nombre d’incidents associés RelatedIncidentCount	Nombre de tickets d’incident associés à ce dossier de problème.
Description Cet attribut compte les tickets d’incident associés au dossier de problème. Dans Zendesk, cette association est gérée au moyen du champ « problem_id » des tickets d’incident, qui renvoie à ce dossier. Lors de l’analyse, il s’agit de la principale métrique pour la corrélation et l’impact des incidents. Elle aide à prioriser les problèmes qui touchent le plus grand nombre d’utilisateurs et à déterminer les corrections qui réduiront le plus le volume de tickets et amélioreront le retour sur investissement. Pourquoi est-ce important ? Il indique l’ampleur du problème et son impact sur les utilisateurs. Où trouver ces données API Zendesk Tickets, nombre de tickets dont type='incident' et problem_id=ThisID Exemples 015342
	Priorité Priority	Niveau d’urgence attribué au dossier de problème.
Description Cet attribut indique l’importance relative du problème, généralement classée comme faible, normale, élevée ou urgente. Il détermine les niveaux de service attendus (SLA) et la répartition des ressources. Lors de l’analyse, il sert à segmenter le processus et à comparer les résultats selon le degré d’urgence. Il permet, par exemple, de vérifier si les problèmes urgents sont effectivement résolus plus rapidement que ceux de priorité faible, comme l’exige le Dashboard de rapidité d’analyse des causes profondes. Pourquoi est-ce important ? Il est essentiel pour segmenter les dossiers, analyser le respect des SLA et prioriser les ressources. Où trouver ces données Objet Ticket de Zendesk, champ « priority » Exemples UrgenteÉlevéeNormaleFaible
	Statut du problème ProblemStatus	État actuel du dossier de problème dans son cycle de vie.
Description Cet attribut indique le statut actuel du problème, par exemple nouveau, ouvert, en attente, résolu ou clôturé. Il reflète l’avancement de l’investigation. Lors de l’analyse, il sert à filtrer les dossiers ouverts et clôturés. Il est essentiel au Dashboard de suivi des dossiers de problème stagnants, qui permet de repérer les dossiers actifs dont le statut n’évolue pas comme prévu. Pourquoi est-ce important ? Il permet de filtrer les dossiers selon leur état d’avancement. Où trouver ces données Objet Ticket de Zendesk, champ « status » Exemples nouveauouverten attenterésoluclôturé
	A un PIR HasPostImplementationReview	Indique si une revue post-implémentation a été réalisée.
Description Cet attribut indique si le processus de résolution du problème comportait une phase de revue. Il est calculé en vérifiant si l’activité « Revue post-implémentation réalisée » figure dans l’historique du dossier. Dans les analyses, il alimente le Dashboard « Couverture des revues post-implémentation ». Il s’agit d’un indicateur de conformité qui vérifie que l’organisation tire des enseignements de ses problèmes majeurs. Pourquoi est-ce important ? Il vérifie le respect des processus d’amélioration continue. Où trouver ces données Déduit de la présence de l’activité « Revue post-implémentation réalisée » Exemples truefalse
	Est obsolète IsStale	Indique si le problème n’a fait l’objet d’aucune activité depuis plus de 14 jours.
Description Cet attribut calculé repère les enregistrements qui n’ont pas été mis à jour récemment. Il compare la date actuelle (ou la date d’analyse) à l’horodatage de la dernière activité. Dans les analyses, il alimente le Dashboard « Suivi des enregistrements de problèmes inactifs ». Il aide les responsables à repérer rapidement les dossiers délaissés qui encombrent le backlog et qui pourraient nécessiter une clôture administrative ou une réaffectation. Pourquoi est-ce important ? Il aide à repérer les tâches inutiles dans le processus et les éléments de travail délaissés. Où trouver ces données Calculé dans l’outil de Process Mining : (Now - LastDataUpdate) > 14 days Exemples truefalse
	Identifiant de l’article de la base de connaissances KnowledgeArticleId	Identifiant de l’article de la base de connaissances créé ou associé au problème.
Description Cet attribut enregistre la référence d’un article Zendesk Guide ou d’une ressource de connaissances externe. Il indique que les enseignements tirés du problème ont été consignés. Dans les analyses, la présence de ce champ sert à calculer le « Taux d’intégration de la base de connaissances ». Elle permet de vérifier que l’organisation tire des enseignements des problèmes en documentant les solutions pour pouvoir les consulter ultérieurement. Pourquoi est-ce important ? Il mesure l’efficacité des processus de gestion des connaissances. Où trouver ces données Champs personnalisés des tickets Zendesk ou contenu associé Exemples 360045889KB-2991
	Identifiant de la demande de changement ChangeRequestId	Identifiant de la demande de changement associée à la mise en œuvre du correctif.
Description Cet attribut relie l’enregistrement du problème à un enregistrement de gestion du changement, éventuellement dans un autre système ou sous un autre type de ticket. Il indique qu’un processus formel de changement a été lancé. Dans les analyses, il alimente le Dashboard « Taux de lancement des demandes de changement ». Il permet de suivre le passage du diagnostic à la mise en œuvre et de vérifier que les causes premières identifiées donnent lieu à des actions de changement formelles. Pourquoi est-ce important ? Il relie le processus de gestion des problèmes au processus de gestion du changement. Où trouver ces données Champs personnalisés des tickets Zendesk ou tickets associés Exemples CR-1002CHG00394
	Objet du problème ProblemSubject	Résumé ou titre succinct du dossier de problème.
Description Cet attribut contient le résumé saisi lors de la création du problème. Il décrit généralement le symptôme ou le problème faisant l’objet de l’investigation. Lors de l’analyse, il donne du contexte à l’analyste qui examine un dossier particulier. Des techniques d’analyse de texte peuvent également servir à regrouper les problèmes similaires ou à repérer des sujets récurrents absents des champs de catégorie structurés. Pourquoi est-ce important ? Il fournit un contexte lisible pour chaque dossier. Où trouver ces données Objet Ticket de Zendesk, champ « subject » Exemples Impossible de traiter les paiements dans la région UEPics de latence sur le serveur de connexionÉchec de l’exportation des données pour les utilisateurs administrateurs
	Solution de contournement active WorkaroundActive	Indique si une solution de contournement a été fournie ou publiée.
Description Cet attribut booléen indique si une solution temporaire a été documentée pour le problème. Il est souvent déduit de la présence de l’activité « Solution de contournement publiée » ou d’une case à cocher spécifique dans le formulaire. Dans les analyses, il sert au Dashboard « Conformité de la publication des solutions de contournement ». Il mesure la fréquence à laquelle l’équipe d’assistance apporte un soulagement immédiat aux utilisateurs pendant que l’enquête à long terme se poursuit. Pourquoi est-ce important ? Il est essentiel pour mesurer la réduction de l’impact sur les utilisateurs pendant les investigations. Où trouver ces données Déduit de la présence de l’activité « Solution de contournement publiée » ou d’un champ personnalisé Exemples truefalse

Obligatoire Recommandé Facultatif

Activités de la Gestion des problèmes

Recueillez ces étapes essentielles du processus et ces changements de statut pour visualiser le flux de bout en bout, depuis l’identification initiale du problème jusqu’à la mise en œuvre d’une solution définitive.

8 Recommandé 4 Facultatif

	Activité	Description
	Affecté à un groupe d’assistance	Affectation du dossier de problème à une équipe technique ou à un service précis. Ce transfert est suivi lorsque le champ Group ID du ticket est mis à jour.
Pourquoi est-ce important ? Indispensable au Dashboard d’analyse des transferts entre groupes d’assistance pour mesurer les temps d’attente entre services. Où trouver ces données Suivez les changements du champ « group_id » dans le journal d’audit du ticket. Données à recueillir Enregistré lors de l’exécution de la transaction Group Assignment Change Type d’événement explicit
	Cause profonde identifiée	Moment où la cause sous-jacente du problème est déterminée. Cette étape est généralement enregistrée lorsqu’un agent renseigne un champ texte personnalisé « Root Cause » ou une catégorie dans une liste déroulante.
Pourquoi est-ce important ? Étape importante pour le Dashboard de rapidité d’analyse des causes profondes et la mesure de l’efficacité du diagnostic. Où trouver ces données Surveillez les modifications des champs personnalisés intitulés « Root Cause », « RCA » ou « Problem Source » lorsqu’ils passent d’une valeur nulle à une valeur renseignée. Données à recueillir Comparer les valeurs des champs personnalisés pour repérer leur renseignement Type d’événement inferred
	Correction définitive appliquée	Indique que la solution technique a été déployée dans l’environnement. Cette étape est généralement suivie au moyen d’un changement de statut personnalisé ou d’une étiquette spécifique, avant la résolution complète du ticket.
Pourquoi est-ce important ? Indispensable au Dashboard d’efficacité de mise en œuvre des corrections pour mesurer le délai entre le diagnostic et le déploiement. Où trouver ces données Déduit de la présence d’une étiquette spécifique, par exemple « fix_deployed », ou d’un champ de statut personnalisé, le cas échéant. Données à recueillir Surveiller les étiquettes ou les listes déroulantes de statut personnalisées Type d’événement inferred
	Début de l’investigation	Marque le passage de l’état passif « Nouveau » à un état de traitement actif. Cela indique qu’un agent a pris connaissance du problème et commencé le diagnostic.
Pourquoi est-ce important ? Sert au calcul des indicateurs de dossier de problème obsolète et marque le début du KPI de durée moyenne d’analyse des causes profondes. Où trouver ces données Déduit lorsque le statut du ticket passe de « Nouveau » à « Ouvert » ou « En attente ». Données à recueillir Comparer le champ de statut avant et après le changement Type d’événement inferred
	Dossier de problème clôturé	Dernier événement du cycle de vie : le ticket est verrouillé et ne peut plus être modifié. Dans Zendesk, cela se produit généralement automatiquement quatre jours après le passage à l’état Résolu.
Pourquoi est-ce important ? Marque la fin définitive du cycle de vie du dossier et sert à la conservation des données et aux rapports historiques. Où trouver ces données Dérivé du passage du statut du ticket à « Clôturé ». Données à recueillir Enregistré lorsque le statut passe à Clôturé Type d’événement explicit
	Dossier de problème enregistré	Création initiale du ticket de problème dans Zendesk Support. Cet événement enregistre l’horodatage auquel le problème a été consigné pour la première fois dans le système et déclenche généralement l’instance du processus.
Pourquoi est-ce important ? Définit l’heure de début du cycle de résolution de bout en bout et sert de référence pour tous les indicateurs de délai ultérieurs. Où trouver ces données Dérivé de l’horodatage « created_at » de l’objet ticket ou de la première entrée du journal d’audit du ticket. Données à recueillir Enregistré lors de l’exécution de la transaction Ticket Created Type d’événement explicit
	Résolution vérifiée	Marquage officiel du problème comme résolu. Dans Zendesk, cette étape intervient lorsque le statut système standard passe à « Résolu », ce qui indique que la correction a été vérifiée et que le dossier est terminé.
Pourquoi est-ce important ? Point de référence principal pour les calculs de performance et de risque du SLA, ainsi que pour le taux de respect du SLA des problèmes. Où trouver ces données Dérivé du passage du statut du ticket à « Résolu ». Données à recueillir Enregistré lorsque le statut passe à Résolu Type d’événement explicit
	Solution de contournement publiée	Action consistant à documenter et à partager une solution temporaire au problème. Dans Zendesk, elle est souvent signalée par une étiquette spécifique ou une case personnalisée indiquant qu’une solution de contournement est disponible.
Pourquoi est-ce important ? Alimente le Dashboard de conformité de publication des solutions de contournement et permet de fournir une solution temporaire aux utilisateurs pendant les investigations de longue durée. Où trouver ces données Surveillez l’ajout de l’étiquette « workaround_published » ou la modification d’un champ booléen personnalisé nommé « Workaround ». Données à recueillir Comparer les valeurs du champ personnalisé ou de l’étiquette Type d’événement inferred
	Demande de changement lancée	Indique qu’un processus formel de gestion du changement a été déclenché pour résoudre le problème. Cette étape est souvent déduite du renseignement d’un champ personnalisé « Change Request ID » ou de l’association d’un ticket de type « Change ».
Pourquoi est-ce important ? Suit le taux de lancement des demandes de changement et relie la gestion des problèmes aux flux de travail de gestion du changement. Où trouver ces données Surveillez les mises à jour d’un champ personnalisé tel que « change_reference » ou la création d’un lien de type « problem_change ». Données à recueillir Surveiller le champ personnalisé pour détecter la saisie d’un identifiant externe Type d’événement inferred
	Investigation du problème rouverte	Se produit lorsqu’un dossier de problème précédemment marqué comme résolu repasse à l’état ouvert ou à un état actif. Cela indique que la correction a échoué ou que la résolution a été rejetée.
Pourquoi est-ce important ? Alimente le KPI de taux de réouverture des problèmes et aide à repérer les problèmes de qualité dans le processus de résolution. Où trouver ces données Déduit lorsque le statut passe de « Résolu » à « Ouvert », « Nouveau » ou « En attente ». Données à recueillir Comparer le champ de statut avant et après le changement Type d’événement inferred
	Projet de solution rédigé	Création d’un article de base de connaissances à partir de l’investigation du problème. Cette étape est déduite de l’utilisation de l’application Zendesk Knowledge Capture ou de l’association d’un nouvel article.
Pourquoi est-ce important ? Alimente le KPI de taux d’intégration de la base de connaissances et soutient l’apprentissage organisationnel. Où trouver ces données Surveillez les événements liés à l’intégration « Knowledge Capture » ou les étiquettes telles que « kcs_draft ». Données à recueillir Déduire l’étape à partir d’étiquettes système spécifiques ou d’événements d’association Type d’événement inferred
	Revue après mise en œuvre effectuée	Confirmation qu’une revue rétrospective a été menée après la correction. Il s’agit généralement d’une case à cocher ou d’un champ de date mis à jour par le coordinateur du processus.
Pourquoi est-ce important ? Nécessaire au KPI de fréquence des revues après mise en œuvre pour vérifier le respect des normes de qualité. Où trouver ces données Surveillez la mise à jour de la case personnalisée « PIR Completed » ou du champ de date « PIR Date ». Données à recueillir Surveiller le champ personnalisé pour confirmer la fin de l’étape Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

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

Étapes

Connectez-vous à votre instance Zendesk et accédez à l’interface de création de rapports Explore depuis le menu des produits.
Cliquez sur le dossier Queries (ou Reports dans les versions récentes), puis sélectionnez New query.
Lorsque vous êtes invité à choisir un jeu de données, sélectionnez Support, puis Updates History, puis Support : Updates History [default]. Ce jeu de données contient les journaux d’événements nécessaires au Process Mining, et pas seulement les données sur l’état actuel.
Dans le panneau Metrics, ajoutez Count (Tickets) ou Count (Updates) pour vous assurer que les données sont récupérées.
Dans le panneau Filters, ajoutez un filtre sur Ticket > Ticket type et sélectionnez Problem afin de limiter le jeu de données au processus de Gestion des problèmes.
Dans le panneau Rows, ajoutez les attributs suivants dans cet ordre précis pour définir la structure du journal d’événements : Ticket > Ticket ID, Time - Timestamp > Update - Timestamp, Updater > Updater name et Changes > Changes - Field name.
Pour créer la colonne Activity Name, vous devez créer un attribut calculé standard. Cliquez sur l’icône Calculation dans la barre latérale droite, sélectionnez Standard calculated attribute, nommez-le Activity Mapper, puis collez le code fourni dans la section Query ci-dessous.
Ajoutez ce nouvel attribut Activity Mapper au panneau Rows. Filtrez cet attribut pour exclure les valeurs NULL et supprimer le bruit système non pertinent.
Ajoutez au panneau Rows des attributs supplémentaires pour apporter du contexte : Ticket > Priority, Ticket > Group, Ticket > Status, ainsi que les champs personnalisés nécessaires à l’analyse des causes profondes ou des catégories (par exemple, Ticket > Ticket tags ou certains Custom Fields).
Dans le panneau Filters, définissez la période à l’aide de Time - Timestamp > Update - Date afin de couvrir la période d’analyse souhaitée (par exemple, Last 6 Months).
Cliquez sur l’icône du type de visualisation et sélectionnez Table. Si l’option est disponible, vérifiez que le tableau est dépivoté ou à plat ; sinon, assurez-vous simplement que tous les attributs figurent dans la section Rows.
Exportez le résultat en cliquant sur Export > CSV. Vérifiez que la case Keep attribute formatting est cochée afin de préserver le format des horodatages pour ProcessMind.

Configuration

Jeu de données : Support : Updates History (Important : n’utilisez pas le jeu de données standard Tickets, car il ne présente que l’état actuel).
Filtre temporel : Update - Date (recommandation : les 90 à 180 derniers jours, selon le volume).
Type de ticket : filtrez exclusivement sur Problem pour éviter de mélanger les incidents et les demandes de service.
Limite de lignes : les exports Zendesk Explore sont souvent limités à 50 000 lignes. Si votre jeu de données dépasse cette limite, utilisez le filtre Update - Date pour exporter les données par périodes mensuelles, puis regroupez-les à l’extérieur de Zendesk.
Champs personnalisés : repérez les identifiants des champs correspondant à la cause profonde, à la demande de changement et à la solution de contournement dans votre instance Zendesk. Il ne s’agit pas de champs système standard.
Autorisations système : une licence Explore Viewer ou Explore Professional est requise.

Exemple de requête config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

Étapes

Vérification des prérequis : vérifiez que le module complémentaire Zendesk Data Sharing est activé pour votre organisation. Assurez-vous de disposer d’identifiants en lecture seule pour la base de données Zendesk répliquée, généralement hébergée sur Snowflake ou Amazon Redshift.
Connexion à la base de données : utilisez le client SQL de votre choix (par exemple, DBeaver, DataGrip ou l’interface Web native de Snowflake ou Redshift) pour vous connecter à votre entrepôt de données Zendesk avec les identifiants fournis.
Repérage des champs personnalisés : avant d’exécuter la requête, repérez les identifiants uniques des champs personnalisés utilisés dans votre processus de Gestion des problèmes. Dans Zendesk, accédez à Admin Center, puis à Objects and rules > Tickets > Fields. Repérez les champs « Root Cause », « Change Request ID », « Workaround Published », « Permanent Fix Applied » et « Post-Implementation Review » pour relever leurs identifiants respectifs. Vous remplacerez ensuite les espaces réservés de la requête par ces identifiants.
Examen de la requête SQL : la requête fournie utilise une expression de table commune (CTE) nommée ProblemTickets pour sélectionner et filtrer d’abord tous les enregistrements de problèmes. Cette méthode améliore les performances et la lisibilité. La requête principale utilise ensuite UNION ALL pour regrouper les résultats de 12 instructions SELECT, une pour chaque activité requise.
Personnalisation de la requête : ouvrez un nouvel éditeur de requête et collez-y le script SQL complet. Modifiez les espaces réservés dans le script :
- Dans la CTE ProblemTickets, définissez la période souhaitée en remplaçant '[YYYY-MM-DD]'.
- Pour chaque activité qui dépend d’un champ personnalisé, remplacez les identifiants fictifs (par exemple, [Your 'Root Cause Category' field_id], [Your 'Change Request ID' field_id]) par les identifiants relevés à l’étape 3.
Exécution de la requête : exécutez le script SQL modifié sur la base de données. La durée d’exécution dépendra de la période choisie et du volume de données des tickets.
Vérification de la logique « Proposed Solution Drafted » : la requête suppose que la rédaction d’une solution est enregistrée dans un champ personnalisé nommé [Your 'KB Article ID' field_id]. Si votre processus fonctionne autrement, par exemple si l’information figure dans une étiquette ou un commentaire, vous devrez adapter cette partie de la requête.
Validation des données : une fois la requête terminée, examinez rapidement les résultats. Vérifiez que le nombre de lignes est cohérent, que toutes les colonnes sont présentes et qu’aucune valeur NULL inattendue ne figure dans les colonnes essentielles, comme ProblemRecordId et EventTimestamp.
Export du journal d’événements : exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Vérifiez que le fichier est encodé en UTF-8 et que les en-têtes de colonnes correspondent aux noms d’attributs requis par votre outil de Process Mining.
Préparation de l’import : avant l’import, vérifiez le format du fichier CSV. Assurez-vous que les dates et heures de la colonne EventTimestamp suivent un format cohérent, par exemple YYYY-MM-DD HH24:MI:SS.

Configuration

Prérequis : cette extraction nécessite le module complémentaire Zendesk Data Sharing et un accès SQL direct aux données répliquées dans une instance Snowflake ou Amazon Redshift.
Filtre sur le type de ticket : la requête est configurée pour analyser uniquement les tickets dont le champ type vaut 'problem'. Cette condition permet d’isoler le processus de Gestion des problèmes des incidents et des autres types de tickets.
Filtrage par période : il est vivement recommandé de limiter les données à une période précise afin de préserver les performances. La requête contient l’espace réservé created_at >= '[YYYY-MM-DD]' dans la CTE initiale. Pour une première analyse, une période de 3 à 6 mois est généralement adaptée.
Configuration des champs personnalisés : cette extraction dépend fortement de la configuration de votre instance Zendesk. Vous devez repérer et renseigner le bon field_id pour les champs personnalisés qui suivent des activités telles que 'Root Cause Identified', 'Change Request Initiated' et 'Workaround Published'. Si les identifiants fictifs ne sont pas remplacés, la requête échouera ou ne renverra aucune donnée pour ces activités.
Latence des données : les données de la base répliquée ne sont pas disponibles en temps réel. Un délai de quelques heures s’écoule généralement entre un événement dans Zendesk et son apparition dans l’entrepôt de données. Tenez-en compte lors de l’analyse des activités les plus récentes.

Exemple de requête sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

Étapes

Prérequis : vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système. Installez les bibliothèques requests et pandas requises en exécutant pip install requests pandas dans votre terminal ou votre invite de commandes.
Création d’un jeton API Zendesk : connectez-vous à Zendesk Support en tant qu’administrateur. Accédez à Admin Center > Apps and integrations > APIs > Zendesk API. Dans la section Token Access, cliquez sur 'Add API token' pour créer un jeton. Copiez-le immédiatement et conservez-le en lieu sûr, car il ne sera plus affiché.
Configuration du script Python : créez un fichier Python (par exemple, extract_zendesk_problems.py) et copiez-y le script complet fourni dans la section Query. Modifiez les variables fictives en haut du script : ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN et START_TIME. Pour la première exécution, définissez START_TIME sur l’horodatage Unix correspondant à la date de début souhaitée pour l’extraction.
Association des identifiants de champs personnalisés : repérez les identifiants numériques des champs personnalisés utilisés dans votre processus de Gestion des problèmes. Vous les trouverez dans Admin Center > Objects and rules > Tickets > Fields, en examinant l’URL ou les propriétés des champs. Mettez à jour le dictionnaire CUSTOM_FIELD_MAPPING du script avec vos identifiants.
Exécution du script : lancez le script depuis votre terminal avec la commande python extract_zendesk_problems.py. Le script commencera à récupérer les données depuis l’API d’export incrémentiel Zendesk.
Suivi de l’exécution : le script affiche sa progression, notamment le nombre de tickets traités et l’horodatage en cours de récupération. Il gère automatiquement les limites de débit de l’API en faisant une pause si nécessaire.
Récupération et transformation des données : le script récupère d’abord tous les tickets de problème créés ou mis à jour depuis START_TIME. Pour chacun d’eux, il récupère ensuite l’historique complet des modifications, qui contient tous les changements passés.
Génération du journal d’événements : le script traite chaque événement d’audit et associe les changements de champs (statut, groupe ou mise à jour d’un champ personnalisé, par exemple) aux activités métier définies. Il récupère et met également en cache les noms des utilisateurs et des groupes afin d’enrichir les données.
Gestion des chargements incrémentiels : après le premier chargement complet, mettez à jour la variable START_TIME lors des exécutions suivantes en utilisant la valeur end_time affichée à la fin de la dernière exécution réussie. Vous ne récupérerez ainsi que les données nouvelles ou modifiées, sans doublons.
Vérification du résultat : à la fin de l’exécution, le script crée un fichier nommé zendesk_problem_event_log.csv dans le même répertoire. Ce fichier CSV contient le journal d’événements structuré, prêt à être analysé.
Préparation de l’import : ouvrez le fichier CSV dans un tableur pour en vérifier le contenu. Avant de l’importer dans ProcessMind, assurez-vous que toutes les colonnes requises (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) sont présentes et correctement renseignées.

Configuration

Identifiants de l’API Zendesk : le script nécessite le sous-domaine Zendesk, l’adresse e-mail de l’utilisateur associé au jeton API et le jeton lui-même pour l’authentification.
Heure de début : la variable START_TIME est un horodatage Unix qui définit le début de l’extraction des données. Pour la première exécution, choisissez une date passée (par exemple, il y a 6 mois) afin de récupérer l’historique. Pour les exécutions suivantes, utilisez l’heure de fin de l’exécution précédente pour récupérer les données de manière incrémentielle.
Association des champs personnalisés : le dictionnaire CUSTOM_FIELD_MAPPING est essentiel. Remplacez les identifiants fictifs par les identifiants réels des champs personnalisés de votre instance Zendesk afin de recueillir correctement les activités telles que 'Workaround Published' et 'Root Cause Identified'.
Filtre sur le type de ticket : le script est configuré pour traiter uniquement les tickets dont le champ type vaut 'problem'. Les incidents, les tâches et les questions sont ainsi exclus du journal d’événements de la Gestion des problèmes.
Limitation du débit de l’API : le script inclut une fonction de base time.sleep(60) pour gérer les erreurs 429 'Too Many Requests'. La durée de la pause peut devoir être ajustée selon votre offre Zendesk et le volume de données à extraire.
Prérequis : le script nécessite un environnement Python 3 avec les bibliothèques requests et pandas. Le jeton API doit être associé à un compte autorisé à lire les données des tickets.

Exemple de requête python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

class=class="hl-string">"hl-comment"># Caching for user and group lookups to reduce API calls
user_cache = {}
group_cache = {}

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

def get_user_name(user_id):
    if not user_id: return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return str(user_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def get_group_name(group_id):
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return str(group_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    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', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

    event_log_data = []
    for i, ticket in enumerate(problem_tickets):
        print(fclass="hl-string">"Processing ticket {i+1}/{len(problem_tickets)}: ID {ticket['id']}")
        process_ticket_audits(ticket, event_log_data)

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'zendesk_problem_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

Prêt à commencer ?

Améliorez la stabilité de votre environnement informatique en appliquant dès aujourd’hui ce modèle à votre environnement Zendesk. Notre équipe peut vous aider à affiner l’extraction de vos données et à démarrer votre démarche de Process Mining.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez la Gestion des problèmes pour corriger plus vite les incidents informatiques

Réduisez de 30 % les cycles de résolution et éliminez les goulots d’étranglement informatiques.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

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

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

Attributs de la Gestion des problèmes

Activités de la Gestion des problèmes

Guides d’extraction

Export de l’historique des mises à jour Zendesk Explore

Étapes

Configuration

Exemple de requête config

Requête SQL via Zendesk Data Sharing

Étapes

Configuration

Exemple de requête sql

Extraction Python avec l’API d’export incrémentiel

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez la Gestion des problèmes pour corriger plus vite les incidents informatiques

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

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

Attributs de la Gestion des problèmes

Activités de la Gestion des problèmes

Guides d’extraction

Export de l’historique des mises à jour Zendesk Explore

Étapes

Configuration

Exemple de requête config

Requête SQL via Zendesk Data Sharing

Étapes

Configuration

Exemple de requête sql

Extraction Python avec l’API d’export incrémentiel

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez la Gestion des problèmes pour corriger plus vite les incidents informatiques

Prêt à commencer ?