> Amélioration continue des processus > Service client > Zendesk Support > Modèle de données

Votre modèle de données pour le service client

Zendesk Support

Attributs du service client (18) Activités du service client (14) Guides d’extraction (4)

Votre modèle de données pour le service client

Ce modèle vous aide à réunir les données nécessaires à l’analyse de votre processus de service client. Il présente les attributs essentiels à recueillir, les activités clés à suivre et des conseils pratiques pour extraire ces informations. Ce guide vous permet de constituer un journal d’événements fiable pour mieux comprendre vos opérations de service et les améliorer.

Attributs recommandés à recueillir
Activités clés à suivre dans votre processus de service client
Conseils d’extraction pour Zendesk Support

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

Télécharger le modèle

Attributs du service client

Voici les champs de données recommandés pour votre journal d’événements afin de réaliser une analyse complète du service client.

5 Obligatoire 6 Recommandé 7 Facultatif

	Nom	Description
	Demande de service ServiceRequest	Identifiant unique de chaque demande de service client, également appelée ticket ou cas.
Description La demande de service est l’identifiant principal du cas. Elle relie toutes les activités associées à une demande ou à un problème client, de sa création à sa résolution définitive. Chaque interaction, mise à jour ou action interne est associée à cet identifiant unique. En process mining, l’analyse des événements regroupés par demande de service donne une vue complète du parcours de service client, de bout en bout. Cet identifiant sert de base au calcul d’indicateurs clés, comme le délai total de résolution, à la détection des écarts de processus et à l’analyse du cycle de vie de chaque problème client. Pourquoi est-ce important ? Il s’agit de l’ID de cas essentiel qui relie toutes les étapes du processus et permet de reconstituer et d’analyser chaque parcours de service client. Où trouver ces données API Zendesk Tickets, champ `id`. Exemples 102451287415332
	Heure de début StartTime	Horodatage indiquant le début d’une activité ou d’un événement.
Description L’heure de début, ou horodatage de l’événement, indique la date et l’heure exactes auxquelles une activité s’est produite. Elle permet, par exemple, de savoir quand un client a ajouté un commentaire, quand un agent a été affecté ou quand le statut du ticket est passé à « Resolved ». Cet horodatage est fondamental en process mining, car il établit l’ordre chronologique des événements. Il sert à calculer les durées entre les activités, à mesurer les temps de cycle, à évaluer les performances au regard des SLA et à comprendre l’évolution du processus de service dans le temps. Pourquoi est-ce important ? Cet horodatage est essentiel pour ordonner les événements, calculer les durées et analyser le déroulement du processus de traitement des demandes de service. Où trouver ces données API Zendesk Ticket Audits, champ `created_at` de chaque événement de la piste d’audit. Exemples 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation ou extraction des données depuis le système source.
Description Cet attribut indique la dernière mise à jour du jeu de données depuis Zendesk Support. Il précise l’ancienneté des données analysées. La date de dernière mise à jour aide les analystes et les équipes métier à savoir si les informations sur le processus sont à jour. Elle permet de connaître la fraîcheur des données et joue un rôle important dans le reporting et le suivi. Pourquoi est-ce important ? Précise l’ancienneté des données afin que les utilisateurs sachent à quelle date remonte l’analyse du processus. Où trouver ces données Champ de métadonnées généré et enregistré lors de l’extraction des données. Il contient l’horodatage de l’extraction. Exemples 2023-10-27T02:00:00Z
	Nom de l’activité ActivityName	Nom de l’événement ou de la tâche qui s’est produit au cours du cycle de vie de la demande de service.
Description Le nom de l’activité désigne une étape ou un jalon du processus de service client, comme « Demande de service créée », « Demande attribuée à un agent » ou « Demande de service résolue ». Ces événements sont horodatés et forment la séquence des actions associées à chaque demande de service. Cet attribut est essentiel pour visualiser le flux du processus, découvrir ses variantes et analyser la fréquence et l’ordre des événements. Il permet aux analystes de comprendre les actions réalisées et de repérer les parcours courants, les goulots d’étranglement et les écarts par rapport à la procédure standard. Pourquoi est-ce important ? Cet attribut définit les étapes du processus et permet de visualiser la carte du processus, puis d’analyser les flux et leurs variantes. Où trouver ces données Dérivé des journaux d’audit des tickets Zendesk ou des flux d’événements qui enregistrent les modifications et les actions. Exemples Demande de service crééeDemande attribuée à un agentPremière réponse publique de l’agent envoyéeDemande de service résolue
	Système source SourceSystem	Système de référence depuis lequel les données ont été extraites.
Description Cet attribut indique le système d’origine des données de demande de service, ici Zendesk Support. Il contribue à la gouvernance et à la traçabilité des données, notamment lorsque celles-ci proviennent de plusieurs systèmes. Dans le cadre de l’analyse, il garantit que les données sont correctement attribuées à leur source. C’est important pour préserver leur intégrité et comprendre le contexte du processus, en particulier dans un environnement composé de plusieurs systèmes. Pourquoi est-ce important ? Indique l’origine des données, ce qui est essentiel pour leur gouvernance et pour distinguer les données de processus dans des environnements intégrés. Où trouver ces données Valeur statique ajoutée lors de l’extraction des données pour en indiquer l’origine. Exemples Zendesk Support
	Agent affecté AssignedAgent	Nom ou identifiant de l’agent de service client chargé de traiter la demande.
Description Cet attribut identifie l’agent responsable d’une activité ou de la demande de service à un moment donné. Il peut changer au cours du cycle de vie si la demande est réattribuée. L’analyse par agent affecté permet de comprendre la charge de travail, les performances et l’efficacité des agents. Elle alimente le Dashboard « Charge de travail et efficacité des agents », qui compare les délais de traitement et le volume de cas entre agents. Ces comparaisons aident à repérer les besoins d’accompagnement et à mieux répartir la charge de travail. Pourquoi est-ce important ? Indique quel agent a effectué une action et permet d’analyser les performances individuelles, la répartition de la charge de travail et l’affectation des ressources. Où trouver ces données API Zendesk Tickets, champ `assignee_id`. Les informations sur les utilisateurs peuvent être récupérées depuis l’API Users. Exemples Jean DupontJeanne MartinSupportBot
	Canal de communication CommunicationChannel	Canal par lequel la demande de service a été envoyée ou la communication a eu lieu.
Description Cet attribut indique le moyen de communication utilisé, par exemple le courriel, un formulaire Web, le chat ou le téléphone. Il reflète la façon dont les clients échangent avec le centre de services. Comprendre l’utilisation des différents canaux est important pour planifier les ressources et améliorer l’expérience client. Le Dashboard « Utilisation des canaux de communication » analyse ces données pour déterminer quels canaux sont les plus utilisés et si certains sont associés à des délais de résolution plus longs ou à des parcours différents. Ces informations peuvent aider à décider où investir pour améliorer le service ou mettre en place l’automatisation. Pourquoi est-ce important ? Montre comment les clients et les agents échangent, afin d’analyser l’efficacité des canaux et leur incidence sur le processus et l’expérience client. Où trouver ces données API Zendesk Tickets, champ `via.channel`. Exemples WebCourrielAPIChat
	Délai cible de résolution du SLA SlaTargetResolutionTime	Délai dans lequel une demande de service doit être résolue, conformément à la politique de SLA applicable.
Description Cet attribut définit le délai cible de résolution d’un ticket selon le contrat de niveau de service (SLA). Ce délai varie souvent en fonction de facteurs tels que la priorité ou le type de la demande, ou encore le forfait de service du client. Cet attribut est fondamental pour le Dashboard « Performance de conformité aux SLA ». Il sert de référence pour mesurer le délai de résolution réel. La comparaison des résultats avec cette cible permet d’évaluer la qualité du service fourni et de vérifier que les engagements contractuels envers les clients sont respectés. Pourquoi est-ce important ? Définit l’engagement de service envers le client et sert de référence pour mesurer le respect des délais et des SLA. Où trouver ces données Déduit des politiques de SLA appliquées au ticket. Ces informations sont disponibles dans l’API Zendesk Ticket Metrics. Exemples 144002880086400
	Priorité Priority	Niveau de priorité attribué à la demande de service, par exemple « Faible », « Normale », « Élevée » ou « Urgente ».
Description La priorité indique le degré d’urgence d’une demande de service. Elle détermine souvent sa position dans la file d’attente et le délai de résolution visé. Elle aide les agents à traiter d’abord les problèmes les plus urgents. Cet attribut est essentiel à l’analyse des performances et des SLA. Le Dashboard « Analyse des délais de résolution des demandes de service » utilise la priorité pour segmenter les données. Il permet de voir si les demandes prioritaires sont traitées plus rapidement que les autres et si les ressources sont réparties en fonction des besoins de l’organisation. Pourquoi est-ce important ? Indique le degré d’urgence d’une demande. Cette information est essentielle pour analyser le respect des SLA et traiter rapidement les demandes critiques. Où trouver ces données API Zendesk Tickets, champ `priority`. Exemples FaibleNormaleÉlevéeUrgente
	SLA dépassé IsSlaBreached	Indicateur booléen précisant si le délai de résolution de la demande de service a dépassé la cible du SLA.
Description Cet attribut calculé indique simplement si une demande de service a respecté ou non le délai de résolution défini dans son contrat de niveau de service (SLA). Il est obtenu en comparant le délai de résolution réel à la cible prévue par le SLA. Cet indicateur simplifie l’analyse du respect des SLA. Il constitue la donnée de référence du Dashboard « Performance de conformité aux SLA » et du KPI « Taux de conformité aux SLA ». Il permet de regrouper et de visualiser rapidement le nombre de demandes traitées dans les délais prévus et le nombre de demandes en retard. Pourquoi est-ce important ? Indique clairement, pour chaque dossier, si le SLA a été respecté ou non, ce qui simplifie le suivi et le reporting de conformité. Où trouver ces données Calculé lors de la transformation des données en comparant le délai total de résolution à SlaTargetResolutionTime. Exemples truefalse
	Type de demande de service ServiceRequestType	Classification de la demande de service, par exemple « Question », « Incident », « Problème » ou « Tâche ».
Description Cet attribut classe la demande de service selon sa nature. Cette classification est généralement définie à la création de la demande ou lors de son tri. Elle aide à déterminer le flux de travail et la priorité appropriés. En analyse, la segmentation par type de demande de service est fondamentale. Elle permet de comparer les délais de résolution, les taux d’escalade et les flux de processus selon le type de problème, comme dans les Dashboards « Analyse des délais de résolution des demandes de service » et « Taux et causes des escalades internes ». Vous pouvez ainsi repérer les types de demandes les plus difficiles ou les moins efficaces à traiter. Pourquoi est-ce important ? Classe les demandes pour comparer les performances et analyser les différents types de problèmes, ce qui est essentiel pour cibler les améliorations des processus. Où trouver ces données API Zendesk Tickets, champ `type`. Exemples QuestionIncidentProblèmeTâche
	Catégorie de produit ou de service ProductServiceCategory	Produit, service ou fonctionnalité concerné par la demande du client.
Description Cet attribut précise le contexte en classant la demande de service selon le produit ou le domaine de service concerné. Il est souvent renseigné manuellement par un agent ou automatiquement à partir du contenu de la demande. Cette classification est essentielle pour les Dashboards « Précision de la catégorisation des demandes » et « Répartition du temps de cycle d’investigation ». Elle permet d’analyser en détail les produits qui génèrent le plus de demandes d’assistance, ceux dont la résolution est la plus complexe et la concordance entre la catégorie initiale et la solution finale. Ces informations peuvent contribuer à améliorer l’orientation des demandes et la formation des agents. Pourquoi est-ce important ? Relie les demandes à des domaines d’activité, des produits ou des services précis, afin de cibler l’analyse des problèmes et de leur incidence sur le processus. Où trouver ces données Il s’agit généralement d’un champ de ticket personnalisé dans Zendesk. Son nom exact dépend de la configuration de Zendesk. Exemples Application mobileGestion des abonnementsIntégration d’APIMatériel
	Code de résolution ResolutionCode	Code ou catégorie indiquant le motif de la résolution finale ou de la clôture de la demande.
Description Le code de résolution fournit des informations structurées sur l’issue d’une demande de service. Il peut s’agir, par exemple, d’une résolution par un agent, d’un doublon, d’une demande ne nécessitant aucune action ou d’un problème connu. Il apporte davantage de contexte qu’un simple statut « Clôturée ». Cet attribut est particulièrement utile pour l’analyse des causes profondes. Dans le Dashboard « Tendances des demandes de service rouvertes », l’analyse du taux de réouverture par code de résolution peut révéler si certaines solutions sont moins efficaces et conduisent les clients à recontacter l’assistance. Pourquoi est-ce important ? Renseigne sur l’issue d’une demande de service, un élément important pour analyser les causes profondes et comprendre pourquoi des demandes sont rouvertes. Où trouver ces données Il s’agit généralement d’un champ de ticket personnalisé dans Zendesk. Son nom exact dépend de la configuration de Zendesk. Exemples Résolution dès le premier contactTransférée au niveau 2En attente du clientDéfaut du produit
	Demande rouverte IsReopened	Indicateur booléen précisant si une demande de service a été rouverte après avoir été marquée comme résolue.
Description Cet indicateur passe à vrai lorsqu’une demande de service revient à l’état ouvert après avoir été marquée comme résolue ou clôturée. Il signale que la résolution initiale n’a pas suffi. Il est utile pour suivre les reprises et les échecs de résolution dès le premier contact. Il alimente directement le Dashboard « Tendances des demandes de service rouvertes » et le KPI « Taux de réouverture des demandes de service », en facilitant le décompte et l’analyse des dossiers qui nécessitent une attention supplémentaire. Ces cas révèlent souvent des problèmes sous-jacents plus importants. Pourquoi est-ce important ? Repère les reprises et les résolutions infructueuses, afin d’évaluer la qualité et l’efficacité des solutions apportées. Où trouver ces données Calculé lors de la transformation des données en vérifiant si le statut d’un ticket passe de « resolved » ou « closed » à « open ». Exemples truefalse
	Groupe d’agents AgentGroup	Groupe ou équipe d’assistance auquel la demande de service est attribuée.
Description Cet attribut désigne l’équipe d’agents responsable de la demande de service. Les demandes sont souvent orientées vers des groupes précis selon les compétences, le produit concerné ou la langue. L’analyse par groupe d’agents permet d’évaluer les résultats de chaque équipe, la répartition de la charge de travail et les transferts entre équipes. Elle offre une vue d’ensemble complémentaire à l’analyse individuelle des agents et peut aider à repérer des problèmes récurrents dans certains services ou certaines fonctions. Pourquoi est-ce important ? Indique quelle équipe est responsable et permet d’analyser les résultats des groupes, les transferts entre équipes et la répartition des ressources entre les différents niveaux ou domaines d’assistance. Où trouver ces données API Zendesk Tickets, champ `group_id`. Les informations sur les groupes sont accessibles dans l’API Groups. Exemples Assistance de niveau 1Assistance techniqueFacturation
	Heure de fin EndTime	Horodatage indiquant la fin d’une activité ou d’un événement.
Description L’heure de fin correspond au moment où une activité s’achève. Dans de nombreuses structures de journaux d’événements, l’heure de début de l’activité suivante peut servir d’heure de fin à l’activité en cours. Pour les activités fondées sur un état, comme « Agent enquête sur le problème », elle indique la fin de cet état. Cet attribut est essentiel pour calculer précisément la durée des activités, un élément central de l’analyse des performances. Il aide à repérer les étapes les plus longues et sert de base à l’analyse détaillée des goulots d’étranglement et à l’évaluation de l’efficacité des ressources. Pourquoi est-ce important ? Permet de calculer la durée des activités, ce qui est essentiel pour repérer les goulots d’étranglement et mesurer les performances. Où trouver ces données Cette valeur est souvent dérivée de l’heure de début de l’événement suivant dans la séquence d’une demande de service donnée. Exemples 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Nombre de demandes d’informations InformationRequestCount	Nombre total de fois où des informations ont été demandées au client pour une même demande de service.
Description Cette métrique calculée compte, pour chaque demande de service, les occurrences de l’activité « Informations demandées au client ». Un nombre élevé peut indiquer que les agents ne recueillent pas toutes les informations nécessaires dès le départ. Cet attribut est utilisé dans le Dashboard « Analyse des demandes répétées d’informations ». Son suivi permet de repérer les inefficacités du processus et les besoins de formation des agents. Réduire le nombre de demandes d’informations peut raccourcir considérablement les délais de résolution et améliorer l’expérience client. Pourquoi est-ce important ? Quantifie les échanges avec le client et met en évidence les inefficacités qui allongent les délais de résolution et nuisent à l’expérience client. Où trouver ces données Calculé en comptant, pour chaque demande de service, les événements dont ActivityName est « Information Requested From Customer ». Exemples 013
	Note de satisfaction SatisfactionRating	Note de satisfaction attribuée par le client après la résolution de sa demande de service.
Description Cet attribut recueille l’avis du client sur son expérience de service, généralement au moyen d’une enquête envoyée après la résolution du ticket. Les réponses courantes sont « Bon », « Mauvais » ou une note chiffrée. Il mesure directement la satisfaction du client et constitue un indicateur de résultat important. Il sert à calculer l’indicateur clé de performance (KPI) « Score de satisfaction client ». L’analyse des notes de satisfaction avec les données de processus, comme le délai de résolution ou le nombre d’interventions des agents, peut révéler quels comportements contribuent à de meilleurs résultats pour les clients. Pourquoi est-ce important ? Mesure directement l’avis du client sur le service reçu et relie les résultats du processus à l’expérience client. Où trouver ces données API Zendesk Tickets, champ `satisfaction_rating.score`. Exemples BonMauvaisProposée

Obligatoire Recommandé Facultatif

Activités du service client

Voici les principales étapes et les principaux jalons à consigner dans votre journal d’événements pour découvrir avec précision le processus de service client.

6 Recommandé 8 Facultatif

	Activité	Description
	Demande attribuée à un agent	Cet événement indique que la demande de service a été attribuée à un agent chargé de la traiter. L’attribution peut être automatique, selon des règles d’acheminement, ou effectuée manuellement par un responsable d’équipe ou un agent.
Pourquoi est-ce important ? L’attribution est une étape importante pour la répartition des responsabilités et la gestion de la charge de travail. L’analyse du délai d’attribution et des réattributions permet de repérer les goulots d’étranglement dans le tri et la distribution des demandes. Où trouver ces données Il s’agit d’un événement « Change » explicite dans l’API Ticket Audits de Zendesk, enregistré chaque fois que le champ « assignee_id » est renseigné ou modifié. Données à recueillir Suivez les modifications du champ « assignee_id » dans le journal Ticket Audits. Type d’événement explicit
	Demande de service clôturée	Cette dernière activité marque la clôture définitive de la demande de service. Elle intervient généralement automatiquement après un délai défini suivant le passage du ticket au statut « solved », si le client n’a pas répondu entre-temps.
Pourquoi est-ce important ? En tant qu’événement de fin définitif, elle clôt le cycle de vie du ticket. Le délai entre « solved » et « closed » correspond à la période pendant laquelle le ticket peut être rouvert. L’événement « closed » confirme que la résolution a été acceptée. Où trouver ces données Il s’agit d’un changement de statut explicite enregistré dans l’API Ticket Audits de Zendesk lorsque le champ « status » passe à « closed ». Données à recueillir Dans Ticket Audits, repérez les événements « Change » qui définissent le statut du ticket sur « closed ». Type d’événement explicit
	Demande de service créée	Cette activité marque le début du processus de service client : un nouveau ticket est créé dans Zendesk depuis un canal tel que le courriel, un formulaire Web ou le chat. À sa création, le système enregistre explicitement cet événement avec un identifiant de ticket unique et un horodatage.
Pourquoi est-ce important ? En tant qu’événement de début principal, il est essentiel pour calculer la durée totale du cas et analyser l’évolution du volume de demandes entrantes. Il sert de référence pour mesurer des indicateurs clés, comme le délai avant la première réponse et le délai total de résolution. Où trouver ces données Il s’agit d’un événement explicite enregistré dans l’API Ticket Audits de Zendesk. Il correspond à l’événement « Create » du ticket et fournit son horodatage initial de création. Données à recueillir Enregistré à partir de l’événement de création du ticket dans le journal Ticket Audits. Type d’événement explicit
	Demande de service résolue	Après avoir apporté une solution au client, un agent marque la demande de service comme « solved ». Cet état est temporaire : le client peut répondre et rouvrir le ticket avant sa fermeture définitive.
Pourquoi est-ce important ? Cette étape est la principale référence pour mesurer le délai de résolution et l’efficacité des agents. Elle marque le moment où l’agent estime le travail terminé et permet d’analyser les reprises si le ticket est rouvert. Où trouver ces données Il s’agit d’un changement de statut explicite enregistré dans l’API Ticket Audits de Zendesk lorsque le champ « status » passe à « solved ». Données à recueillir Dans Ticket Audits, repérez les événements « Change » qui définissent le statut du ticket sur « solved ». Type d’événement explicit
	Demande de service rouverte	Cette activité a lieu lorsqu’un client répond à un ticket dont le statut est « solved ». Zendesk fait alors automatiquement repasser le statut à « open », ce qui indique que le problème n’a pas été entièrement résolu.
Pourquoi est-ce important ? Les réouvertures indiquent souvent un échec de la résolution au premier contact et une qualité de solution insuffisante. L’analyse de leur fréquence et de leurs causes aide à repérer les améliorations à apporter à la formation des agents et aux procédures de résolution. Où trouver ces données Il s’agit d’un changement de statut explicite dans l’API Ticket Audits, enregistré lorsque le statut passe de « solved » à « open ». Données à recueillir Suivez les événements « Change » faisant passer le statut de « solved » à « open ». Type d’événement explicit
	Informations demandées au client	Cette activité a lieu lorsqu’un agent a besoin d’informations supplémentaires pour poursuivre le traitement et fait passer le statut du ticket à « pending ». Ce changement de statut indique explicitement que le processus est en attente d’une réponse externe.
Pourquoi est-ce important ? Cette activité met en évidence la dépendance à l’égard du client et suspend le décompte des SLA internes. Si elle se répète sur un même ticket, cela peut indiquer que les informations initiales recueillies sont incomplètes et allonger les délais de résolution. Où trouver ces données Il s’agit d’un changement de statut explicite enregistré dans l’API Ticket Audits de Zendesk. Il est consigné lorsque le champ « status » passe à « pending ». Données à recueillir Dans Ticket Audits, repérez les événements « Change » qui définissent le statut du ticket sur « pending ». Type d’événement explicit
	Demande catégorisée et priorisée	Cette activité a lieu lorsqu’un agent ou une automatisation définit ou met à jour des champs du ticket, comme le type, la catégorie et la priorité. Cette étape est enregistrée comme un événement de modification dans l’historique du ticket.
Pourquoi est-ce important ? Une catégorisation et une priorisation adéquates sont essentielles pour orienter efficacement les demandes et répartir les ressources. L’analyse de cette activité permet d’évaluer la précision du tri initial et son effet sur les délais de résolution. Où trouver ces données Enregistrée dans l’API Ticket Audits de Zendesk sous forme d’événements « Change ». Pour la repérer, recherchez la première mise à jour de champs comme « priority », « type » ou les champs personnalisés associés à la catégorisation. Données à recueillir Dans les journaux Ticket Audit, filtrez les événements « Change » pour repérer la première modification des champs de catégorisation clés après la création du ticket. Type d’événement explicit
	Dépassement du SLA constaté	Cette activité marque le moment où une demande de service ne respecte pas un accord de niveau de service prédéfini, par exemple le délai de première réponse ou le délai de résolution. Cet événement est calculé en comparant les horodatages des activités du ticket aux règles de SLA.
Pourquoi est-ce important ? Les dépassements de SLA ont un effet direct sur la satisfaction client et le respect des engagements contractuels. Il est essentiel d’analyser quand et pourquoi ils surviennent pour repérer les retards systémiques, le manque de ressources ou des objectifs de performance irréalistes. Où trouver ces données Ces données peuvent provenir de l’API Ticket Metrics de Zendesk, qui enregistre les horodatages des dépassements de SLA (« breached_at »). Vous pouvez aussi les calculer en comparant les horodatages des événements du ticket aux règles de SLA définies. Données à recueillir Utilisez l’horodatage « breached_at » de l’API Ticket Metrics ou calculez le dépassement en comparant le délai de résolution à la durée prévue par la règle de SLA. Type d’événement calculated
	Enquête de satisfaction envoyée	Correspond au moment où une enquête de satisfaction client (CSAT) est envoyée automatiquement au client. Cela se produit généralement peu après que le ticket a été marqué comme « solved ».
Pourquoi est-ce important ? Cette activité lance la boucle de retour client. Il est important de savoir quand les enquêtes sont envoyées, et si elles le sont, pour interpréter les scores de satisfaction et mesurer l’efficacité du programme de retour client. Où trouver ces données Cet événement peut être déduit d’un journal d’automatisation ou de l’ajout d’une étiquette précise au ticket. La section « satisfaction_rating » de l’API Ticket Audits indique également quand l’enquête a été proposée. Données à recueillir Recherchez des étiquettes comme « csat_sent » ou utilisez l’horodatage auquel l’évaluation de satisfaction a été proposée. Type d’événement inferred
	Escalade interne déclenchée	Correspond au transfert d’une demande de service vers une autre équipe interne ou vers un niveau d’assistance supérieur. Ce transfert est généralement déduit du changement du groupe auquel le ticket est attribué.
Pourquoi est-ce important ? Le suivi des escalades permet de repérer les faiblesses des processus, les lacunes de connaissances de l’assistance de première ligne et les types de demandes complexes. Un taux d’escalade élevé peut indiquer qu’il faut améliorer la formation ou la documentation des processus. Où trouver ces données Déduit d’un événement « Change » dans l’API Ticket Audits lorsque le champ « group_id » est modifié. Le changement de groupe indique un transfert entre équipes. Données à recueillir Suivez les modifications du champ « group_id » dans le journal Ticket Audits. Type d’événement inferred
	Évaluation de satisfaction reçue	Cet événement a lieu lorsque le client répond à l’enquête de satisfaction en attribuant une note, par exemple « Bon » ou « Mauvais ». La note et tout commentaire associé sont enregistrés dans le ticket.
Pourquoi est-ce important ? Les retours directs des clients sont précieux pour mesurer la qualité du service et leur perception. En analysant ces évaluations dans le contexte du flux de processus, vous pouvez établir des liens entre certaines activités ou certains agents et les résultats obtenus. Où trouver ces données Enregistré comme événement « Change » dans l’API Ticket Audits lorsque le champ « satisfaction_rating » est renseigné avec la note et le commentaire du client. Données à recueillir Dans les journaux Ticket Audit, filtrez les modifications du champ « satisfaction_rating ». Type d’événement explicit
	Premier accusé de réception envoyé	Correspond à la première réponse automatique envoyée au client pour confirmer la réception de sa demande. Elle est généralement déclenchée par une règle Zendesk qui envoie un courriel prédéfini juste après la création du ticket.
Pourquoi est-ce important ? Le suivi de cette activité est essentiel pour mesurer la réactivité initiale et gérer les attentes des clients. Le délai entre la création de la demande et cet accusé de réception est un indicateur clé de la satisfaction client. Où trouver ces données Déduit du premier commentaire public sur le ticket si son auteur est un utilisateur automatisé ou si le commentaire est publié quelques secondes après la création du ticket. Cette activité peut être repérée en analysant le flux Ticket Comments. Données à recueillir Repérez le premier commentaire public publié par une automatisation ou une règle juste après la création du ticket. Type d’événement inferred
	Première réponse publique de l’agent envoyée	Cette activité marque le premier commentaire public envoyé au client par un agent, par opposition à un accusé de réception automatique. Elle indique le début de la prise en charge du problème par un agent.
Pourquoi est-ce important ? Cette étape est essentielle pour mesurer le SLA « First Reply Time », un indicateur clé de la réactivité du service. Elle distingue les communications automatisées du début de l’analyse et de l’assistance assurées par un agent. Où trouver ces données Repérez le premier commentaire public du flux Ticket Comments dont l’auteur est un agent humain, et non un utilisateur système automatisé. Données à recueillir Parcourez les commentaires des tickets, filtrez les commentaires publics des agents, puis sélectionnez celui dont l’horodatage est le plus ancien. Type d’événement inferred
	Réponse du client reçue	Cet événement est déclenché lorsqu’un client répond à un ticket, généralement au statut « pending ». Zendesk fait alors automatiquement repasser le ticket de « pending » à « open », ce qui indique que l’agent peut reprendre le traitement.
Pourquoi est-ce important ? Cette activité marque la fin d’une période d’attente et permet au processus de reprendre. L’analyse du délai de réponse des clients peut aider à évaluer la clarté des demandes formulées par les agents. Où trouver ces données Cet événement correspond à un nouveau commentaire public de l’utilisateur final, qui déclenche dans l’API Ticket Audits un changement de statut explicite de « pending » à « open ». Données à recueillir Suivez les événements « Change » faisant passer le statut de « pending » à « open », ou repérez les nouveaux commentaires publics d’un utilisateur final. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

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

Étapes

Accédez à Zendesk Explore : Connectez-vous à votre instance Zendesk, puis ouvrez Explore en cliquant sur l’icône de lancement des produits dans la barre supérieure et en sélectionnant Explore.
Créez une nouvelle requête : Dans Explore, cliquez sur l’icône Queries dans la barre latérale gauche, puis sur le bouton « New query » en haut à droite.
Sélectionnez le jeu de données : Dans la fenêtre « Choose a dataset », sélectionnez le jeu de données Support : Tickets. Il contient les principaux attributs des tickets et les horodatages clés des événements.
Ajoutez des métriques : Dans le générateur de requêtes, ouvrez le panneau « Metrics » et cliquez sur « Add ». Sélectionnez COUNT(Tickets) pour vérifier le volume de données.
Ajoutez des attributs aux lignes : Ouvrez le panneau « Rows » et cliquez sur « Add ». Ajoutez les attributs suivants. Ils constitueront les colonnes de base de votre export au format large.
- Ticket ID (il s’agit de votre identifiant de cas, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Ajoutez les horodatages des activités aux lignes : Ajoutez les attributs d’horodatage suivants au panneau « Rows ». Chacun correspond à une activité possible. Certaines activités nécessitent la création d’un attribut calculé personnalisé.
- Ticket created - Timestamp : pour Service Request Created et Initial Acknowledgment Sent.
- Ticket assigned - Timestamp : pour Request Assigned To Agent.
- First reply time - Timestamp : pour First Agent Public Reply Sent.
- Ticket solved - Timestamp : pour Service Request Resolved et Satisfaction Survey Sent.
- Ticket reopened - Timestamp : pour Service Request Reopened.
- Satisfaction rating received - Timestamp : pour Satisfaction Rating Received.
- Ticket closed - Timestamp : pour Service Request Closed.
Créez des attributs calculés personnalisés pour les autres activités : Certaines activités dépendent de changements précis dans les champs. Pour en enregistrer l’horodatage, vous devez créer des attributs personnalisés. Ouvrez le menu Calculations (icône de calculatrice) et sélectionnez « Standard calculated attribute ». Créez un attribut pour chacune des activités suivantes. Vous devrez repérer les noms exacts des champs et des valeurs dans votre instance Zendesk.
- Nom : Timestamp - Categorized and Prioritized. Formule : IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Après sa création, ajoutez cet attribut au panneau « Rows » et choisissez MIN comme agrégateur.
- Nom : Timestamp - Info Requested. Formule : IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Ajoutez-le à « Rows » et choisissez MIN comme agrégateur.
- Nom : Timestamp - Customer Responded. Formule : IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Ajoutez-le à « Rows » et choisissez MIN comme agrégateur.
- Nom : Timestamp - Escalated. Formule : IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Ajoutez-le à « Rows » et choisissez MIN comme agrégateur.
- Nom : Timestamp - SLA Breach. Formule : IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Ajoutez-le à « Rows » et choisissez MIN comme agrégateur.
Filtrez les données : Ouvrez le panneau « Filters » et cliquez sur « Add ». Ajoutez un filtre sur Ticket created - Date et choisissez une période adaptée, par exemple les 3 à 6 derniers mois, afin de conserver un jeu de données de taille raisonnable.
Exécutez et exportez le rapport : Cliquez sur « Save » pour exécuter la requête. Une fois les données affichées dans le tableau, cliquez sur « Export » et choisissez le format souhaité, par exemple CSV ou Excel.
Transformez les données au format journal d’événements : Le fichier exporté est au format « large » : chaque ligne correspond à un ticket et chaque colonne à l’horodatage d’un événement. Pour le Process Mining, vous devez le convertir au format « long ». Utilisez un outil comme Microsoft Excel (fonction Annuler le pivotement de Power Query), Python ou un autre outil de préparation des données.
- Pour chaque ligne (ticket), créez plusieurs lignes, une pour chaque colonne d’horodatage non vide.
- Le tableau final doit comporter des colonnes telles que ServiceRequest, ActivityName, StartTime et les autres attributs, qui seront répétés pour chaque activité d’une même demande de service.

Configuration

Jeu de données : Utilisez principalement le jeu de données Support : Tickets. Il donne accès à la plupart des propriétés des tickets et aux principaux horodatages dans une seule requête.
Autorisations : Vous devez disposer au minimum du rôle Editor ou Admin dans Zendesk Explore pour créer et enregistrer des requêtes.
Période : Il est essentiel de filtrer Ticket created - Date sur une période donnée. Une période de 3 à 6 mois permet généralement de trouver un bon équilibre entre la pertinence de l’analyse et les performances. L’export de millions de tickets peut être lent ou échouer.
Filtres de requête : Vous pouvez ajouter des filtres sur des propriétés précises, comme Ticket brand, Ticket form ou Ticket group, afin de cibler un service ou une équipe.
Attributs calculés : Cette méthode repose largement sur la création d’attributs calculés standard pour enregistrer les horodatages d’événements qui ne sont pas des attributs par défaut, comme les changements de statut ou les escalades. Vérifiez que vous êtes autorisé à créer ces attributs.

a Exemple de requête config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Étapes

Préparez l’accès à l’API Zendesk : Connectez-vous à Zendesk en tant qu’administrateur. Ouvrez le Centre d’administration, puis accédez à Apps and integrations > APIs > Zendesk API. Dans l’onglet Settings, vérifiez que Token Access est activé. Cliquez sur « Add API token » pour créer un jeton. Copiez-le et conservez-le en lieu sûr, car il ne sera plus affiché.
Configurez l’environnement Python : Vérifiez que Python 3.6 ou une version ultérieure est installé. Installez la bibliothèque requests, nécessaire pour envoyer des requêtes HTTP à l’API Zendesk. Pour cela, exécutez la commande pip install requests dans la ligne de commande.
Configurez le script Python : Enregistrez le script Python fourni dans un fichier, par exemple extract_zendesk_log.py. Ouvrez-le dans un éditeur de texte et remplacez les variables fictives en haut du fichier, ZENDESK_SUBDOMAIN, ZENDESK_EMAIL et API_TOKEN, par les informations et identifiants de votre instance Zendesk.
Définissez la période d’extraction : Repérez la variable START_TIMESTAMP dans le script. Elle indique la date de début de l’extraction historique et doit être exprimée sous forme d’horodatage Unix. Pour une première analyse, il est conseillé de choisir une date correspondant aux 3 à 6 derniers mois.
Exécutez le script : Ouvrez un terminal ou une invite de commandes, accédez au dossier où vous avez enregistré le script, puis lancez la commande python extract_zendesk_log.py.
Suivez l’exécution : Le script affiche dans la console des informations sur l’avancement, notamment le nombre de tickets traités. La durée totale dépend du volume de données extrait et des limites de débit de l’API Zendesk. Le script comporte une logique de base pour gérer les réponses indiquant une limite de débit atteinte.
Récupérez le journal d’événements : Une fois l’exécution terminée, le script crée dans le même dossier un fichier nommé zendesk_event_log.csv. Ce fichier contient le journal d’événements structuré, prêt à être analysé.
Préparez l’importation : Ouvrez zendesk_event_log.csv pour vérifier qu’il a été créé correctement. Assurez-vous que les colonnes correspondent aux attributs requis : ServiceRequest, ActivityName, StartTime, SourceSystem et LastDataUpdate. Le fichier est prêt à être importé dans l’outil de Process Mining.

Configuration

Identifiants de l’API : Le script nécessite un sous-domaine Zendesk valide, l’adresse e-mail d’un agent ou d’un administrateur et un jeton d’API actif. Le compte associé doit être autorisé à lire les tickets, les audits de tickets, les utilisateurs et les métriques des tickets.
Période : La date de début de l’extraction est définie par la variable START_TIMESTAMP du script, qui doit être un horodatage Unix. Il est conseillé de commencer par une période plus courte, par exemple 3 mois, afin de vérifier les résultats et les performances du script avant d’extraire un historique plus long.
API d’export incrémentiel : Cette solution utilise l’API Incremental Export de Zendesk. C’est la méthode recommandée et la plus efficace pour récupérer un grand nombre de tickets, car elle est conçue pour les exports en masse et évite les problèmes courants liés à la pagination.
Performances et limites de débit : Zendesk applique des limites de débit qui varient selon l’abonnement. Le script met en pause l’exécution lorsqu’une limite est atteinte, en fonction de l’en-tête Retry-After renvoyé par l’API. Dans les très grandes instances, l’extraction peut prendre plusieurs heures.
Prérequis : Cette méthode nécessite un environnement Python 3.6 ou ultérieur fonctionnel et la bibliothèque externe requests. Vous devez disposer d’un accès administrateur à l’instance Zendesk cible pour générer le jeton d’API requis.

a Exemple de requête python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Étapes

Vérifiez que votre compte Zendesk Support autorise l’accès à l’API Incremental Exports et que le compte d’intégration peut lire les tickets, les événements des tickets, les utilisateurs, les groupes, les commentaires, les évaluations de satisfaction et les données SLA lorsque ces fonctionnalités sont disponibles. Confirmez le sous-domaine du compte et la méthode d’authentification à l’aide de la configuration approuvée par votre organisation.
Choisissez une heure de début d’extraction couvrant la période d’analyse requise. Les exports incrémentiels de tickets utilisent un horodatage Unix et renvoient les enregistrements créés ou mis à jour à partir de cette date. Pour charger l’historique complet, utilisez [Configure based on your system] comme heure de début initiale, puis conservez l’heure de fin renvoyée pour les extractions incrémentielles suivantes. Pour les analyses courantes, une période de 3 à 6 mois suffit généralement si l’historique opérationnel est adéquat.
Exécutez le script d’extraction Python après avoir configuré le sous-domaine Zendesk, les identifiants d’authentification, l’horodatage de début et, le cas échéant, les filtres propres à votre entreprise. Le script demande les données incrémentielles des tickets, parcourt les pages et enregistre les enregistrements bruts ainsi que les détails d’événements disponibles avant leur transformation.
Récupérez l’historique des audits ou des événements de chaque ticket si la réponse de l’export incrémentiel ne fournit pas suffisamment de détails sur les changements de champs, les affectations, les commentaires ou les statuts. Utilisez uniquement les ressources de l’API Zendesk activées et autorisées dans votre compte. Conservez l’identifiant du ticket source, l’identifiant de l’audit, l’identifiant du commentaire, l’horodatage de l’événement, l’acteur, le nom du champ, l’ancienne valeur et la nouvelle valeur, lorsqu’ils sont renvoyés.
Normalisez les horodatages en UTC et convertissez les horodatages Unix ou les valeurs ISO 8601 dans un format date-heure cohérent. Triez les enregistrements sources par ServiceRequest, horodatage de l’événement et identifiant de l’événement source. Dédupliquez les enregistrements à l’aide de l’identifiant source stable le plus précis disponible, par exemple un identifiant d’audit ou de commentaire.
Créez des lignes explicites dans le journal d’événements pour les 14 activités requises. Ne comptez pas sur ProcessMind pour déduire les activités à partir des changements de statut ou des valeurs de champs. Produisez Service Request Created à partir de la création du ticket, Initial Acknowledgment Sent à partir d’une première réponse automatisée vérifiée, Request Categorized And Prioritized à partir des changements de catégorie, de type ou de priorité, Request Assigned To Agent à partir des changements d’agent assigné, First Agent Public Reply Sent à partir du premier commentaire public admissible d’un agent, Information Requested From Customer à partir d’un passage au statut en attente associé à une demande d’information, Customer Responded à partir d’une réponse admissible du client, Internal Escalation Triggered à partir d’un changement du groupe assigné, SLA Breach Occurred à partir d’un horodatage de dépassement SLA vérifié ou d’un dépassement calculé explicitement, Service Request Resolved à partir d’un passage au statut résolu, Service Request Reopened à partir d’un passage de résolu à ouvert causé par une réponse du client, Satisfaction Survey Sent à partir d’un envoi de questionnaire vérifié, Satisfaction Rating Received à partir d’une évaluation soumise et Service Request Closed à partir d’un passage au statut fermé ou d’un événement de clôture définitive vérifié.
Renseignez les colonnes obligatoires ServiceRequest, ActivityName, StartTime, SourceSystem et LastDataUpdate. Renseignez les colonnes recommandées AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime et IsSlaBreached lorsque la source fournit des valeurs fiables. Utilisez des valeurs nulles pour les attributs facultatifs indisponibles, sans inventer de valeurs.
Appliquez les filtres approuvés propres à votre entreprise après l’extraction et avant l’export. Conservez les identifiants et horodatages sources bruts dans une copie de préparation interne afin de pouvoir vérifier les décisions prises pour les événements et relancer le traitement.
Vérifiez le nombre de lignes, la couverture des activités, l’ordre des horodatages, la déduplication et le renseignement des attributs. Confirmez que chaque ligne produite comporte ServiceRequest, ActivityName, StartTime, SourceSystem et LastDataUpdate.
Exportez le journal d’événements transformé au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Vérifiez que les noms de colonnes correspondent exactement aux attributs requis, qu’une occurrence d’activité est présente par ligne et importez le fichier au moyen du processus d’importation ProcessMind configuré.

Configuration

Méthode d’extraction : Utilisez l’API Zendesk Incremental Exports pour extraire un grand volume de tickets. Le script doit demander les données à partir d’un horodatage Unix conservé, parcourir les pages, respecter les limites de débit et enregistrer l’horodatage de fin renvoyé pour l’exécution suivante.
Authentification : Configurez la méthode d’authentification Zendesk approuvée, le sous-domaine du compte, les identifiants et les autorisations d’API conformément aux règles de sécurité de votre organisation. Ne stockez pas les identifiants dans le code source.
Période : Pour les analyses courantes, utilisez une période de 3 à 6 mois. Lors du premier chargement, choisissez une heure de début antérieure à la période de processus requise, car des activités associées à des tickets créés plus tôt peuvent survenir pendant la période d’analyse. Pour les chargements incrémentiels, reprenez le dernier point de contrôle d’extraction réussi et ajoutez une courte période de chevauchement afin de tenir compte des mises à jour tardives, puis dédupliquez à l’aide des identifiants sources.
Filtres : Appliquez uniquement les filtres pris en charge par les ressources Zendesk disponibles dans votre compte, par exemple ceux portant sur l’organisation, le groupe, la marque, le type de ticket, le statut ou les champs personnalisés approuvés. Configurez les filtres propres à votre entreprise en fonction de votre système. Ne partez pas du principe que Zendesk comporte un champ Company Code ou Document Type.
Colonnes de sortie obligatoires : ServiceRequest, ActivityName, StartTime, SourceSystem et LastDataUpdate.
Colonnes de sortie recommandées : AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime et IsSlaBreached.
Détails des événements : Les enregistrements de tickets issus de l’export incrémentiel ne contiennent pas nécessairement toutes les transitions historiques. Récupérez les audits de tickets, les commentaires, les évaluations de satisfaction et les événements SLA autorisés selon les besoins. Produisez explicitement une ligne pour chaque activité requise.
Configuration SLA : Utilisez la politique SLA réelle et les horodatages de dépassement renvoyés par le compte, lorsqu’ils sont disponibles. Si le statut de dépassement est calculé, documentez la politique, les heures ouvrées, les pauses et le fuseau horaire utilisés. Lorsque des règles sur les heures ouvrées s’appliquent, ne calculez pas un dépassement à partir du seul temps écoulé en heures calendaires.
Performances : Traitez les pages au fur et à mesure, diffusez les enregistrements ou traitez-les par lots, mettez en cache les détails des tickets, limitez le parallélisme, respectez les réponses de Zendesk signalant une limite de débit et enregistrez des points de contrôle après chaque page traitée avec succès. Évitez de redemander l’historique complet à chaque exécution.
Conservation des données : Conservez les réponses brutes de l’API, les points de contrôle d’extraction, les métadonnées des requêtes et les journaux de transformation pour faciliter les rapprochements et les relances.
Prérequis : Accès à l’API Zendesk, autorisation de lire les ressources pertinentes sur les tickets et les événements, activation de l’audit des tickets et des commentaires lorsque nécessaire, accès aux données de satisfaction si les activités CSAT sont requises et accès aux données SLA si les activités de dépassement SLA sont requises. La disponibilité des fonctionnalités dépend de l’offre Zendesk et de la configuration du compte.

a Exemple de requête python

import csv
import json
import os
import sys
import time
from datetime import datetime, timezone
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

ZENDESK_SUBDOMAIN = os.environ.get(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Configure based on your system]")
ZENDESK_EMAIL = os.environ.get(class="hl-string">"ZENDESK_EMAIL", class="hl-string">"[Configure based on your system]")
ZENDESK_API_TOKEN = os.environ.get(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Configure based on your system]")
START_TIME = os.environ.get(class="hl-string">"START_TIME", class="hl-string">"[Configure based on your system]")
OUTPUT_FILE = os.environ.get(class="hl-string">"OUTPUT_FILE", class="hl-string">"zendesk_processmind_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"

REQUIRED_COLUMNS = [
    class="hl-string">"ServiceRequest",
    class="hl-string">"ActivityName",
    class="hl-string">"StartTime",
    class="hl-string">"SourceSystem",
    class="hl-string">"LastDataUpdate",
]
RECOMMENDED_COLUMNS = [
    class="hl-string">"AssignedAgent",
    class="hl-string">"ServiceRequestType",
    class="hl-string">"Priority",
    class="hl-string">"CommunicationChannel",
    class="hl-string">"SlaTargetResolutionTime",
    class="hl-string">"IsSlaBreached",
]
ALL_COLUMNS = REQUIRED_COLUMNS + RECOMMENDED_COLUMNS


def fail(message: str) -> None:
    raise RuntimeError(message)


def parse_start_time(value: str) -> int:
    if value.isdigit():
        return int(value)
    try:
        return int(datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00")).timestamp())
    except ValueError as exc:
        raise RuntimeError(class="hl-string">"START_TIME must be a Unix timestamp or ISO 8601 timestamp") from exc


def iso_timestamp(value: Any) -> Optional[str]:
    if value is None or value == class="hl-string">"":
        return None
    if isinstance(value, (int, float)):
        return datetime.fromtimestamp(value, tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    text = str(value)
    if text.isdigit():
        return datetime.fromtimestamp(int(text), tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    return text


def now_utc() -> str:
    return datetime.now(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")


def api_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    url = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    while True:
        response = session.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 1))
            continue
        response.raise_for_status()
        return response.json()


def paged_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Iterable[Dict[str, Any]]:
    next_url: Optional[str] = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    next_params = params
    while next_url:
        while True:
            response = session.get(next_url, params=next_params, timeout=60)
            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
                time.sleep(max(retry_after, 1))
                continue
            response.raise_for_status()
            payload = response.json()
            break
        for item in payload.get(class="hl-string">"tickets", payload.get(class="hl-string">"audits", payload.get(class="hl-string">"comments", payload.get(class="hl-string">"results", [])))):
            yield item
        next_url = payload.get(class="hl-string">"next_page")
        next_params = None


def get_user_name(session: requests.Session, user_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not user_id:
        return None
    key = str(user_id)
    if key in cache:
        return cache[key]
    try:
        user = api_get(session, fclass="hl-string">"/api/v2/users/{key}.json").get(class="hl-string">"user", {})
        name = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def get_group_name(session: requests.Session, group_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not group_id:
        return None
    key = str(group_id)
    if key in cache:
        return cache[key]
    try:
        group = api_get(session, fclass="hl-string">"/api/v2/groups/{key}.json").get(class="hl-string">"group", {})
        name = group.get(class="hl-string">"name") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def ticket_field(ticket: Dict[str, Any], names: List[str]) -> Any:
    for name in names:
        if ticket.get(name) is not None:
            return ticket.get(name)
    return None


def base_row(ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str]) -> Dict[str, Any]:
    return {
        class="hl-string">"ServiceRequest": str(ticket.get(class="hl-string">"id")),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"StartTime": iso_timestamp(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": last_update,
        class="hl-string">"AssignedAgent": get_user_name(session, ticket.get(class="hl-string">"assignee_id"), user_cache),
        class="hl-string">"ServiceRequestType": ticket.get(class="hl-string">"type"),
        class="hl-string">"Priority": ticket.get(class="hl-string">"priority"),
        class="hl-string">"CommunicationChannel": ticket.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(ticket.get(class="hl-string">"via"), dict) else ticket.get(class="hl-string">"via"),
        class="hl-string">"SlaTargetResolutionTime": ticket.get(class="hl-string">"sla_target_resolution_time"),
        class="hl-string">"IsSlaBreached": ticket.get(class="hl-string">"is_sla_breached"),
    }


def add_event(events: List[Dict[str, Any]], seen: set, ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str], source_key: str) -> None:
    if event_time is None:
        return
    key = (str(ticket.get(class="hl-string">"id")), activity, source_key, str(event_time))
    if key in seen:
        return
    seen.add(key)
    events.append(base_row(ticket, activity, event_time, last_update, user_cache))


def audit_events(session: requests.Session, ticket_id: Any) -> List[Dict[str, Any]]:
    return list(paged_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/audits.json"))


def audit_events_for_field(audit: Dict[str, Any], field_names: List[str]) -> List[Tuple[str, Any, Any]]:
    output: List[Tuple[str, Any, Any]] = []
    for event in audit.get(class="hl-string">"events", []):
        if event.get(class="hl-string">"type") != class="hl-string">"Change":
            continue
        field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
        if field in field_names:
            output.append((field, event.get(class="hl-string">"previous_value"), event.get(class="hl-string">"value")))
    return output


def is_customer_actor(audit: Dict[str, Any], ticket: Dict[str, Any]) -> bool:
    author_id = audit.get(class="hl-string">"author_id")
    requester_id = ticket.get(class="hl-string">"requester_id")
    return author_id is not None and requester_id is not None and str(author_id) == str(requester_id)


def is_public_comment(event: Dict[str, Any]) -> bool:
    return event.get(class="hl-string">"type") in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and event.get(class="hl-string">"public") is not False


def is_automated_acknowledgment(event: Dict[str, Any]) -> bool:
    body = str(event.get(class="hl-string">"body") or event.get(class="hl-string">"html_body") or class="hl-string">"").lower()
    marker = str(event.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(event.get(class="hl-string">"via"), dict) else event.get(class="hl-string">"via") or class="hl-string">"").lower()
    return class="hl-string">"acknowledg" in body or class="hl-string">"received your request" in body or marker in {class="hl-string">"trigger", class="hl-string">"automation", class="hl-string">"system"}


def extract_ticket_events(session: requests.Session, ticket: Dict[str, Any], last_update: str, user_cache: Dict[str, str], group_cache: Dict[str, str], seen: set) -> List[Dict[str, Any]]:
    events: List[Dict[str, Any]] = []
    ticket_id = ticket.get(class="hl-string">"id")
    audits = audit_events(session, ticket_id)
    audits.sort(key=lambda item: (str(item.get(class="hl-string">"created_at") or class="hl-string">""), str(item.get(class="hl-string">"id") or class="hl-string">"")))
    add_event(events, seen, ticket, class="hl-string">"Service Request Created", ticket.get(class="hl-string">"created_at"), last_update, user_cache, class="hl-string">"ticket_created")
    first_public_agent_reply = False
    first_ack = False
    for audit in audits:
        audit_time = audit.get(class="hl-string">"created_at")
        audit_id = str(audit.get(class="hl-string">"id") or audit_time)
        for event in audit.get(class="hl-string">"events", []):
            event_type = event.get(class="hl-string">"type")
            if event_type in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and is_public_comment(event):
                if not first_ack and is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"Initial Acknowledgment Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":ack")
                    first_ack = True
                if not is_customer_actor(audit, ticket) and not first_public_agent_reply and not is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"First Agent Public Reply Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":first_agent_reply")
                    first_public_agent_reply = True
                if is_customer_actor(audit, ticket):
                    add_event(events, seen, ticket, class="hl-string">"Customer Responded", audit_time, last_update, user_cache, audit_id + class="hl-string">":customer_reply")
            if event_type == class="hl-string">"Change":
                field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
                previous = event.get(class="hl-string">"previous_value")
                value = event.get(class="hl-string">"value")
                if field in {class="hl-string">"type", class="hl-string">"priority", class="hl-string">"custom_fields"}:
                    add_event(events, seen, ticket, class="hl-string">"Request Categorized And Prioritized", audit_time, last_update, user_cache, audit_id + class="hl-string">":category_priority:" + field)
                if field in {class="hl-string">"assignee_id", class="hl-string">"assignee"} and value not in (None, class="hl-string">"", 0, class="hl-string">"0"):
                    add_event(events, seen, ticket, class="hl-string">"Request Assigned To Agent", audit_time, last_update, user_cache, audit_id + class="hl-string">":assignee")
                if field in {class="hl-string">"group_id", class="hl-string">"group"} and previous not in (None, class="hl-string">"", 0, class="hl-string">"0") and value not in (None, class="hl-string">"", 0, class="hl-string">"0") and str(previous) != str(value):
                    get_group_name(session, value, group_cache)
                    add_event(events, seen, ticket, class="hl-string">"Internal Escalation Triggered", audit_time, last_update, user_cache, audit_id + class="hl-string">":group")
                if field == class="hl-string">"status":
                    old_status = str(previous or class="hl-string">"").lower()
                    new_status = str(value or class="hl-string">"").lower()
                    if new_status == class="hl-string">"pending":
                        add_event(events, seen, ticket, class="hl-string">"Information Requested From Customer", audit_time, last_update, user_cache, audit_id + class="hl-string">":pending")
                    if new_status == class="hl-string">"solved":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Resolved", audit_time, last_update, user_cache, audit_id + class="hl-string">":solved")
                    if old_status == class="hl-string">"solved" and new_status == class="hl-string">"open":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Reopened", audit_time, last_update, user_cache, audit_id + class="hl-string">":reopened")
                    if new_status == class="hl-string">"closed":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Closed", audit_time, last_update, user_cache, audit_id + class="hl-string">":closed")
                if field in {class="hl-string">"satisfaction_survey_sent", class="hl-string">"csat_survey_sent"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes", class="hl-string">"sent"}:
                    add_event(events, seen, ticket, class="hl-string">"Satisfaction Survey Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":survey_sent")
                if field in {class="hl-string">"sla_breached", class="hl-string">"is_sla_breached"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes"}:
                    row = base_row(ticket, class="hl-string">"SLA Breach Occurred", audit_time, last_update, user_cache)
                    row[class="hl-string">"IsSlaBreached"] = True
                    key = (str(ticket_id), class="hl-string">"SLA Breach Occurred", audit_id, str(audit_time))
                    if key not in seen:
                        seen.add(key)
                        events.append(row)
    try:
        satisfaction = api_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/satisfaction_rating.json").get(class="hl-string">"satisfaction_rating")
    except requests.HTTPError:
        satisfaction = None
    if satisfaction:
        add_event(events, seen, ticket, class="hl-string">"Satisfaction Rating Received", satisfaction.get(class="hl-string">"created_at") or satisfaction.get(class="hl-string">"updated_at"), last_update, user_cache, str(satisfaction.get(class="hl-string">"id") or class="hl-string">"rating"))
    return events


def validate_rows(rows: List[Dict[str, Any]]) -> None:
    activities = {
        class="hl-string">"Service Request Created",
        class="hl-string">"Initial Acknowledgment Sent",
        class="hl-string">"Request Categorized And Prioritized",
        class="hl-string">"Request Assigned To Agent",
        class="hl-string">"First Agent Public Reply Sent",
        class="hl-string">"Information Requested From Customer",
        class="hl-string">"Customer Responded",
        class="hl-string">"Internal Escalation Triggered",
        class="hl-string">"SLA Breach Occurred",
        class="hl-string">"Service Request Resolved",
        class="hl-string">"Service Request Reopened",
        class="hl-string">"Satisfaction Survey Sent",
        class="hl-string">"Satisfaction Rating Received",
        class="hl-string">"Service Request Closed",
    }
    missing_columns = [column for column in ALL_COLUMNS if column not in rows[0]] if rows else ALL_COLUMNS
    if missing_columns:
        fail(class="hl-string">"Missing output columns: " + class="hl-string">", ".join(missing_columns))
    invalid = [row for row in rows if not row.get(class="hl-string">"ServiceRequest") or not row.get(class="hl-string">"ActivityName") or not row.get(class="hl-string">"StartTime") or not row.get(class="hl-string">"SourceSystem") or not row.get(class="hl-string">"LastDataUpdate")]
    if invalid:
        fail(fclass="hl-string">"{len(invalid)} rows are missing required values")
    unexpected = sorted({row[class="hl-string">"ActivityName"] for row in rows} - activities)
    if unexpected:
        fail(class="hl-string">"Unexpected activity names: " + class="hl-string">", ".join(unexpected))


def main() -> None:
    global session
    if ZENDESK_SUBDOMAIN.startswith(class="hl-string">"[") or ZENDESK_EMAIL.startswith(class="hl-string">"[") or ZENDESK_API_TOKEN.startswith(class="hl-string">"[") or START_TIME.startswith(class="hl-string">"["):
        fail(class="hl-string">"Configure ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN, and START_TIME")
    start_time = parse_start_time(START_TIME)
    session = requests.Session()
    session.auth = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
    session.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})
    last_update = now_utc()
    user_cache: Dict[str, str] = {}
    group_cache: Dict[str, str] = {}
    seen = set()
    rows: List[Dict[str, Any]] = []
    tickets = paged_get(session, class="hl-string">"/api/v2/incremental/tickets/cursor.json", {class="hl-string">"start_time": start_time})
    for ticket in tickets:
        rows.extend(extract_ticket_events(session, ticket, last_update, user_cache, group_cache, seen))
    rows.sort(key=lambda row: (row[class="hl-string">"ServiceRequest"], row[class="hl-string">"StartTime"], row[class="hl-string">"ActivityName"]))
    validate_rows(rows)
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=ALL_COLUMNS, extrasaction=class="hl-string">"ignore")
        writer.writeheader()
        writer.writerows(rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(rows), class="hl-string">"last_data_update": last_update}))


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

Étapes

Choisissez une plateforme ETL ou ELT commerciale dotée d’un connecteur Zendesk Support pris en charge. Vérifiez que ce connecteur peut répliquer les tickets, les événements ou les audits de tickets, les commentaires, les utilisateurs, les groupes, les évaluations de satisfaction, les données SLA et les résultats des déclencheurs ou automatisations disponibles dans votre compte Zendesk.
Créez une intégration à l’API Zendesk à l’aide de la méthode d’authentification approuvée par votre organisation et prise en charge par le connecteur choisi. Accordez uniquement les autorisations de lecture nécessaires pour les tickets, les audits, les commentaires, les utilisateurs, les groupes, les données de satisfaction et les données SLA. Stockez la chaîne de connexion et les identifiants dans le coffre sécurisé de l’outil.
Configurez le connecteur pour répliquer les objets Zendesk requis dans l’entrepôt de données cible. Utilisez les objets sources générés par le connecteur au lieu de supposer que les noms de tables ou de colonnes sont fixes. Dans la documentation du projet, consignez les noms réels des objets et les associations de champs sous la forme [Your table name] et [Your column name] lorsque le connecteur utilise des noms propres au compte.
Configurez l’extraction incrémentielle à l’aide de l’horodatage de mise à jour, du curseur ou du mécanisme de suivi des modifications pris en charge par le système source. Incluez les données historiques de la période d’analyse choisie, généralement de trois à six mois, et conservez l’identifiant de l’événement ou de l’audit source afin de dédupliquer les mises à jour répétées.
Créez un modèle de préparation normalisé qui combine les enregistrements de tickets avec l’historique des tickets, les audits ou événements, les commentaires, les utilisateurs, les groupes, les évaluations de satisfaction, les enregistrements SLA et les éventuels enregistrements de déclencheurs ou d’automatisations propres au connecteur. Conservez, lorsqu’ils sont disponibles, l’horodatage source d’origine, l’identifiant de l’enregistrement source, l’identifiant du ticket, l’identifiant de l’acteur, le type d’événement, le nom du champ, l’ancienne valeur et la nouvelle valeur.
Créez une transformation d’événements qui produit une ligne pour chaque activité observée explicitement. Associez la création d’un ticket à Service Request Created, la première réponse automatisée admissible à Initial Acknowledgment Sent, les changements de type, de catégorie ou de priorité à Request Categorized And Prioritized, les changements d’agent assigné à Request Assigned To Agent, la première réponse publique admissible d’un agent à First Agent Public Reply Sent, un passage au statut en attente associé à une demande d’information à Information Requested From Customer, une réponse du client à Customer Responded, les changements de groupe à Internal Escalation Triggered, un enregistrement ou événement de dépassement SLA observé à SLA Breach Occurred, les passages au statut résolu à Service Request Resolved, les passages de résolu à ouvert causés par une réponse du client à Service Request Reopened, l’envoi observé d’un questionnaire à Satisfaction Survey Sent, une évaluation soumise à Satisfaction Rating Received et un passage définitif au statut fermé à Service Request Closed.
Ne créez pas de lignes déduites uniquement du statut actuel du ticket ou du temps écoulé. Si la source ne signale pas explicitement l’envoi d’un questionnaire, un dépassement SLA, un accusé de réception automatisé ou une clôture définitive, omettez l’activité ou utilisez un flux de données distinct, documenté et qui l’enregistre explicitement. ProcessMind lit le journal d’événements tel quel et ne reconstitue pas les événements manquants.
Dédupliquez les événements à l’aide de l’identifiant de l’événement ou de l’audit source, lorsqu’il est disponible. En l’absence d’identifiant stable, utilisez une clé composite documentée comprenant ServiceRequest, ActivityName, StartTime, l’acteur et l’identifiant de l’enregistrement source. Conservez les occurrences légitimes multiples d’activités telles que Customer Responded, Information Requested From Customer, Internal Escalation Triggered et Service Request Reopened.
Renseignez les colonnes de sortie obligatoires ServiceRequest, ActivityName, StartTime, SourceSystem et LastDataUpdate. Ajoutez AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime et IsSlaBreached lorsque la source les fournit. Utilisez un format d’horodatage UTC cohérent et conservez la règle de conversion du fuseau horaire source.
Exportez le journal d’événements final dans un fichier CSV compatible avec ProcessMind ou chargez-le dans l’emplacement d’ingestion ProcessMind configuré. Vérifiez qu’une occurrence d’activité correspond à une ligne, que ServiceRequest est l’identifiant du cas, que ActivityName contient les libellés exacts des activités, que StartTime est un horodatage valide et que les attributs obligatoires sont présents dans chaque ligne de sortie lorsqu’ils sont disponibles techniquement.

Configuration

Périmètre du connecteur et des sources : Configurez l’outil ETL ou ELT commercial choisi pour Zendesk Support et sélectionnez les objets sources qui exposent les tickets, les audits ou événements de tickets, les commentaires, les utilisateurs, les groupes, les évaluations de satisfaction, les informations SLA et les résultats des automatisations ou déclencheurs. Les noms des objets varient selon le connecteur et le compte. Référez-vous donc au catalogue réel du connecteur plutôt qu’à des noms de tables supposés.
Authentification et autorisations : Utilisez l’option d’authentification Zendesk approuvée par votre organisation. Accordez un accès en lecture à tous les objets sources sélectionnés, y compris aux événements historiques des tickets et aux données de satisfaction client. Vérifiez que l’accès à l’API, les fonctionnalités requises de l’offre Zendesk et toute licence du connecteur sont activés.
Période : Commencez par un historique de trois à six mois. N’étendez la période qu’après avoir vérifié les quotas de l’API, la capacité de l’entrepôt, le volume d’événements et la disponibilité des audits, des données SLA et des évaluations de satisfaction historiques.
Chargement incrémentiel : Privilégiez le curseur natif du connecteur, le suivi des modifications ou l’horodatage de mise à jour source. Planifiez un premier chargement historique, puis des chargements incrémentiels fréquents. Prévoyez une période de reprise pour tenir compte des commentaires, des évaluations, des résultats SLA et des mises à jour de tickets reçus tardivement.
Filtres d’activité : Filtrez les enregistrements sources selon la période d’analyse choisie et l’instance Zendesk Support concernée. Ne filtrez pas uniquement sur le statut actuel du ticket, car des activités historiques peuvent concerner des tickets dont le statut a changé depuis.
Filtres d’entreprise ou de compte : Si le connecteur expose plusieurs instances Zendesk, marques, organisations ou unités opérationnelles, appliquez le filtre d’entreprise ou de compte approuvé à l’aide du champ réel du connecteur. Ne partez pas du principe qu’un champ Company Code existe.
Association des événements : Tenez à jour une table d’association explicite entre le type d’événement source, le nom du champ, la transition de statut, le type d’acteur et l’indicateur d’automatisation, d’une part, et les 14 valeurs requises de ActivityName, d’autre part. Exigez une preuve explicite dans la source pour chaque ligne produite.
Identification de l’accusé de réception : Configurez l’association à Initial Acknowledgment Sent uniquement lorsque la source identifie une première réponse automatisée ou une notification équivalente générée par un déclencheur. Ne classez pas une réponse d’agent comme accusé de réception automatisé sans preuve dans la source.
Gestion des SLA : Utilisez les enregistrements explicites de dépassement SLA ou les résultats SLA exposés par le connecteur. Enregistrez la durée cible dans SlaTargetResolutionTime et le résultat du dépassement dans IsSlaBreached. Ne calculez pas un dépassement à partir du temps écoulé, sauf si le calendrier SLA, la politique, les heures ouvrées et la durée cible sont disponibles et que le calcul est documenté.
Performances : Limitez le chargement initial par date, ne sélectionnez que les colonnes nécessaires, utilisez la réplication incrémentielle, activez le partitionnement ou le regroupement de l’entrepôt sur ServiceRequest et StartTime lorsque cela est pris en charge, puis matérialisez le modèle d’événements normalisé après l’ingestion des données brutes. Évitez de parcourir à nouveau l’historique complet des tickets à chaque exécution.
Qualité des données : Conservez les identifiants et horodatages sources, normalisez les horodatages en UTC, uniformisez les valeurs booléennes et gardez les valeurs nulles lorsque la source ne fournit pas un attribut. Ne remplacez pas les données manquantes sur l’agent, la catégorie, la priorité, le SLA ou le canal par des valeurs inventées.
Horodatage d’actualisation : Définissez LastDataUpdate sur l’horodatage de fin de l’extraction ou de la transformation, en utilisant un fuseau horaire et un format cohérents dans tout le journal d’événements.

a Exemple de requête config

WITH source_data AS (
    SELECT
        [Your ticket identifier column] AS service_request,
        [Your source event identifier column] AS source_event_id,
        [Your event type column] AS source_event_type,
        [Your field name column] AS source_field_name,
        [Your previous value column] AS previous_value,
        [Your new value column] AS new_value,
        [Your event timestamp column] AS event_time,
        [Your actor type column] AS actor_type,
        [Your actor identifier column] AS actor_id,
        [Your assigned agent column] AS assigned_agent,
        [Your request type column] AS service_request_type,
        [Your priority column] AS priority,
        [Your communication channel column] AS communication_channel,
        [Your SLA target resolution time column] AS sla_target_resolution_time,
        [Your SLA breached flag column] AS is_sla_breached,
        [Your automated response flag column] AS is_automated_response,
        [Your public comment flag column] AS is_public_comment,
        [Your customer reply flag column] AS is_customer_reply,
        [Your survey sent flag column] AS is_survey_sent,
        [Your satisfaction rating column] AS satisfaction_rating,
        [Your source system value] AS source_system,
        [Your extraction timestamp column] AS last_data_update
    FROM [Your normalized Zendesk event source]
    WHERE [Your event timestamp column] >= [Your start date parameter]
      AND [Your event timestamp column] < [Your end date parameter]
),
activity_events AS (
    SELECT service_request, 'Service Request Created' AS activity_name, event_time AS start_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_created'
    UNION ALL
    SELECT service_request, 'Initial Acknowledgment Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_automated_response = TRUE AND is_public_comment = TRUE
    UNION ALL
    SELECT service_request, 'Request Categorized And Prioritized', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('type', 'category', 'priority')
    UNION ALL
    SELECT service_request, 'Request Assigned To Agent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('assignee', 'assigned_agent')
    UNION ALL
    SELECT service_request, 'First Agent Public Reply Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND actor_type = 'agent' AND is_automated_response = FALSE
    UNION ALL
    SELECT service_request, 'Information Requested From Customer', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'pending'
    UNION ALL
    SELECT service_request, 'Customer Responded', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Internal Escalation Triggered', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('group', 'assigned_group')
    UNION ALL
    SELECT service_request, 'SLA Breach Occurred', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, TRUE, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('sla_breach', 'sla_breached') OR is_sla_breached = TRUE
    UNION ALL
    SELECT service_request, 'Service Request Resolved', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'solved'
    UNION ALL
    SELECT service_request, 'Service Request Reopened', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND previous_value = 'solved' AND new_value = 'open' AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Survey Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_survey_sent', 'csat_survey_sent') OR is_survey_sent = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Rating Received', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_rating_received', 'csat_rating_received') OR satisfaction_rating IS NOT NULL
    UNION ALL
    SELECT service_request, 'Service Request Closed', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'closed'
),
deduplicated_events AS (
    SELECT
        service_request,
        activity_name,
        start_time,
        assigned_agent,
        service_request_type,
        priority,
        communication_channel,
        sla_target_resolution_time,
        is_sla_breached,
        source_system,
        last_data_update,
        ROW_NUMBER() OVER (PARTITION BY service_request, activity_name, source_event_id ORDER BY start_time) AS event_rank
    FROM activity_events
)
SELECT
    service_request AS ServiceRequest,
    activity_name AS ActivityName,
    start_time AS StartTime,
    source_system AS SourceSystem,
    last_data_update AS LastDataUpdate,
    assigned_agent AS AssignedAgent,
    service_request_type AS ServiceRequestType,
    priority AS Priority,
    communication_channel AS CommunicationChannel,
    sla_target_resolution_time AS SlaTargetResolutionTime,
    is_sla_breached AS IsSlaBreached
FROM deduplicated_events
WHERE event_rank = 1
ORDER BY service_request, start_time, activity_name;

Prêt à commencer ?

Commencez dès aujourd’hui à optimiser votre service client en préparant vos données à l’aide de ce modèle. Faites ressortir des informations utiles et améliorez l’efficacité de vos opérations Zendesk Support.

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

Éliminez les goulots d’étranglement du service client et améliorez votre CSAT dès maintenant

Évitez les contacts répétés. Atteignez un taux de résolution au premier contact de 80 % et améliorez la satisfaction client.

Démarrez votre essai gratuit

Aucune carte bancaire requise

Votre modèle de données pour le service client

Votre modèle de données pour le service client

Attributs du service client

Activités du service client

Guides d’extraction

Interface Zendesk Explore pour les rapports et l’export des données

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l’API REST Zendesk Support

Étapes

Configuration

a Exemple de requête python

API Zendesk Incremental Exports pour l’export de données en masse

Étapes

Configuration

a Exemple de requête python

Connecteur d’un outil ETL tiers pour Zendesk

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Éliminez les goulots d’étranglement du service client et améliorez votre CSAT dès maintenant

Votre modèle de données pour le service client

Votre modèle de données pour le service client

Attributs du service client

Activités du service client

Guides d’extraction

Interface Zendesk Explore pour les rapports et l’export des données

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l’API REST Zendesk Support

Étapes

Configuration

a Exemple de requête python

API Zendesk Incremental Exports pour l’export de données en masse

Étapes

Configuration

a Exemple de requête python

Connecteur d’un outil ETL tiers pour Zendesk

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Éliminez les goulots d’étranglement du service client et améliorez votre CSAT dès maintenant

Nous respectons votre vie privée

Prêt à commencer ?