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

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

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

Ce modèle offre une approche structurée pour collecter les données essentielles nécessaires à une analyse détaillée de votre processus de service client. Il décrit les attributs essentiels à recueillir, les activités clés à suivre et fournit des conseils sur la façon d'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 ? 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 de votre processus de service client.
5 Obligatoire 7 Recommandé 8 Facultatif
Nom Descriptionn
Demande de service
ServiceRequest
L'identifiant unique d'une demande de service client, également connue sous le nom de cas ou de ticket.
Descriptionn

La Demande de Service sert d'identifiant principal, reliant toutes les activités liées à une seule demande ou problème client. Elle agit comme l'ID de Cas pour le Process Mining, assurant une vision globale 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 complet, de mesurer les temps de résolution et d'identifier des schémas entre des cas similaires.

Pourquoi est-ce important ? :

C'est l'identifiant de cas principal qui relie tous les événements connexes en une seule instance de processus, permettant l'analyse de processus complet.

Source des données :

Il s'agit de la clé primaire de l'entité Cas (incident) dans Microsoft Dynamics 365 Customer Service.

Exemples
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
Activité
ActivityName
Le nom de l'événement commercial spécifique qui s'est produit à un moment donné pour une demande de service.
Descriptionn

Cet attribut décrit une étape unique ou un changement de statut au sein du processus de service client, tel que « Cas créé », « Problème enquêté par l'agent » ou « Cas résolu ». Ces activités constituent l'pilier central de la carte de processus, pour visualiser et l'analyse du flux de processus. Chaque activité, lorsqu'elle est combinée avec un horodatage, crée un événement qui définit la séquence de processus.

Pourquoi est-ce important ? :

Les activités définissent les étapes du processus. L'analyse de la séquence et de la fréquence des activités est clée pour comprendre les flux de processus, identifier les écarts et trouver les points de blocage.

Source des données :

Généralement dérivé en mappant les changements de statut (statuscode) ou des événements spécifiques provenant d'entités connexes comme les Tâches, les E-mails ou les Appels téléphoniques à un nom d'activité standardisé.

Exemples
Dossier crééL'agent a enquêté sur le problèmeSolution proposée au clientDossier clos
Dernière mise à jour des données
LastDataUpdate
L'horodatage de la dernière actualisation ou extraction des données du système source.
Descriptionn

Cet attribut indique la date de la dernière extraction des données de Microsoft Dynamics 365. Il est utilisé pour comprendre la la réactualisation des données analysées et est indispensable à des fins de reporting et de suivi. Il garantit que les utilisateurs sont conscients de la réactualisation des données lors de l'interprétation des tableau de bords et des analyses.

Pourquoi est-ce important ? :

Informe les utilisateurs sur la la réactualisation des données, ce qui est indispensable à prendre des décisions commerciales rapides et pertinentes basées sur l'analyse des processus.

Source des données :

Cette valeur est générée et horodatée sur le jeu de données au moment de l'extraction des données.

Exemples
2023-10-27T08:00:00Z
Heure de début
EventTime
L'horodatage indiquant quand l'activité a eu lieu.
Descriptionn

Cet attribut consigne la date et l'heure précises auxquelles une activité spécifique a eu lieu. Il est indispensable pour séquencer correctement les événements et pour toutes les analyses temporelles, y compris 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 impératif pour l'intégrité de l'analyse de Process Mining.

Pourquoi est-ce important ? :

Cet horodatage ordonne les événements chronologiquement et permet tous les calculs basés sur la durée, qui sont essentiels à l'analyse des performances et l'identification des points de blocage.

Source des données :

Ceci correspond à des champs comme « createdon » ou « modifiedon » sur l'entité Cas (incident) ou les entités d'activité associées (par exemple, E-mail, Tâche, Appel téléphonique).

Exemples
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
Système source
SourceSystem
Identifie le système source d'où les données ont été extraites.
Descriptionn

Cet attribut spécifie l'origine des données d'événement. Pour ce processus, il identifiera systématiquement Microsoft Dynamics 365 Customer Service comme source. Dans les environnements multi-systèmes, ce champ est indispensable pour distinguer les sources de données et assurer la traçabilité des données.

Pourquoi est-ce important ? :

Fournit une traçabilité des données claire, cruciale pour la gouvernance des données et pour le dépannage des incohérences de données, en particulier dans les analyses de systèmes mixtes.

Source des données :

Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter l'origine du jeu de données.

Exemples
Microsoft Dynamics 365 Customer Service
Canal
Channel
Le canal de communication par lequel la demande de service a été initiée.
Descriptionn

Cet attribut identifie l'origine de l'interaction client, comme Téléphone, E-mail, Portail Web ou Chat. Différents canaux ont souvent des flux de processus distincts, des attentes client et des complexités de résolution différentes. L'analyse du processus par canal aide à optimiser les workflows spécifiques aux canaux et l'allocation des ressources.

Pourquoi est-ce important ? :

Fournit des informations sur la manière dont les différents canaux de contact client impactent l'efficacité des processus, le temps de résolution et la satisfaction client.

Source des données :

Ceci correspond au champ « Origine du cas » (caseorigincode) sur l'entité Cas (incident).

Exemples
TéléphoneE-mailWebChat
Motif du statut
StatusReason
Fournit une raison plus détaillée pour le statut actuel de la demande de service.
Descriptionn

Alors qu'un cas a un statut général comme « Actif » ou « Résolu », la Raison du statut fournit un contexte plus spécifique, comme « Informations fournies » ou « Problème résolu ». Cet attribut est impératif pour comprendre les nuances de la façon et des raisons pour lesquelles les cas progressent tout au long de leur cycle de vie. Par exemple, il peut différencier les cas résolus avec succès de ceux annulés par le client, ce qui est indispensable à une analyse précise des résultats.

Pourquoi est-ce important ? :

Offre une vision granulaire du résultat d'un cas et des raisons de ses changements de statut, permettant une analyse plus précise des parcours de résolution et des causes profondes.

Source des données :

Ceci correspond au champ « Raison du statut » (statuscode) sur l'entité Cas (incident).

Exemples
En coursEn AttenteProblème résoluInformations fournies
Nom de l'agent
AgentName
Le nom de l'agent ou de l'utilisateur du service client responsable de l'activité.
Descriptionn

Cet attribut identifie l'agent ou l'utilisateur du système spécifique qui a effectué une activité, comme la sélection d'un élément dans une file d'attente ou la résolution d'un cas. Il est impératif pour analyser les performances des agents, la répartition de la charge de travail et l'allocation des ressources. En suivant les activités au niveau de l'agent, les organisations peuvent identifier les collaborateurs les plus performants, les besoins en formation et les déséquilibres de charge de travail.

Pourquoi est-ce important ? :

Permet l'analyse des performances individuelles et d'équipe, aide à équilibrer la charge de travail et identifie les opportunités de coaching pour améliorer la qualité globale du service.

Source des données :

Correspond au champ 'Propriétaire' (ownerid) de l'entité Cas (incident), qui renvoie à l'entité Utilisateur système (systemuser).

Exemples
Alice SmithBob JohnsonSystème
Nom du client
CustomerName
Le nom du client ou du compte associé à la demande de service.
Descriptionn

Cet attribut identifie le client qui a initié la demande de service. Il permet d'analyser le processus sous un angle centré sur le client, aidant à identifier quels clients soumettent le plus de demandes, connaissent les temps de résolution les plus longs ou ont les problèmes les plus complexes. Ceci est indispensable pour la gestion des relations client et l'amélioration de la prestation de service spécifique au client.

Pourquoi est-ce important ? :

Permet une analyse au niveau du client pour identifier des modèles, améliorer le service pour les comptes clés et comprendre le parcours client.

Source des données :

C'est le champ de recherche « Customer » (customerid) sur l'entité Cas (incident), qui peut pointer vers un enregistrement Compte ou Contact.

Exemples
Global Tech Inc.Jane DoeSolutions Innovantes
Priorité
Priority
Le niveau de priorité assigné à la demande de service, indiquant son urgence.
Descriptionn

Cet attribut définit l'urgence d'une demande de service, généralement catégorisée comme Faible, Normale, Élevée ou Urgente. La priorité est utilisée pour déterminer l'ordre dans lequel les cas sont traités et dicte souvent les objectifs SLA. L'analyse de la façon dont la priorité influence le flux de processus, l'allocation des ressources et les temps de résolution est indispensablele pour garantir que les problèmes critiques sont traités rapidement.

Pourquoi est-ce important ? :

Aide à comprendre si les demandes de haute priorité sont traitées plus rapidement et atteignent leurs objectifs, et comment les niveaux de priorité affectent la performance globale du processus.

Source des données :

Ceci correspond au champ « Priorité » (prioritycode) sur l'entité Cas (incident).

Exemples
FaibleNormalÉlevé
Temps de résolution cible du SLA
SlaTargetResolutionTime
Le temps cible convenu contractuellement pour la résolution de la demande de service.
Descriptionn

Cet attribut spécifie la durée cible dans laquelle une demande de service doit être résolue selon l'accord de niveau de service (SLA) actif. Il sert de référence pour mesurer la performance réelle. Cette valeur est indispensable pour le Tableau de bord de surveillance de la conformité SLA et pour le calcul du KPI du taux de conformité SLA, soulignant où le processus ne respecte pas les engagements de service.

Pourquoi est-ce important ? :

Ceci est la principale référence pour mesurer la performance du service par rapport aux engagements, permettant directement l'analyse de la conformité et des violations SLA.

Source des données :

Cette valeur est déterminée par la configuration SLA dans Dynamics 365 et est associée à un cas via les instances de KPI SLA.

Exemples
2592008640014400
Type de demande de service
ServiceRequestType
La catégorie ou classification principale de la demande de service.
Descriptionn

Cet attribut catégorise la demande de service en fonction de sa nature, comme « Demande de facturation », « Support technique » ou « Commentaires sur le produit ». Il est indispensable pour segmenter l'analyse du processus afin de comprendre comment différents types de demandes sont traités. L'analyse par type peut révéler que certaines catégories ont des temps de résolution plus longs, des taux d'escalade plus élevés ou suivent des chemins de processus différents.

Pourquoi est-ce important ? :

Permet la segmentation des processus pour identifier les points de blocage spécifiques au type, les besoins en ressources et les opportunités d'amélioration, favorisant de meilleures stratégies de routage et de gestion.

Source des données :

Cette information est souvent stockée dans le champ « Sujet » (subjectid) ou un champ de catégorie personnalisé sur l'entité Cas (incident).

Exemples
Demande de FacturationSupport techniqueCommentaires sur le produitGestion de Compte
Équipe responsable
OwnerTeam
L'équipe qui est actuellement propriétaire de la demande de service.
Descriptionn

Cet attribut identifie l'équipe responsable de la demande de service. Une demande peut être détenue par un agent individuel ou par une équipe (file d'attente). L'analyse par équipe est indispensablele pour comprendre la performance au niveau de l'équipe, la répartition de la charge de travail entre les différents niveaux ou spécialités de support, et l'identification des variations de processus entre les équipes.

Pourquoi est-ce important ? :

Permet une analyse des performances au niveau de l'équipe, essentielle pour gérer efficacement les niveaux de support et les groupes spécialisés.

Source des données :

Dérivé du champ 'Propriétaire' (ownerid) de l'entité Cas (incident) lorsque le propriétaire est un enregistrement d'équipe plutôt qu'un utilisateur système.

Exemples
Support de Niveau 1Service de facturationSpécialistes techniques
Est escaladé
IsEscalated
Un indicateur signalant si la demande de service a été escaladée.
Descriptionn

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 est incapable de résoudre un problème, nécessitant l'intervention d'une équipe plus expérimentée ou d'un spécialiste. Le suivi de cet indicateur est indispensable pour le Tableau de bord des parcours d'escalade interne et le KPI du taux d'escalade interne, aidant à identifier les causes profondes des escalades et les faiblesses des niveaux de support initiaux.

Pourquoi est-ce important ? :

Mesure directement la fréquence des escalades, mettant en évidence les problèmes de résolution au premier contact et indiquant les domaines nécessitant des améliorations de processus ou de compétences des agents.

Source des données :

Ceci correspond au champ « Est escaladé » (isescalated) sur l'entité Cas (incident).

Exemples
truefaux
Est un reprises
IsRework
Un indicateur calculé signalant si un cas a impliqué des activités de reprises.
Descriptionn

Cet indicateur booléen identifie les cas qui contiennent des boucles de reprise ou des activités répétées, telles que plusieurs événements « Informations demandées au client » ou un événement « Cas réactivé » après résolution. Il est calculé en analysant la séquence d'activités à la recherche de schémas indiquant une inefficacité ou un échec à résoudre le problème correctement du premier coup. Cet attribut est indispensable pour le Tableau de bord d'analyse des reprises et des contacts répétés.

Pourquoi est-ce important ? :

Aide à quantifier et à isoler les inefficacités de processus, permettant aux analystes de se concentrer sur les causes profondes du travail répété et des efforts gaspillés.

Source des données :

Calculé en détectant des séquences d'activités spécifiques (par exemple, Résolu -> Réactivé) ou des activités répétées au sein d'un cas à l'aide de l'analyse Process Mining.

Exemples
truefaux
Est-ce une Résolution au Premier Contact
IsFirstContactResolution
Un indicateur signalant si la demande a été résolue lors du premier contact.
Descriptionn

Cet attribut calculé identifie les demandes de service qui ont été résolues sans interactions de suivi du client ou sans retards significatifs nécessitant une réaffectation de l'agent. La définition de la logique exacte peut être complexe, mais elle implique généralement de vérifier un temps de cycle court et l'absence de réouverture ou d'activités de demande client après l'interaction initiale. C'est la base du KPI du taux de résolution au premier contact.

Pourquoi est-ce important ? :

Ceci est une mesure critique de l'efficacité du service et de la satisfaction client, car elle met en évidence la capacité à résoudre les problèmes rapidement et complètement.

Source des données :

Calculé en fonction de la séquence et du timing des activités dans le journal d'événements pour chaque cas.

Exemples
truefaux
ID de l'article de connaissance
KnowledgeArticleId
L'identifiant d'un article de la base de connaissances lié à la demande de service.
Descriptionn

Cet attribut capture l'ID de tout article de connaissance utilisé ou lié lors de la résolution d'une demande de service. Il fournit une mesure directe de l'efficacité avec laquelle la base de connaissances est utilisée par les agents pour résoudre les problèmes des clients. Cette donnée est indispensablele pour le tableau de bord d'utilisation des articles de connaissance et le KPI correspondant, aidant à évaluer la valeur et l'exhaustivité de la base de connaissances.

Pourquoi est-ce important ? :

Suit l'utilisation de la base de connaissances, aidant à comprendre si les agents exploitent les ressources disponibles pour résoudre les problèmes plus rapidement et de manière plus cohérente.

Source des données :

Cette information se trouve dans la relation entre les entités Cas (incident) et Article de connaissance (knowledgearticle).

Exemples
KA-01337KA-02048
Produit impliqué
ProductInvolved
Le produit associé à la demande de service du client.
Descriptionn

Cet attribut identifie le produit ou service spécifique auquel le problème du client se rapporte. Il permet une segmentation du processus de service basée sur les produits, ce qui peut révéler si certains produits génèrent plus de demandes de support, ont des problèmes plus complexes ou nécessitent des compétences d'agent spécialisées. Cette analyse aide à l'amélioration des produits et à la planification des ressources.

Pourquoi est-ce important ? :

Permet une analyse de processus spécifique au produit pour identifier les problèmes de produit récurrents, améliorer la documentation de support et allouer efficacement les ressources expertes.

Source des données :

Ceci correspond au champ de recherche « Produit » (productid) sur l'entité Cas (incident).

Exemples
Alpha-100 PrinterLogiciel CRM ZetaForfait de données Omega
Score CSAT
CustomerSatisfactionScore
Le score de satisfaction fourni par le client après la résolution du cas.
Descriptionn

Cet attribut contient l'évaluation numérique ou catégorielle d'une enquête de satisfaction client (CSAT), généralement collectée après la clôture d'une demande de service. C'est une mesure directe de la perception de la qualité de service par le client. Ces données sont indispensables pour le Tableau de bord des tendances de satisfaction client et le KPI du score CSAT moyen après résolution, reliant la performance du processus aux résultats client.

Pourquoi est-ce important ? :

Fournit une mesure directe de la satisfaction client, permettant à l'organisation de corréler les comportements des processus avec le sentiment client et de stimuler les améliorations.

Source des données :

Ceci est généralement tiré d'une entité d'enquête connexe, comme Customer Voice, et lié à l'entité Cas (incident).

Exemples
5341
SLA dépassé
IsSlaBreached
Un indicateur calculé signalant si la demande de service a dépassé son objectif SLA.
Descriptionn

Cet indicateur booléen est déterminé en comparant le temps de résolution réel d'une demande de service à son « Temps de résolution cible SLA ». Il est défini sur vrai si le temps réel est supérieur au temps cible. Cet attribut est indispensable pour le Tableau de bord de surveillance de la conformité SLA et pour le calcul du KPI du taux de conformité SLA, fournissant un résultat binaire clair pour la performance SLA de chaque cas.

Pourquoi est-ce important ? :

Fournit un résultat clair de succès ou d'échec pour la conformité SLA sur chaque cas, facilitant le filtrage, l'agrégation et l'analyse des causes profondes des violations.

Source des données :

Calculé en comparant le 'ServiceRequestCycleTime' avec le 'SlaTargetResolutionTime'.

Exemples
truefaux
Obligatoire Recommandé Facultatif

Activités (Activities) du service client

Ce sont les étapes clés du processus et les jalons à capturer dans votre journal d'événements pour une découverte et une optimisation précises du service client.
6 Recommandé 7 Facultatif
Activité Descriptionn
Dossier attribué
Cette activité représente l'affectation d'un cas à une file d'attente ou à un utilisateur spécifique pour traitement. Le système enregistre explicitement les changements de propriétaire du cas, qui peuvent être suivis via les journaux d'audit du système.
Pourquoi est-ce important ? :

Le suivi des affectations est impératif pour analyser la répartition de la charge de travail, identifier les retards liés aux affectations et comprendre l'efficacité du routage. Il aide à répondre aux questions sur la rapidité avec laquelle les cas sont acheminés à la bonne équipe ou personne.

Source des données :

Capturé en suivant les changements du champ 'ownerid' sur l'entité 'Incident'. L'horodatage du changement est disponibleble dans les journaux d'historique d'audit.

Capture

Extraire les modifications horodatées du champ 'ownerid' des journaux d'audit.

Type d'événement explicit
Dossier clos
Ceci est la clôture administrative finale de l'enregistrement de cas, qui peut survenir en même temps que la résolution ou un certain temps après. Cette activité est capturée par un changement d'état du cas à « Clôturé ».
Pourquoi est-ce important ? :

Ceci représente la fin absolue du cycle de vie du processus dans le système. Le temps entre « Résolu » et « Clôturé » peut indiquer une surcharge administrative ou des retards dans la finalisation des enregistrements.

Source des données :

Capturé par un changement du champ 'statecode' sur l'entité 'Incident' à 'Annulé' (2) ou un état fermé personnalisé. L'horodatage est disponibleble dans l'historique d'audit.

Capture

Suivez l'horodatage du « statecode » changeant vers son état terminal final (par exemple, Annulé/Clôturé).

Type d'événement explicit
Dossier créé
Cette activité marque le début du processus de service client, lorsqu'un nouvel enregistrement de cas est créé dans le système. La création est un événement explicite, enregistré avec un horodatage spécifique lorsque l'enregistrement de l'entité « Incident » est sauvegardé pour la première fois.
Pourquoi est-ce important ? :

En tant qu'événement de début principal, cette activité est indispensablele pour calculer la durée globale du cycle de vie du cas et comprendre les tendances du volume de cas. Elle sert de point d'ancrage pour toutes les analyses de processus ultérieures.

Source des données :

Cet événement est capturé à partir de l'horodatage « createdon » sur l'entité « Incident » (Cas) pour chaque nouvel enregistrement.

Capture

Utilisez l'horodatage « createdon » de l'enregistrement d'incident.

Type d'événement explicit
Dossier escaladé
Représente l'escalade formelle d'un cas vers un niveau de support supérieur ou une équipe différente. Il peut s'agir d'une action utilisateur explicite qui réaffecte le cas à une file d'attente d'escalade ou à un utilisateur désigné.
Pourquoi est-ce important ? :

Le suivi des escalades est indispensable à le KPI « Taux d'escalade interne » et pour identifier les causes profondes des problèmes que le support de premier niveau ne peut résoudre. Il met en évidence les faiblesses des processus et les opportunités de formation.

Source des données :

Déduit d'un changement du champ 'ownerid' vers une file d'attente ou une équipe d'escalade désignée. Il peut également s'agir d'une action personnalisée explicite qui marque le cas comme escaladé.

Capture

Identifier un changement horodaté du 'ownerid' vers une file d'attente d'escalade connue.

Type d'événement inferred
Dossier résolu
Ceci est un jalon clé représentant le moment où l'agent considère le problème du client comme traité. C'est une action explicite dans Dynamics 365, créant un enregistrement d'activité « Résolution de cas » lié au cas.
Pourquoi est-ce important ? :

En tant qu'événement de fin principal basé sur le succès, cette activité est indispensablele pour calculer les temps de résolution et les taux de succès. C'est un élément clé de presque tous les KPI du service client.

Source des données :

Cet événement correspond à la création d'un enregistrement d'activité « Résolution » (Résolution de cas). L'horodatage « actualend » sur cet enregistrement marque le temps de résolution.

Capture

Utilisez l'horodatage « actualend » ou « createdon » de l'enregistrement d'activité « Résolution » 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 cas, qui commence à suivre le temps par rapport à une métrique de service définie comme 'Première réponse d'ici' ou 'Résoudre d'ici'. Il s'agit d'un événement explicite géré par le moteur SLA de Dynamics 365.
Pourquoi est-ce important ? :

Cette activité est clée pour surveiller la conformité SLA et comprendre quand le compteur démarre pour les engagements de service. Elle contribue directement au l'analyse du respect des objectifs de service.

Source des données :

Comptabilisé dans l'entité « Instance de KPI SLA », liée à l'entité « Incident ». L'horodatage « createdon » de l'enregistrement d'instance de KPI SLA pertinent marque le début.

Capture

Utilisez l'horodatage de création de l'enregistrement « Instance de KPI SLA » associé au cas.

Type d'événement explicit
Article de file d'attente sélectionné par l'agent
Cet événement se produit lorsqu'un agent prend activement un cas d'une file d'attente partagée pour commencer à travailler dessus. Il s'agit d'une action délibérée de l'utilisateur, distincte de l'affectation du cas à la file d'attente par le système.
Pourquoi est-ce important ? :

Cette activité aide à mesurer le temps réel d'attente d'un cas dans une file d'attente avant qu'un agent ne commence à travailler. Elle est indispensablele pour identifier les points de blocage des files d'attente et comprendre la proactivité des agents.

Source des données :

Suivi lorsqu'un utilisateur met à jour le champ « workedbyid » sur l'entité « QueueItem » associée au cas, ou lorsque le propriétaire du cas passe d'une file d'attente à un utilisateur.

Capture

Identifier l'horodatage lorsque le champ 'workedbyid' de l'élément de file d'attente est renseigné.

Type d'événement explicit
Cas réactivé
Se produit lorsqu'un cas précédemment résolu est rouvert automatiquement ou manuellement, généralement parce que le client a répondu ou a signalé que le problème n'était pas résolu. Il s'agit d'un comportement système standard qui fait passer le statut du cas de « Résolu » à « Actif ».
Pourquoi est-ce important ? :

Cette activité est indispensablele pour identifier les reprises et analyser le « Taux de résolution au premier contact ». Un nombre élevé de réactivations indique des solutions initiales incomplètes ou inefficaces.

Source des données :

Capturé par un changement du champ 'statecode' sur l'entité 'Incident' de 'Résolu' (1) à 'Actif' (0). L'horodatage de ce changement est enregistré dans l'historique d'audit.

Capture

Suivez l'horodatage du changement de « statecode » de Résolu à Actif dans les journaux d'audit.

Type d'événement explicit
Catégorisation du cas modifiée
Cet événement se produit lorsqu'un agent modifie la catégorie ou le sujet d'un cas après sa création initiale. Il s'agit d'un changement explicite suivi par la fonctionnalité d'audit du système.
Pourquoi est-ce important ? :

Le suivi de la recatégorisation est indispensable pour le KPI « Taux de recatégorisation des demandes de service ». Une fréquence élevée indique des problèmes de triage initial, entraînant un routage incorrect et des retards.

Source des données :

Capturé à partir de l'historique d'audit de l'entité 'Incident', spécifiquement en suivant les changements du champ 'subjectid' ou d'autres champs de catégorisation personnalisés.

Capture

Extraire les modifications horodatées du champ 'subjectid' des journaux d'audit.

Type d'événement explicit
Enquête de satisfaction envoyée
Marque l'envoi d'une enquête de satisfaction client, généralement déclenchée automatiquement après la résolution d'un cas. Ceci est généralement enregistré comme un e-mail sortant ou une activité d'enquête Customer Voice.
Pourquoi est-ce 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 chemin de processus qu'un cas a suivi.

Source des données :

Déduit de la création d'une activité 'E-mail' sortante avec un lien vers un sondage, ou d'un enregistrement d'activité 'Invitation au sondage Customer Voice' lié au cas.

Capture

Utilisez l'horodatage de création de l'enregistrement d'activité lié à l'enquête.

Type d'événement inferred
Informations demandées au client
Cette activité marque un point où l'agent a besoin de plus d'informations du client pour continuer. Elle est souvent inférée par le changement de statut du cas à un état « en attente » ou par l'envoi d'un e-mail sortant depuis la chronologie du cas.
Pourquoi est-ce important ? :

Ceci est impératif pour mesurer les retards liés aux clients et comprendre le KPI « Temps d'attente des informations client ». Il aide à isoler le temps de processus passé à attendre une entrée externe.

Source des données :

Peut être déduit d'un changement du champ 'statuscode' sur l'entité 'Incident' vers une valeur comme 'En attente' avec la raison 'En attente du client'. L'horodatage de ce changement de statut est utilisé.

Capture

Suivez l'horodatage d'un changement de « statuscode » vers un état désigné « en attente du client ».

Type d'événement inferred
L'agent a enquêté sur le problème
Représente l'agent travaillant activement pour comprendre et diagnostiquer le problème du client. Il s'agit d'une activité inférée, souvent identifiée par l'agent liant un article de connaissance au cas, indiquant qu'une recherche a eu lieu.
Pourquoi est-ce important ? :

Le suivi de cela aide à mesurer l'utilisation des ressources de connaissance et son impact sur les temps de résolution. Il fournit des informations sur la manière dont les agents exploitent les outils disponibles pour résoudre les problèmes efficacement.

Source des données :

Déduit de la création d'un enregistrement dans l'entité 'IncidentKnowledgeBaseRecord', qui lie un article de la base de connaissances à un cas. L'horodatage de cette création d'enregistrement est utilisé.

Capture

Utilisez l'horodatage lorsque un article de connaissance est associé à l'incident.

Type d'événement inferred
Solution proposée au client
Cette activité signifie que l'agent a formulé une solution et l'a communiquée au client. Elle est généralement inférée d'un e-mail sortant envoyé depuis la chronologie du cas ou d'un changement de statut à « En attente de confirmation client ».
Pourquoi est-ce important ? :

Ce jalon marque la transition de l'enquête à la résolution. L'analyse du temps entre lÀ proposition et la confirmation d'une solution peut révéler des retards dans la réponse du client ou des problèmes avec les correctifs proposés.

Source des données :

Peut être déduit de l'horodatage d'un enregistrement d'activité 'E-mail' sortant lié au cas ou d'un changement de 'statuscode' vers un état de prélèvement.-résolution.

Capture

Utilisez l'horodatage d'une activité d'e-mail sortant ou d'un changement de statut à « Solution proposée ».

Type d'événement inferred
Recommandé Facultatif

Guides d'extraction

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