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

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

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

Ce modèle fournit un guide détaillé 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
Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributes du service client

Ce sont les champs de données recommandés à inclure dans votre `journal d'événements` pour une analyse complète du service client et pour obtenir des analyses approfondies.
3 Obligatoire 4 Recommandé 12 Facultatif
Nom Descriptionn
Activité
Activity
Le nom d'un `event` commercial ou d'une étape spécifique survenue dans le processus de service client.
Descriptionn

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 cartographie des processus.

L'analyse de la séquence et de la fréquence de ces activités constitue le fondement du Process Mining. Elle permet de visualiser les flux de processus, d'identifier les chemins courants et rares, et de détecter les écarts par rapport à la procédure opérationnelle standard. Comprendre les activités est impératif pour identifier les inefficacités, les boucles de rework comme 'Ticket Rouvert' ou les problèmes de conformité.

Pourquoi est-ce important ? :

Cet attribut définit les étapes de la cartographie des processus, pour visualiser et l'analyse du flux de processus complet.

Source des données :

Dérivé des types d'event dans 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`.
Descriptionn

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 indispensable pour reconstruire le parcours complet 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 points de blocage affectant les case individuels.

Pourquoi est-ce important ? :

C'est l'ID de Case essentiel qui relie tous les events connexes en une seule instance de processus, permettant une vision globale de chaque parcours de service client.

Source des données :

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.
Descriptionn

Event Time, ou l'horodatage (horodatage), enregistre la date et l'heure exactes auxquelles une activity a eu lieu. C'est un élément clé 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 (horodatage) 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 points de blocage. Des horodatages précis sont essentiels pour comprendre la performance du processus et identifier les retards.

Pourquoi est-ce important ? :

Ce horodatage est indispensable 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.

Source des données :

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`.
Descriptionn

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 indispensable 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 est-ce important ? :

Permet l'analyse de la performance par agent individuel, aidant à identifier les meilleurs collaborateurs les plus performants, les opportunités de formation et l'impact des réaffectations.

Source des données :

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
Priorité
Priority
Le niveau de priorité attribué à la demande de service, tel que 'Faible', 'Moyen', 'Élevé' ou 'Urgent'.
Descriptionn

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 indispensable pour analyser la conformité SLA et l'allocation des ressources. En filtrant la cartographie 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 est-ce important ? :

Primordial pour l'analyse des SLA et pour comprendre si les ressources sont correctement allouées.rectement allouées pour traiter les problèmes de haute priorité plus rapidement que ceux de faible priorité.

Source des données :

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é'.
Descriptionn

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 indispensable 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 points de blocage. 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 est-ce important ? :

Le suivi des changements de status est indispensable 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'.

Source des données :

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é'.
Descriptionn

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 indispensablele pour identifier les points de blocage spécifiques à chaque type et optimiser les workflows en conséquence.

Pourquoi est-ce 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.

Source des données :

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'.
Descriptionn

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 à améliorer 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 est-ce 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.

Source des données :

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
L'horodatage indiquant la dernière fois que les données ont été actualisées à partir du système source.
Descriptionn

Cet attribut enregistre la date et l'heure de la dernière extraction ou mise à jour du jeu de data depuis Freshdesk. Il permet de vérifier la fraîcheur des data analysées, ce qui est indispensable pour prendre des décisions stratégiques au bon moment 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 métadonnée clé pour tout tableau de bord ou rapport de Process Mining, garantissant que les parties prenantes sont conscientes de la récence des data.

Pourquoi est-ce important ? :

Indique la fraîcheur des data, garantissant que les analyses et les décisions sont basées sur des informations à jour.

Source des données :

Ceci est un champ de métadonnées généré pendant le processus d'extraction de data, capturant le horodatage de l'extraction de data.

Exemples
2023-12-01T08:00:00Z
Groupe assigné
AssignedGroup
L'équipe ou le département auquel la demande de service est affectée.
Descriptionn

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 indispensablele pour optimiser les structures d'équipe et les workflows.

Pourquoi est-ce important ? :

Permet une analyse de la performance au niveau de l'équipe ou du département, mettant en évidence les transferts et identifiant les points de blocage spécifiques aux groupes.

Source des données :

Ceci correspond au champ 'group_id' dans l'objet 'Tickets' de Freshdesk.

Exemples
Support L1Support technique L2FacturationSuccès client
Incident rouvert
IsReopened
Un indicateur booléen signalant si une demande de service résolue a été rouverte.
Descriptionn

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 est-ce important ? :

Identifie les cases qui ont nécessité un reprises, 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.

Source des données :

Champ calculé. Défini à vrai (true) pour un Service Request si un event avec Activity = 'Ticket Reopened' existe pour ce case.

Exemples
truefaux
Nom du client
CustomerName
Le nom ou l'ID du client qui a initié la demande de service.
Descriptionn

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 essentiel pour comprendre le parcours client complet à travers plusieurs demandes de service.

Pourquoi est-ce important ? :

Permet une vue de processus orientée client, aidant à identifier les demandeurs fréquents ou les clients rencontrant des problèmes récurrents.

Source des données :

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.
Descriptionn

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 est-ce 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.

Source des données :

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.
Descriptionn

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 est-ce 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.

Source des données :

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 dépassé
IsSlaBreached
Un indicateur booléen signalant si le temps de résolution de la demande de service a dépassé la cible `SLA`.
Descriptionn

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 contribue directement au le tableau de bord et le KPI 'Aperçu de la conformité SLA'.

Pourquoi est-ce 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.

Source des données :

Ceci est un champ calculé, dérivé en comparant le horodatage 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`.
Descriptionn

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 impératif pour maintenir l'intégrité des data et renforcer la confiance dans l'analyse.

Pourquoi est-ce important ? :

Fournit un contexte essentiel sur l'origine des data, ce qui est impératif pour la gouvernance des data et lors de la combinaison de data provenant de plusieurs systèmes sources.

Source des données :

Il s'agit d'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.
Descriptionn

Le Taux de satisfaction est une indicateur de résultat majeur, 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 est-ce 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.

Source des données :

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.
Descriptionn

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 (horodatage) 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 est-ce 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.

Source des données :

Champ calculé. C'est la durée entre l'horodatage (horodatage) 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.
Descriptionn

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 est-ce important ? :

Fournit la base pour mesurer la conformité SLA, un indicateur clé de performance pour toute organisation de service client.

Source des données :

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

Activités (Activities) du service client

Ce sont les étapes clés du processus et les jalons importants à capturer dans votre `journal d'événements` pour une découverte précise des processus et l'identification des `points de blocage`.
5 Recommandé 8 Facultatif
Activité Descriptionn
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 est-ce 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.

Source des données :

Ceci est un event spécifique que Freshdesk suit à des fins de SLA. Il correspond au horodatage 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 est-ce important ? :

Le suivi des affectations est impératif 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.

Source des données :

Capturé à partir du log des 'Ticket Activités (Activities)' où les modifications des champs 'Agent' ou 'Group' sont enregistrées avec un horodatage.

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 est-ce 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 complet.

Source des données :

Capturé à partir du log des 'Ticket Activités (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 est-ce 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.

Source des données :

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 est-ce 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.

Source des données :

Capturé à partir du log des 'Ticket Activités (Activities)', qui enregistre le changement de statut spécifique à 'Resolved' ainsi qu'un horodatage.

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 est-ce 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 indispensablele pour l'« Analyse de la réouverture des tickets » et l'amélioration de la résolution au premier contact.

Source des données :

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 est-ce important ? :

Cette activité est indispensablele 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é.

Source des données :

Comptabilisé 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 est-ce 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.

Source des données :

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 est-ce 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.

Source des données :

Comptabilisé 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 est-ce 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.

Source des données :

Capturé à partir du log des 'Ticket Activités (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 est-ce important ? :

Cette activité contribue directement au 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 indispensable pour identifier les causes systémiques des retards.

Source des données :

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 horodatages 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 est-ce 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.

Source des données :

Capturé à partir du log des 'Ticket Activités (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 est-ce 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.

Source des données :

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