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

Votre Modèle de Données de Service Client

Zendesk Support

Attributs du service client (19) Activités du service client (14) Guides d'extraction (4)

Votre Modèle de Données de Service Client

Ce 'template' vous aide à collecter les bonnes 'data' pour analyser votre processus de service client. Il décrit les attributs de 'data' essentiels à collecter, les activités clés à suivre et fournit des conseils pratiques sur la façon d'extraire ces informations. En utilisant ce guide, vous pouvez construire un 'event log' robuste pour découvrir des informations et améliorer vos opérations de service.

Attributs recommandés à collecter
Activités clés à suivre pour votre processus de service client
Guide d'extraction pour Zendesk Support

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

Télécharger le modèle

Attributs du service client

Ce sont les champs de données recommandés à inclure dans votre 'event log' pour une analyse complète du service client.

5 Obligatoire 7 Recommandé 7 Facultatif

	Nom	Description
	Demande de service ServiceRequest	L'identifiant unique de chaque demande de service client, également appelé ticket ou 'case'.
Description La Demande de service est l'identifiant de 'case' principal qui relie toutes les activités liées à une seule demande ou problème client, de sa création à sa résolution finale. Chaque interaction, mise à jour ou action interne est liée à cet ID unique. En Process Mining, l'analyse des 'events' regroupés par Demande de service permet une vue complète de bout en bout du parcours du service client. C'est le fondement du calcul des métriques clés comme le temps de résolution total, l'identification des déviations de processus et la compréhension du cycle de vie de chaque problème client. Pourquoi c'est important C'est l''ID de case' essentiel qui relie toutes les étapes du processus, permettant la reconstruction et l'analyse de chaque parcours de service client individuel. Où obtenir API Zendesk Tickets, champ 'id'. Exemples 102451287415332
	Heure de début StartTime	L'horodatage indiquant le début d'une activité ou d'un événement.
Description L'Heure de début, ou 'event timestamp', enregistre la date et l'heure exactes auxquelles une activité spécifique s'est produite. Par exemple, elle capture le moment où un commentaire client a été ajouté, où un agent a été assigné, ou quand le statut du ticket est passé à « Résolu ». Ce 'timestamp' est fondamental pour le Process Mining car il établit l'ordre chronologique des 'events'. Il est utilisé pour calculer les durées entre les activités, mesurer les temps de cycle, analyser les performances par rapport aux SLA et comprendre la dynamique temporelle du processus de service. Pourquoi c'est important Ce 'timestamp' est essentiel pour ordonner les 'events', calculer les durées et analyser la chronologie du processus de demande de service. Où obtenir API Zendesk Ticket Audits, champ 'created_at' pour chaque 'event' dans 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	Le timestamp de la dernière actualisation des données ou de l'extraction du système source.
Description Cet attribut indique la dernière fois que l''dataset' a été mis à jour depuis Zendesk Support. Il fournit un contexte sur la fraîcheur des données analysées. Connaître l'heure de la dernière mise à jour est crucial pour les analystes et les utilisateurs métier afin de comprendre s'ils visualisent les informations de processus les plus récentes. Cela aide à gérer les attentes concernant la récence des données et est vital à des fins de reporting et de suivi. Pourquoi c'est important Clarifie la fraîcheur des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse de processus. Où obtenir C'est un champ de métadonnées généré et stocké pendant le processus d'extraction de 'data', enregistrant le 'timestamp' du 'job' d'extraction. Exemples 2023-10-27T02:00:00Z
	Nom de l'activité ActivityName	Le nom de l''event' ou de la tâche spécifique survenue au cours du cycle de vie de la demande de service.
Description Le Nom de l'activité décrit une seule étape ou un jalon dans le processus de service client, comme « Demande de service créée », « Demande assignée à l'agent » ou « Demande de service résolue ». Ces 'events' sont 'timestamped' et forment la séquence d'actions pour chaque demande de service. Cet attribut est essentiel pour visualiser le flux de processus, découvrir les variantes de processus et analyser la fréquence et l'ordre des 'events'. Il permet aux analystes de comprendre quelles actions sont effectuées et d'identifier les chemins communs, les 'bottlenecks' et les écarts par rapport à la procédure standard. Pourquoi c'est important Cet attribut définit les étapes du processus, permettant la visualisation de la carte de processus et l'analyse des flux et des variations de processus. Où obtenir Dérivé des journaux d'audit de tickets Zendesk ou des flux d'événements qui enregistrent les changements et les actions. Exemples Demande de service crééeDemande assignée à l'agentPremière réponse publique de l'agent envoyéeDemande de service résolue
	Système source SourceSystem	Le système d'enregistrement à partir duquel les données ont été extraites.
Description Cet attribut spécifie le système d'origine pour les données de demande de service, qui est dans ce cas Zendesk Support. Il aide à la gouvernance et à la traçabilité des 'data', en particulier lors de la combinaison de 'data' provenant de plusieurs systèmes. En analyse, il garantit que les 'data' sont correctement attribuées à leur source, ce qui est important pour maintenir l'intégrité des 'data' et comprendre le contexte du processus, particulièrement dans les environnements multi-systèmes. Pourquoi c'est important Identifie l'origine des données, ce qui est crucial pour la gouvernance des données et pour distinguer les données de processus dans des environnements intégrés. Où obtenir C'est une valeur statique ajoutée pendant le processus d'extraction de 'data' pour étiqueter l'origine des 'data'. Exemples Zendesk Support
	Agent assigné AssignedAgent	Le nom ou l'ID de l'agent du service client assigné pour traiter la demande de service.
Description Cet attribut identifie l'agent spécifique responsable d'une activité ou de la demande de service à un moment donné. Il peut changer tout au long du cycle de vie si la demande est réassignée. L'analyse par Agent assigné est essentielle pour comprendre la charge de travail, les performances et l'efficacité des agents. Elle supporte le 'dashboard' « Charge de travail et efficacité des agents » en permettant des comparaisons des temps de traitement et des volumes de 'case' entre différents agents, aidant à identifier les opportunités de 'coaching' et à assurer des charges de travail équilibrées. Pourquoi c'est important Suivi de l'agent ayant effectué une action, permettant l'analyse des performances individuelles, de la distribution de la charge de travail et de l'allocation des ressources. Où obtenir API Zendesk Tickets, champ 'assignee_id'. Les détails de l'utilisateur peuvent être récupérés depuis l'API Users. Exemples John SmithJane DoeSupportBot
	Canal de communication CommunicationChannel	Le canal par lequel la demande de service a été soumise ou la communication a eu lieu.
Description Cet attribut identifie la méthode de communication utilisée, telle que l'e-mail, le formulaire web, le chat ou le téléphone. Il reflète la manière dont les clients interagissent avec le service d'assistance. Comprendre l'utilisation des canaux est important pour la planification des ressources et l'amélioration de l'expérience client. Le 'dashboard' « Aperçu de l'utilisation des canaux de communication » analyse ces 'data' pour voir quels canaux sont les plus populaires et si certains canaux sont associés à des temps de résolution plus longs ou à des chemins de processus différents. Cela peut aider à décider où investir dans l'amélioration ou l'automatisation du service. Pourquoi c'est important Montre comment les clients et les agents interagissent, permettant l'analyse de l'efficacité des canaux et de leur impact sur le processus et l'expérience client. Où obtenir API Zendesk Tickets, champ 'via.channel'. Exemples webemailapichat
	Délai de résolution ServiceRequestResolutionTime	Le temps total écoulé entre la création d'une demande de service et sa résolution finale.
Description Cette métrique mesure la durée de bout en bout d'une demande de service. Elle est calculée comme la différence entre le 'timestamp' de l'activité « Demande de service résolue » et l'activité « Demande de service créée ». C'est l'un des KPI les plus importants pour tout processus de service client. C'est la métrique principale pour le 'dashboard' « Analyse du temps de résolution des demandes de service » et le KPI « Temps moyen de résolution des demandes de service ». L'analyse de cette durée aide à identifier les retards systémiques et à mesurer l'efficacité globale du processus de support. Pourquoi c'est important Mesure la durée de cas de bout en bout, un KPI critique pour évaluer l'efficacité globale du processus et l'expérience client. Où obtenir Calculé en soustrayant l'horodatage de création de l'horodatage de résolution finale pour chaque demande de service. Exemples 720086400172800
	Priorité Priority	Le niveau de priorité assigné à la demande de service, tel que « Basse », « Normale », « Élevée » ou « Urgente ».
Description La priorité indique l'urgence d'une demande de service et influence souvent sa position dans la file d'attente ainsi que le délai de résolution cible. Elle aide les agents à se concentrer d'abord sur les problèmes les plus critiques. Cet attribut est essentiel pour l'analyse des performances et des SLA. Le 'dashboard' « Analyse du temps de résolution des demandes de service » utilise la priorité pour segmenter les données, révélant si les demandes de haute priorité sont traitées plus rapidement que celles de faible priorité et si les ressources sont allouées efficacement en fonction des besoins de l'entreprise. Pourquoi c'est important Indique l'urgence d'une demande, ce qui est essentiel pour analyser la conformité aux SLA et garantir que les problèmes critiques sont traités rapidement. Où obtenir API Zendesk Tickets, champ 'priority'. Exemples FaibleNormalÉlevéUrgent
	SLA est enfreint IsSlaBreached	Un indicateur booléen indiquant si le temps de résolution de la demande de service a dépassé sa cible SLA.
Description Cet attribut calculé est un simple 'flag' 'true' ou 'false' qui indique si une demande de service n'a pas respecté son Accord de Niveau de Service (SLA) défini pour le temps de résolution. Il est dérivé en comparant la durée de résolution réelle avec l'objectif SLA planifié. Ce 'flag' simplifie l'analyse de la conformité SLA. C'est le point de données central pour le 'dashboard' « Performance de Conformité SLA » et le KPI « Taux de Conformité SLA », permettant une agrégation et une visualisation rapides du nombre de demandes respectant les objectifs de service par rapport à celles qui ne les respectent pas. Pourquoi c'est important Fournit un résultat binaire clair pour la performance SLA de chaque cas, simplifiant le suivi de la conformité et le reporting. Où obtenir Calculé lors de la transformation des données en comparant le temps de résolution total avec le `SlaTargetResolutionTime`. Exemples truefaux
	Temps de résolution cible SLA SlaTargetResolutionTime	La durée cible dans laquelle une demande de service est censée être résolue, basée sur sa politique SLA.
Description Cet attribut définit l'objectif de l'Accord sur les Niveaux de Service (SLA) pour la résolution d'un ticket. Cet objectif est souvent dynamique et dépend de facteurs tels que la priorité de la demande, son type ou le plan de service du client. C'est un attribut fondamental pour le 'dashboard' « Performance de Conformité SLA ». Il sert de référence par rapport auquel le temps de résolution réel est mesuré. L'analyse des performances par rapport à cet objectif aide à quantifier la qualité de la prestation de service et à garantir que les obligations contractuelles envers les clients sont respectées. Pourquoi c'est important Définit la promesse de service au client, servant de référence pour mesurer la performance à temps et la conformité aux SLA. Où obtenir Dérivé des politiques SLA appliquées à un ticket. Ces informations sont disponibles via l'API Zendesk Ticket Metrics. Exemples 144002880086400
	Type de demande de service ServiceRequestType	La classification de la demande de service, telle que « Question », « Incident », « Problème » ou « Tâche ».
Description Cet attribut catégorise la demande de service en fonction de sa nature. Cette classification est généralement définie lors de la création ou du triage de la demande et aide à déterminer le 'workflow' et la priorité appropriés. En analyse, la segmentation par Type de demande de service est fondamentale. Elle permet de comparer les temps de résolution, les taux d'escalade et les flux de processus pour différents types de problèmes, comme le montrent des 'dashboards' tels que « Analyse du temps de résolution des demandes de service » et « Taux d'escalade interne et causes ». Cela aide à identifier si certains types de demandes sont plus problématiques ou inefficaces à gérer. Pourquoi c'est important Catégorise les demandes pour permettre la comparaison des performances et l'analyse entre différents types de problèmes, ce qui est crucial pour l'amélioration ciblée des processus. Où obtenir API Zendesk Tickets, champ 'type'. Exemples QuestionIncidentProblèmeTâche
	Catégorie de service produit ProductServiceCategory	Le produit, service ou fonctionnalité spécifique sur lequel porte la demande du client.
Description Cet attribut fournit un contexte détaillé en catégorisant la demande de service en fonction d'un produit ou d'une zone de service. Il est souvent défini manuellement par un agent ou automatiquement en fonction du contenu de la demande. Cette catégorisation est vitale pour les 'dashboards' « Précision de la catégorisation des demandes » et « Analyse des temps de cycle d'investigation ». Elle permet une analyse approfondie des produits générant le plus de demandes de support, des plus complexes à résoudre, et si la catégorisation initiale correspond à la solution finale, contribuant à améliorer l'acheminement et la formation des agents. Pourquoi c'est important Lie les demandes à des domaines d'activité, produits ou services spécifiques, permettant une analyse ciblée sur les zones problématiques et leur impact sur le processus. Où obtenir C'est typiquement un champ de ticket personnalisé dans Zendesk. Le nom exact du champ dépend de la configuration spécifique de Zendesk. Exemples Mobile AppGestion des abonnementsIntégration APIHardware
	Code de Résolution ResolutionCode	Un code ou une catégorie indiquant la raison 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 le résultat d'une demande de service. Les exemples incluent « Résolu par l'agent », « Duplicata », « Aucune action requise » ou « Problème connu ». Il offre plus de contexte qu'un simple statut « Fermé ». Cet attribut est particulièrement précieux pour l'analyse des causes profondes. Pour le 'dashboard' « Tendances des demandes de service rouvertes », l'analyse des taux de réouverture par code de résolution peut révéler si certains types de solutions sont moins efficaces, amenant les clients à devoir réengager le support. Pourquoi c'est important Fournit un aperçu du résultat d'une demande de service, ce qui est crucial pour l'analyse des causes profondes et la compréhension des raisons pour lesquelles les demandes sont rouvertes. Où obtenir C'est typiquement un champ de ticket personnalisé dans Zendesk. Le nom exact du champ dépend de la configuration spécifique de Zendesk. Exemples Résolution au premier contactEscaladé au niveau 2En attente du clientBogue produit
	Est rouvert IsReopened	Un indicateur booléen indiquant si une demande de service a été rouverte après avoir été marquée comme résolue.
Description Cet attribut est un 'flag' qui devient 'true' si une demande de service repasse à l'état ouvert après avoir été précédemment définie comme résolue ou fermée. Il signale que la résolution initiale n'était pas suffisante. Ce 'flag' est crucial pour le suivi du 'rework' et des échecs de résolution au premier contact. Il soutient directement le 'dashboard' « Tendances des demandes de service rouvertes » et le KPI « Taux de réouverture des demandes de service » en facilitant le comptage et l'analyse des 'cases' qui nécessitent une attention supplémentaire, ce qui indique souvent des problèmes sous-jacents plus profonds. Pourquoi c'est important Identifie les reprises et les résolutions échouées, aidant à mesurer la qualité et l'efficacité des solutions fournies. Où obtenir Calculé lors de la transformation des données en vérifiant si le statut d'un ticket passe de « résolu » ou « clôturé » à « ouvert ». Exemples truefaux
	Groupe d'agents AgentGroup	Le groupe de support ou l'équipe à laquelle la demande de service est assignée.
Description Cet attribut représente l'équipe d'agents responsable de la demande de service. Les demandes sont souvent acheminées vers des groupes spécifiques en fonction des compétences, de la zone produit ou de la langue. L'analyse par Groupe d'agents aide à comprendre les performances au niveau de l'équipe, la distribution de la charge de travail et les schémas d'escalade entre les équipes. Elle offre une vue de niveau supérieur par rapport à l'analyse individuelle des agents et peut aider à identifier les problèmes systémiques au sein de départements ou de fonctions spécifiques. Pourquoi c'est important Suivi de la responsabilité de l'équipe, permettant l'analyse des performances de groupe, des transferts inter-équipes et de l'allocation des ressources entre les différents niveaux de support ou spécialités. Où obtenir API Zendesk Tickets, champ 'group_id'. Les détails du groupe peuvent être récupérés depuis l'API Groups. Exemples Support de Niveau 1Support techniqueFacturation
	Heure de fin EndTime	Le 'timestamp' indiquant quand une activité ou un 'event' a été complété.
Description L'Heure de fin représente l'heure d'achèvement d'une activité. Dans de nombreuses structures d''event log', l'Heure de début de l'activité suivante peut servir d'Heure de fin de l'activité actuelle. Pour les activités basées sur un état comme « L'agent enquête sur le problème », elle marque le moment où cet état a pris fin. Cet attribut est essentiel pour calculer la durée précise des activités, ce qui est un élément central de l'analyse des performances. Il aide à identifier les étapes les plus chronophages et constitue la base d'une analyse détaillée des 'bottlenecks' et des calculs d'efficacité des ressources. Pourquoi c'est important Permet le calcul des durées d'activité, ce qui est essentiel pour identifier les goulots d'étranglement et mesurer les performances. Où obtenir Ceci est souvent dérivé en prenant le 'StartTime' de l''event' subséquent dans la séquence pour 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	Le nombre total de fois où des informations ont été demandées au client pour une seule demande de service.
Description Cette métrique calculée compte les occurrences de l'activité « Informations demandées au client » pour chaque demande de service. Un nombre élevé suggère que les agents ne collectent pas toutes les informations nécessaires dès le départ. Cet attribut est utilisé dans le 'dashboard' « Analyse des demandes d'informations répétées ». Le suivi de ce compte aide à identifier les inefficacités de processus et les domaines de formation des agents. La réduction du nombre de fois où des informations sont demandées peut considérablement raccourcir les délais de résolution et améliorer l'expérience client. Pourquoi c'est important Quantifie les échanges de communication avec le client, mettant en évidence les inefficacités qui prolongent les délais de résolution et dégradent l'expérience client. Où obtenir Calculé en comptant le nombre d'événements où le `ActivityName` est « Information demandée au client » pour chaque demande de service. Exemples 013
	Note de satisfaction SatisfactionRating	Le score de satisfaction fourni par le client après la résolution de la demande de service.
Description Cet attribut capture le retour d'information du client sur son expérience de service, généralement recueilli via un sondage après la résolution du ticket. Les notes courantes incluent « Bien », « Mal » ou un score numérique. C'est une mesure directe du sentiment client et un 'outcome metric' clé. Il est utilisé pour calculer le KPI « Score de sentiment client ». L'analyse des notes de satisfaction en conjonction avec les données de processus, telles que le temps de résolution ou le nombre de touches d'agent, peut révéler quels comportements de processus conduisent à de meilleurs résultats pour le client. Pourquoi c'est important Mesure directement les retours clients sur le service fourni, reliant la performance du processus aux résultats client. Où obtenir API Zendesk Tickets, champ 'satisfaction_rating.score'. Exemples bonmauvaisoffert

Obligatoire Recommandé Facultatif

Activités du service client

Ce sont les étapes clés du processus et les jalons à capturer dans votre 'event log' pour une découverte précise du processus de service client.

6 Recommandé 8 Facultatif

	Activité	Description
	Demande assignée à l'agent	Cet 'event' signifie que la demande de service a été assignée à un agent spécifique pour traitement. Cela peut se produire automatiquement en fonction des règles de routage ou manuellement par un chef d'équipe ou un agent.
Pourquoi c'est important L'attribution est une étape critique pour la responsabilisation et la gestion de la charge de travail. L'analyse du temps d'attribution et des schémas de réattribution révèle des goulots d'étranglement dans le processus de triage et de distribution. Où obtenir C'est un 'event' « Changement » explicite dans l'API Zendesk Ticket Audits, enregistré chaque fois que le champ 'assignee_id' est rempli ou modifié. Capture Suivre les changements du champ 'assignee_id' dans l''event log' des Tickets Audits. Type d'événement explicit
	Demande de service créée	Cette activité marque le début du processus de service client, lorsqu'un nouveau ticket est généré dans Zendesk depuis n'importe quel canal comme l'e-mail, le formulaire web ou le chat. Cet 'event' est explicitement enregistré par le système avec un ID de ticket unique et un 'timestamp' lors de sa création.
Pourquoi c'est important En tant qu'événement de début principal, il est essentiel pour calculer la durée totale du cas et analyser les volumes de demandes entrantes au fil du temps. Il sert de référence pour mesurer les indicateurs clés de performance tels que le temps de première réponse et le temps de résolution total. Où obtenir C'est un 'event' explicite capturé dans l'API Zendesk Ticket Audits. Il correspond à l''event' « Créer » pour un ticket, fournissant le 'timestamp' de création initial. Capture Capturé à partir de l'événement de création de ticket dans le journal des Audits de Tickets. Type d'événement explicit
	Demande de service fermée	C'est l'activité finale, marquant la clôture permanente de la demande de service. Cela se produit généralement automatiquement après qu'une période définie s'est écoulée depuis que le ticket a été marqué « résolu », sans nouvelles réponses du client.
Pourquoi c'est important En tant qu'événement de fin définitif, il finalise le cycle de vie du ticket. Le temps entre « résolu » et « clôturé » représente la fenêtre pour les réouvertures potentielles, et l'événement « clôturé » confirme que la résolution a été acceptée. Où obtenir C'est un changement de statut explicite enregistré dans l'API Zendesk Ticket Audits lorsque le champ 'status' est défini sur « fermé ». Capture Identifiez les événements « Change » dans les Audits de Tickets où le statut du ticket est défini sur « fermé ». Type d'événement explicit
	Demande de service résolue	Un agent marque la demande de service comme « résolue » après avoir fourni une solution au client. Il s'agit d'un état temporaire, car le ticket peut être rouvert par une réponse du client avant d'être définitivement clôturé.
Pourquoi c'est important C'est le jalon principal pour mesurer le temps de résolution et l'efficacité de l'agent. Il marque le point où l'agent estime que le travail est terminé, fournissant une base pour analyser le 'rework' si le ticket est rouvert. Où obtenir C'est un changement de statut explicite enregistré dans l'API Zendesk Ticket Audits lorsque le champ 'status' est défini sur « résolu ». Capture Identifiez les événements « Change » dans les Audits de Tickets où le statut du ticket est défini sur « résolu ». Type d'événement explicit
	Demande de service rouverte	Cette activité se produit si un client répond à un ticket qui est en statut « résolu ». Zendesk modifie automatiquement le statut en « ouvert », indiquant que le problème n'était pas entièrement résolu.
Pourquoi c'est important Les réouvertures sont un indicateur critique de l'échec de la résolution au premier contact et de la mauvaise qualité des solutions. L'analyse de la fréquence et des raisons des tickets rouverts aide à identifier les domaines d'amélioration de la formation des agents et des procédures de résolution. Où obtenir C'est un changement de statut explicite dans l'API Ticket Audits, capturé lorsque le 'status' passe de « résolu » à « ouvert ». Capture Suivre les 'events' de « Changement » de statut de « résolu » à « ouvert ». Type d'événement explicit
	Information demandée au client	Se produit lorsqu'un agent a besoin de plus d'informations d'un client pour continuer et change le statut du ticket en « en attente ». Ce changement de statut indique explicitement que le processus est maintenant en attente d'une partie externe.
Pourquoi c'est important Cette activité met en évidence les dépendances vis-à-vis du client et suspend les horloges internes des SLA. Des occurrences fréquentes ou répétées sur un même ticket peuvent indiquer une collecte initiale d'informations incomplète et entraîner des délais de résolution plus longs. Où obtenir C'est un 'event' de changement de statut explicite enregistré dans l'API Zendesk Ticket Audits. Il est capturé lorsque le champ 'status' passe à « en attente ». Capture Identifiez les événements « Change » dans les Audits de Tickets où le statut du ticket est défini sur « en attente ». Type d'événement explicit
	Accusé de réception initial envoyé	Représente la première réponse automatisée envoyée au client, confirmant que sa demande a été reçue. Ceci est généralement géré par un 'trigger' Zendesk qui envoie une notification par e-mail 'template' immédiatement après la création du ticket.
Pourquoi c'est important Le suivi de cette activité est crucial pour mesurer la réactivité initiale et gérer les attentes des clients. Le temps entre la création de la demande et cet accusé de réception est une métrique clé pour la satisfaction client. Où obtenir Déduit du premier commentaire public sur le ticket si son auteur est un utilisateur automatisé ou s'il se produit quelques secondes après la création du ticket. Ceci peut être identifié en analysant le flux de commentaires de tickets. Capture Identifiez le premier commentaire public créé par une automatisation ou un déclencheur immédiatement après la création du ticket. Type d'événement inferred
	Client a répondu	Cet 'event' est 'triggered' lorsqu'un client répond à un ticket, généralement un ticket qui était en état « en attente ». Zendesk fait automatiquement passer le statut du ticket de « en attente » à « ouvert », signalant que l'agent peut reprendre le travail.
Pourquoi c'est important Cette activité marque la fin d'un temps d'attente et est un 'trigger' pour la poursuite du processus. L'analyse du temps de réponse des clients peut fournir des informations sur la clarté des demandes des agents. Où obtenir Cet 'event' correspond à un nouveau commentaire public de l'utilisateur final, qui 'trigger' un changement de statut explicite de « en attente » à « ouvert » dans l'API Ticket Audits. Capture Suivre les 'events' de « Changement » de statut de « en attente » à « ouvert » ou identifier les nouveaux commentaires publics d'un utilisateur final. Type d'événement explicit
	Demande catégorisée et priorisée	Cette activité se produit lorsqu'un agent ou une automatisation définit ou met à jour des champs de ticket tels que le type, la catégorie et la priorité. Cette étape est enregistrée comme un 'change event' dans l'historique du ticket.
Pourquoi c'est important Une catégorisation et une priorisation appropriées sont essentielles pour un acheminement efficace et une allocation optimale des ressources. L'analyse de cette activité aide à déterminer la précision du triage initial et son impact sur les délais de résolution. Où obtenir Capturé à partir de l'API Zendesk Ticket Audits comme des événements « Change ». Il peut être identifié en recherchant la première mise à jour de champs tels que « priority », « type » ou des champs personnalisés liés à la catégorisation. Capture Filtrez les journaux d'audit des tickets pour le premier événement « Change » sur les champs de catégorisation clés après la création. Type d'événement explicit
	Escalade interne déclenchée	Représente le transfert d'une demande de service à une autre équipe interne ou à un niveau de support supérieur. Cela est généralement déduit lorsque le groupe assigné au ticket est modifié.
Pourquoi c'est important Le suivi des escalades est essentiel pour identifier les faiblesses des processus, les lacunes de connaissances du support de première ligne et les types de demandes complexes. Des taux d'escalade élevés peuvent indiquer un besoin d'amélioration de la formation ou de la documentation des processus. Où obtenir Déduit d'un événement « Change » dans l'API Ticket Audits où le champ « group_id » est modifié. Un changement de groupe signifie un transfert entre les équipes. Capture Surveillez les changements du champ « group_id » dans le journal des Audits de Tickets. Type d'événement inferred
	Note de satisfaction reçue	Cet 'event' se produit lorsque le client soumet sa réponse au sondage de satisfaction, fournissant une note comme « Bien » ou « Mal ». La note et tout commentaire associé sont enregistrés sur le ticket.
Pourquoi c'est important Les retours directs des clients sont inestimables pour mesurer la qualité du service et le sentiment client. L'analyse de ces évaluations dans le contexte du flux de processus aide à corréler des activités ou des agents spécifiques avec des résultats. Où obtenir Capturé comme un événement « Change » dans l'API Ticket Audits lorsque le champ « satisfaction_rating » est renseigné avec la note et le commentaire du client. Capture Filtrez les journaux d'audit des tickets pour les changements dans le champ « satisfaction_rating ». Type d'événement explicit
	Première réponse publique de l'agent envoyée	Cette activité marque la première fois qu'un agent envoie un commentaire public au client, par opposition à un accusé de réception automatisé. Cet 'event' est un indicateur crucial de l'engagement initial de l'agent avec le problème du client.
Pourquoi c'est important C'est un jalon clé pour mesurer le SLA « Temps de première réponse », un indicateur critique de la réactivité du service. Il sépare la communication automatisée du début de l'investigation et du support actifs, menés par un humain. Où obtenir Identifié en trouvant le premier commentaire public dans le flux de commentaires de tickets où l'auteur est un agent humain (pas un utilisateur système automatisé). Capture Scannez les commentaires de ticket, en filtrant les commentaires publics des agents et en sélectionnant celui avec le 'timestamp' le plus ancien. Type d'événement inferred
	Sondage de satisfaction envoyé	Représente le moment où un sondage de satisfaction client (CSAT) est automatiquement envoyé au client. Cela se produit généralement peu de temps après que le ticket est marqué comme résolu.
Pourquoi c'est important Cette activité initie la boucle de rétroaction client. Comprendre quand et si les sondages sont envoyés est important pour contextualiser les scores de satisfaction et mesurer l'efficacité du programme de rétroaction. Où obtenir Cela peut être déduit d'un 'automation log' ou par l'ajout d'une 'tag' spécifique au ticket. La section 'satisfaction_rating' dans l'API Ticket Audits enregistre également le moment où le sondage a été proposé. Capture Recherchez des étiquettes comme « csat_sent » ou utilisez l'horodatage du moment où la note de satisfaction a été proposée. Type d'événement inferred
	Violation de SLA survenue	Cette activité marque le moment où une demande de service ne respecte pas un Accord de Niveau de Service (SLA) prédéfini, tel que le temps de première réponse ou le temps de résolution. Cet 'event' est calculé en fonction des 'timestamps' des activités du ticket comparés aux politiques SLA.
Pourquoi c'est important Les SLA breaches impactent directement la satisfaction client et la conformité contractuelle. Analyser quand et pourquoi elles se produisent est crucial pour identifier les retards systémiques, les pénuries de ressources ou les objectifs de performance irréalistes. Où obtenir Cela peut être extrait de l'API Zendesk Ticket Metrics, qui stocke les 'timestamps' de violation SLA ('breached_at'). Alternativement, il peut être calculé en comparant les 'timestamps' d''event' du ticket aux règles SLA définies. Capture Utilisez le 'timestamp' 'breached_at' de l'API Ticket Metrics ou calculez en comparant le temps de résolution au temps de la politique SLA. Type d'événement calculated

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Zendesk Support

Étapes

Naviguez vers Zendesk Explore : Connectez-vous à votre instance Zendesk et ouvrez le produit Explore en cliquant sur l'icône de lancement de produit dans la barre supérieure et en sélectionnant Explore.
Créez une nouvelle requête : Dans Explore, cliquez sur l'icône Requêtes dans la barre latérale gauche, puis sur le bouton « Nouvelle requête » en haut à droite.
Sélectionnez le jeu de données : Dans la fenêtre « Choisir un jeu de données », sélectionnez le jeu de données Support : Tickets. Ce jeu de données contient les attributs principaux des tickets et les horodatages clés des événements.
Ajoutez des métriques : Dans le constructeur de requêtes, allez dans le panneau « Métriques » et cliquez sur « Ajouter ». Sélectionnez COUNT(Tickets). Cela aide à valider le volume de données.
Ajoutez des attributs aux lignes : Allez dans le panneau « Lignes » et cliquez sur « Ajouter ». Ajoutez les attributs suivants. Ceux-ci formeront les colonnes de base de votre exportation au format large.
- Ticket ID (Ceci est 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 des horodatages d'activité aux lignes : Ajoutez les attributs d'horodatage suivants au panneau « Lignes ». Chacun d'eux représente une activité potentielle. 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 d'autres activités : Certaines activités sont basées sur des changements de champs spécifiques et nécessitent la création d'attributs personnalisés pour capturer leur horodatage. Allez dans le menu Calculs (icône calculatrice) et sélectionnez « Attribut calculé standard ». Créez un attribut pour chacune des activités suivantes. Vous devrez trouver 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 l'avoir créé, ajoutez ce nouvel attribut au panneau « Lignes » et modifiez son agrégateur en MIN.
- Nom : Timestamp - Info Requested. Formule : IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Ajoutez-le aux « Lignes » et définissez l'agrégateur sur MIN.
- 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 aux « Lignes » et définissez l'agrégateur sur MIN.
- Nom : Timestamp - Escalated. Formule : IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Ajoutez-le aux « Lignes » et définissez l'agrégateur sur MIN.
- Nom : Timestamp - SLA Breach. Formule : IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Ajoutez-le aux « Lignes » et définissez l'agrégateur sur MIN.
Filtrez les données : Allez dans le panneau « Filtres » et cliquez sur « Ajouter ». Ajoutez un filtre pour Ticket created - Date et sélectionnez une plage de dates appropriée, telle que les 3 à 6 derniers mois, pour maintenir le jeu de données gérable.
Exécutez et exportez le rapport : Cliquez sur « Enregistrer » pour exécuter la requête. Une fois que le tableau affiche les données, cliquez sur le bouton « Exporter » et choisissez votre format préféré, tel que CSV ou Excel.
Transformez les données au format journal d'événements : Le fichier exporté est au format « large » où chaque ligne est un ticket et chaque colonne est un horodatage d'événement. Vous devez le transformer en format « long » pour le Process Mining. Utilisez un outil comme Microsoft Excel (avec la fonctionnalité de 'Dépivoter' de Power Query), Python, ou un autre outil de préparation de données.
- Pour chaque ligne (ticket), créez plusieurs nouvelles lignes, une pour chaque colonne d'horodatage non vide.
- La table finale devrait avoir des colonnes comme ServiceRequest, ActivityName, StartTime, et les autres attributs, qui seront dupliqués pour chaque activité d'une demande de service donnée.

Configuration

Jeu de données : Le jeu de données principal à utiliser est Support : Tickets. Il permet d'accéder à la plupart des propriétés de tickets et des horodatages clés dans une seule requête.
Autorisations : Vous avez besoin au minimum d'un rôle d'éditeur ou d'administrateur dans Zendesk Explore pour créer et enregistrer des requêtes.
Plage de dates : Il est crucial de définir un filtre de plage de dates sur Ticket created - Date. Une plage de données de 3 à 6 mois est recommandée pour équilibrer la pertinence des analyses et la performance. L'exportation de millions de tickets peut être lente ou échouer.
Filtres de requête : Envisagez d'ajouter des filtres pour des propriétés de tickets spécifiques telles que Ticket brand, Ticket form ou Ticket group afin de concentrer l'analyse sur un service ou une équipe particulière.
Attributs calculés : Cette méthode repose fortement sur la création d'attributs calculés standard pour capturer les horodatages d'événements qui ne sont pas des attributs par défaut, tels que les changements de statut ou les escalades. Assurez-vous d'avoir les autorisations nécessaires pour 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. Naviguez vers le Centre d'administration, puis allez dans Applications et intégrations > APIs > Zendesk API. Sous l'onglet Paramètres, assurez-vous que l'accès par jeton est activé. Cliquez sur 'Ajouter un jeton API' pour créer un nouveau jeton. Copiez le jeton généré en toute sécurité, car il ne sera plus affiché.
Configurez l'environnement Python : Assurez-vous d'avoir Python 3.6 ou plus récent installé. Installez la bibliothèque requests, qui est nécessaire pour effectuer des requêtes HTTP vers l'API Zendesk. Vous pouvez l'installer via la ligne de commande : pip install requests.
Configurez le script Python : Enregistrez le script Python fourni dans un fichier, par exemple extract_zendesk_log.py. Ouvrez le fichier dans un éditeur de texte et mettez à jour les variables d'espace réservé en haut : ZENDESK_SUBDOMAIN, ZENDESK_EMAIL et API_TOKEN avec les détails de votre instance Zendesk et vos identifiants spécifiques.
Définissez la période d'extraction : Localisez la variable START_TIMESTAMP dans le script. Cette valeur détermine la date de début historique pour l'extraction des données. Il doit s'agir d'un horodatage Unix epoch. Pour une analyse initiale, une valeur correspondant aux 3 à 6 derniers mois est recommandée.
Exécutez le script : Ouvrez un terminal ou une invite de commande, naviguez jusqu'au répertoire où vous avez enregistré le script, et exécutez-le en utilisant la commande : python extract_zendesk_log.py.
Surveillez l'exécution : Le script affichera les mises à jour de progression dans la console, indiquant le nombre de tickets traités. Le temps d'exécution total dépendra du volume de données extraites et des éventuelles limitations de taux d'API imposées par Zendesk. Le script inclut une logique de base pour gérer les réponses de limitation de taux.
Récupérez le journal d'événements : Une fois l'opération terminée avec succès, le script créera un fichier nommé zendesk_event_log.csv dans le même répertoire. Ce fichier contient le journal d'événements structuré prêt pour l'analyse.
Préparez le téléchargement : Ouvrez le fichier zendesk_event_log.csv pour vous assurer qu'il a été généré correctement. Vérifiez que les colonnes correspondent aux attributs requis : ServiceRequest, ActivityName, StartTime, SourceSystem et LastDataUpdate. Le fichier est maintenant prêt à être téléchargé dans l'outil de Process Mining.

Configuration

Identifiants API : Le script nécessite un sous-domaine Zendesk valide, l'adresse e-mail d'un utilisateur agent ou administrateur, et un jeton API actif. L'utilisateur associé à ces identifiants doit avoir les autorisations de lecture des tickets, des audits de tickets, des utilisateurs et des métriques de tickets.
Plage de dates : La date de début de l'extraction est contrôlée par la variable START_TIMESTAMP dans le script, qui doit être un horodatage Unix epoch. Il est conseillé de commencer par une période plus courte, telle que 3 mois, pour valider la sortie et la performance du script avant de tenter une extraction de données historiques plus importante.
API d'exportation incrémentielle : Cette solution utilise l'API d'exportation incrémentielle de Zendesk. C'est la méthode la plus efficace et la plus recommandée pour récupérer un grand nombre de tickets, car elle est conçue pour l'exportation de données en masse et évite les pièges courants de la pagination.
Performance et limitation du taux : Zendesk applique des limites de taux d'API qui varient en fonction du plan d'abonnement. Le script intègre une logique pour suspendre l'exécution lorsqu'une limite de taux est atteinte, basée sur l'en-tête Retry-After renvoyé par l'API. Pour les très grandes instances, l'extraction peut prendre plusieurs heures.
Prérequis : Cette méthode d'extraction nécessite un environnement Python 3.6+ fonctionnel et la bibliothèque externe requests. Un accès administrateur à l'instance Zendesk cible est nécessaire pour générer le jeton 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

Préparez l'accès à l'API Zendesk : Connectez-vous à Zendesk en tant qu'administrateur. Naviguez vers le Centre d'administration, puis allez dans Applications et intégrations > APIs > Zendesk API. Sous l'onglet Paramètres, assurez-vous que l'accès par jeton est activé. Cliquez sur 'Ajouter un jeton API' pour créer un nouveau jeton. Copiez le jeton généré en toute sécurité, car il ne sera plus affiché.
Configurez l'environnement Python : Assurez-vous d'avoir Python 3.6 ou plus récent installé. Installez la bibliothèque requests, qui est nécessaire pour effectuer des requêtes HTTP vers l'API Zendesk. Vous pouvez l'installer via la ligne de commande : pip install requests.
Configurez le script Python : Enregistrez le script Python fourni dans un fichier, par exemple extract_zendesk_log.py. Ouvrez le fichier dans un éditeur de texte et mettez à jour les variables d'espace réservé en haut : ZENDESK_SUBDOMAIN, ZENDESK_EMAIL et API_TOKEN avec les détails de votre instance Zendesk et vos identifiants spécifiques.
Définissez la période d'extraction : Localisez la variable START_TIMESTAMP dans le script. Cette valeur détermine la date de début historique pour l'extraction des données. Il doit s'agir d'un horodatage Unix epoch. Pour une analyse initiale, une valeur correspondant aux 3 à 6 derniers mois est recommandée.
Exécutez le script : Ouvrez un terminal ou une invite de commande, naviguez jusqu'au répertoire où vous avez enregistré le script, et exécutez-le en utilisant la commande : python extract_zendesk_log.py.
Surveillez l'exécution : Le script affichera les mises à jour de progression dans la console, indiquant le nombre de tickets traités. Le temps d'exécution total dépendra du volume de données extraites et des éventuelles limitations de taux d'API imposées par Zendesk. Le script inclut une logique de base pour gérer les réponses de limitation de taux.
Récupérez le journal d'événements : Une fois l'opération terminée avec succès, le script créera un fichier nommé zendesk_event_log.csv dans le même répertoire. Ce fichier contient le journal d'événements structuré prêt pour l'analyse.
Préparez le téléchargement : Ouvrez le fichier zendesk_event_log.csv pour vous assurer qu'il a été généré correctement. Vérifiez que les colonnes correspondent aux attributs requis : ServiceRequest, ActivityName, StartTime, SourceSystem et LastDataUpdate. Le fichier est maintenant prêt à être téléchargé dans l'outil de Process Mining.

Configuration

Identifiants API : Le script nécessite un sous-domaine Zendesk valide, l'adresse e-mail d'un utilisateur agent ou administrateur, et un jeton API actif. L'utilisateur associé à ces identifiants doit avoir les autorisations de lecture des tickets, des audits de tickets, des utilisateurs et des métriques de tickets.
Plage de dates : La date de début de l'extraction est contrôlée par la variable START_TIMESTAMP dans le script, qui doit être un horodatage Unix epoch. Il est conseillé de commencer par une période plus courte, telle que 3 mois, pour valider la sortie et la performance du script avant de tenter une extraction de données historiques plus importante.
API d'exportation incrémentielle : Cette solution utilise l'API d'exportation incrémentielle de Zendesk. C'est la méthode la plus efficace et la plus recommandée pour récupérer un grand nombre de tickets, car elle est conçue pour l'exportation de données en masse et évite les pièges courants de la pagination.
Performance et limitation du taux : Zendesk applique des limites de taux d'API qui varient en fonction du plan d'abonnement. Le script intègre une logique pour suspendre l'exécution lorsqu'une limite de taux est atteinte, basée sur l'en-tête Retry-After renvoyé par l'API. Pour les très grandes instances, l'extraction peut prendre plusieurs heures.
Prérequis : Cette méthode d'extraction nécessite un environnement Python 3.6+ fonctionnel et la bibliothèque externe requests. Un accès administrateur à l'instance Zendesk cible est nécessaire pour générer le jeton 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

Naviguez vers Zendesk Explore : Connectez-vous à votre instance Zendesk et ouvrez le produit Explore en cliquant sur l'icône de lancement de produit dans la barre supérieure et en sélectionnant Explore.
Créez une nouvelle requête : Dans Explore, cliquez sur l'icône Requêtes dans la barre latérale gauche, puis sur le bouton « Nouvelle requête » en haut à droite.
Sélectionnez le jeu de données : Dans la fenêtre « Choisir un jeu de données », sélectionnez le jeu de données Support : Tickets. Ce jeu de données contient les attributs principaux des tickets et les horodatages clés des événements.
Ajoutez des métriques : Dans le constructeur de requêtes, allez dans le panneau « Métriques » et cliquez sur « Ajouter ». Sélectionnez COUNT(Tickets). Cela aide à valider le volume de données.
Ajoutez des attributs aux lignes : Allez dans le panneau « Lignes » et cliquez sur « Ajouter ». Ajoutez les attributs suivants. Ceux-ci formeront les colonnes de base de votre exportation au format large.
- Ticket ID (Ceci est 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 des horodatages d'activité aux lignes : Ajoutez les attributs d'horodatage suivants au panneau « Lignes ». Chacun d'eux représente une activité potentielle. 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 d'autres activités : Certaines activités sont basées sur des changements de champs spécifiques et nécessitent la création d'attributs personnalisés pour capturer leur horodatage. Allez dans le menu Calculs (icône calculatrice) et sélectionnez « Attribut calculé standard ». Créez un attribut pour chacune des activités suivantes. Vous devrez trouver 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 l'avoir créé, ajoutez ce nouvel attribut au panneau « Lignes » et modifiez son agrégateur en MIN.
- Nom : Timestamp - Info Requested. Formule : IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Ajoutez-le aux « Lignes » et définissez l'agrégateur sur MIN.
- 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 aux « Lignes » et définissez l'agrégateur sur MIN.
- Nom : Timestamp - Escalated. Formule : IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Ajoutez-le aux « Lignes » et définissez l'agrégateur sur MIN.
- Nom : Timestamp - SLA Breach. Formule : IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Ajoutez-le aux « Lignes » et définissez l'agrégateur sur MIN.
Filtrez les données : Allez dans le panneau « Filtres » et cliquez sur « Ajouter ». Ajoutez un filtre pour Ticket created - Date et sélectionnez une plage de dates appropriée, telle que les 3 à 6 derniers mois, pour maintenir le jeu de données gérable.
Exécutez et exportez le rapport : Cliquez sur « Enregistrer » pour exécuter la requête. Une fois que le tableau affiche les données, cliquez sur le bouton « Exporter » et choisissez votre format préféré, tel que CSV ou Excel.
Transformez les données au format journal d'événements : Le fichier exporté est au format « large » où chaque ligne est un ticket et chaque colonne est un horodatage d'événement. Vous devez le transformer en format « long » pour le Process Mining. Utilisez un outil comme Microsoft Excel (avec la fonctionnalité de 'Dépivoter' de Power Query), Python, ou un autre outil de préparation de données.
- Pour chaque ligne (ticket), créez plusieurs nouvelles lignes, une pour chaque colonne d'horodatage non vide.
- La table finale devrait avoir des colonnes comme ServiceRequest, ActivityName, StartTime, et les autres attributs, qui seront dupliqués pour chaque activité d'une demande de service donnée.

Configuration

Jeu de données : Le jeu de données principal à utiliser est Support : Tickets. Il permet d'accéder à la plupart des propriétés de tickets et des horodatages clés dans une seule requête.
Autorisations : Vous avez besoin au minimum d'un rôle d'éditeur ou d'administrateur dans Zendesk Explore pour créer et enregistrer des requêtes.
Plage de dates : Il est crucial de définir un filtre de plage de dates sur Ticket created - Date. Une plage de données de 3 à 6 mois est recommandée pour équilibrer la pertinence des analyses et la performance. L'exportation de millions de tickets peut être lente ou échouer.
Filtres de requête : Envisagez d'ajouter des filtres pour des propriétés de tickets spécifiques telles que Ticket brand, Ticket form ou Ticket group afin de concentrer l'analyse sur un service ou une équipe particulière.
Attributs calculés : Cette méthode repose fortement sur la création d'attributs calculés standard pour capturer les horodatages d'événements qui ne sont pas des attributs par défaut, tels que les changements de statut ou les escalades. Assurez-vous d'avoir les autorisations nécessaires pour 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`

Votre Modèle de Données de Service Client

Votre Modèle de Données de Service Client

Attributs du service client

Activités du service client

Guides d'extraction

Interface utilisateur Zendesk Explore pour le rapport et l'exportation de données

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST de Zendesk Support

Étapes

Configuration

a Exemple de requête python

API d'exportations incrémentielles Zendesk pour les données en masse

Étapes

Configuration

a Exemple de requête python

Connecteur d'outil ETL tiers pour Zendesk

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Éliminez les goulots d'étranglement du service client, augmentez le CSAT maintenant

Votre Modèle de Données de Service Client

Votre Modèle de Données de Service Client

Attributs du service client

Activités du service client

Guides d'extraction

Interface utilisateur Zendesk Explore pour le rapport et l'exportation de données

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST de Zendesk Support

Étapes

Configuration

a Exemple de requête python

API d'exportations incrémentielles Zendesk pour les données en masse

Étapes

Configuration

a Exemple de requête python

Connecteur d'outil ETL tiers pour Zendesk

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Éliminez les goulots d'étranglement du service client, augmentez le CSAT maintenant