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

Votre `template` de `data` pour le service client

Freshdesk

`Attributes` du service client (20) `Activities` du service client (13) Guides d'extraction (3)

Votre `template` de `data` pour le service client

Ce `template` fournit un guide complet sur les `attributs` de `data` essentiels et les activités de processus nécessaires à une analyse efficace du service client. Il comprend également des conseils d'extraction pratiques pour vous aider à collecter vos `data` efficacement. Utilisez cette ressource pour rationaliser votre collecte de `data` et vous préparer à un Process Mining riche en informations.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction

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

Télécharger le modèle

`Attributes` du service client

Ce sont les champs de `data` recommandés à inclure dans votre `event log` pour une analyse complète du service client et pour obtenir des informations approfondies.

3 Obligatoire 5 Recommandé 12 Facultatif

	Nom	Description
	Activité Activity	Le nom d'un `event` commercial ou d'une étape spécifique survenue dans le processus de service client.
Description L'`attribut` Activité représente une action distincte ou un changement de `status` dans le cycle de vie d'une demande de service. Il enregistre les `events` commerciaux clés tels que 'Ticket Créé', 'Ticket Affecté', 'Première Réponse Envoyée' et 'Ticket Résolu'. Ces activités forment les nœuds de la carte des processus. L'analyse de la séquence et de la fréquence de ces activités est au cœur du Process Mining. Elle permet de visualiser les flux de processus, d'identifier les chemins courants et rares, et de détecter les déviations par rapport à la procédure opérationnelle standard. Comprendre les activités est crucial pour identifier les inefficacités, les boucles de `rework` comme 'Ticket Rouvert' ou les problèmes de conformité. Pourquoi c'est important Cet `attribut` définit les étapes de la carte des processus, permettant la visualisation et l'analyse du flux de processus de bout en bout. Où obtenir Dérivé des types d'`event` au sein de Freshdesk. Il peut s'agir d'une combinaison de changements de statut provenant du `endpoint` API 'Tickets' et d'`events` spécifiques comme des notes ou des réponses provenant du `endpoint` 'Conversations'. Exemples Ticket crééPremière Réponse EnvoyéeStatut changé à En attenteTicket RésoluTicket clôturé
	Demande de service ServiceRequest	L'`identifiant` unique pour une seule demande ou un seul problème client, communément appelé ticket ou `case`.
Description La Demande de service est l'`identifiant` principal du `case` qui relie toutes les activités liées à une seule interaction client. Chaque nouvelle demande, problème ou requête client génère un ID de demande de service unique. Cet ID reste constant tout au long du cycle de vie du ticket, de la création et l'affectation à la résolution et la fermeture. Dans le Process Mining, cet `attribut` est fondamental pour reconstruire le parcours de bout en bout de chaque `case` client. En regroupant tous les `events` connexes sous un seul ID de demande de service, les analystes peuvent visualiser les flux de processus, mesurer les temps de cycle et identifier les variations ou les `bottlenecks` affectant les `case` individuels. Pourquoi c'est important C'est l'ID de `Case` essentiel qui relie tous les `events` connexes en une seule instance de processus, permettant une vue complète de chaque parcours de service client. Où obtenir Ceci est l'ID principal du ticket dans Freshdesk, généralement trouvé comme champ 'id' dans l'`endpoint` API 'Tickets'. Exemples SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
	Heure de l'événement EventTime	L'horodatage indiquant quand une activité ou un événement spécifique s'est produit.
Description `Event Time`, ou l'horodatage (`timestamp`), enregistre la date et l'heure exactes auxquelles une `activity` a eu lieu. C'est un composant critique pour ordonner les `events` chronologiquement et pour calculer les durées entre les différentes étapes du processus. Chaque `activity` enregistrée doit avoir un horodatage (`timestamp`) correspondant. En analyse, cet `attribute` est utilisé pour construire la chronologie de chaque `Service Request`. Il est la base du calcul de tous les `KPI` liés au temps, tels que le temps de résolution, le temps de première réponse et la durée des `bottlenecks`. Des `timestamps` précis sont essentiels pour comprendre la performance du processus et identifier les retards. Pourquoi c'est important Ce `timestamp` est essentiel pour ordonner les `events` chronologiquement et calculer toutes les métriques basées sur la durée, telles que les temps de cycle et la conformité SLA. Où obtenir Ceci correspond aux champs 'created_at' ou 'updated_at' associés aux `events` de tickets, réponses ou changements de `status` dans l'API Freshdesk. Exemples 2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
	Agent assigné AssignedAgent	Le nom ou l'ID de l'agent de service client responsable du ticket au moment de l'`event`.
Description Cet `attribut` identifie l'agent spécifique affecté pour traiter la demande de service. L'agent affecté peut changer tout au long du cycle de vie du ticket en raison de réaffectations ou d'escalades. L'analyse des `data` par Agent Affecté est critique pour les `dashboards` de gestion de la performance. Elle permet de mesurer les KPI spécifiques aux agents comme le temps de résolution moyen, le volume de tickets et les taux de réouverture. Cela aide à identifier les agents les plus performants, à détecter les besoins en formation et à analyser l'impact des transferts d'agents sur le temps de résolution global. Pourquoi c'est important Permet l'analyse de la performance par agent individuel, aidant à identifier les meilleurs performeurs, les opportunités de formation et l'impact des réaffectations. Où obtenir Ceci correspond au champ 'responder_id' dans l'objet 'Tickets' de Freshdesk, qui peut ensuite être joint aux détails de l'agent. Exemples Alice JohnsonRobert SmithMaria Garcia
	Délai de résolution ResolutionTime	Le temps total écoulé entre la création d'une demande de service et sa résolution.
Description Le temps de résolution est un KPI critique au niveau du `case` qui mesure la durée de bout en bout du processus de service. Il est calculé comme la différence entre le `timestamp` de l'activité 'Ticket Résolu' et l'activité 'Ticket Créé'. Cet `attribut` est une mesure principale de l'efficacité des processus. Il est utilisé dans presque tous les `dashboards` de service pour suivre la performance au fil du temps, comparer les performances entre différentes catégories et identifier les `case` qui prennent un temps de résolution exceptionnellement long. La réduction du temps de résolution moyen est souvent un objectif clé des initiatives d'amélioration des processus. Pourquoi c'est important Ceci est un KPI principal pour mesurer l'efficacité du processus, montrant le temps total nécessaire pour résoudre le problème d'un client du début à la fin. Où obtenir Champ calculé. C'est la durée entre l'horodatage (`timestamp`) du premier `event` (création) et l'horodatage (`timestamp`) de l'`event` 'Ticket Resolved' pour chaque `Service Request`. Exemples 25920000086400000604800000
	Priorité Priority	Le niveau de priorité attribué à la demande de service, tel que 'Faible', 'Moyen', 'Élevé' ou 'Urgent'.
Description L'`attribut` Priorité reflète l'urgence d'une demande de service et dicte souvent les délais de réponse et de résolution cibles. La priorité peut être définie automatiquement en fonction de règles ou manuellement par un agent lors du triage. Cet `attribut` est essentiel pour analyser la conformité SLA et l'allocation des ressources. En filtrant la carte des processus par priorité, les analystes peuvent déterminer si les tickets à haute priorité sont réellement traités plus rapidement que ceux à faible priorité. Il aide également à comprendre si les changements de priorité, une forme de `rework`, sont courants et quel impact ils ont sur le processus. Pourquoi c'est important Essentiel pour l'analyse des `SLA` et pour comprendre si les ressources sont correctement allouées pour traiter les problèmes de haute priorité plus rapidement que ceux de faible priorité. Où obtenir Ceci correspond au champ 'priority' dans l'objet 'Tickets' de Freshdesk. Exemples FaibleMoyenÉlevéUrgent
	Statut Status	Le `status` actuel ou historique de la demande de service, tel que 'Ouvert', 'En attente', 'Résolu' ou 'Fermé'.
Description L'`attribut` `Status` indique l'état d'une demande de service à un moment donné. Les changements de `status` représentent souvent des étapes clés du processus, par exemple, passer de 'Ouvert' à 'En attente' lors de l'attente d'une entrée client, ou de 'En attente' à 'Ouvert' lorsque le client répond. Le suivi des changements de `status` est fondamental pour comprendre le cycle de vie du ticket. Il aide à identifier le temps que les tickets passent dans certains états, ce qui est utile pour identifier les `bottlenecks`. Par exemple, une longue durée dans le `status` 'En attente' pourrait indiquer des retards dans la réception d'informations de la part des clients. Pourquoi c'est important Le suivi des changements de `status` est essentiel pour comprendre le cycle de vie du ticket et identifier combien de temps les `case` passent dans des états spécifiques comme 'En attente' ou 'En pause'. Où obtenir Ceci correspond au champ 'status' dans l'objet 'Tickets' de Freshdesk. Les `status` historiques doivent être inférés à partir des journaux d'activité. Exemples OuvertEn attenteRésoluClôturé
	Type de demande de service ServiceRequestType	La classification de la demande de service, telle que 'Question', 'Incident', 'Problème' ou 'Demande de fonctionnalité'.
Description Le `Service Request Type` est un champ de catégorisation crucial qui définit la nature de la demande du client. Cette classification est généralement définie lors de la création du ticket ou lors d'une étape de triage initiale, et aide à acheminer la demande vers l'équipe ou l'agent approprié. En analyse, cet `attribut` permet de segmenter le processus pour comprendre comment différents types de demandes sont traités. Il aide à répondre à des questions telles que 'Les incidents prennent-ils plus de temps à résoudre que les questions ?' et 'Quels types de demandes sont les plus fréquemment rouverts ?'. Cette segmentation est essentielle pour identifier les `bottlenecks` spécifiques à chaque type et optimiser les `workflows` en conséquence. Pourquoi c'est important Permet la segmentation des processus pour comparer les performances et les `workflows` pour différents types de problèmes client, comme les incidents par rapport aux questions. Où obtenir Ceci est probablement le champ 'type' disponible dans l'objet 'Tickets' de Freshdesk. Exemples QuestionIncidentProblèmeDemande de fonctionnalité
	Canal de communication CommunicationChannel	Le canal par lequel la demande de service a été initiée, tel que 'Email', 'Téléphone', 'Chat' ou 'Portail Web'.
Description Cet `attribut` identifie l'origine ou le canal de la communication client. Différents canaux peuvent avoir des flux de processus et des temps de résolution distincts. Par exemple, une demande initiée par `chat` pourrait avoir un temps de résolution attendu plus court qu'une soumise par email. L'analyse du processus par canal de communication aide à optimiser l'allocation des ressources et à comprendre l'efficacité des canaux. Elle peut révéler quels canaux sont associés à des résolutions plus rapides ou à une satisfaction client plus élevée, éclairant les décisions stratégiques concernant les canaux à promouvoir ou dans lesquels investir. Pourquoi c'est important Aide à analyser la performance et l'efficacité des processus sur différents canaux de contact client comme l'e-mail, le téléphone ou le `chat`. Où obtenir Ceci correspond au champ 'source' dans l'objet 'Tickets' de Freshdesk. Exemples E-mailTéléphonePortail webChat
	Dernière mise à jour des données LastDataUpdate	Le timestamp indiquant la dernière fois que les données ont été actualisées à partir du système source.
Description Cet `attribut` enregistre la date et l'heure de la dernière extraction ou mise à jour du jeu de `data` depuis Freshdesk. Il offre une transparence sur la fraîcheur des `data` analysées, ce qui est essentiel pour prendre des décisions commerciales opportunes et pertinentes. Les analystes utilisent cette information pour comprendre la fenêtre temporelle couverte par les `data` et pour confirmer qu'ils travaillent avec les informations les plus récentes disponibles. C'est une pièce maîtresse des métadonnées pour tout `dashboard` ou rapport de Process Mining, garantissant que les parties prenantes sont conscientes de la récence des `data`. Pourquoi c'est important Indique la fraîcheur des `data`, garantissant que les analyses et les décisions sont basées sur des informations à jour. Où obtenir Ceci est un champ de métadonnées généré pendant le processus d'extraction de `data`, capturant le `timestamp` de l'extraction de `data`. Exemples 2023-12-01T08:00:00Z
	Est rouvert IsReopened	Un indicateur booléen signalant si une demande de service résolue a été rouverte.
Description Cet `attribut` au niveau du `case` est un indicateur qui est défini à vrai si une demande de service a connu une activité 'Ticket Rouvert' à tout moment de son cycle de vie. Il offre un moyen simple d'identifier et d'analyser les `case` qui ont nécessité un `rework`. Un taux élevé de tickets rouverts suggère que la résolution initiale n'était pas efficace ou complète, entraînant une inefficacité et une frustration client. En filtrant les tickets rouverts, les analystes peuvent enquêter sur les causes profondes, telles que les raisons courantes de réouverture, quels agents ou équipes ont des taux plus élevés, et quels types de tickets sont les plus sujets à être rouverts. Pourquoi c'est important Identifie les `cases` qui ont nécessité un retravail, un indicateur clé de la qualité de la résolution et de l'inefficacité du processus. L'analyse de ces `cases` aide à améliorer la résolution au premier contact. Où obtenir Champ calculé. Défini à vrai (`true`) pour un `Service Request` si un `event` avec `Activity` = 'Ticket Reopened' existe pour ce `case`. Exemples truefaux
	Groupe assigné AssignedGroup	L'équipe ou le département auquel la demande de service est affectée.
Description Le Groupe Affecté représente l'équipe d'agents responsable du traitement d'une demande de service spécifique. Les tickets sont souvent acheminés vers des groupes spécialisés en fonction de leur type ou de leur complexité, tels que le 'Support Technique' ou le 'Service de Facturation'. Cet `attribut` est précieux pour analyser les transferts interdépartementaux et la performance au niveau de l'équipe. Il aide à identifier quels groupes traitent le plus de tickets, lesquels ont les temps de résolution les plus longs, et à quelle fréquence les tickets sont transférés entre les groupes. Cette information est essentielle pour optimiser les structures d'équipe et les `workflows`. Pourquoi c'est important Permet une analyse de la performance au niveau de l'équipe ou du département, mettant en évidence les transferts et identifiant les `bottlenecks` spécifiques aux groupes. Où obtenir Ceci correspond au champ 'group_id' dans l'objet 'Tickets' de Freshdesk. Exemples Support L1Support technique L2FacturationSuccès client
	Nom du client CustomerName	Le nom ou l'ID du client qui a initié la demande de service.
Description Cet `attribut` identifie le client associé à la demande de service. Il offre un moyen d'analyser le processus du point de vue client, en suivant toutes les interactions pour un client spécifique au fil du temps. L'analyse par client peut révéler des modèles tels que quels clients soumettent le plus de tickets ou lesquels rencontrent le plus de problèmes rouverts. Cela peut éclairer les initiatives de succès client et aider à identifier les clients qui pourraient être à risque d'attrition en raison de mauvaises expériences de service. C'est également crucial pour comprendre le parcours client de bout en bout à travers plusieurs demandes de service. Pourquoi c'est important Permet une vue de processus centrée sur le client, aidant à identifier les demandeurs fréquents ou les clients rencontrant des problèmes récurrents. Où obtenir Cette information est liée via le 'requester_id' dans l'objet 'Tickets', qui se connecte à l'objet 'Contacts' ou 'Users' dans Freshdesk. Exemples John DoeJane SmithGlobal Tech Inc.
	Nombre de transferts d'agents AgentTransferCount	Le nombre total de fois qu'une demande de service a été réaffectée d'un agent à un autre.
Description Cet `attribut` est une métrique au niveau du `case` qui compte le nombre de fois où l'agent affecté à un ticket a changé. Il est calculé en comptant les occurrences de l'activité 'Ticket Réaffecté' pour chaque demande de service. Les transferts fréquents, également connus sous le nom de 'ping-ponging', peuvent entraîner des retards significatifs et une expérience client frustrante, car le contexte est perdu à chaque transfert. L'analyse du nombre de transferts aide à identifier les problèmes d'acheminement initial, les lacunes de compétences des agents ou la complexité du processus. L'objectif est souvent de minimiser les transferts inutiles pour améliorer l'efficacité et la satisfaction client. Pourquoi c'est important Mesure la fréquence des transferts internes, source majeure de retards et de frustration client, contribuant à améliorer la résolution au premier niveau. Où obtenir Champ calculé. Il s'agit du nombre d'`activities` 'Ticket Reassigned' pour chaque `Service Request` unique. Exemples 0132
	Produit Product	Le produit ou service auquel la demande du client est liée.
Description Cet `attribut` spécifie la ligne de produit ou de service qui fait l'objet de la demande de service. Il s'agit souvent d'un champ personnalisé configuré dans Freshdesk pour aider à catégoriser les tickets à des fins de routage et de reporting. En filtrant le processus par produit, les organisations peuvent découvrir des problèmes spécifiques aux produits. Par exemple, il peut mettre en évidence si un certain produit génère un nombre disproportionné de tickets de support ou si un nouveau lancement de produit provoque un pic de demandes. Cette analyse fournit des retours précieux aux équipes de développement et de gestion des produits. Pourquoi c'est important Permet de filtrer le processus par domaine produit, offrant des `insights` sur les produits qui génèrent le plus de demandes de support ou qui ont les temps de résolution les plus longs. Où obtenir Ceci est généralement un champ personnalisé. L'emplacement exact dépend de la configuration Freshdesk, probablement trouvé dans la partie 'custom_fields' de la réponse API 'Tickets'. Exemples Plateforme AlphaApplication mobile BetaAbonnement Gamma
	SLA est enfreint IsSlaBreached	Un indicateur booléen signalant si le temps de résolution de la demande de service a dépassé la cible `SLA`.
Description Cet `attribut` calculé fournit un indicateur binaire clair de la conformité SLA pour chaque demande de service. Il est dérivé en comparant le `ResolutionTime` réel avec le `SlaTargetResolutionTime`. Si le temps réel est supérieur à la cible, l'indicateur est vrai. Cet `attribut` simplifie l'analyse et la création de `dashboards` pour la conformité SLA. Il permet un comptage et un filtrage faciles des tickets en violation, permettant aux analystes d'identifier rapidement l'ampleur de la non-conformité SLA et d'explorer les modèles de processus des tickets en infraction pour en trouver les causes profondes. Il soutient directement le `dashboard` et le KPI 'Aperçu de la conformité SLA'. Pourquoi c'est important Simplifie l'analyse de la conformité SLA en fournissant un indicateur clair pour chaque `case` n'ayant pas atteint son objectif, permettant une analyse des causes profondes des violations. Où obtenir Ceci est un champ calculé, dérivé en comparant le `timestamp` de résolution réel avec le champ 'SlaTargetResolutionTime' ou 'due_by' de Freshdesk. Exemples truefaux
	Système source SourceSystem	Le système à partir duquel les `data` ont été extraites, qui est 'Freshdesk' dans ce `case`.
Description Cet `attribut` identifie l'application source d'où proviennent les `data` du processus. Pour cette analyse, la valeur sera statique, par exemple, 'Freshdesk', indiquant que tous les `events` proviennent de la plateforme de service client Freshdesk. Bien que cela puisse sembler simple, cet `attribut` est important pour la gouvernance des `data` et dans les scénarios où les `data` de plusieurs systèmes sont fusionnées. Il fournit une traçabilité et un contexte clairs, garantissant que les analystes comprennent l'origine des `data` qu'ils examinent. C'est crucial pour maintenir l'intégrité des `data` et renforcer la confiance dans l'analyse. Pourquoi c'est important Fournit un contexte essentiel sur l'origine des `data`, ce qui est crucial pour la gouvernance des `data` et lors de la combinaison de `data` provenant de plusieurs systèmes sources. Où obtenir Ceci est une valeur statique, 'Freshdesk', ajoutée pendant le processus de transformation des `data` pour identifier la source des `data`. Exemples Freshdesk
	Taux de satisfaction SatisfactionRating	Le score de satisfaction fourni par le client après la résolution du ticket.
Description Le Taux de satisfaction est une métrique de résultat clé, généralement recueillie via une enquête envoyée après la résolution d'un ticket. Il consiste généralement en un score numérique ou une évaluation catégorielle comme 'Satisfait', 'Neutre' ou 'Insatisfait'. Cet `attribut` permet de corréler les modèles de processus avec les résultats client. En analysant les variantes de processus qui mènent à de faibles scores de satisfaction, les organisations peuvent identifier les comportements ou les retards spécifiques qui impactent négativement l'expérience client. Cela établit un lien direct entre l'efficacité du processus et le bonheur du client. Pourquoi c'est important Lie l'exécution du processus aux résultats client, aidant à identifier quels comportements de processus conduisent à une satisfaction client élevée ou faible. Où obtenir Ces `data` font partie de la fonctionnalité d'évaluation de la satisfaction dans Freshdesk et peuvent être récupérées via les `endpoints` d'API 'Surveys' ou 'Satisfaction Ratings'. Exemples 5314
	Temps de première réponse FirstResponseTime	Le temps écoulé entre la création du ticket et la première réponse de l'agent au client.
Description Le Temps de première réponse mesure la rapidité avec laquelle un client reçoit une réponse initiale non automatisée d'un agent de service. Il est calculé comme la différence entre l'horodatage (`timestamp`) de l'`activity` 'First Response Sent' et l'`activity` 'Ticket Created'. Ce `KPI` est un indicateur clé de la réactivité du service et a un fort impact sur la satisfaction client. Un temps de première réponse court assure au client que son problème a été pris en compte et est en cours de traitement. L'analyse de cette métrique aide les organisations à s'assurer qu'elles respectent les `SLA` de réponse initiale et qu'elles offrent une expérience client rapide. Pourquoi c'est important Mesure la réactivité du service, un facteur clé de la satisfaction client qui répond directement à l'objectif de prestation de service proactive. Où obtenir Champ calculé. C'est la durée entre l'horodatage (`timestamp`) de l'`event` 'Ticket Created' et l'`event` 'First Response Sent'. Exemples 3000009000001800000
	Temps de résolution cible du SLA SlaTargetResolutionTime	Le délai contractuel ou ciblé pour la résolution de la demande de service.
Description Cet `attribut` définit la durée cible dans laquelle une demande de service doit être résolue conformément au `Service Level Agreement` (SLA). Cette cible dépend souvent de la priorité ou du type du ticket. C'est une entrée critique pour le calcul de la conformité SLA. En comparant le temps de résolution réel à cette cible, une détermination de 'Respecté' ou 'Violé' peut être faite. L'analyse de la performance SLA à travers différents types de demandes, équipes ou agents est une partie essentielle de la gestion des services. Pourquoi c'est important Fournit la base pour mesurer la conformité SLA, un indicateur clé de performance pour toute organisation de service client. Où obtenir Ceci peut être disponible comme un champ tel que 'fr_due_by' (première réponse) ou 'due_by' (résolution) dans l'objet 'Tickets' de Freshdesk, ou il peut devoir être dérivé en fonction des règles de politique SLA. Exemples 2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z

Obligatoire Recommandé Facultatif

`Activities` du service client

Ce sont les étapes clés du processus et les jalons importants à capturer dans votre `event log` pour une découverte précise des processus et l'identification des `bottlenecks`.

5 Recommandé 8 Facultatif

	Activité	Description
	Première Réponse Envoyée	Marque la première réponse publique envoyée par un agent au client après la création du ticket. Freshdesk capture explicitement cet `event` pour mesurer le 'First Response Time' pour le suivi `SLA`.
Pourquoi c'est important Ceci est une étape critique pour mesurer la réactivité client et la conformité SLA. L'analyse du temps jusqu'à cette activité aide à identifier les retards dans l'engagement initial avec les clients. Où obtenir Ceci est un `event` spécifique que Freshdesk suit à des fins de SLA. Il correspond au `timestamp` du premier commentaire public ajouté par un agent. Capture Identifié par la première réponse publique de l'agent dans l'historique de conversation du ticket. Type d'événement explicit
	Ticket Assigné	Représente l'affectation d'un ticket à un agent ou un groupe spécifique pour traitement. Cet `event` est explicitement enregistré dans l'historique du ticket chaque fois que le champ de l'agent ou du groupe affecté est rempli ou modifié.
Pourquoi c'est important Le suivi des affectations est crucial pour analyser la charge de travail des agents, identifier les inefficacités de routage et mesurer les KPI de temps d'affectation. Il aide à comprendre comment le travail est distribué et où des retards surviennent avant que le travail ne commence. Où obtenir Capturé à partir du `log` des 'Ticket Activities' où les modifications des champs 'Agent' ou 'Group' sont enregistrées avec un `timestamp`. Capture `Event` enregistré lorsque le champ 'Assigned to' est mis à jour pour un agent ou un group. Type d'événement explicit
	Ticket clôturé	Ceci est l'activité finale, représentant la fermeture permanente du ticket. Elle est souvent effectuée automatiquement par le système après une période définie à l'état 'Résolu' sans aucune nouvelle réponse du client.
Pourquoi c'est important Cette activité marque la fin définitive du cycle de vie de la demande de service. Elle fournit le point final pour des calculs précis de temps de cycle de bout en bout. Où obtenir Capturé à partir du `log` des 'Ticket Activities', qui enregistre le changement de statut final à 'Closed'. Cela est souvent déclenché par une automatisation système. Capture `Event` enregistré lorsque le champ 'Status' du ticket est mis à jour à 'Closed'. Type d'événement explicit
	Ticket créé	Ceci est le premier `event` dans le cycle de vie du service client, représentant le moment où la demande d'un client est officiellement enregistrée dans Freshdesk. Cette activité est explicitement capturée lorsqu'un nouveau ticket est généré, que ce soit par email, un portail, téléphone ou intégration API.
Pourquoi c'est important Cette activité sert de point de départ pour chaque `case`, la rendant essentielle pour calculer les temps de résolution globaux et analyser les tendances de volume de tickets par canal ou type. Où obtenir Ceci est un `event` explicite dans le journal 'Activités du ticket' de Freshdesk. Il est généré automatiquement lors de la création d'un nouvel enregistrement de ticket. Capture Directement enregistré dans le flux d'`activity` du ticket dès sa création. Type d'événement explicit
	Ticket Résolu	Représente l'étape clé où l'agent a fourni une solution et modifié le `status` du ticket à 'Résolu'. Il s'agit d'un changement de `status` explicite enregistré dans l'historique du ticket.
Pourquoi c'est important Cette activité marque la fin du travail actif sur un ticket et constitue la base pour mesurer le temps de résolution. C'est un `event` critique pour analyser la performance des agents et l'efficacité globale du processus. Où obtenir Capturé à partir du `log` des 'Ticket Activities', qui enregistre le changement de statut spécifique à 'Resolved' ainsi qu'un `timestamp`. Capture `Event` enregistré lorsque le champ 'Status' du ticket est mis à jour à 'Resolved'. Type d'événement explicit
	`Ticket Réouvert`	Cette activité se produit lorsqu'un client répond à un ticket déjà à l'état 'Résolu', ce qui modifie automatiquement son `status` en 'Ouvert'. Il s'agit d'un `event` explicite enregistré par le système.
Pourquoi c'est important Un taux de réouverture élevé indique que les solutions initiales ne sont pas efficaces, entraînant des reprises et une insatisfaction client. L'analyse de cette `activity` est essentielle pour l'« Analyse de la réouverture des tickets » et l'amélioration de la résolution au premier contact. Où obtenir Cet `event` est capturé lorsqu'une réponse client déclenche un changement de `status` automatique de 'Résolu' à 'Ouvert'. Ce changement de `status` est enregistré dans le journal 'Activités du ticket'. Capture Changement de `status` de 'Résolu' à 'Ouvert' déclenché par une interaction client. Type d'événement explicit
	Client a répondu	Représente une nouvelle réponse ou communication reçue du client. Il s'agit d'un `event` explicite dans le fil de conversation du ticket et déclenche généralement un changement de `status` de 'En attente' à 'Ouvert'.
Pourquoi c'est important Cette activité est essentielle pour comprendre la nature des interactions client et mesurer les temps de réponse client. Elle relance également les minuteurs SLA en pause, impactant les métriques de conformité. Où obtenir Enregistré comme nouvelle entrée dans le fil de conversation du ticket. L'`event` est associé à l'enregistrement du contact client. Capture Une nouvelle note publique ajoutée au ticket par le contact client. Type d'événement explicit
	Enquête de satisfaction envoyée	Représente l'envoi d'une enquête de satisfaction client, généralement déclenchée par une règle d'automatisation après la résolution d'un ticket. Cet `event` peut être enregistré si l'action d'automatisation est consignée dans l'historique du ticket.
Pourquoi c'est important Marque le début du processus de collecte de `feedback`. La corrélation des réponses aux enquêtes avec les variantes de processus peut fournir des `insights` approfondis sur la manière dont la performance du processus impacte la satisfaction client. Où obtenir Ceci est généralement déclenché par une 'Règle d'automatisation'. Sa visibilité en tant qu'`event` distinct dans le journal d'activité du ticket dépend de la configuration de journalisation de Freshdesk pour les automatismes. Capture `Event` enregistré par l'exécution d'une règle d'automatisation après la résolution du ticket. Type d'événement explicit
	Note interne ajoutée	Un agent ajoute une note privée au ticket, destinée à la collaboration interne avec d'autres agents. Il s'agit d'un `event` explicite capturé dans le flux d'`activity` du ticket, visible uniquement par les agents.
Pourquoi c'est important Le suivi des notes internes aide à analyser les schémas de collaboration et à identifier les problèmes nécessitant des discussions internes importantes. Une fréquence élevée de notes internes avant la résolution peut indiquer des problèmes complexes ou des lacunes de connaissances. Où obtenir Enregistré comme une 'Note privée' dans l'historique de conversation du ticket, distincte des réponses publiques au client. Capture `Event` enregistré lorsqu'un agent ajoute une note marquée 'Private'. Type d'événement explicit
	Priorité du ticket modifiée	Cet `event` se produit lorsqu'un agent ou une règle d'automatisation modifie le niveau de priorité d'un ticket, par exemple de 'Faible' à 'Élevé'. Ceci est enregistré comme une mise à jour explicite dans le journal d'activité du ticket.
Pourquoi c'est important Les changements de priorité peuvent signaler des escalades ou une réévaluation de l'urgence du problème. L'analyse de ces changements aide à comprendre les déclencheurs d'escalade et leur impact sur le temps de résolution. Où obtenir Capturé à partir du `log` des 'Ticket Activities', qui enregistre toutes les modifications des propriétés du ticket, y compris le champ 'Priority'. Capture `Event` enregistré lorsque la valeur du champ 'Priority' est mise à jour. Type d'événement explicit
	SLA Non Respecté	Un `event` calculé qui se produit lorsque le temps de réponse ou de résolution d'un ticket dépasse la cible de politique `SLA` définie. Freshdesk suit le statut `SLA` et marque les tickets comme 'violés', ce qui peut être utilisé pour dériver cette `activity`.
Pourquoi c'est important Cette activité soutient directement l'analyse de la conformité SLA en identifiant précisément quand et où les engagements de niveau de service ne sont pas respectés. Elle est critique pour identifier les causes systémiques des retards. Où obtenir Cet `event` est inféré ou calculé en observant le `status` 'SLA' d'un ticket. Une activité peut être générée lorsque le `status` SLA du ticket passe à 'Violé' ou en comparant les `timestamps` de réponse/résolution aux objectifs SLA. Capture Dériver des `data` du ticket lorsque le 'Time to Resolve' dépasse le 'SLA Target Resolution Time'. Type d'événement calculated
	Statut changé à En attente	Cette activité se produit lorsqu'un agent attend des informations du client et modifie le `status` du ticket en 'En attente'. Cet `event` est explicitement enregistré comme un changement de `status` dans l'historique d'activité du ticket.
Pourquoi c'est important Identifie les périodes où le processus est mis en pause en attendant une contribution externe. L'analyse du temps passé dans ce statut aide à quantifier les retards côté client et soutient l'analyse de la conformité `SLA`, car les minuteurs `SLA` sont souvent suspendus dans cet état. Où obtenir Capturé à partir du `log` des 'Ticket Activities', qui enregistre toutes les modifications de statut, y compris la transition vers 'Pending'. Capture `Event` enregistré lorsque le champ 'Status' du ticket est mis à jour à 'Pending'. Type d'événement explicit
	Ticket réaffecté	Se produit lorsqu'un ticket est transféré d'un agent ou d'un groupe à un autre après l'affectation initiale. Il s'agit d'un `event` explicite enregistré dans le journal d'activité du ticket comme un changement de propriétaire.
Pourquoi c'est important Des réaffectations fréquentes, ou un taux de transfert élevé d'agent à agent, indiquent souvent un routage initial incorrect ou des connaissances cloisonnées. Cette analyse aide à identifier les opportunités d'améliorer la résolution au premier contact. Où obtenir Suivi via les changements apportés aux champs 'Agent' ou 'Groupe' dans le journal 'Activités du ticket' après la première affectation. Capture Une mise à jour ultérieure du champ 'Assigned to' après une attribution initiale. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos `data` de Freshdesk

Étapes

Connectez-vous à votre instance Freshdesk avec un compte Administrateur disposant des autorisations de visualisation et d'exportation des tickets.
Naviguez vers l'onglet principal Tickets depuis le menu de navigation de gauche pour afficher la liste des tickets.
Utilisez le panneau Filtrer les tickets à droite pour définir la portée de votre extraction de data. Au minimum, définissez une plage de dates de Création, par exemple, les 6 derniers mois. Vous pouvez ajouter d'autres filtres comme Group, Agent ou Source pour affiner le jeu de data.
Une fois les filtres appliqués, cliquez sur l'icône Exporter, qui ressemble à une flèche pointant vers le bas dans un plateau, située en haut à droite de la liste des tickets.
Dans la fenêtre contextuelle Exporter les tickets, sélectionnez les champs que vous souhaitez inclure. Assurez-vous de sélectionner tous les champs par défaut et personnalisés pertinents nécessaires au event log, y compris : ID du Ticket, Created at, Resolved at, Closed at, First responded at, Agent, Group, Statut, Priority, Type, et tout autre champ personnalisé qui pourrait être utile.
Confirmez votre sélection. Freshdesk commencera à traiter l'exportation en arrière-plan. Vous recevrez un e-mail contenant un lien pour télécharger les data sous forme de fichier CSV. Cela peut prendre un certain temps pour les grands jeux de data.
Téléchargez le fichier CSV à partir du lien dans l'e-mail.
Le fichier exporté contient une ligne par ticket, représentant un instantané de l'état actuel du ticket et des horodatages clés. Pour créer un event log, vous devez transformer ces data.
Utilisez un script, comme le script Python fourni dans la section 'Query', ou un outil de préparation des data pour « dépivoter » les colonnes d'horodatage (Created at, First responded at, Resolved at, Closed at) en lignes séparées. Chaque nouvelle ligne représentera une seule activity.
Mappez les colonnes d'horodatage d'origine à des noms d'Activity spécifiques, par exemple, mappez la colonne 'Created at' à l'activity 'Ticket Created'.
Générez le event log CSV final avec les colonnes requises : ServiceRequest, Activity et EventTime, ainsi que tous les autres attributes recommandés.
Enregistrez le fichier transformé au format CSV, adapté pour l'importation dans votre outil de Process Mining.

Configuration

Autorisations : Nécessite le rôle d'Administrateur ou un rôle personnalisé avec les autorisations nécessaires pour consulter et exporter les tickets du compte.
Filtre de Plage de Dates : Il est crucial de définir une plage de dates en utilisant les champs de temps 'Créé' ou 'Fermé' pour éviter d'exporter l'historique complet, ce qui peut être très lent. Une période de 3 à 6 mois est généralement recommandée pour une analyse initiale.
Champs des Tickets : Dans la boîte de dialogue d'exportation, vous avez la possibilité de sélectionner les champs à inclure. Assurez-vous de sélectionner tous les champs d'horodatage disponibles, tels que Created at, First responded at, Resolved at, et Closed at, car ils constituent la base du event log. Incluez également les champs d'identification comme Ticket ID et les champs de contexte comme Agent, Group, Priority, et Type.
Volume des Données : Les exportations sont limitées en nombre de tickets pouvant être exportés en une seule fois, généralement 30 000 tickets. Pour des jeux de data plus importants, vous devrez peut-être effectuer plusieurs exportations en divisant la plage de temps en segments plus petits, par exemple, mois par mois.
Livraison : L'exportation est un processus asynchrone. Le fichier CSV n'est pas téléchargé directement, mais est envoyé sous forme de lien de téléchargement à l'adresse e-mail de l'utilisateur qui a initié l'exportation.

a Exemple de requête config

### Part 1: Freshdesk Export Configuration

This process uses the user interface for extraction. In the **Export Tickets** dialog, configure the following settings:

```json
{
  "filter_by": {
    "created": "[Specify Date Range, e.g., Last 6 Months]",
    "status": ["Open", "Pending", "Resolved", "Closed"],
    "// additional_filters": "Optionally filter by Group, Agent, Type, etc."
  },
  "export_fields": [
    "Ticket ID",
    "Created at",
    "First responded at",
    "Resolved at",
    "Closed at",
    "Group",
    "Agent",
    "Status",
    "Priority",
    "Type",
    "// include_custom_fields": "[Select any relevant custom fields]"
  ]
}
```

### Part 2: Data Transformation Script (Python with Pandas)

The exported CSV is a snapshot and must be transformed into an event log. The following script reshapes the data to create a row for each key activity.

```python
import pandas as pd

# --- Configuration ---
# Replace with the actual path to your downloaded Freshdesk CSV export
input_csv_path = 'freshdesk_export.csv'
output_csv_path = 'freshdesk_event_log.csv'

# --- Load Data ---
def transform_freshdesk_export(file_path):
    """Loads the Freshdesk export and transforms it into an event log."""
    try:
        df_raw = pd.read_csv(file_path)
    except FileNotFoundError:
        print(f"Error: The file {file_path} was not found.")
        return None

    # --- Rename and Select Columns ---
    # Adjust column names based on your specific export file
    column_mapping = {
        'Ticket ID': 'ServiceRequest',
        'Agent': 'AssignedAgent',
        'Type': 'ServiceRequestType',
        'Status': 'Status',
        'Priority': 'Priority',
        'Created at': 'Time_Ticket_Created',
        'First responded at': 'Time_First_Response_Sent',
        'Resolved at': 'Time_Ticket_Resolved',
        'Closed at': 'Time_Ticket_Closed'
    }
    df = df_raw.rename(columns=column_mapping)

    # Define the columns that are common to all events for a given ticket
    base_columns = ['ServiceRequest', 'AssignedAgent', 'ServiceRequestType', 'Status', 'Priority']
    # Ensure all required base columns exist
    for col in base_columns:
        if col not in df.columns:
            df[col] = None # Add missing columns as null

    # --- Unpivot Timestamp Columns to Create Events ---
    events = []
    activity_map = {
        'Time_Ticket_Created': 'Ticket Created',
        'Time_First_Response_Sent': 'First Response Sent',
        'Time_Ticket_Resolved': 'Ticket Resolved',
        'Time_Ticket_Closed': 'Ticket Closed'
    }

    for time_col, activity_name in activity_map.items():
        if time_col in df.columns:
            # Select rows where the timestamp exists
            df_event = df[df[time_col].notna()].copy()
            if not df_event.empty:
                df_event['Activity'] = activity_name
                df_event['EventTime'] = pd.to_datetime(df_event[time_col])
                events.append(df_event[base_columns + ['Activity', 'EventTime']])

    if not events:
        print("No events could be generated. Please check your column names and data.")
        return None

    # --- Combine, Sort, and Finalize ---
    df_event_log = pd.concat(events, ignore_index=True)

    # Calculate Resolution Time (optional, as an attribute)
    if 'Time_Ticket_Created' in df.columns and 'Time_Ticket_Resolved' in df.columns:
        df_res_time = df[['ServiceRequest', 'Time_Ticket_Created', 'Time_Ticket_Resolved']].dropna()
        df_res_time['ResolutionTime'] = (pd.to_datetime(df_res_time['Time_Ticket_Resolved']) - pd.to_datetime(df_res_time['Time_Ticket_Created'])).dt.total_seconds() / 3600.0 # In hours
        df_event_log = df_event_log.merge(df_res_time[['ServiceRequest', 'ResolutionTime']], on='ServiceRequest', how='left')

    # Sort the event log for proper ordering
    df_event_log = df_event_log.sort_values(by=['ServiceRequest', 'EventTime'], ascending=[True, True])

    return df_event_log

# --- Execute Transformation ---
if __name__ == "__main__":
    event_log = transform_freshdesk_export(input_csv_path)
    if event_log is not None:
        event_log.to_csv(output_csv_path, index=False)
        print(f"Event log successfully created at: {output_csv_path}")
```

Étapes

Prérequis : Assurez-vous d'avoir Python 3.6 ou une version ultérieure installée sur votre système. Installez les bibliothèques Python requises, requests pour les appels API et pandas pour la manipulation des data, en exécutant la commande : pip install requests pandas.
Obtenir la clé API Freshdesk : Connectez-vous à votre instance Freshdesk en tant qu'Administrateur. Cliquez sur l'icône de votre profil en haut à droite et sélectionnez 'Paramètres du profil'. Votre clé API sera affichée sur le côté droit. Copiez cette clé en toute sécurité.
Configurer le script Python : Créez un nouveau fichier Python (par exemple, extract_freshdesk.py). Copiez le script Python complet fourni dans la section 'query' dans ce fichier.
Paramétrer le script : Ouvrez le script et mettez à jour les variables d'espace réservé en haut. Définissez DOMAIN sur votre domaine Freshdesk (par exemple, votresociete.freshdesk.com), API_KEY sur la clé que vous avez obtenue, et START_DATE_STR sur la date de début souhaitée pour l'extraction des data au format 'AAAA-MM-JJ'.
Exécuter le script : Exécutez le script depuis votre terminal en utilisant la commande : python extract_freshdesk.py. Le script commencera à récupérer les data des tickets de l'API Freshdesk.
Surveiller l'extraction : Le script affichera des mises à jour de progression dans la console, indiquant la page de tickets en cours de traitement. En fonction de la plage de dates et du nombre de tickets, ce processus peut prendre un temps considérable en raison des limites de taux de l'API.
Gérer les réponses de l'API : Le script inclut une logique pour gérer la pagination de l'API en récupérant les tickets page par page. Il respecte également les limites de taux de l'API en suspendant l'exécution si une erreur 429 Too Many Requests est reçue, puis en réessayant après la durée spécifiée par Freshdesk.
Transformation des data : Pour chaque ticket, le script récupère ses conversations et activities associées. Il analyse ensuite ces réponses JSON brutes pour identifier et créer des enregistrements explicites pour chacune des 13 activities requises, telles que 'Ticket créé', 'Statut passé à En attente' et 'Ticket résolu'.
Examiner le résultat : Une fois le script terminé, il générera un fichier nommé freshdesk_event_log.csv dans le même répertoire. Ce fichier contient le event log structuré avec toutes les activities et les attributes extraits.
Préparer l'importation : Ouvrez le fichier CSV généré pour vous assurer qu'il contient les data attendues. Vérifiez que les colonnes ServiceRequest, Activity et EventTime sont présentes et correctement renseignées. Le fichier est maintenant prêt à être importé dans ProcessMind.

Configuration

Prérequis : Un compte Freshdesk avec des privilèges d'administrateur est nécessaire pour obtenir une clé API avec un accès complet aux data des tickets. Vous devez avoir Python 3.6+ ainsi que les bibliothèques requests et pandas installées.
Identifiants API : Le script nécessite votre DOMAIN Freshdesk spécifique et une API_KEY valide. Ceux-ci doivent être configurés comme variables dans le script.
Plage de Dates : La variable START_DATE_STR détermine le point de départ de l'extraction. Il est recommandé de commencer avec une plage plus petite, par exemple 3 à 6 mois, pour gérer le temps d'exécution et l'utilisation de l'API. Le script utilise le filtre updated_since pour une meilleure efficacité.
Version de l'Endpoint API : Le script est conçu pour l'API Freshdesk v2. Assurez-vous que votre compte est compatible avec cette version.
Considérations de Performance : Le script est soumis aux limites de taux (rate limits) de l'API Freshdesk. Un mécanisme de délai intégré empêche de dépasser ces limites, mais cela signifie que l'extraction de grands volumes de data sera lente. Pour des chargements historiques complets couvrant plusieurs années, envisagez d'exécuter le script par lots ou pendant les heures creuses.
Données Incluses : Le script est configuré pour récupérer les tickets et leurs conversations associées. Le paramètre include=stats est utilisé pour récupérer efficacement les métadonnées comme les temps de résolution et de réponse.

a Exemple de requête python

import requests
import pandas as pd
import time
import datetime
import re

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Freshdesk domain
DOMAIN = class="hl-string">'[your_domain].freshdesk.com'
class=class="hl-string">"hl-comment"># Replace with your Freshdesk API Key
API_KEY = class="hl-string">'[your_api_key]'
class=class="hl-string">"hl-comment"># Set the start date for the extraction in class="hl-string">'YYYY-MM-DD' format.
START_DATE_STR = class="hl-string">'2023-01-01'

BASE_URL = fclass="hl-string">'https://{DOMAIN}/api/v2'
AUTH = (API_KEY, class="hl-string">'X')

def make_api_request(url, params=None):
    class="hl-string">"""Makes a GET request to the Freshdesk API, handling rate limits."""
    while True:
        try:
            response = requests.get(url, auth=AUTH, params=params)
            response.raise_for_status()
            return response
        except requests.exceptions.HTTPError as err:
            if err.response.status_code == 429:
                retry_after = int(err.response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                time.sleep(retry_after)
            else:
                print(fclass="hl-string">"HTTP Error: {err}")
                return None
        except requests.exceptions.RequestException as err:
            print(fclass="hl-string">"Request Error: {err}")
            return None

def parse_iso_timestamp(ts):
    class="hl-string">"""Parses Freshdesk's ISO 8601 timestamp string."""
    if not ts or not isinstance(ts, str):
        return None
    return datetime.datetime.strptime(ts, class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

def get_freshdesk_event_log(start_date):
    class="hl-string">"""Fetches and processes Freshdesk tickets to create an event log."""
    events = []
    page = 1
    
    class=class="hl-string">"hl-comment"># Convert start_date to the required format for the API query
    start_datetime = datetime.datetime.strptime(start_date, class="hl-string">'%Y-%m-%d')
    query_date = start_datetime.strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

    while True:
        print(fclass="hl-string">"Fetching tickets page {page}...")
        tickets_url = fclass="hl-string">'{BASE_URL}/tickets'
        class=class="hl-string">"hl-comment"># Use class="hl-string">'updated_since' for incremental loads. For a full load, consider filtering by class="hl-string">'created_at'.
        params = {class="hl-string">'page': page, class="hl-string">'per_page': 100, class="hl-string">'order_by': class="hl-string">'updated_at', class="hl-string">'order_type': class="hl-string">'asc', class="hl-string">'updated_since': query_date, class="hl-string">'include': class="hl-string">'stats,requester'}
        
        response = make_api_request(tickets_url, params=params)
        if not response:
            break
            
        tickets_data = response.json()
        if not tickets_data:
            print(class="hl-string">"No more tickets found.")
            break

        for ticket in tickets_data:
            ticket_id = ticket[class="hl-string">'id']
            created_at = parse_iso_timestamp(ticket[class="hl-string">'created_at'])
            resolved_at = parse_iso_timestamp(ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'resolved_at'))
            
            resolution_time_hours = (resolved_at - created_at).total_seconds() / 3600 if resolved_at and created_at else None

            common_attrs = {
                class="hl-string">'ServiceRequest': ticket_id,
                class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                class="hl-string">'AssignedAgent': ticket.get(class="hl-string">'responder_id'),
                class="hl-string">'ResolutionTime': resolution_time_hours
            }
            
            class=class="hl-string">"hl-comment"># 1. Ticket Created
            events.append({
                **common_attrs,
                class="hl-string">'Activity': class="hl-string">'Ticket Created',
                class="hl-string">'EventTime': created_at.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                class="hl-string">'Status': class="hl-string">'Open' 
            })
            
            class=class="hl-string">"hl-comment"># 2. First Response Sent
            first_responded_at = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'first_responded_at')
            if first_responded_at:
                events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'First Response Sent',
                    class="hl-string">'EventTime': parse_iso_timestamp(first_responded_at).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': ticket.get(class="hl-string">'status')
                })

            class=class="hl-string">"hl-comment"># Fetch conversations for detailed activities
            conv_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/conversations'
            conv_response = make_api_request(conv_url)
            if conv_response:
                conversations = conv_response.json()
                for conv in conversations:
                    event_time = parse_iso_timestamp(conv[class="hl-string">'created_at']).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
                    
                    class=class="hl-string">"hl-comment"># 3. Customer Responded vs 4. Internal Note Added
                    if conv[class="hl-string">'source_type'] == class="hl-string">'note':
                        if conv.get(class="hl-string">'private', False):
                            events.append({
                                **common_attrs,
                                class="hl-string">'Activity': class="hl-string">'Internal Note Added',
                                class="hl-string">'EventTime': event_time,
                                class="hl-string">'Status': ticket.get(class="hl-string">'status')
                            })
                        else: class=class="hl-string">"hl-comment"># System generated notes for status changes etc.
                            body_text = conv.get(class="hl-string">'body_text', class="hl-string">'')
                            class=class="hl-string">"hl-comment"># 5. Status Changed to Pending
                            if class="hl-string">'Status changed from' in body_text and class="hl-string">'to Pending' in body_text:
                                events.append({**common_attrs, class="hl-string">'Activity': class="hl-string">'Status Changed to Pending', class="hl-string">'EventTime': event_time, class="hl-string">'Status': class="hl-string">'Pending'})
                            class=class="hl-string">"hl-comment"># 6. Ticket Assigned / Reassigned
                            if class="hl-string">'Assigned to' in body_text:
                                activity_name = class="hl-string">'Ticket Assigned' if any(e[class="hl-string">'Activity'] == class="hl-string">'Ticket Assigned' for e in events if e[class="hl-string">'ServiceRequest'] == ticket_id) else class="hl-string">'Ticket Reassigned'
                                events.append({**common_attrs, class="hl-string">'Activity': activity_name, class="hl-string">'EventTime': event_time, class="hl-string">'Status': ticket.get(class="hl-string">'status')})
                            class=class="hl-string">"hl-comment"># 7. Ticket Priority Changed
                            if class="hl-string">'Priority changed from' in body_text:
                                events.append({**common_attrs, class="hl-string">'Activity': class="hl-string">'Ticket Priority Changed', class="hl-string">'EventTime': event_time, class="hl-string">'Status': ticket.get(class="hl-string">'status')})
                            class=class="hl-string">"hl-comment"># 8. Satisfaction Survey Sent
                            if class="hl-string">'Satisfaction Survey was sent to the contact' in body_text:
                                events.append({**common_attrs, class="hl-string">'Activity': class="hl-string">'Satisfaction Survey Sent', class="hl-string">'EventTime': event_time, class="hl-string">'Status': ticket.get(class="hl-string">'status')})
                    else: class=class="hl-string">"hl-comment"># Not a note, so it's a reply
                        class=class="hl-string">"hl-comment"># 9. Customer Responded
                        if conv.get(class="hl-string">'incoming', False):
                            events.append({
                                **common_attrs,
                                class="hl-string">'Activity': class="hl-string">'Customer Responded',
                                class="hl-string">'EventTime': event_time,
                                class="hl-string">'Status': class="hl-string">'Open' class=class="hl-string">"hl-comment"># Typically a customer response re-opens the ticket
                            })
            
            class=class="hl-string">"hl-comment"># 10. SLA Breached
            if ticket.get(class="hl-string">'fr_escalated', False) or ticket.get(class="hl-string">'resolution_escalated', False):
                 breach_time = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'status_updated_at', ticket.get(class="hl-string">'updated_at'))
                 events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'SLA Breached',
                    class="hl-string">'EventTime': parse_iso_timestamp(breach_time).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': ticket.get(class="hl-string">'status')
                })

            class=class="hl-string">"hl-comment"># 11. Ticket Resolved
            if resolved_at:
                events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'Ticket Resolved',
                    class="hl-string">'EventTime': resolved_at.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': class="hl-string">'Resolved'
                })

            class=class="hl-string">"hl-comment"># 12. Ticket Reopened
            reopened_at = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at')
            if reopened_at:
                events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'Ticket Reopened',
                    class="hl-string">'EventTime': parse_iso_timestamp(reopened_at).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': class="hl-string">'Open'
                })
                
            class=class="hl-string">"hl-comment"># 13. Ticket Closed
            closed_at = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'closed_at')
            if closed_at:
                events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'Ticket Closed',
                    class="hl-string">'EventTime': parse_iso_timestamp(closed_at).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': class="hl-string">'Closed'
                })

        page += 1

    class=class="hl-string">"hl-comment"># Create DataFrame and sort by time
    df = pd.DataFrame(events)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequest', class="hl-string">'EventTime']).reset_index(drop=True)
    df[class="hl-string">'EventTime'] = df[class="hl-string">'EventTime'].dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

    return df

if __name__ == class="hl-string">'__main__':
    print(class="hl-string">"Starting Freshdesk data extraction...")
    event_log_df = get_freshdesk_event_log(START_DATE_STR)
    if not event_log_df.empty:
        output_filename = class="hl-string">'freshdesk_event_log.csv'
        event_log_df.to_csv(output_filename, index=False)
        print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")
    else:
        print(class="hl-string">"No data extracted.")

Étapes

Connectez-vous à votre instance Freshdesk avec un compte Administrateur disposant des autorisations de visualisation et d'exportation des tickets.
Naviguez vers l'onglet principal Tickets depuis le menu de navigation de gauche pour afficher la liste des tickets.
Utilisez le panneau Filtrer les tickets à droite pour définir la portée de votre extraction de data. Au minimum, définissez une plage de dates de Création, par exemple, les 6 derniers mois. Vous pouvez ajouter d'autres filtres comme Group, Agent ou Source pour affiner le jeu de data.
Une fois les filtres appliqués, cliquez sur l'icône Exporter, qui ressemble à une flèche pointant vers le bas dans un plateau, située en haut à droite de la liste des tickets.
Dans la fenêtre contextuelle Exporter les tickets, sélectionnez les champs que vous souhaitez inclure. Assurez-vous de sélectionner tous les champs par défaut et personnalisés pertinents nécessaires au event log, y compris : ID du Ticket, Created at, Resolved at, Closed at, First responded at, Agent, Group, Statut, Priority, Type, et tout autre champ personnalisé qui pourrait être utile.
Confirmez votre sélection. Freshdesk commencera à traiter l'exportation en arrière-plan. Vous recevrez un e-mail contenant un lien pour télécharger les data sous forme de fichier CSV. Cela peut prendre un certain temps pour les grands jeux de data.
Téléchargez le fichier CSV à partir du lien dans l'e-mail.
Le fichier exporté contient une ligne par ticket, représentant un instantané de l'état actuel du ticket et des horodatages clés. Pour créer un event log, vous devez transformer ces data.
Utilisez un script, comme le script Python fourni dans la section 'Query', ou un outil de préparation des data pour « dépivoter » les colonnes d'horodatage (Created at, First responded at, Resolved at, Closed at) en lignes séparées. Chaque nouvelle ligne représentera une seule activity.
Mappez les colonnes d'horodatage d'origine à des noms d'Activity spécifiques, par exemple, mappez la colonne 'Created at' à l'activity 'Ticket Created'.
Générez le event log CSV final avec les colonnes requises : ServiceRequest, Activity et EventTime, ainsi que tous les autres attributes recommandés.
Enregistrez le fichier transformé au format CSV, adapté pour l'importation dans votre outil de Process Mining.

Configuration

Autorisations : Nécessite le rôle d'Administrateur ou un rôle personnalisé avec les autorisations nécessaires pour consulter et exporter les tickets du compte.
Filtre de Plage de Dates : Il est crucial de définir une plage de dates en utilisant les champs de temps 'Créé' ou 'Fermé' pour éviter d'exporter l'historique complet, ce qui peut être très lent. Une période de 3 à 6 mois est généralement recommandée pour une analyse initiale.
Champs des Tickets : Dans la boîte de dialogue d'exportation, vous avez la possibilité de sélectionner les champs à inclure. Assurez-vous de sélectionner tous les champs d'horodatage disponibles, tels que Created at, First responded at, Resolved at, et Closed at, car ils constituent la base du event log. Incluez également les champs d'identification comme Ticket ID et les champs de contexte comme Agent, Group, Priority, et Type.
Volume des Données : Les exportations sont limitées en nombre de tickets pouvant être exportés en une seule fois, généralement 30 000 tickets. Pour des jeux de data plus importants, vous devrez peut-être effectuer plusieurs exportations en divisant la plage de temps en segments plus petits, par exemple, mois par mois.
Livraison : L'exportation est un processus asynchrone. Le fichier CSV n'est pas téléchargé directement, mais est envoyé sous forme de lien de téléchargement à l'adresse e-mail de l'utilisateur qui a initié l'exportation.

a Exemple de requête config

### Part 1: Freshdesk Export Configuration

This process uses the user interface for extraction. In the **Export Tickets** dialog, configure the following settings:

```json
{
  "filter_by": {
    "created": "[Specify Date Range, e.g., Last 6 Months]",
    "status": ["Open", "Pending", "Resolved", "Closed"],
    "// additional_filters": "Optionally filter by Group, Agent, Type, etc."
  },
  "export_fields": [
    "Ticket ID",
    "Created at",
    "First responded at",
    "Resolved at",
    "Closed at",
    "Group",
    "Agent",
    "Status",
    "Priority",
    "Type",
    "// include_custom_fields": "[Select any relevant custom fields]"
  ]
}
```

### Part 2: Data Transformation Script (Python with Pandas)

The exported CSV is a snapshot and must be transformed into an event log. The following script reshapes the data to create a row for each key activity.

```python
import pandas as pd

# --- Configuration ---
# Replace with the actual path to your downloaded Freshdesk CSV export
input_csv_path = 'freshdesk_export.csv'
output_csv_path = 'freshdesk_event_log.csv'

# --- Load Data ---
def transform_freshdesk_export(file_path):
    """Loads the Freshdesk export and transforms it into an event log."""
    try:
        df_raw = pd.read_csv(file_path)
    except FileNotFoundError:
        print(f"Error: The file {file_path} was not found.")
        return None

    # --- Rename and Select Columns ---
    # Adjust column names based on your specific export file
    column_mapping = {
        'Ticket ID': 'ServiceRequest',
        'Agent': 'AssignedAgent',
        'Type': 'ServiceRequestType',
        'Status': 'Status',
        'Priority': 'Priority',
        'Created at': 'Time_Ticket_Created',
        'First responded at': 'Time_First_Response_Sent',
        'Resolved at': 'Time_Ticket_Resolved',
        'Closed at': 'Time_Ticket_Closed'
    }
    df = df_raw.rename(columns=column_mapping)

    # Define the columns that are common to all events for a given ticket
    base_columns = ['ServiceRequest', 'AssignedAgent', 'ServiceRequestType', 'Status', 'Priority']
    # Ensure all required base columns exist
    for col in base_columns:
        if col not in df.columns:
            df[col] = None # Add missing columns as null

    # --- Unpivot Timestamp Columns to Create Events ---
    events = []
    activity_map = {
        'Time_Ticket_Created': 'Ticket Created',
        'Time_First_Response_Sent': 'First Response Sent',
        'Time_Ticket_Resolved': 'Ticket Resolved',
        'Time_Ticket_Closed': 'Ticket Closed'
    }

    for time_col, activity_name in activity_map.items():
        if time_col in df.columns:
            # Select rows where the timestamp exists
            df_event = df[df[time_col].notna()].copy()
            if not df_event.empty:
                df_event['Activity'] = activity_name
                df_event['EventTime'] = pd.to_datetime(df_event[time_col])
                events.append(df_event[base_columns + ['Activity', 'EventTime']])

    if not events:
        print("No events could be generated. Please check your column names and data.")
        return None

    # --- Combine, Sort, and Finalize ---
    df_event_log = pd.concat(events, ignore_index=True)

    # Calculate Resolution Time (optional, as an attribute)
    if 'Time_Ticket_Created' in df.columns and 'Time_Ticket_Resolved' in df.columns:
        df_res_time = df[['ServiceRequest', 'Time_Ticket_Created', 'Time_Ticket_Resolved']].dropna()
        df_res_time['ResolutionTime'] = (pd.to_datetime(df_res_time['Time_Ticket_Resolved']) - pd.to_datetime(df_res_time['Time_Ticket_Created'])).dt.total_seconds() / 3600.0 # In hours
        df_event_log = df_event_log.merge(df_res_time[['ServiceRequest', 'ResolutionTime']], on='ServiceRequest', how='left')

    # Sort the event log for proper ordering
    df_event_log = df_event_log.sort_values(by=['ServiceRequest', 'EventTime'], ascending=[True, True])

    return df_event_log

# --- Execute Transformation ---
if __name__ == "__main__":
    event_log = transform_freshdesk_export(input_csv_path)
    if event_log is not None:
        event_log.to_csv(output_csv_path, index=False)
        print(f"Event log successfully created at: {output_csv_path}")
```

Votre `template` de `data` pour le service client

Votre `template` de `data` pour le service client

`Attributes` du service client

`Activities` du service client

Guides d'extraction

Exportation native des `data` de tickets Freshdesk en CSV

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l'API REST Freshdesk

Étapes

Configuration

a Exemple de requête python

Outil ETL tiers avec un connecteur Freshdesk

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Optimisez votre service client Freshdesk dès aujourd'hui

Votre template de data pour le service client

Votre template de data pour le service client

Attributes du service client

Activities du service client

Guides d'extraction

Exportation native des `data` de tickets Freshdesk en CSV

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l'API REST Freshdesk

Étapes

Configuration

a Exemple de requête python

Outil ETL tiers avec un connecteur Freshdesk

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimisez votre service client Freshdesk dès aujourd'hui

Votre `template` de `data` pour le service client

Votre `template` de `data` pour le service client

`Attributes` du service client

`Activities` du service client