Votre modèle de données de service client

Microsoft Dynamics 365 Customer Service
Votre modèle de données de service client

Votre modèle de données de service client

Ce modèle propose une méthode structurée pour recueillir les données essentielles nécessaires à une analyse approfondie de votre processus de service client. Il présente les attributs importants à collecter, les activités clés à suivre et des conseils pour extraire efficacement ces informations.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d’extraction pour Microsoft Dynamics 365 Customer Service
Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Attributs du service client

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser complètement votre processus de service client.
5 Obligatoire 7 Recommandé 8 Facultatif
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
Obligatoire Recommandé Facultatif

Activités du service client

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour permettre une découverte et une optimisation précises du service client.
6 Recommandé 7 Facultatif
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
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Microsoft Dynamics 365 Customer Service

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.

Démarrer l’essai gratuit

Aucune carte bancaire requise. La configuration ne prend que quelques minutes.