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

Votre modèle de données de Gestion des problèmes

Zendesk Support

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

Votre modèle de données de Gestion des problèmes

Ce modèle fournit un cadre complet pour modéliser 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 identifier les goulots d’étranglement lors de l’analyse des causes profondes. En suivant cette structure, vous pouvez créer un journal d’événements de qualité pour obtenir des analyses détaillées de votre 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 ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la gestion des 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 la répartition des 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 réalisée sur l’enregistrement du problème.
Description Cet attribut décrit l’étape ou l’action précise réalisée au cours du cycle de vie de l’enregistrement du problème. Il peut s’agir de changements d’état, comme « Open » vers « Pending », de changements d’affectation ou d’étapes précises du flux de travail, comme « Workaround Published ». Dans l’analyse, il constitue l’un des nœuds de la carte de processus. La séquence de ces activités permet aux analystes de visualiser le déroulement du travail, d’identifier les goulots d’étranglement et de mesurer le temps écoulé entre certaines étapes du processus. Pourquoi c’est important Il définit le « quoi » du processus, ce qui permet de visualiser le flux du processus et d’analyser ses variantes. Où les obtenir Dérivé des audits Zendesk Ticket ou des métriques des tickets Exemples Enregistrement du problème crééInvestigation commencéeSolution de contournement publiée
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière modification de l’enregistrement du problème.
Description Cet attribut correspond à la dernière mise à jour des données de l’enregistrement du problème dans le système source. Il se distingue de l’horodatage de l’événement, car il concerne le niveau de l’enregistrement et non celui de l’activité. Dans l’analyse, il aide à déterminer l’actualité des données. Il permet de vérifier si le jeu de données est à jour ou si des retards de synchronisation existent entre le système source et l’environnement de Process Mining. Pourquoi c’est important Il suit l’actualité des données et contribue aux stratégies de chargement incrémentiel. Où les obtenir Objet Zendesk Ticket, champ « updated_at » Exemples 2023-11-01T14:20:00Z
	Enregistrement du problème ProblemRecordId	Identifiant numérique unique attribué au ticket de problème dans Zendesk.
Description Cet attribut représente la clé unique de l’enregistrement du problème dans le système Zendesk Support. Il sert d’identifiant central du cas pour le Process Mining, en permettant de regrouper tous les événements, mises à jour et interactions ultérieurs au sein d’une même instance de processus. Dans l’analyse, cet identifiant permet de distinguer chaque parcours d’investigation d’un problème, de sa création à sa clôture. Il permet de mettre en relation les incidents associés et de suivre le cycle de vie du problème à travers les différents niveaux d’assistance. Pourquoi c’est important Il s’agit de la clé obligatoire fondamentale requise pour regrouper les événements en cas dans toute analyse de Process Mining. Où les obtenir Objet Zendesk Ticket, 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é s’est produite dans le système 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, identifier 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 vitesse du processus de résolution des problèmes. Pourquoi c’est important Il permet de trier les activités et de calculer tous les KPI fondés sur le temps. Où les obtenir Audits Zendesk Ticket, champ « created_at » Exemples 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Système source SourceSystem	Nom du système à l’origine des données.
Description Cet attribut identifie la plateforme logicielle depuis laquelle les données du processus ont été extraites. Dans ce contexte, il contient systématiquement la valeur « Zendesk Support ». Dans l’analyse, notamment lorsque des données provenant de plusieurs systèmes sont combinées, par exemple Zendesk et Jira, ce champ permet aux analystes de filtrer ou de regrouper les données selon leur origine. Il garantit la traçabilité et la chaîne de provenance des données dans les vues de processus multisystèmes. Pourquoi c’est important Il garantit la traçabilité des données et prend en charge les configurations de Process Mining multisystèmes. Où les obtenir Défini en dur lors de l’extraction Exemples Zendesk Support
	Catégorie de la cause profonde RootCauseCategory	Cause sous-jacente identifiée du problème, par exemple défaut de code ou erreur de configuration.
Description Cet attribut enregistre le diagnostic final de la cause du problème. Il est généralement renseigné lors de l’activité « Root Cause Identified ». Dans l’analyse, il sert à produire le rapport Problem Categorization Accuracy et à étudier les tendances des défaillances système. Il aide la direction à déterminer si elle doit concentrer ses efforts sur la qualité du code, la stabilité de l’infrastructure ou la gestion des fournisseurs. Pourquoi c’est important Il permet d’analyser les schémas de défaillance et d’orienter les efforts d’amélioration à long terme. Où les obtenir 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 ou réseau.
Description Cet attribut catégorise le problème selon le service ou la pile technologique concernée. Il s’agit généralement d’un champ de liste déroulante personnalisé dans les formulaires Zendesk. Dans l’analyse, il est utilisé par le Dashboard Problem Categorization Accuracy. La comparaison entre cette catégorie initiale et la cause profonde finale permet de vérifier si le triage initial oriente correctement les problèmes vers les équipes compétentes. Pourquoi c’est important Il permet de segmenter les données par technologie ou par service métier. Où les obtenir Champs personnalisés des tickets Zendesk Exemples Base de donnéesUI/UXInfrastructure réseau
	Date d’échéance du SLA SlaDueDate	Date et heure cibles auxquelles le problème devrait être résolu.
Description Cet attribut représente 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 la date de création du ticket. Dans l’analyse, elle est comparée au temps de résolution réel afin de calculer le taux de respect des SLA des problèmes. Elle alimente le Dashboard SLA Performance and Risk en mettant en évidence les cas qui approchent de leur échéance ou l’ont dépassée. Pourquoi c’est important Il est essentiel pour mesurer la conformité et la performance contractuelle. Où les obtenir Métriques des tickets Zendesk ou endpoint des politiques de SLA Exemples 2023-12-01T17:00:00Z
	Groupe d’assistance SupportGroup	Équipe ou service actuellement affecté à l’enregistrement du problème.
Description Cet attribut identifie le groupe d’agents responsable du problème à un moment donné. Il évolue lorsque le ticket est transféré d’une équipe à une autre. Dans l’analyse, il est essentiel pour le Dashboard Support Group Handover Analysis. Il permet de mesurer les performances de chaque équipe, d’identifier les goulots d’étranglement lors des transferts et d’analyser la répartition de la charge entre les ressources. Pourquoi c’est important Il permet d’analyser l’organisation et d’identifier les goulots d’étranglement entre les services. Où les obtenir Objet Zendesk Ticket, champ « group_id » (résolu en nom) Exemples Support de niveau 2Équipe base de donnéesOpérations réseau
	Nom de l’agent affecté AssigneeName	Agent précisément chargé de traiter le problème.
Description Cet attribut contient le nom de l’utilisateur actuellement responsable de l’enregistrement du problème. Il offre une visibilité détaillée sur l’auteur des différentes actions. Dans l’analyse, il aide à comprendre la charge et les performances individuelles. Si l’analyse au niveau du groupe est courante, les données relatives à l’agent affecté peuvent mettre en évidence des besoins de formation ou les personnes particulièrement efficaces pour résoudre des causes profondes complexes. Pourquoi c’est important Il permet d’analyser les ressources au niveau individuel. Où les obtenir Objet Zendesk Ticket, champ « assignee_id » (résolu en nom) Exemples John DoeJane SmithSystème
	Nombre d’incidents associés RelatedIncidentCount	Nombre de tickets d’incident associés à cet enregistrement de problème.
Description Cet attribut compte le nombre de tickets d’incident associés à cet enregistrement de problème. Dans Zendesk, cette relation est gérée au moyen du champ « problem_id » des tickets d’incident, qui renvoie vers cet enregistrement. Dans l’analyse, il s’agit de l’indicateur principal d’Incident Correlation and Impact. Il aide à prioriser les problèmes qui touchent le plus grand nombre d’utilisateurs et à déterminer quelles corrections auront le meilleur retour sur investissement en matière de réduction du volume de tickets. Pourquoi c’est important Il indique l’ampleur du problème et son impact sur les utilisateurs. Où les obtenir API Zendesk Tickets, nombre de tickets dont type='incident' et problem_id=ThisID Exemples 015342
	Priorité Priority	Niveau d’urgence attribué à l’enregistrement du 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 et l’affectation des ressources. Dans l’analyse, il sert à segmenter le processus et à comparer les performances selon les niveaux d’urgence. Il permet par exemple de vérifier que les problèmes urgents sont effectivement résolus plus rapidement que les problèmes de faible priorité, comme l’exige le Dashboard Root Cause Investigation Velocity. Pourquoi c’est important Il est essentiel pour segmenter les cas, analyser le respect des SLA et prioriser les ressources. Où les obtenir Objet Zendesk Ticket, champ « priority » Exemples UrgentÉlevéNormalFaible
	Statut du problème ProblemStatus	État actuel de l’enregistrement du problème dans son cycle de vie.
Description Cet attribut indique le statut actuel du problème, par exemple New, Open, Pending, Solved ou Closed. Il reflète l’avancement de l’investigation. Dans l’analyse, il sert à filtrer les cas ouverts et clôturés. Il est essentiel au Dashboard Stale Problem Record Monitoring, qui identifie les cas actifs n’évoluant pas selon le cycle de statuts attendu. Pourquoi c’est important Il permet de filtrer les cas selon leur état d’achèvement. Où les obtenir Objet Zendesk Ticket, champ « status » Exemples NouveauOuvertEn attenteRésoluFermé
	Est obsolète IsStale	Indique si aucune activité n’a été enregistrée pour le problème depuis plus de 14 jours.
Description Cet attribut calculé identifie 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 « Stale Problem Record Monitoring ». Il aide les responsables à isoler rapidement les cas négligés qui encombrent le backlog et peuvent nécessiter une clôture administrative ou une réaffectation. Pourquoi c’est important Il aide à identifier les activités sans valeur et les éléments de travail négligés. Où les obtenir Calculé dans l’outil de Process Mining : (Now - LastDataUpdate) > 14 days Exemples truefalse
	Identifiant de l’article de connaissances KnowledgeArticleId	Identifiant de l’article de base de connaissances créé ou associé au problème.
Description Cet attribut stocke la référence d’un article Zendesk Guide ou d’une ressource de connaissances externe. Il indique que les connaissances acquises lors du traitement du problème ont été capitalisées. Dans l’analyse, la présence de ce champ sert à calculer le taux d’intégration de la base de connaissances. Elle vérifie que l’organisation boucle le cycle d’apprentissage en documentant les solutions pour pouvoir les consulter ultérieurement. Pourquoi c’est important Il mesure l’efficacité des processus de gestion des connaissances. Où les obtenir 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 pour mettre en œuvre la correction.
Description Cet attribut relie l’enregistrement du problème à un enregistrement de Gestion du changement, éventuellement situé dans un autre système ou correspondant à un autre type de ticket. Il indique qu’un processus formel de changement a été initié. Dans l’analyse, il alimente le Dashboard Change Request Initiation Rate. Il aide à suivre le passage du diagnostic à la mise en œuvre et à vérifier que les causes profondes identifiées donnent lieu à des actions de changement formelles. Pourquoi c’est important Il relie le processus de gestion des problèmes au processus de gestion du changement. Où les obtenir Champs personnalisés des tickets Zendesk ou tickets associés Exemples CR-1002CHG00394
	Objet du problème ProblemSubject	Résumé court ou titre de l’enregistrement du problème.
Description Cet attribut contient le résumé textuel 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. Dans l’analyse, il fournit un contexte à l’analyste lorsqu’il examine des cas précis. Des techniques de text mining peuvent également être appliquées pour regrouper les problèmes similaires ou identifier les thèmes récurrents qui ne sont pas capturés par les champs de catégorie structurés. Pourquoi c’est important Il fournit un contexte lisible par l’utilisateur pour chaque cas. Où les obtenir Objet Zendesk Ticket, 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
	PIR réalisé 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 comprenait une phase de revue. Il est dérivé de la vérification de la présence de l’activité « Post-Implementation Review Conducted » dans l’historique du cas. Dans les analyses, il alimente le Dashboard « Post Implementation Review Coverage ». Il s’agit d’un indicateur de Conformité qui vérifie que l’organisation tire des enseignements de ses problèmes majeurs. Pourquoi c’est important Il vérifie la conformité avec les processus d’amélioration continue. Où les obtenir Dérivé de la présence de l’activité « Post-Implementation Review Conducted » Exemples truefalse
	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 correction temporaire a été documentée pour le problème. Il est souvent dérivé de la présence d’une activité « Workaround Published » ou d’une case à cocher spécifique dans le formulaire. Dans les analyses, il est utilisé pour le Dashboard « Workaround Publication Compliance ». Il mesure la fréquence à laquelle l’équipe de support apporte une solution immédiate aux utilisateurs pendant la poursuite de l’analyse à long terme. Pourquoi c’est important Il est essentiel pour mesurer l’atténuation de l’impact sur les utilisateurs pendant les investigations. Où les obtenir Dérivé de la présence de l’activité « Workaround Published » ou d’un champ personnalisé Exemples truefalse

Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Enregistrez 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 correction définitive.

8 Recommandé 4 Facultatif

	Activité	Description
	Affecté à un groupe d’assistance	Routage de l’enregistrement du problème vers une équipe technique ou un service donné. Cet événement est suivi lorsque le champ Group ID du ticket est mis à jour.
Pourquoi c’est important Essentiel pour le Dashboard Support Group Handover Analysis, qui mesure les temps d’attente entre les services. Où les obtenir Surveiller les changements du champ « group_id » dans le journal d’audit du ticket. Collecte 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. Cet événement est généralement enregistré lorsqu’un agent renseigne un champ texte personnalisé « Root Cause » ou une catégorie sous forme de liste déroulante.
Pourquoi c’est important Étape essentielle pour le Dashboard Root Cause Investigation Velocity et pour mesurer l’efficacité du diagnostic. Où les obtenir Surveiller les modifications des champs personnalisés intitulés « Root Cause », « RCA » ou « Problem Source » lorsqu’ils passent à une valeur non nulle. Collecte Comparer les valeurs des champs personnalisés pour vérifier leur renseignement Type d’événement inferred
	Correction définitive appliquée	Signale que la solution technique a été déployée dans l’environnement. Cet événement est généralement suivi au moyen d’un changement de statut personnalisé ou d’une balise spécifique avant la résolution complète du ticket.
Pourquoi c’est important Essentiel pour le Dashboard Fix Implementation Efficiency, qui mesure le délai entre le diagnostic et le déploiement. Où les obtenir Déduit d’une balise spécifique, par exemple « fix_deployed », ou d’un champ de statut personnalisé lorsqu’il existe. Collecte Surveiller les balises ou les listes déroulantes de statut personnalisées Type d’événement inferred
	Enregistrement du problème clôturé	Dernier événement du cycle de vie, au cours duquel le ticket est verrouillé et ne peut plus être modifié. Dans Zendesk, cela se produit généralement automatiquement quatre jours après l’état « Solved ».
Pourquoi c’est important Marque la fin définitive de la vie de l’enregistrement et sert à la conservation des données ainsi qu’aux rapports historiques. Où les obtenir Dérivé du passage du statut du ticket à « Closed ». Collecte Enregistré lorsque le statut passe à Closed Type d’événement explicit
	Enregistrement du problème créé	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 c’est 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ù les obtenir Dérivé de l’horodatage « created_at » dans l’objet ticket ou de la première entrée du journal d’audit du ticket. Collecte Enregistré lors de l’exécution de la transaction Ticket Created Type d’événement explicit
	Investigation commencée	Marque le passage de l’état passif « New » à un état de travail actif. Cela indique qu’un agent a pris connaissance du problème et commencé le diagnostic.
Pourquoi c’est important Utilisé pour calculer les indicateurs relatifs aux enregistrements de problèmes obsolètes et constitue le point de départ du KPI de durée moyenne d’analyse des causes profondes. Où les obtenir Déduit lorsque le statut du ticket passe de « New » à « Open » ou « Pending ». Collecte Comparer le champ de statut avant et après Type d’événement inferred
	Résolution vérifiée	Marquage formel du problème comme résolu. Dans Zendesk, cet événement se produit lorsque le statut système standard est défini sur « Solved », ce qui indique que la correction a été vérifiée et que le dossier est terminé.
Pourquoi c’est important Point final principal pour les calculs de performance et de risque liés aux SLA, ainsi que pour le taux de respect des SLA des problèmes. Où les obtenir Dérivé du passage du statut du ticket à « Solved ». Collecte Enregistré lorsque le statut passe à Solved Type d’événement explicit
	Solution de contournement publiée	Action consistant à documenter et à partager une correction temporaire du problème. Dans Zendesk, cet événement est souvent enregistré au moyen d’une balise spécifique ou d’une case personnalisée indiquant qu’une solution de contournement est disponible.
Pourquoi c’est important Alimente le Dashboard Workaround Publication Compliance et garantit qu’une solution temporaire est proposée aux utilisateurs pendant les investigations longues. Où les obtenir Surveiller l’ajout de la balise « workaround_published » ou la modification d’un champ booléen personnalisé nommé « Workaround ». Collecte Comparer les valeurs d’un champ personnalisé ou d’une balise Type d’événement inferred
	Demande de changement initiée	Indique qu’un processus formel de Gestion du changement a été déclenché pour résoudre le problème. Cet événement est souvent déduit lorsqu’un champ personnalisé « Change Request ID » est renseigné ou lorsqu’un ticket de type « Change » est associé.
Pourquoi c’est important Suit le taux de lancement des demandes de changement et relie les flux de travail de Gestion des problèmes à ceux de la Gestion du changement. Où les obtenir Surveiller les mises à jour d’un champ personnalisé tel que « change_reference » ou la création d’un type de lien « problem_change ». Collecte 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 enregistrement de problème précédemment marqué comme « Solved » revient à l’état « Open » ou à un état actif. Cela indique l’échec de la correction ou le rejet de la résolution.
Pourquoi c’est important Alimente le KPI de taux de réouverture des problèmes et aide à identifier les problèmes de qualité du processus de résolution. Où les obtenir Déduit lorsque le statut passe de « Solved » à « Open », « New » ou « Pending ». Collecte Comparer le champ de statut avant et après Type d’événement inferred
	Projet de solution proposé	Création d’un article de base de connaissances à partir de l’investigation du problème. Cet événement est déduit de l’utilisation de l’application Zendesk Knowledge Capture ou de l’association d’un nouvel article.
Pourquoi c’est important Alimente le KPI Knowledge Base Integration Rate et soutient la capitalisation des connaissances de l’organisation. Où les obtenir Surveiller les événements liés à l’intégration « Knowledge Capture » ou les balises telles que « kcs_draft ». Collecte Déduire l’événement à partir de balises système spécifiques ou d’événements d’association Type d’événement inferred
	Revue post-implémentation réalisée	Confirmation qu’une revue rétrospective a été réalisée après la correction. Cet événement est généralement enregistré au moyen d’une case à cocher ou d’un champ de date mis à jour par le coordinateur du processus.
Pourquoi c’est important Requis pour le KPI de fréquence des revues post-implémentation, afin de garantir le respect des normes de qualité. Où les obtenir Surveiller les mises à jour de la case personnalisée « PIR Completed » ou du champ de date « PIR Date ». Collecte Surveiller le champ personnalisé pour vérifier son achèvement 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 plus récentes, puis sélectionnez New query.
Lorsque vous devez sélectionner un jeu de données, choisissez 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 non uniquement les données d’état actuelles.
Dans le panneau Metrics, ajoutez Count (Tickets) ou Count (Updates) afin de vérifier que les données sont bien récupérées.
Dans le panneau Filters, ajoutez un filtre pour 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 de l’Event Log : 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 Standard Calculated Attribute. 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 sans intérêt.
Ajoutez au panneau Rows des attributs supplémentaires pour fournir du contexte : Ticket > Priority, Ticket > Group, Ticket > Status, ainsi que tous les champs personnalisés nécessaires à l’analyse de la cause racine ou des catégories, par exemple Ticket > Ticket tags ou certains Custom Fields.
Définissez la période dans le panneau Filters à 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. Vérifiez que le tableau est dénormalisé ou plat si cette option est disponible, ou assurez-vous simplement que tous les attributs figurent dans la section Rows.
Exportez le résultat en cliquant sur Export > CSV. Vérifiez que l’option Keep attribute formatting est cochée afin de préserver les formats d’horodatage pour ProcessMind.

Configuration

Jeu de données : Support: Updates History (important : n’utilisez pas le jeu de données standard Tickets, car il affiche uniquement l’état actuel).
Filtre temporel : Update - Date (recommandation : les 90 à 180 derniers jours selon le volume).
Type de ticket : filtrez strictement sur Problem afin d’é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 tranches mensuelles, puis fusionnez-les en dehors de Zendesk.
Champs personnalisés : identifiez les ID de champ spécifiques à la cause racine, à la demande de changement et à la solution de contournement dans votre instance Zendesk, car il ne s’agit pas de champs système standard.
Autorisations système : une licence Explore Viewer ou Explore Professional est requise.

a 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. Confirmez que vous disposez d’identifiants d’accès en lecture seule à 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 votre client SQL habituel, tel que 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.
Identification des champs personnalisés : avant d’exécuter la requête, identifiez les ID 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 » afin d’obtenir leurs ID spécifiques. Ils serviront à remplacer les espaces réservés dans la requête.
Vérification de la requête SQL : la requête fournie utilise une Common Table Expression (CTE) nommée ProblemTickets pour sélectionner et filtrer d’abord tous les enregistrements de problèmes. Cette approche améliore les performances et la lisibilité. La partie principale de la requête utilise ensuite UNION ALL pour combiner les résultats de 12 instructions SELECT distinctes, une pour chaque activité requise.
Personnalisation de la requête : ouvrez un nouvel éditeur de requêtes et collez l’intégralité du script SQL. 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 ID réservés, par exemple [Your 'Root Cause Category' field_id] et [Your 'Change Request ID' field_id], par les ID réels identifié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 varie selon la période sélectionnée et le 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 par le renseignement d’un champ personnalisé nommé [Your 'KB Article ID' field_id]. Si votre processus diffère, par exemple si vous utilisez un tag ou un commentaire spécifique, vous devrez adapter cette partie de la requête.
Validation des données : une fois la requête terminée, effectuez une vérification rapide des résultats. Contrôlez 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 telles que ProblemRecordId et EventTimestamp.
Export de l’Event Log : exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Vérifiez que le fichier utilise l’encodage UTF-8 et que les en-têtes de colonnes correspondent aux noms d’attributs requis par votre outil de Process Mining.
Préparation du chargement : avant l’importation, vérifiez le fichier CSV pour détecter d’éventuels problèmes de format. Assurez-vous que les valeurs de date et d’heure de la colonne EventTimestamp utilisent un format cohérent, tel que 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 préconfigurée pour analyser uniquement les tickets dont le type est « problem ». Cette restriction est essentielle pour 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 filtrer les données sur une période précise afin de maîtriser 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 votre configuration Zendesk. Vous devez identifier et renseigner le field_id correct pour les champs personnalisés qui suivent des activités telles que « Root Cause Identified », « Change Request Initiated » et « Workaround Published ». Si les ID réservés 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 la survenue d’un événement dans Zendesk et son apparition dans l’entrepôt de données. Tenez-en compte lors de l’analyse d’activités très récentes.

a 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.
Générer un jeton d’API Zendesk : connectez-vous à Zendesk Support en tant qu’administrateur. Accédez à Admin Center > Applications et intégrations > API > API Zendesk. Dans la section Accès par jeton, cliquez sur « Ajouter un jeton d’API » pour créer un nouveau jeton. Copiez immédiatement ce jeton et conservez-le dans un emplacement sécurisé, car il ne sera plus affiché.
Configurer le script Python : créez un nouveau fichier Python, par exemple extract_zendesk_problems.py, puis copiez-y l’intégralité du script fourni dans la section Query. Mettez à jour les variables d’espace réservé situées au début du script : ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN et START_TIME. Lors de la première exécution, définissez START_TIME sur l’horodatage Unix correspondant à la date de début souhaitée pour l’extraction.
Mapper les identifiants des champs personnalisés : identifiez les identifiants numériques des champs personnalisés utilisés dans votre processus de Gestion des problèmes. Vous pouvez les trouver en accédant à Admin Center > Objets et règles > Tickets > Champs, puis en examinant l’URL ou les propriétés du champ. Mettez à jour le dictionnaire CUSTOM_FIELD_MAPPING du script avec vos identifiants spécifiques.
Exécuter le script : lancez le script depuis votre terminal à l’aide de la commande python extract_zendesk_problems.py. Le script commencera à récupérer les données depuis l’API d’export incrémentiel Zendesk.
Surveiller l’exécution : le script affichera sa progression, notamment le nombre de tickets traités et l’horodatage actuellement récupéré. Il gérera automatiquement les limites de débit de l’API en se mettant en pause lorsque cela sera nécessaire.
Récupérer et transformer les données : le script récupère d’abord tous les tickets de problème créés ou mis à jour depuis START_TIME. Pour chaque ticket de problème, il récupère ensuite l’historique complet des audits, qui contient toutes les modifications enregistrées.
Générer l’Event Log : le script traite chaque événement d’audit et associe les modifications de champs, comme le statut, le groupe ou les champs personnalisés, 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.
Gérer les chargements incrémentiels : après le chargement initial complet, mettez à jour, lors des exécutions suivantes, la variable START_TIME avec la valeur end_time affichée à la fin de la dernière exécution réussie. Vous récupérerez ainsi uniquement les données nouvelles et mises à jour, sans doublons.
Vérifier le résultat : une fois le script terminé, il générera un fichier nommé zendesk_problem_event_log.csv dans le même répertoire. Ce fichier CSV contient l’Event Log structuré, prêt à être analysé.
Préparer le chargement : ouvrez le fichier CSV dans un tableur afin d’en vérifier le contenu. Avant de le charger 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 d’API et le jeton d’API lui-même pour l’authentification.
Heure de début : la variable START_TIME est un horodatage Unix qui définit le point de départ de l’extraction des données. Lors de la première exécution, définissez-la sur une date antérieure, par exemple six mois auparavant, afin de récupérer les données historiques. Lors des 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.
Mappage des champs personnalisés : le dictionnaire CUSTOM_FIELD_MAPPING est essentiel. Vous devez remplacer les identifiants d’espace réservé par les identifiants réels des champs personnalisés de votre instance Zendesk afin de capturer correctement des activités telles que « Contournement publié » et « Cause racine identifiée ».
Filtre sur le type de ticket : le script est configuré pour traiter uniquement les tickets dont le type est « problem ». Les incidents, tâches et questions sont ainsi exclus de l’Event Log de Gestion des problèmes.
Limitation du débit de l’API : le script inclut une fonction time.sleep(60) de base pour gérer les erreurs 429 « Too Many Requests ». La durée de cette pause devra peut-être être ajustée selon votre offre Zendesk et le volume de données extrait.
Prérequis : un environnement Python 3 avec les bibliothèques requests et pandas est nécessaire pour exécuter le script. Le jeton d’API doit être associé à un compte autorisé à lire les données des tickets.

a 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 ?

Transformez dès aujourd’hui la stabilité de votre environnement informatique en appliquant ce modèle à votre environnement Zendesk. Notre équipe peut vous aider à affiner l’extraction de vos données et à commencer votre démarche de process mining.

Retour au guide d’amélioration Télécharger le modèle

Optimisez votre Gestion des problèmes pour accélérer les corrections informatiques

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

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

Votre modèle de données de Gestion des problèmes

Votre modèle de données de Gestion des problèmes

Attributs de la gestion des problèmes

Activités de gestion des problèmes

Guides d’extraction

Export de l’historique des mises à jour Zendesk Explore

Étapes

Configuration

a Exemple de requête config

Requête SQL via Zendesk Data Sharing

Étapes

Configuration

a Exemple de requête sql

Extraction Python à l’aide de l’API d’export incrémentiel

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez votre Gestion des problèmes pour accélérer les corrections informatiques

Votre modèle de données de Gestion des problèmes

Votre modèle de données de Gestion des problèmes

Attributs de la gestion des problèmes

Activités de gestion des problèmes

Guides d’extraction

Export de l’historique des mises à jour Zendesk Explore

Étapes

Configuration

a Exemple de requête config

Requête SQL via Zendesk Data Sharing

Étapes

Configuration

a Exemple de requête sql

Extraction Python à l’aide de l’API d’export incrémentiel

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez votre Gestion des problèmes pour accélérer les corrections informatiques

Nous attachons de l’importance à votre confidentialité