> 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 gestion des problèmes (20) 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 cartographier votre cycle de vie de la gestion des problèmes dans Zendesk Support. Il décrit les attributs essentiels, les jalons de processus et la logique d'extraction nécessaires pour identifier les goulots d'étranglement dans l'analyse des causes premières. En suivant cette structure, vous pouvez construire un journal d'événements de haute qualité pour des informations de processus plus approfondies.

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

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

Télécharger le modèle

Attributs de gestion des 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 responsabilité tout au long du cycle de vie complet de résolution des problèmes.

5 Obligatoire 8 Recommandé 7 Facultatif

	Nom	Description
	Activité ActivityName	Le nom de l'événement ou de l'action effectuée sur le dossier de problème.
Description Cet attribut capture l'étape ou l'action spécifique entreprise pendant le cycle de vie du dossier de problème. Les exemples incluent les changements de statut comme « Open » à « Pending », les changements d'affectation ou des étapes de workflow spécifiques comme « Solution de contournement publiée ». En analyse, cela forme les nœuds de la carte de processus. La séquence de ces activités permet aux analystes de visualiser le flux de travail, d'identifier les goulots d'étranglement et de mesurer le temps pris entre les étapes spécifiques du processus. Pourquoi c'est important Il définit le « quoi » du processus, permettant la visualisation du flux de processus et l'analyse des variantes. Où obtenir Dérivé des Audits de tickets Zendesk ou des Métriques de tickets Exemples Dossier de problème enregistréInvestigation commencéeSolution de contournement publiée
	Dernière mise à jour des données LastDataUpdate	Le timestamp indiquant la dernière modification du dossier de problème.
Description Cet attribut reflète la dernière fois que les données du dossier de problème ont été mises à jour dans le système source. Il est distinct du timestamp de l'événement, car il se réfère au niveau du dossier plutôt qu'au niveau de l'activité. En analyse, cela aide à déterminer la fraîcheur des données. Il est utilisé pour identifier si le jeu de données est à jour ou s'il existe des retards de synchronisation entre le système source et l'environnement de process mining. Pourquoi c'est important Il suit la fraîcheur des données et aide aux stratégies de chargement de données incrémentiel. Où obtenir Objet Ticket Zendesk, champ 'updated_at' Exemples 2023-11-01T14:20:00Z
	Dossier de problème ProblemRecordId	L'identifiant numérique unique assigné au ticket problème dans Zendesk.
Description Cet attribut représente la clé unique du dossier de problème au sein du système Zendesk Support. Il sert d'ID de Cas central pour le process mining, permettant de regrouper tous les événements, mises à jour et interactions ultérieurs en une seule instance de processus. En analyse, cet ID est utilisé pour identifier de manière distinctive chaque parcours d'investigation de problème, de la création à la clôture. Il permet la corrélation des incidents liés et le suivi du cycle de vie du problème à travers les différents niveaux de support. Pourquoi c'est important C'est la clé fondamentale et obligatoire requise pour regrouper les événements en cas pour toute analyse de Process Mining. Où obtenir Objet Ticket Zendesk, champ 'id' où le type est 'problème' Exemples 1045293849921
	Heure de début EventTimestamp	La date et l'heure spécifiques auxquelles une activité a eu lieu.
Description Cet attribut enregistre le moment exact où une activité a eu lieu au sein du système Zendesk. Il fournit la dimension temporelle nécessaire pour séquencer correctement les événements et calculer les durées entre les étapes. En analyse, il est essentiel pour calculer les temps de cycle, identifier les retards, vérifier la conformité SLA et visualiser le processus au fil du temps. Sans des timestamps précis, il est impossible de comprendre la vélocité du processus de résolution des problèmes. Pourquoi c'est important Il permet le tri des activités et le calcul de tous les KPI basés sur le temps. Où obtenir Audits de tickets Zendesk, champ 'created_at' Exemples 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Système source SourceSystem	Le nom du système d'où proviennent les données.
Description Cet attribut identifie la plateforme logicielle à partir de laquelle les données de processus ont été extraites. Dans ce contexte, il sera systématiquement renseigné avec « Zendesk Support ». En analyse, en particulier lors de la combinaison de données provenant de plusieurs systèmes (ex. : Zendesk et Jira), ce champ permet aux analystes de filtrer ou de regrouper les données par leur origine. Il assure la lignée des données et la traçabilité dans les vues de processus multi-systèmes. Pourquoi c'est important Il assure la lignée des données et prend en charge les configurations de Process Mining multi-systèmes. Où obtenir Codé en dur lors de l'extraction Exemples Zendesk Support
	Catégorie de Cause Racine RootCauseCategory	La cause première identifiée du problème (ex. : Défaut de Code, Erreur de Configuration).
Description Cet attribut capture le diagnostic final de ce qui a causé le problème. Il est généralement renseigné pendant l'activité « Root Cause Identified ». En analyse, il est utilisé pour générer le rapport « Précision de la Catégorisation des Problèmes » et pour analyser les tendances des défaillances du système. Il aide la direction à comprendre si elle doit se concentrer sur la qualité du code, la stabilité de l'infrastructure ou la gestion des fournisseurs. Pourquoi c'est important Il permet l'analyse des schémas de défaillance et oriente les efforts d'amélioration à long terme. Où obtenir Champs personnalisés des tickets Zendesk Exemples Bogue logicielErreur de configurationErreur utilisateur
	Catégorie de problème ProblemCategory	La classification du problème (ex. : Logiciel, Matériel, Réseau).
Description Cet attribut catégorise le problème en fonction du service ou de la pile technologique affectée. C'est généralement un champ déroulant personnalisé dans les formulaires Zendesk. En analyse, il est utilisé pour le tableau de bord « Précision de la Catégorisation des Problèmes ». Comparer cette catégorie initiale à la cause première finale aide à identifier si le triage initial achemine correctement les problèmes vers les bonnes équipes. Pourquoi c'est important Il permet une segmentation par technologie ou service métier. Où obtenir Champs personnalisés des tickets Zendesk Exemples Base de `données`UI/UXInfrastructure Réseau
	Date d'échéance du `SLA` SlaDueDate	La date et l'heure cibles auxquelles le problème devrait être résolu.
Description Cet attribut représente la date limite de résolution basée sur la configuration de l'accord de niveau de service. Il est généralement calculé en fonction de la priorité et de l'heure de création du ticket. En analyse, il est comparé au temps de résolution réel pour calculer le « Taux d'Adhérence SLA des Problèmes ». Il alimente le tableau de bord « Performance et Risque SLA » en mettant en évidence les cas qui approchent ou ont dépassé leur temps imparti. Pourquoi c'est important Il est essentiel pour mesurer la conformité et la performance contractuelle. Où obtenir Endpoint des métriques de tickets Zendesk ou des politiques SLA Exemples 2023-12-01T17:00:00Z
	Groupe de support SupportGroup	L'équipe ou le département actuellement assigné au dossier de problème.
Description Cet attribut identifie le groupe spécifique d'agents responsable du problème à un moment donné. Il change à mesure que le ticket est transféré d'une équipe à l'autre. En analyse, il est crucial pour le tableau de bord « Analyse des Transferts de Groupes de Support ». Il permet de mesurer la performance par équipe, d'identifier les goulots d'étranglement lors des transferts et d'analyser la distribution de la charge de travail des ressources. Pourquoi c'est important Il permet l'analyse organisationnelle et l'identification des goulots d'étranglement entre les départements. Où obtenir Objet Ticket Zendesk, champ 'group_id' (résolu en nom) Exemples Support N2Équipe Base de donnéesOpérations Réseau
	Nom de l'assigné AssigneeName	L'agent spécifique assigné pour travailler sur le problème.
Description Cet attribut contient le nom de l'utilisateur individuel actuellement responsable du dossier de problème. Il offre une visibilité granulaire sur qui a effectué des actions spécifiques. En analyse, cela aide à comprendre la charge de travail et la performance individuelles. Bien que l'analyse au niveau du groupe soit courante, les données au niveau de l'assigné peuvent mettre en évidence les besoins en formation ou les individus particulièrement efficaces pour résoudre les causes premières complexes. Pourquoi c'est important Il permet l'analyse des ressources au niveau individuel. Où obtenir Objet Ticket Zendesk, champ 'assignee_id' (résolu en nom) Exemples John DoeJane SmithSystème
	Nombre d'incidents liés RelatedIncidentCount	Le nombre de tickets d'incident liés à ce dossier de problème.
Description Cet attribut compte le nombre de tickets d'incident individuels associés à ce dossier de problème. Dans Zendesk, cela est géré via le champ « problem_id » sur les tickets d'incident qui renvoient à ce dossier. En analyse, c'est la métrique principale pour « Corrélation et Impact des Incidents ». Il aide à prioriser les problèmes qui affectent le plus grand nombre d'utilisateurs, guidant les décisions stratégiques sur les corrections qui produiront le ROI le plus élevé en termes de réduction du volume de tickets. Pourquoi c'est important Il indique l'ampleur et l'impact du problème sur l'utilisateur. Où obtenir API Tickets Zendesk, nombre de tickets où type='incident' et problem_id=CetID Exemples 015342
	Priorité Priority	Le niveau d'urgence assigné au dossier de problème.
Description Cet attribut indique l'importance relative du problème, généralement catégorisé comme Faible, Normal, Élevé ou Urgent. Il détermine les accords de niveau de service (SLA) attendus et l'allocation des ressources. En analyse, il est utilisé pour segmenter le processus et comparer les performances selon différents niveaux d'urgence. Par exemple, il aide à vérifier si les problèmes « Urgents » sont effectivement résolus plus rapidement que ceux de priorité « Faible », comme l'exige le tableau de bord « Vélocité d'Investigation de la Cause Première ». Pourquoi c'est important Il est essentiel pour segmenter les cas afin d'analyser le respect des SLA et la priorisation des ressources. Où obtenir Objet Ticket Zendesk, champ 'priority' Exemples UrgentÉlevéNormalFaible
	Statut du problème ProblemStatus	L'état actuel du dossier de problème dans son cycle de vie.
Description Cet attribut affiche le statut actuel du problème, tel que Nouveau, Ouvert, En attente, Résolu ou Clôturé. Il reflète l'avancement de l'investigation. En analyse, il est utilisé pour filtrer les cas ouverts par rapport aux cas fermés. Il est vital pour le tableau de bord « Surveillance des Dossiers de Problèmes Stagnants » d'identifier quels cas actifs ne progressent pas dans le cycle de vie de statut attendu. Pourquoi c'est important Il permet de filtrer les cas en fonction de leur état d'achèvement. Où obtenir Objet Ticket Zendesk, champ 'status' Exemples nouveauopenpendingsolvedfermé
	A PIR HasPostImplementationReview	Indique si un examen post-implémentation a été effectué.
Description Cet attribut indique si le processus de résolution du problème a inclus une phase de revue. Il est dérivé en vérifiant si l'activité « Revue Post-Implémentation Effectuée » existe dans l'historique du cas. En analyse, il soutient le tableau de bord « Couverture des Revues Post-Implémentation ». C'est un indicateur de conformité garantissant que l'organisation apprend de ses problèmes majeurs. Pourquoi c'est important Il valide la conformité aux processus d'amélioration continue. Où obtenir Dérivé de la présence de l'activité « Examen post-implémentation effectué » Exemples truefaux
	Durée de l'enquête InvestigationDuration	Le temps pris du début de l'investigation à l'identification de la cause première.
Description Cet attribut calculé mesure la durée de la phase de diagnostic principale. Il calcule la différence de temps entre l'activité « Investigation Commencée » et l'activité « Root Cause Identified ». En analyse, c'est la métrique principale pour la « Durée Moyenne de l'Analyse des Causes Premières ». Il permet de comparer la vitesse de diagnostic entre différents groupes de support et catégories de problèmes. Pourquoi c'est important Il mesure l'efficacité du processus de diagnostic. Où obtenir Calculé dans l'outil Process Mining : Horodatage(Cause première) - Horodatage(Début d'enquête) Exemples 48 heures5 jours
	Est obsolète IsStale	Indique si le problème n'a eu aucune activité depuis plus de 14 jours.
Description Cet attribut calculé identifie les dossiers qui n'ont pas été mis à jour récemment. Il compare la date actuelle (ou la date d'analyse) avec le timestamp de la dernière activité. En analyse, il alimente le tableau de bord « Surveillance des Dossiers de Problèmes Stagnants ». Il aide les gestionnaires à isoler rapidement les cas négligés qui encombrent l'arriéré et peuvent nécessiter une clôture administrative ou une réaffectation. Pourquoi c'est important Il aide à identifier le gaspillage de processus et les éléments de travail négligés. Où obtenir Calculé dans l'outil Process Mining : (Maintenant - LastDataUpdate) > 14 jours Exemples truefaux
	ID de l'article de connaissance KnowledgeArticleId	L'ID de l'article de la base de connaissances créé ou lié au problème.
Description Cet attribut stocke la référence à un article de Zendesk Guide ou à un élément de connaissance externe. Il indique que les connaissances acquises grâce au problème ont été capturées. En analyse, la présence de ce champ est utilisée pour calculer le « Taux d'Intégration de la Base de Connaissances ». Il vérifie que l'organisation boucle la boucle d'apprentissage en documentant les solutions pour référence future. Pourquoi c'est important Il mesure l'efficacité des processus de gestion des connaissances. Où obtenir Champs personnalisés des tickets Zendesk ou contenu lié Exemples 360045889KB-2991
	ID de la demande de changement ChangeRequestId	L'identifiant de la demande de changement liée pour implémenter la correction.
Description Cet attribut lie le dossier de problème à un dossier de gestion du changement (potentiellement dans un autre système ou un type de ticket différent). Il signifie qu'un processus de changement formel a été initié. En analyse, cela soutient le tableau de bord « Taux d'Initiation des Demandes de Changement ». Il aide à suivre la transition du diagnostic à l'implémentation, garantissant que les causes premières identifiées débouchent sur des actions de changement formelles. Pourquoi c'est important Il lie le processus de problème au processus de gestion des changements. Où obtenir Champs personnalisés des tickets Zendesk ou tickets liés Exemples CR-1002CHG00394
	Objet du problème ProblemSubject	Le bref résumé ou le titre du dossier de 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'enquête. En analyse, cela fournit un contexte à l'analyste lors de l'examen approfondi de cas spécifiques. Des techniques de text mining peuvent également être appliquées ici pour regrouper des problèmes similaires ou identifier des sujets 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'homme pour les cas individuels. Où obtenir Objet Ticket 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 de données pour les utilisateurs administrateurs
	Solution de contournement active WorkaroundActive	Un indicateur signalant si une solution de contournement a été fournie/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é « Solution de contournement publiée » ou d'une case à cocher spécifique sur le formulaire. En analyse, il est utilisé pour le tableau de bord « Conformité de Publication des Solutions de Contournement ». Il mesure la fréquence à laquelle l'équipe de support fournit un soulagement immédiat aux utilisateurs pendant que l'investigation à long terme se poursuit. Pourquoi c'est important C'est essentiel pour mesurer l'atténuation de l'impact utilisateur pendant les enquêtes. Où obtenir Dérivé de la présence de l'activité « Solution de contournement publiée » ou d'un champ personnalisé Exemples truefaux

Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Capturez ces étapes de processus essentielles et ces changements de statut pour visualiser le flux de bout en bout, de l'identification initiale du problème à l'implémentation de la correction permanente.

8 Recommandé 4 Facultatif

	Activité	Description
	Affecté au Groupe de Support	Le routage du dossier de problème vers une équipe technique ou un département spécifique. Ceci est suivi lorsque le champ ID de Groupe sur le ticket est mis à jour.
Pourquoi c'est important Crucial pour le tableau de bord d'analyse des transferts de groupe de support afin de mesurer les temps d'attente entre les départements. Où obtenir Surveillez le champ « group_id » du journal d'audit des tickets pour les modifications. Capture Enregistré lors de l'exécution de la transaction Changement d'affectation de groupe Type d'événement explicit
	Cause profonde identifiée	Le moment où la cause première du problème est déterminée. Ceci est généralement capturé lorsqu'un champ de texte personnalisé « Root Cause » ou une catégorie déroulante est renseignée par l'agent.
Pourquoi c'est important Une étape cruciale pour le tableau de bord de la vélocité des enquêtes sur les causes premières et pour la mesure de l'efficacité du diagnostic. Où obtenir Surveillez les modifications des champs personnalisés étiquetés « Root Cause », « RCA » ou « Source du Problème » pour les valeurs non nulles. Capture Comparez les valeurs des champs personnalisés pour le renseignement Type d'événement inferred
	Correction permanente appliquée	Signifie que la solution technique a été déployée dans l'environnement. Ceci est généralement suivi via une transition de statut personnalisée ou une balise spécifique avant que le ticket ne soit entièrement résolu.
Pourquoi c'est important Essentiel pour le tableau de bord d'efficacité de l'implémentation des correctifs afin de mesurer le temps entre le diagnostic et le déploiement. Où obtenir Déduit d'une balise spécifique (par exemple, 'fix_deployed') ou d'un champ de statut personnalisé s'il en existe un. Capture Surveillez les balises ou les menus déroulants de statut personnalisé Type d'événement inferred
	Dossier de problème clôturé	L'événement final du cycle de vie où le ticket est verrouillé et aucune autre modification ne peut être apportée. Dans Zendesk, cela se produit généralement automatiquement 4 jours après l'état Résolu.
Pourquoi c'est important Marque la fin absolue de la vie du dossier et est utilisé pour la rétention des données et les rapports historiques. Où obtenir Dérivé du statut du ticket passant à « Fermé ». Capture Enregistré lorsque le statut passe à Clôturé Type d'événement explicit
	Dossier de problème enregistré	La création initiale du ticket problème au sein de Zendesk Support. Cet événement capture le timestamp lorsque le problème a été enregistré pour la première fois dans le système, déclenchant généralement l'instance de processus.
Pourquoi c'est important Établit l'heure de début du cycle de résolution de bout en bout et sert de référence pour toutes les métriques de délai subséquentes. Où obtenir Dérivé de l'horodatage 'created_at' dans l'objet ticket ou de la première entrée dans le journal d'audit du ticket. Capture Enregistré lors de l'exécution de la transaction Ticket créé Type d'événement explicit
	Investigation commencée	Marque la transition d'un état « Nouveau » passif à un état de travail actif. Cela indique qu'un agent a pris connaissance du problème et a commencé le diagnostic.
Pourquoi c'est important Utilisé pour calculer les métriques des dossiers de problèmes stagnants et est le point de départ pour le KPI de la Durée Moyenne de l'Analyse des Causes Premières. Où obtenir Déduit lorsque le statut du ticket passe de « Nouveau » à « Ouvert » ou « En attente ». Capture Comparer le champ de statut avant/après Type d'événement inferred
	Résolution vérifiée	La désignation formelle du problème comme Résolu. Dans Zendesk, cela se produit lorsque le statut système standard est défini sur « Solved », indiquant que la correction est vérifiée et que le cas est terminé.
Pourquoi c'est important Le point de terminaison principal pour les calculs de performance et de risque SLA et le taux d'adhérence SLA des problèmes. Où obtenir Dérivé du statut du ticket passant à « Résolu ». Capture Enregistré lorsque le statut passe à Résolu Type d'événement explicit
	Solution de contournement publiée	L'action de documenter et de partager une correction temporaire pour le problème. Dans Zendesk, ceci est souvent capturé via une balise spécifique ou un champ case à cocher personnalisé indiquant qu'une solution de contournement est disponible.
Pourquoi c'est important Soutient le tableau de bord de conformité de publication des solutions de contournement, garantissant un soulagement temporaire aux utilisateurs lors de longues investigations. Où obtenir Surveiller l'ajout d'une balise « workaround_published » ou une modification d'un champ booléen personnalisé nommé « Solution de contournement ». Capture Comparez les valeurs des champs personnalisés ou des étiquettes Type d'événement inferred
	Demande de changement initiée	Indique qu'un processus formel de gestion des changements a été déclenché pour résoudre le problème. Ceci est souvent déduit lorsqu'un champ personnalisé « ID de demande de changement » est renseigné ou qu'un ticket de type « Changement » est lié.
Pourquoi c'est important Suit le taux d'initiation des demandes de changement et lie la gestion des problèmes aux workflows de gestion des changements. Où obtenir Surveiller les mises à jour d'un champ personnalisé comme « change_reference » ou la création d'un type de lien « problem_change ». Capture Surveiller le champ personnalisé pour la saisie d'un ID externe Type d'événement inferred
	Investigation de problème rouverte	Se produit lorsqu'un dossier de problème précédemment marqué comme Résolu retourne à un état Ouvert ou actif. Cela indique un échec de la correction ou une résolution rejetée.
Pourquoi c'est important Soutient le KPI du taux de réouverture des problèmes et aide à identifier les problèmes de qualité dans le processus de résolution. Où obtenir Déduit lorsque le statut passe de « Résolu » à « Ouvert », « Nouveau » ou « En attente ». Capture Comparer le champ de statut avant/après Type d'événement inferred
	Revue Post-Implémentation effectuée	Confirmation qu'un examen rétrospectif a été effectué 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 de processus.
Pourquoi c'est important Requis pour l'indicateur clé de performance (KPI) de fréquence des revues post-implémentation afin d'assurer la conformité aux normes de qualité. Où obtenir Surveiller les mises à jour d'une case à cocher personnalisée « PIR Terminé » ou du champ de date « Date PIR ». Capture Surveiller le champ personnalisé pour son achèvement Type d'événement inferred
	Solution proposée rédigée	La création d'un article de base de connaissances basée sur l'investigation du problème. Ceci est déduit de l'utilisation de l'application Zendesk Knowledge Capture ou du lien vers un nouvel article.
Pourquoi c'est important Soutient le KPI du taux d'intégration de la base de connaissances, assurant l'apprentissage organisationnel. Où obtenir Surveiller les événements liés à l'intégration « Knowledge Capture » ou des balises comme « kcs_draft ». Capture Déduire des balises système spécifiques ou des événements de lien Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Zendesk Support

Étapes

Connectez-vous à votre instance Zendesk et naviguez vers l'interface de reporting Explore via la barre de produits.
Cliquez sur le dossier Requêtes (ou Rapports dans les versions plus récentes) et sélectionnez Nouvelle requête.
Lorsque vous êtes invité à sélectionner un jeu de données, choisissez Support suivi de Historique des mises à jour suivi de Support : Historique des mises à jour [par défaut]. Ce jeu de données contient les journaux d'événements requis pour le Process Mining plutôt que les données d'état actuel.
Dans le panneau Métriques, ajoutez Nombre (Tickets) ou Nombre (Mises à jour) pour vous assurer que les données sont extraites.
Dans le panneau Filtres, ajoutez un filtre pour Ticket > Type de ticket et sélectionnez Problème pour restreindre le jeu de données au processus de Gestion des problèmes.
Dans le panneau Lignes, ajoutez les attributs suivants dans cet ordre spécifique pour définir la structure du journal d'événements : Ticket > ID de ticket, Heure - Horodatage > Horodatage de mise à jour, Metteur à jour > Nom du metteur à jour, et Modifications > Modifications - Nom du champ.
Pour créer la colonne Nom de l'activité, vous devez créer un Attribut calculé standard. Cliquez sur l'icône Calcul dans la barre latérale droite, sélectionnez Attribut calculé standard, nommez-le Activity Mapper, et collez le code fourni dans la section Requête ci-dessous.
Ajoutez ce nouvel attribut Activity Mapper au panneau Lignes. Filtrez cet attribut pour exclure les valeurs NULL afin de supprimer le bruit système non pertinent.
Ajoutez des attributs supplémentaires au panneau Lignes pour le contexte : Ticket > Priorité, Ticket > Groupe, Ticket > Statut, et tout champ personnalisé requis pour l'analyse des causes premières ou des catégories (par exemple, Ticket > Étiquettes de ticket ou Champs personnalisés spécifiques).
Définissez la plage de temps dans le panneau Filtres en utilisant Heure - Horodatage > Date de mise à jour pour couvrir la fenêtre d'analyse souhaitée (par exemple, Les 6 derniers mois).
Cliquez sur l'icône Type de visualisation et sélectionnez Tableau. Assurez-vous que le tableau est non pivoté ou plat si cette option est disponible, ou assurez-vous simplement que tous les attributs sont dans la section Lignes.
Exportez le résultat en cliquant sur Exporter > CSV. Assurez-vous que la case « Conserver le formatage des attributs » est cochée pour préserver les formats d'horodatage pour ProcessMind.

Configuration

Jeu de données : Support : Historique des mises à jour (Important : N'utilisez pas le jeu de données standard Tickets, car il ne présente que l'état actuel).
Filtre temporel : Date de mise à jour (Recommandé : Les 90 à 180 derniers jours, selon le volume).
Type de ticket : Filtrez strictement par Problème pour éviter de mélanger les Incidents et les Demandes de service.
Limite de lignes : Les exportations Zendesk Explore sont souvent limitées à 50 000 lignes. Si votre jeu de données dépasse cette limite, utilisez le filtre Date de mise à jour pour exporter par segments mensuels plus petits et les fusionner en externe.
Champs personnalisés : Identifiez les ID de champ spécifiques pour la Cause première, la Demande de changement et la Solution de contournement dans votre instance Zendesk, car ce ne sont pas des champs système standards.
Permissions système : Nécessite une licence Explore Viewer ou Explore Professional.

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

Confirmation des prérequis : Assurez-vous que votre organisation a activé l'add-on Zendesk Data Sharing. Confirmez que vous disposez d'identifiants d'accès en lecture seule pour la base de données Zendesk répliquée, généralement hébergée sur Snowflake ou Amazon Redshift.
Connectez-vous à la base de données : Utilisez votre client SQL préféré (tel que DBeaver, DataGrip ou l'interface web native Snowflake/Redshift) pour établir une connexion à votre entrepôt de données Zendesk en utilisant les identifiants fournis.
Identifiez les champs personnalisés : Avant d'exécuter la requête, vous devez identifier les ID uniques des champs personnalisés utilisés dans votre processus de Gestion des problèmes. Naviguez vers l'Admin Center dans Zendesk, allez dans Objets et règles > Tickets > Champs. Recherchez les champs pour « Cause première », « ID de demande de changement », « Solution de contournement publiée », « Correctif permanent appliqué » et « Examen post-implémentation » pour obtenir leurs ID de champ spécifiques. Ceux-ci seront utilisés pour remplacer les substituts dans la requête.
Examinez la requête SQL : La requête fournie utilise une expression de table commune (CTE) nommée ProblemTickets pour d'abord sélectionner et filtrer tous les enregistrements de problème. Cela 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.
Personnalisez la requête : Ouvrez un nouvel éditeur de requête et collez le script SQL complet. Modifiez les substituts dans le script :
- Dans la CTE ProblemTickets, définissez la plage de dates souhaitée en remplaçant '[YYYY-MM-DD]'.
- Pour chaque activité qui dépend d'un champ personnalisé, remplacez les ID de substitut (par exemple, [Votre ID de champ 'Catégorie de cause première'], [Votre ID de champ 'ID de demande de changement']) par les ID réels que vous avez identifiés à l'étape 3.
Exécutez la requête : Exécutez le script SQL modifié sur la base de données. Le temps d'exécution variera en fonction de la plage de dates et du volume de données de ticket.
Examinez la logique de « Solution proposée rédigée » : La requête suppose que la rédaction d'une solution est capturée par le renseignement d'un champ personnalisé nommé [Votre ID de champ 'ID d'article de base de connaissances']. Si votre processus diffère, par exemple, en utilisant une balise ou un commentaire spécifique, vous devrez ajuster cette partie de la requête en conséquence.
Validation des données : Une fois la requête terminée, effectuez un bref examen des résultats. Vérifiez un nombre raisonnable de lignes, assurez-vous que toutes les colonnes sont présentes et recherchez d'éventuelles valeurs NULL inattendues dans des colonnes critiques comme ProblemRecordId et EventTimestamp.
Exportez le journal d'événements : Exportez l'ensemble du jeu de résultats de votre client SQL vers un fichier CSV. Assurez-vous que le fichier utilise l'encodage UTF-8 et que les en-têtes de colonne correspondent aux noms d'attributs requis par votre outil de Process Mining.
Préparez-vous à l'importation : Avant d'importer, vérifiez le fichier CSV pour tout problème de formatage. Assurez-vous que les valeurs de date et d'heure dans la colonne EventTimestamp sont dans un format cohérent, tel que YYYY-MM-DD HH24:MI:SS.

Configuration

Prérequis : Cette extraction nécessite l'add-on Zendesk Data Sharing et un accès SQL direct aux données répliquées dans une instance Snowflake ou Amazon Redshift.
Filtre de type de ticket : La requête est préconfigurée pour n'analyser que les tickets dont le type est « problème ». Ceci est essentiel pour isoler le processus de Gestion des problèmes des incidents et autres types de tickets.
Filtrage par plage de dates : Il est fortement recommandé de filtrer les données pour une période spécifique afin de gérer les performances. La requête inclut un substitut created_at >= '[YYYY-MM-DD]' dans la CTE initiale. Pour une première analyse, une plage de 3 à 6 mois est typique.
Configuration des champs personnalisés : Cette extraction dépend fortement de votre configuration Zendesk spécifique. Vous devez identifier et insérer le field_id correct pour les champs personnalisés qui suivent des activités comme « Cause première identifiée », « Demande de changement initiée » et « Solution de contournement publiée ». La requête échouera ou ne retournera aucune donnée pour ces activités si les ID de substitut ne sont pas remplacés.
Latence des données : Les données dans la base de données répliquée ne sont pas en temps réel. Il y a généralement un délai de quelques heures entre un événement se produisant dans Zendesk et son apparition dans l'entrepôt de données. Gardez cela à l'esprit 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 : Assurez-vous d'avoir Python 3.6+ installé sur votre système. Installez les bibliothèques requests et pandas requises en exécutant pip install requests pandas dans votre terminal ou invite de commande.
Générez un jeton API Zendesk : Connectez-vous à Zendesk Support en tant qu'administrateur. Naviguez vers Admin Center > Applications et intégrations > API > API Zendesk. Dans la section Accès au jeton, cliquez sur « Ajouter un jeton API » pour créer un nouveau jeton. Copiez ce jeton immédiatement et stockez-le en toute sécurité, car il ne sera plus affiché.
Configurez le script Python : Créez un nouveau fichier Python (par exemple, extract_zendesk_problems.py) et copiez le script complet fourni dans la section Requête dans ce fichier. Mettez à jour les variables de substitution 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 de la date de début souhaitée pour votre extraction.
Mappez les ID de champ personnalisés : Identifiez les ID numériques des champs personnalisés utilisés dans votre processus de Gestion des problèmes. Vous pouvez les trouver en naviguant vers Admin Center > Objets et règles > Tickets > Champs et en inspectant l'URL ou les propriétés des champs. Mettez à jour le dictionnaire CUSTOM_FIELD_MAPPING dans le script avec vos ID spécifiques.
Exécutez le script : Exécutez le script depuis votre terminal en utilisant la commande python extract_zendesk_problems.py. Le script commencera à récupérer les données de l'API Zendesk Incremental Export.
Surveillez l'exécution : Le script affichera sa progression, y compris le nombre de tickets traités et l'horodatage actuel qu'il récupère. Il gérera automatiquement les limites de débit 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 le START_TIME. Pour chaque ticket de problème, il récupère ensuite la piste d'audit complète, qui contient toutes les modifications historiques.
Génération du journal d'événements : Le script traite chaque événement d'audit, mappant les modifications de champ (comme le statut, le groupe ou les mises à jour de champ personnalisé) aux activités commerciales définies. Il récupère et met également en cache les noms d'utilisateurs et de groupes pour enrichir les données.
Gestion des chargements incrémentiels : Après le chargement complet initial, pour les exécutions ultérieures, mettez à jour la variable START_TIME avec la end_time imprimée à la fin de la précédente exécution réussie. Cela garantit que vous ne tirez que les données nouvelles et mises à jour sans duplication.
Examinez la sortie : 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 le journal d'événements structuré prêt pour l'analyse.
Préparez-vous à l'importation : Ouvrez le fichier CSV dans un outil de feuille de calcul pour vérifier son contenu. Assurez-vous que toutes les colonnes requises (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) sont présentes et correctement renseignées avant d'importer dans ProcessMind.

Configuration

Identifiants API Zendesk : Le script nécessite votre sous-domaine Zendesk, l'adresse e-mail de l'utilisateur associé au jeton API, et le jeton API lui-même pour l'authentification.
Start Time : La variable START_TIME est un horodatage Unix epoch qui définit le point de départ de l'extraction des données. Pour la première exécution, définissez-la sur une date passée (par exemple, 6 mois auparavant) pour obtenir des données historiques. Pour les exécutions ultérieures, 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 mettre à jour les ID de substitut avec les ID de champ personnalisés réels de votre instance Zendesk pour capturer correctement des activités comme « Solution de contournement publiée » et « Cause première identifiée ».
Filtre de type de ticket : Le script est codé en dur pour ne traiter que les tickets dont le type est « problème ». Cela garantit que les incidents, les tâches et les questions sont exclus du journal d'événements de gestion des problèmes.
Limitation du débit API : Le script inclut une fonction time.sleep(60) de base pour gérer les erreurs 429 « Trop de requêtes ». La durée de cette pause peut nécessiter un ajustement en fonction de votre plan Zendesk et du volume de données extraites.
Prérequis : Un environnement Python 3 avec les bibliothèques requests et pandas est nécessaire pour exécuter le script. Le jeton API doit être associé à un compte ayant la permission de lire les données de ticket.

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

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

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

Attributs de gestion des problèmes

Activités de gestion des problèmes

Guides d'extraction

Exportation de l'historique des mises à jour de Zendesk Explore

Étapes

Configuration

a Exemple de requête config

Requête SQL via le partage de données Zendesk

Étapes

Configuration

a Exemple de requête sql

Extraction Python via l'API d'exportation incrémentielle

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Optimisez votre gestion des problèmes pour des corrections IT plus rapides

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

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

Attributs de gestion des problèmes

Activités de gestion des problèmes

Guides d'extraction

Exportation de l'historique des mises à jour de Zendesk Explore

Étapes

Configuration

a Exemple de requête config

Requête SQL via le partage de données Zendesk

Étapes

Configuration

a Exemple de requête sql

Extraction Python via l'API d'exportation incrémentielle

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimisez votre gestion des problèmes pour des corrections IT plus rapides