Votre modèle de données de service client
Votre modèle de données de service client
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d’extraction pour Microsoft Dynamics 365 Customer Service
Attributs du service client
| Nom | Description | ||
|---|---|---|---|
|
Demande de service
ServiceRequest
|
Identifiant unique d’une demande de service client, également appelée dossier ou ticket. | ||
|
Description
La demande de service sert d’identifiant principal et relie toutes les activités associées à une même demande ou à un même problème client. Elle fait office de Case ID pour le Process Mining et garantit une vue complète et cohérente de chaque interaction client, de la création à la clôture. L’analyse par demande de service permet de suivre le parcours de bout en bout, de mesurer les délais de résolution et d’identifier les tendances parmi les dossiers similaires.
Pourquoi c’est important
Il s’agit du Case ID essentiel qui relie tous les événements associés au sein d’une même instance de processus et rend possible l’analyse du processus de bout en bout.
Où les obtenir
Il s’agit de la clé primaire de l’entité Case (incident) dans Microsoft Dynamics 365 Customer Service.
Exemples
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
Activité
ActivityName
|
Nom de l’événement métier précis qui s’est produit à un moment donné pour une demande de service. | ||
|
Description
Cet attribut décrit une étape ou une modification de statut au sein du processus de service client, comme « Case Created », « Agent Investigated Issue » ou « Case Resolved ». Ces activités constituent la base de la cartographie du processus et permettent de visualiser et d’analyser son déroulement. Associée à un horodatage, chaque activité forme un événement qui définit la séquence du processus.
Pourquoi c’est important
Les activités définissent les étapes du processus. L’analyse de leur séquence et de leur fréquence est fondamentale pour comprendre les flux de processus, identifier les écarts et repérer les goulots d’étranglement.
Où les obtenir
Généralement obtenu en associant les modifications de statut (« statuscode ») ou des événements précis provenant d’entités associées, telles que Tasks, Emails ou Phone Calls, à un nom d’activité standardisé.
Exemples
Dossier crééAgent ayant analysé le problèmeSolution proposée au clientDossier clôturé
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Horodatage de la dernière actualisation ou extraction des données depuis le système source. | ||
|
Description
Cet attribut indique à quel moment les données ont été extraites pour la dernière fois de Microsoft Dynamics 365. Il permet d’évaluer leur fraîcheur et est essentiel aux activités de reporting et de suivi. Il garantit que les utilisateurs connaissent l’actualité des données lorsqu’ils interprètent les Dashboards et les analyses.
Pourquoi c’est important
Informe les utilisateurs de la récence des données, un élément essentiel pour prendre des décisions métier rapides et précises à partir de l’analyse des processus.
Où les obtenir
Cette valeur est générée et apposée sur le jeu de données au moment de l’extraction.
Exemples
2023-10-27T08:00:00Z
|
|||
|
Heure de début
EventTime
|
Horodatage indiquant le moment où l’activité s’est produite. | ||
|
Description
Cet attribut enregistre la date et l’heure précises auxquelles une activité donnée a eu lieu. Il est essentiel pour ordonner correctement les événements et pour toutes les analyses temporelles, notamment le calcul des temps de cycle, des durées et des temps d’attente entre les activités. Un horodatage précis et cohérent est indispensable à l’intégrité de l’analyse de Process Mining.
Pourquoi c’est important
Cet horodatage ordonne les événements chronologiquement et permet tous les calculs fondés sur la durée, essentiels à l’analyse des performances et à l’identification des goulots d’étranglement.
Où les obtenir
Cela correspond à des champs tels que « createdon » ou « modifiedon » de l’entité Case (incident), ou à ceux d’entités d’activité associées, par exemple Email, Task ou Phone Call.
Exemples
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
Système source
SourceSystem
|
Identifie le système source à partir duquel les données ont été extraites. | ||
|
Description
Cet attribut précise l’origine des données d’événements. Pour ce processus, il identifie systématiquement Microsoft Dynamics 365 Customer Service comme source. Dans les environnements qui utilisent plusieurs systèmes, ce champ est essentiel pour distinguer les sources de données et garantir leur traçabilité.
Pourquoi c’est important
Fournit une traçabilité claire des données, essentielle à leur gouvernance et au diagnostic des incohérences, notamment dans les analyses combinant plusieurs systèmes.
Où les obtenir
Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données afin d’indiquer l’origine du jeu de données.
Exemples
Microsoft Dynamics 365 Customer Service
|
|||
|
Canal
Channel
|
Canal de communication par lequel la demande de service a été initiée. | ||
|
Description
Cet attribut identifie l’origine de l’interaction avec le client, par exemple Phone, E-mail, Web Portal ou Chat. Les différents canaux présentent souvent des flux de processus, des attentes clients et des niveaux de complexité distincts. L’analyse du processus par canal aide à optimiser les flux de travail propres à chaque canal et l’allocation des ressources.
Pourquoi c’est important
Fournit des analyses sur l’incidence des différents canaux de contact client sur l’efficacité du processus, le délai de résolution et la satisfaction client.
Où les obtenir
Correspond au champ « Case Origin » (« caseorigincode ») de l’entité Case (incident).
Exemples
TéléphoneE-mailWebChat
|
|||
|
Délai cible de résolution du SLA
SlaTargetResolutionTime
|
Délai cible convenu contractuellement pour résoudre la demande de service. | ||
|
Description
Cet attribut précise la durée cible dans laquelle une demande de service doit être résolue conformément au Service Level Agreement (SLA) en vigueur. Il sert de référence pour mesurer les performances réelles. Cette valeur est essentielle au Dashboard de suivi de la conformité au SLA et au calcul du KPI « Taux de conformité au SLA », en mettant en évidence les situations où le processus ne respecte pas les engagements de service.
Pourquoi c’est important
Il s’agit de la référence principale pour mesurer les performances du service au regard des engagements, et il permet directement d’analyser la conformité au SLA et les dépassements.
Où les obtenir
Cette valeur est définie dans la configuration du SLA de Dynamics 365 et associée à un dossier par l’intermédiaire des instances de KPI SLA.
Exemples
2592008640014400
|
|||
|
Motif du statut
StatusReason
|
Fournit une explication plus détaillée du statut actuel de la demande de service. | ||
|
Description
Alors qu’un dossier possède un statut général tel que « Actif » ou « Résolu », le motif du statut fournit un contexte plus précis, par exemple « Informations fournies » ou « Problème résolu ». Cet attribut est essentiel pour comprendre les nuances de la progression des dossiers et les raisons de cette progression. Il peut notamment distinguer les dossiers résolus avec succès de ceux annulés par le client, ce qui est indispensable à une analyse précise des résultats.
Pourquoi c’est important
Fournit une analyse détaillée du résultat d’un dossier et des raisons de ses changements de statut, permettant une étude plus précise des parcours de résolution et des causes profondes.
Où les obtenir
Correspond au champ « Status Reason » (« statuscode ») de l’entité Case (incident).
Exemples
En coursEn attenteProblème résoluInformations fournies
|
|||
|
Nom de l’agent
AgentName
|
Nom de l’agent du service client ou de l’utilisateur responsable de l’activité. | ||
|
Description
Cet attribut identifie l’agent ou l’utilisateur système précis qui a réalisé une activité, par exemple prendre un élément dans une file ou résoudre un dossier. Il est essentiel pour analyser les performances des agents, répartir la charge de travail et affecter les Ressources. Le suivi des activités au niveau de l’agent permet aux organisations d’identifier les meilleurs résultats, les besoins en formation et les déséquilibres de charge.
Pourquoi c’est important
Permet d’analyser les performances individuelles et collectives, contribue à équilibrer la charge de travail et met en évidence les possibilités d’accompagnement pour améliorer la qualité globale du service.
Où les obtenir
Correspond au champ « Owner » (« ownerid ») de l’entité Case (incident), qui renvoie à l’entité System User (« systemuser »).
Exemples
Alice SmithBob JohnsonSystème
|
|||
|
Nom du client
CustomerName
|
Nom du client ou du compte associé à la demande de service. | ||
|
Description
Cet attribut identifie le client à l’origine de la demande de service. Il permet d’analyser le processus du point de vue du client et de déterminer quels clients soumettent le plus de demandes, connaissent les délais de résolution les plus longs ou présentent les problèmes les plus complexes. Il est essentiel à la gestion de la relation client et à l’amélioration du service fourni à chaque client.
Pourquoi c’est important
Permet une analyse au niveau du client afin d’identifier les tendances, d’améliorer le service fourni aux comptes stratégiques et de comprendre le parcours client.
Où les obtenir
Il s’agit du champ de recherche « Customer » (« customerid ») de l’entité Case (incident), qui peut pointer vers un enregistrement Account ou Contact.
Exemples
Global Tech Inc.Jane DoeInnovate Solutions
|
|||
|
Priorité
Priority
|
Niveau de priorité attribué à la demande de service, indiquant son degré d’urgence. | ||
|
Description
Cet attribut définit le degré d’urgence d’une demande de service, généralement classé comme Faible, Normal, Élevé ou Urgent. La priorité sert à déterminer l’ordre de traitement des dossiers et définit souvent les objectifs du SLA. L’analyse de l’incidence de la priorité sur le flux du processus, l’affectation des Ressources et les délais de résolution est essentielle pour traiter rapidement les problèmes importants.
Pourquoi c’est important
Aide à déterminer si les demandes prioritaires sont traitées plus rapidement et respectent leurs objectifs, ainsi qu’à comprendre l’incidence des niveaux de priorité sur les performances globales du processus.
Où les obtenir
Correspond au champ « Priority » (« prioritycode ») de l’entité Case (incident).
Exemples
FaibleNormaleÉlevée
|
|||
|
Type de demande de service
ServiceRequestType
|
Catégorie ou classification principale de la demande de service. | ||
|
Description
Cet attribut catégorise la demande de service selon sa nature, par exemple « Demande de facturation », « Support technique » ou « Retour sur le produit ». Il est fondamental pour segmenter l’analyse du processus et comprendre la manière dont les différents types de demandes sont traités. L’analyse par type peut révéler que certaines catégories présentent des délais de résolution plus longs, des taux d’escalade plus élevés ou des parcours différents.
Pourquoi c’est important
Permet de segmenter le processus afin de faire apparaître les goulots d’étranglement propres à chaque type, les besoins en Ressources et les possibilités d’amélioration, tout en favorisant de meilleures stratégies d’acheminement et de traitement.
Où les obtenir
Ces informations sont souvent stockées dans le champ « Subject » (« subjectid ») ou dans un champ de catégorie personnalisé de l’entité Case (incident).
Exemples
Demande de facturationAssistance techniqueRetour sur le produitGestion des comptes
|
|||
|
Dépasse le SLA
IsSlaBreached
|
Indicateur calculé précisant si la demande de service a dépassé son objectif de SLA. | ||
|
Description
Cet indicateur booléen est déterminé en comparant le délai réel de résolution d’une demande de service à son « SLA Target Resolution Time ». Il prend la valeur true lorsque le délai réel est supérieur au délai cible. Cet attribut est fondamental pour le Dashboard de suivi de la conformité au SLA et pour le calcul du KPI « Taux de conformité au SLA », car il fournit un résultat binaire clair pour chaque dossier.
Pourquoi c’est important
Fournit un résultat clair de respect ou de non-respect du SLA pour chaque dossier, ce qui facilite le filtrage, l’agrégation et l’analyse des causes profondes des dépassements.
Où les obtenir
Calculé en comparant « ServiceRequestCycleTime » à « SlaTargetResolutionTime ».
Exemples
truefalse
|
|||
|
Équipe responsable
OwnerTeam
|
Équipe qui est actuellement responsable de la demande de service. | ||
|
Description
Cet attribut identifie l’équipe responsable de la demande de service. Une demande peut être attribuée à un agent individuel ou à une équipe, c’est-à-dire une file. L’analyse par équipe est essentielle pour comprendre les performances de chaque équipe, répartir la charge entre les différents niveaux ou domaines de spécialité du support et identifier les variations du processus entre les équipes.
Pourquoi c’est important
Permet d’analyser les performances au niveau de l’équipe, ce qui est essentiel pour gérer efficacement les niveaux de support et les groupes spécialisés.
Où les obtenir
Dérivé du champ « Owner » (« ownerid ») de l’entité Case (incident) lorsque le responsable est un enregistrement Team et non un System User.
Exemples
Assistance de niveau 1Service de facturationSpécialistes techniques
|
|||
|
Est escaladé
IsEscalated
|
Indicateur précisant si la demande de service a été escaladée. | ||
|
Description
Cet attribut booléen indique si une demande de service a fait l’objet d’une escalade. Les escalades se produisent lorsque le support de premier niveau ne parvient pas à résoudre un problème et qu’une équipe plus expérimentée ou un spécialiste doit intervenir. Le suivi de cet indicateur est essentiel au Dashboard des parcours d’escalade internes et au KPI « Taux d’escalade interne », car il aide à identifier les causes profondes des escalades et les faiblesses des premiers niveaux de support.
Pourquoi c’est important
Mesure directement la fréquence des escalades, met en évidence les problèmes de résolution au premier contact et indique les domaines nécessitant une amélioration des processus ou des compétences des agents.
Où les obtenir
Correspond au champ « Is Escalated » (« isescalated ») de l’entité Case (incident).
Exemples
truefalse
|
|||
|
ID de l’article de la base de connaissances
KnowledgeArticleId
|
Identifiant d’un article de la base de connaissances associé à la demande de service. | ||
|
Description
Cet attribut enregistre l’ID de tout article de la base de connaissances utilisé ou associé lors de la résolution d’une demande de service. Il fournit une mesure directe de l’utilisation de la base de connaissances par les agents pour résoudre les problèmes des clients. Ces données sont essentielles au Dashboard d’utilisation des articles de la base de connaissances et au KPI associé, qui permettent d’évaluer la valeur et l’exhaustivité de la base de connaissances.
Pourquoi c’est important
Suit l’utilisation de la base de connaissances et aide à déterminer si les agents utilisent les Ressources disponibles pour résoudre les problèmes plus rapidement et de manière plus cohérente.
Où les obtenir
Ces informations se trouvent dans la relation entre les entités Case (incident) et Knowledge Article (knowledgearticle).
Exemples
KA-01337KA-02048
|
|||
|
Produit concerné
ProductInvolved
|
Produit associé à la demande de service du client. | ||
|
Description
Cet attribut identifie le produit ou service précis concerné par le problème du client. Il permet de segmenter le processus de service par produit et de déterminer si certains produits génèrent davantage de demandes de support, présentent des problèmes plus complexes ou nécessitent des compétences spécialisées. Cette analyse contribue à l’amélioration des produits et à la planification des Ressources.
Pourquoi c’est important
Permet une analyse du processus par produit afin d’identifier les problèmes récurrents, d’améliorer la documentation de support et d’affecter efficacement les Ressources spécialisées.
Où les obtenir
Correspond au champ de recherche « Product » (« productid ») de l’entité Case (incident).
Exemples
Imprimante Alpha-100Zeta CRM SoftwareOmega Data Plan
|
|||
|
Reprise
IsRework
|
Indicateur calculé précisant si un dossier a comporté des activités de reprise. | ||
|
Description
Cet indicateur booléen identifie les dossiers qui contiennent des boucles de reprise ou des activités répétées, par exemple plusieurs événements « Information Requested From Customer » ou un événement « Case Reactivated » après une résolution. Il est calculé en analysant la séquence des activités afin de repérer les schémas révélant une inefficacité ou l’échec de la résolution dès la première intervention. Cet attribut est essentiel au Dashboard d’analyse des reprises et des contacts répétés.
Pourquoi c’est important
Aide à quantifier et à isoler les inefficacités du processus, afin de permettre aux analystes de se concentrer sur les causes profondes du travail répété et des efforts inutiles.
Où les obtenir
Calculé en détectant des séquences d’activités précises, par exemple Resolved -> Reactivated, ou des activités répétées au sein d’un dossier à l’aide des analyses de Process Mining.
Exemples
truefalse
|
|||
|
Résolution au premier contact
IsFirstContactResolution
|
Indicateur précisant si la demande a été résolue lors du premier contact. | ||
|
Description
Cet attribut calculé identifie les demandes de service résolues sans interaction de suivi avec le client ni retard important nécessitant une réattribution à un agent. La définition précise de la logique peut être complexe, mais elle consiste généralement à vérifier un temps de cycle court et l’absence de réouverture ou de nouvelles demandes du client après l’interaction initiale. Il constitue la base du KPI « Taux de résolution au premier contact ».
Pourquoi c’est important
Il s’agit d’une mesure essentielle de l’efficacité du service et de la satisfaction client, car elle met en évidence la capacité à résoudre rapidement et complètement les problèmes.
Où les obtenir
Calculé à partir de la séquence et du calendrier des activités dans l’Event Log de chaque dossier.
Exemples
truefalse
|
|||
|
Score CSAT
CustomerSatisfactionScore
|
Score de satisfaction fourni par le client après la résolution du dossier. | ||
|
Description
Cet attribut contient l’évaluation numérique ou catégorielle issue d’une enquête de satisfaction client (CSAT), généralement recueillie après la clôture d’une demande de service. Il mesure directement la perception qu’a le client de la qualité du service. Ces données sont essentielles au Dashboard des tendances de satisfaction client et au KPI « Score CSAT moyen après résolution », qui relient les performances du processus aux résultats obtenus pour le client.
Pourquoi c’est important
Fournit une mesure directe de la satisfaction client et permet à l’organisation de mettre en relation les comportements du processus avec le ressenti des clients afin d’améliorer le service.
Où les obtenir
Provient généralement d’une entité d’enquête associée, telle que Customer Voice, puis est relié à l’entité Case (incident).
Exemples
5341
|
|||
Activités du service client
| Activité | Description | ||
|---|---|---|---|
|
Dossier attribué
|
Cette activité représente l’attribution d’un dossier à une file d’attente ou à un utilisateur précis pour traitement. Le système enregistre explicitement les changements de propriétaire du dossier, qui peuvent être suivis dans les journaux d’audit du système. | ||
|
Pourquoi c’est important
Le suivi des attributions est essentiel pour analyser la répartition de la charge de travail, identifier les retards liés à l’attribution et comprendre l’efficacité de l’orientation. Il permet notamment de déterminer à quelle vitesse les dossiers sont dirigés vers la bonne équipe ou la bonne personne.
Où les obtenir
L’événement est capturé en suivant les modifications du champ « ownerid » sur l’entité « Incident ». L’horodatage de la modification est disponible dans les journaux d’historique d’audit.
Collecte
Extrayez des journaux d’audit les modifications horodatées du champ « ownerid ».
Type d’événement
explicit
|
|||
|
Dossier clôturé
|
Il s’agit de la clôture administrative finale de l’enregistrement du dossier, qui peut intervenir en même temps que la résolution ou ultérieurement. Cette activité est capturée par une modification de l’état du dossier vers « Closed ». | ||
|
Pourquoi c’est important
Elle représente la fin absolue du cycle de vie du processus dans le système. Le délai entre « Resolved » et « Closed » peut révéler une charge administrative ou des retards dans la finalisation des enregistrements.
Où les obtenir
Capturé par une modification du champ « statecode » de l’entité « Incident » vers « Canceled » (2) ou vers un état de clôture personnalisé. L’horodatage est disponible dans l’historique d’audit.
Collecte
Suivre l’horodatage du passage de « statecode » à son état terminal final, par exemple Canceled/Closed.
Type d’événement
explicit
|
|||
|
Dossier créé
|
Cette activité marque le début du processus de service client, lorsqu’un nouvel enregistrement de dossier est créé dans le système. Il s’agit d’un événement explicite, enregistré avec un horodatage précis au moment de la première sauvegarde de l’enregistrement de l’entité « Incident ». | ||
|
Pourquoi c’est important
En tant qu’événement de début principal, cette activité est essentielle pour calculer la durée globale du cycle de vie d’un dossier et comprendre les tendances du volume de dossiers. Elle sert de point d’ancrage à toutes les analyses ultérieures du processus.
Où les obtenir
Cet événement est capturé à partir de l’horodatage « createdon » de l’entité « Incident » (Case) pour chaque nouvel enregistrement.
Collecte
Utilisez l’horodatage « createdon » de l’enregistrement Incident.
Type d’événement
explicit
|
|||
|
Dossier escaladé
|
Représente l’escalade formelle d’un dossier vers un niveau de support supérieur ou une autre équipe. Il peut s’agir d’une action explicite de l’utilisateur, qui réattribue le dossier à une file d’escalade ou à un utilisateur désigné. | ||
|
Pourquoi c’est important
Le suivi des escalades est essentiel pour le KPI « Taux d’escalade interne » et pour identifier les causes profondes des problèmes que le support de premier niveau ne peut pas résoudre. Il met en évidence les faiblesses du processus et les besoins en formation.
Où les obtenir
Déduit d’une modification du champ « ownerid » vers une file d’escalade ou une équipe désignée. Il peut également s’agir d’une action personnalisée explicite qui signale que le dossier a été escaladé.
Collecte
Identifier une modification horodatée de « ownerid » vers une file d’escalade connue.
Type d’événement
inferred
|
|||
|
Dossier résolu
|
Il s’agit d’une étape clé qui correspond au moment où l’agent considère que le problème du client est traité. Cette action explicite dans Dynamics 365 crée un enregistrement d’activité « Case Resolution » associé au dossier. | ||
|
Pourquoi c’est important
En tant qu’événement de fin principal fondé sur la réussite, cette activité est essentielle au calcul des délais et des taux de résolution. Elle constitue un élément important de presque tous les KPI du service client.
Où les obtenir
Cet événement correspond à la création d’un enregistrement d’activité « Resolution » (« Case Resolution »). L’horodatage « actualend » de cet enregistrement indique l’heure de résolution.
Collecte
Utiliser l’horodatage « actualend » ou « createdon » de l’enregistrement d’activité « Resolution » associé.
Type d’événement
explicit
|
|||
|
Minuteur SLA démarré
|
Indique l’activation d’un minuteur d’accord de niveau de service (SLA) pour le dossier. Celui-ci commence à mesurer le temps par rapport à un indicateur de service défini, comme « First Response By » ou « Resolve By ». Il s’agit d’un événement explicite géré par le moteur SLA de Dynamics 365. | ||
|
Pourquoi c’est important
Cette activité est fondamentale pour suivre la Conformité aux SLA et comprendre à quel moment commence le délai associé aux engagements de service. Elle permet directement d’analyser si les objectifs de service sont atteints.
Où les obtenir
L’événement est enregistré dans l’entité « SLA KPI Instance », qui est liée à l’entité « Incident ». L’horodatage « createdon » de l’enregistrement SLA KPI Instance concerné marque le début.
Collecte
Utilisez l’horodatage de création de l’enregistrement « SLA KPI Instance » associé au dossier.
Type d’événement
explicit
|
|||
|
Agent ayant analysé le problème
|
Représente le travail actif de l’agent pour comprendre et diagnostiquer le problème du client. Il s’agit d’une activité déduite, souvent identifiée lorsque l’agent associe un article de connaissances au dossier, ce qui indique qu’une recherche a été effectuée. | ||
|
Pourquoi c’est important
Le suivi de cette activité permet de mesurer l’utilisation des ressources de connaissances et son impact sur les délais de résolution. Il indique si les agents utilisent les outils disponibles pour résoudre efficacement les problèmes.
Où les obtenir
L’événement est déduit de la création d’un enregistrement dans l’entité « IncidentKnowledgeBaseRecord », qui associe un article de connaissances à un dossier. L’horodatage de création de cet enregistrement est utilisé.
Collecte
Utilisez l’horodatage auquel un article de connaissances est associé à l’Incident.
Type d’événement
inferred
|
|||
|
Catégorisation du dossier modifiée
|
Cet événement se produit lorsqu’un agent modifie la catégorie ou l’objet d’un dossier après sa création initiale. Il s’agit d’une modification explicite suivie par la fonctionnalité d’audit du système. | ||
|
Pourquoi c’est important
Le suivi des recatégorisations est essentiel pour l’indicateur « Service Request Recategorization Rate ». Une fréquence élevée révèle des problèmes lors du tri initial, qui entraînent une mauvaise orientation et des retards.
Où les obtenir
L’événement est capturé dans l’historique d’audit de l’entité « Incident », en suivant notamment les modifications du champ « subjectid » ou d’autres champs de catégorisation personnalisés.
Collecte
Extrayez des journaux d’audit les modifications horodatées du champ « subjectid ».
Type d’événement
explicit
|
|||
|
Dossier réactivé
|
Se produit lorsqu’un dossier précédemment résolu est rouvert automatiquement ou manuellement, généralement parce que le client a répondu ou signalé que le problème n’était pas résolu. Il s’agit d’un comportement standard du système, qui fait passer le statut du dossier de « Résolu » à « Actif ». | ||
|
Pourquoi c’est important
Cette activité est essentielle pour identifier les reprises et analyser le « Taux de résolution au premier contact ». Un nombre élevé de réactivations indique que les solutions initiales sont incomplètes ou inefficaces.
Où les obtenir
Capturé par une modification du champ « statecode » de l’entité « Incident », qui passe de « Resolved » (1) à « Active » (0). L’horodatage de cette modification est enregistré dans l’historique d’audit.
Collecte
Suivre l’horodatage de la modification de « statecode » de Resolved à Active dans les journaux d’audit.
Type d’événement
explicit
|
|||
|
Élément de file d’attente pris en charge par un agent
|
Cet événement se produit lorsqu’un agent prend activement un dossier dans une file d’attente partagée pour commencer à le traiter. Il s’agit d’une action volontaire de l’utilisateur, distincte de l’attribution du dossier à la file d’attente par le système. | ||
|
Pourquoi c’est important
Cette activité permet de mesurer le temps réel pendant lequel un dossier attend dans une file d’attente avant qu’un agent commence à le traiter. Elle est essentielle pour identifier les goulots d’étranglement des files d’attente et comprendre la réactivité des agents.
Où les obtenir
L’événement est suivi lorsqu’un utilisateur renseigne le champ « workedbyid » de l’entité « QueueItem » associée au dossier, ou lorsque le propriétaire du dossier passe d’une file d’attente à un utilisateur.
Collecte
Identifiez l’horodatage auquel le champ « workedbyid » de QueueItem est renseigné.
Type d’événement
explicit
|
|||
|
Enquête de satisfaction envoyée
|
Indique l’envoi d’une enquête de satisfaction client, généralement déclenché automatiquement après la résolution d’un dossier. Cette activité est habituellement capturée sous la forme d’un e-mail sortant ou d’une activité d’enquête Customer Voice. | ||
|
Pourquoi c’est important
Cette activité relie le processus opérationnel aux résultats de l’expérience client. Elle permet d’analyser les scores de satisfaction dans le contexte du parcours suivi par le dossier.
Où les obtenir
Déduit de la création d’une activité « Email » sortante contenant un lien vers l’enquête, ou d’un enregistrement d’activité « Customer Voice survey invite » associé au dossier.
Collecte
Utiliser l’horodatage de création de l’enregistrement d’activité associé à l’enquête.
Type d’événement
inferred
|
|||
|
Informations demandées au client
|
Cette activité marque le moment où l’agent a besoin d’informations supplémentaires de la part du client pour poursuivre le traitement. Elle est souvent déduite du passage du statut du dossier à un état d’attente ou de l’envoi d’un e-mail sortant depuis la chronologie du dossier. | ||
|
Pourquoi c’est important
Cette activité est essentielle pour mesurer les retards liés au client et comprendre l’indicateur « Customer Information Wait Time ». Elle permet d’isoler le temps du processus consacré à l’attente d’informations externes.
Où les obtenir
L’événement peut être déduit d’une modification du champ « statuscode » de l’entité « Incident » vers une valeur telle que « On Hold », avec le motif « Waiting for Customer ». L’horodatage de cette modification de statut est utilisé.
Collecte
Suivez l’horodatage d’une modification de statuscode vers un état désigné « waiting for customer ».
Type d’événement
inferred
|
|||
|
Solution proposée au client
|
Cette activité indique que l’agent a formulé une solution et l’a communiquée au client. Elle est généralement déduite d’un e-mail sortant envoyé depuis la chronologie du dossier ou d’un changement de statut vers « En attente de confirmation du client ». | ||
|
Pourquoi c’est important
Cette étape marque le passage de l’investigation à la résolution. L’analyse du délai entre la proposition et la confirmation d’une solution peut révéler des retards dans la réponse du client ou des problèmes liés aux correctifs proposés.
Où les obtenir
Peut être déduite de l’horodatage d’une activité « Email » sortante associée au dossier ou d’une modification de « statuscode » vers un état préalable à la résolution.
Collecte
Utiliser l’horodatage d’une activité e-mail sortante ou d’un changement de statut vers « Solution proposée ».
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à commencer ?
Utilisez ce modèle de données pour commencer votre démarche de Process Mining et réaliser de nouveaux gains d’efficacité dans vos opérations de service client. Commencez dès aujourd’hui à optimiser vos flux de travail pour améliorer l’expérience client.
Optimisez votre service client : augmentez le FCR et réduisez vos coûts dès maintenant
Identifiez les goulots d’étranglement et atteignez 80 % de résolution au premier contact pour des clients plus satisfaits.
Aucune carte bancaire requise. La configuration ne prend que quelques minutes.