Votre modèle de données pour le service client
Votre modèle de données pour le service client
- Attributs recommandés à collecter
- Activités clés à suivre
- Conseils 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 cas ou ticket. | ||
|
Description
La demande de service est l’identifiant principal qui relie toutes les activités associées à une même question ou à un même problème client. Elle sert d’ID de cas pour le Process Mining et garantit une vue complète et cohérente de chaque interaction, 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 de repérer des tendances parmi des cas similaires.
Pourquoi est-ce important ?
Il s’agit de l’ID de cas essentiel qui relie tous les événements associés en une seule instance de processus et rend possible l’analyse de bout en bout.
Où trouver ces données
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 un changement de statut dans le processus de service client, par exemple « Demande créée », « Problème examiné par un agent » ou « Cas résolu ». Ces activités constituent la base de la cartographie du processus et permettent d’en visualiser et d’en analyser le déroulement. Associée à un horodatage, chaque activité devient un événement qui définit la séquence du processus.
Pourquoi est-ce 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, repérer les écarts et trouver les goulots d’étranglement.
Où trouver ces données
Cet attribut est généralement obtenu en associant les changements de statut (statuscode) ou des événements précis provenant d’entités liées, comme les tâches, les courriels ou les appels téléphoniques, à un nom d’activité normalisé.
Exemples
Demande crééeProblème examiné par un agentSolution proposée au clientCas 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 la dernière extraction des données depuis Microsoft Dynamics 365. Il permet d’évaluer leur fraîcheur et est essentiel à la création de rapports et au suivi. Les utilisateurs peuvent ainsi tenir compte de l’actualité des données lorsqu’ils interprètent les Dashboards et les analyses.
Pourquoi est-ce important ?
Il renseigne les utilisateurs sur l’actualité des données, un élément essentiel pour prendre des décisions métier opportunes et précises à partir de l’analyse des processus.
Où trouver ces données
Cette valeur est générée et ajoutée au 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é a eu lieu. | ||
|
Description
Cet attribut enregistre la date et l’heure précises auxquelles une activité a eu lieu. Il est essentiel pour ordonner correctement les événements et effectuer toutes les analyses temporelles, notamment le calcul des temps de cycle, des durées et des temps d’attente entre les activités. La précision et la cohérence des horodatages sont indispensables à la fiabilité de l’analyse Process Mining.
Pourquoi est-ce important ?
Cet horodatage ordonne les événements chronologiquement et permet tous les calculs de durée, essentiels à l’analyse des performances et au repérage des goulots d’étranglement.
Où trouver ces données
Cet attribut correspond à des champs tels que « createdon » ou « modifiedon » de l’entité Case (incident) ou des 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 dont les données ont été extraites. | ||
|
Description
Cet attribut indique l’origine des données d’événement. Pour ce processus, il désigne toujours Microsoft Dynamics 365 Customer Service comme système source. Dans les environnements qui utilisent plusieurs systèmes, ce champ est essentiel pour distinguer les sources de données et assurer leur traçabilité.
Pourquoi est-ce important ?
Cet attribut assure une traçabilité claire des données, essentielle à leur gouvernance et à la résolution des incohérences, notamment dans les analyses combinant plusieurs systèmes.
Où trouver ces données
Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données pour indiquer l’origine du jeu de données.
Exemples
Microsoft Dynamics 365 Customer Service
|
|||
|
Canal
Channel
|
Canal de communication utilisé pour soumettre la demande de service. | ||
|
Description
Cet attribut indique l’origine de l’interaction avec le client, par exemple un appel téléphonique, un courriel, un portail web ou une conversation par chat. Chaque canal peut correspondre à un déroulement de processus, à des attentes client et à un niveau de complexité différents. L’analyse par canal aide à optimiser les flux de travail et l’affectation des ressources propres à chacun.
Pourquoi est-ce important ?
Cet attribut permet de comprendre comment les différents canaux de contact influent sur l’efficacité du processus, les délais de résolution et la satisfaction client.
Où trouver ces données
Cet attribut correspond au champ « Case Origin » (caseorigincode) de l’entité Case (incident).
Exemples
TéléphoneCourrielWebChat
|
|||
|
Délai de résolution cible du SLA
SlaTargetResolutionTime
|
Délai cible convenu par contrat pour résoudre la demande de service. | ||
|
Description
Cet attribut indique le délai cible dans lequel une demande de service doit être résolue, conformément à l’accord de niveau de service (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é aux SLA et au calcul de l’indicateur de taux de conformité aux SLA. Elle permet de repérer les situations où le processus ne respecte pas les engagements de service.
Pourquoi est-ce important ?
Cette valeur est la référence principale pour mesurer les performances du service au regard des engagements. Elle permet directement d’analyser la conformité aux SLA et les manquements.
Où trouver ces données
Cette valeur est définie dans la configuration SLA de Dynamics 365 et associée à un cas par l’intermédiaire des instances SLA KPI.
Exemples
2592008640014400
|
|||
|
Motif du statut
StatusReason
|
Précise le motif du statut actuel de la demande de service. | ||
|
Description
Un cas peut avoir un statut général comme « Active » ou « Resolved ». Le motif du statut apporte des précisions, par exemple « Information Provided » ou « Problem Solved ». Cet attribut est essentiel pour comprendre les différentes étapes du cycle de vie des cas et les raisons de leur progression. Il permet, par exemple, de distinguer les cas résolus des cas annulés par le client, ce qui est indispensable à une analyse précise des résultats.
Pourquoi est-ce important ?
Cet attribut apporte une vue détaillée du résultat d’un cas et des raisons de ses changements de statut. Il permet d’analyser plus précisément les parcours de résolution et les causes profondes.
Où trouver ces données
Cet attribut 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 du système qui a effectué une activité, par exemple prendre un élément dans une file d’attente ou résoudre un cas. Il est essentiel pour analyser les performances des agents, la répartition de la charge de travail et l’affectation des ressources. Le suivi des activités à l’échelle des agents permet de repérer les personnes les plus performantes, les besoins de formation et les déséquilibres de charge.
Pourquoi est-ce important ?
Cet attribut permet d’analyser les performances individuelles et collectives, de mieux répartir la charge de travail et de repérer les besoins d’accompagnement pour améliorer la qualité globale du service.
Où trouver ces données
Cet attribut correspond au champ « Owner » (ownerid) de l’entité Case (incident), qui est lié à 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 repérer ceux qui soumettent le plus de demandes, connaissent les délais de résolution les plus longs ou rencontrent les problèmes les plus complexes. Il est essentiel à la gestion des relations client et à l’amélioration du service pour chaque client.
Pourquoi est-ce important ?
L’analyse à l’échelle du client permet de repérer des tendances, d’améliorer le service offert aux comptes clés et de mieux comprendre le parcours client.
Où trouver ces données
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, qui indique 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é détermine l’ordre de traitement des cas et fixe souvent les objectifs SLA. Il est essentiel d’analyser son effet sur le déroulement du processus, l’affectation des ressources et les délais de résolution pour traiter rapidement les problèmes prioritaires.
Pourquoi est-ce important ?
Cet attribut permet de vérifier si les demandes prioritaires sont traitées plus rapidement et dans les délais prévus, et de comprendre l’effet des niveaux de priorité sur les performances globales du processus.
Où trouver ces données
Cet attribut 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 classe la demande de service selon sa nature, par exemple « Question sur la facturation », « Assistance technique » ou « Commentaire sur un produit ». Il est fondamental pour segmenter l’analyse et comprendre comment 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, davantage d’escalades ou des parcours différents.
Pourquoi est-ce important ?
La segmentation du processus permet de repérer les goulots d’étranglement propres à chaque type de demande, les besoins en ressources et les possibilités d’amélioration. Elle aide également à définir de meilleures stratégies de routage et de traitement.
Où trouver ces données
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
Question sur la facturationAssistance techniqueCommentaire sur un produitGestion des comptes
|
|||
|
Dépassement du SLA
IsSlaBreached
|
Indicateur calculé qui précise si la demande de service a dépassé le délai prévu par le SLA. | ||
|
Description
Cet indicateur booléen est calculé en comparant le temps réel de résolution d’une demande de service au « SLA Target Resolution Time ». Il prend la valeur true si le temps réel dépasse le délai prévu. Cet attribut est essentiel pour le Dashboard de suivi de la conformité aux SLA et pour calculer le KPI du taux de conformité aux SLA. Il fournit un résultat binaire clair pour chaque dossier.
Pourquoi est-ce important ?
Indique clairement si chaque dossier respecte ou non le SLA, ce qui facilite le filtrage, l’agrégation et l’analyse des causes des dépassements.
Où trouver ces données
Calculé en comparant « ServiceRequestCycleTime » à « SlaTargetResolutionTime ».
Exemples
truefalse
|
|||
|
Équipe responsable
OwnerTeam
|
Équipe 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 ou à une équipe (file d’attente). L’analyse par équipe est essentielle pour comprendre les performances de chaque équipe, la répartition de la charge entre les différents niveaux d’assistance ou spécialités, ainsi que les écarts de processus entre équipes.
Pourquoi est-ce important ?
Permet d’analyser les performances par équipe, ce qui est essentiel pour gérer efficacement les niveaux d’assistance et les groupes spécialisés.
Où trouver ces données
Dérivé du champ « Owner » (ownerid) de l’entité Case (incident) lorsque le propriétaire est un enregistrement Team plutôt qu’un System User.
Exemples
Assistance de niveau 1Service de facturationSpécialistes techniques
|
|||
|
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 contient l’ID de tout article de la base de connaissances utilisé ou associé lors de la résolution d’une demande de service. Il indique directement dans quelle mesure les agents s’appuient sur la base de connaissances pour résoudre les problèmes des clients. Ces données sont essentielles pour le Dashboard d’utilisation des articles de la base de connaissances et le KPI associé, qui permettent d’évaluer la valeur et l’exhaustivité de cette base.
Pourquoi est-ce important ?
Suit l’utilisation de la base de connaissances et permet de déterminer si les agents s’appuient sur les ressources disponibles pour résoudre les problèmes plus rapidement et de manière plus cohérente.
Où trouver ces données
Cette information figure 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 le service concerné par le problème du client. Il permet de segmenter le processus de service par produit et de repérer ceux qui génèrent davantage de demandes d’assistance, 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 est-ce important ?
Permet d’analyser les processus par produit afin de repérer les problèmes récurrents, d’améliorer la documentation d’assistance et d’affecter efficacement les ressources spécialisées.
Où trouver ces données
Correspond au champ de recherche « Product » (productid) de l’entité Case (incident).
Exemples
Imprimante Alpha-100Logiciel CRM ZetaForfait de données Omega
|
|||
|
Reprises
IsRework
|
Indicateur calculé qui précise si un dossier a comporté des activités de reprise. | ||
|
Description
Cet indicateur booléen repère les dossiers comportant 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 la résolution. Il est calculé en analysant l’ordre des activités pour détecter les schémas révélateurs d’inefficacité ou d’une résolution incorrecte dès la première tentative. Cet attribut est essentiel pour le Dashboard d’analyse des reprises et des contacts répétés.
Pourquoi est-ce important ?
Aide à quantifier et à isoler les inefficacités du processus afin que les analystes puissent se concentrer sur les causes des tâches répétées et du travail inutile.
Où trouver ces données
Calculé en détectant des séquences d’activités précises (par exemple, Resolved -> Reactivated) ou des activités répétées dans un dossier à l’aide des analyses de Process Mining.
Exemples
truefalse
|
|||
|
Résolution au premier contact
IsFirstContactResolution
|
Indique si la demande a été résolue dès le premier contact. | ||
|
Description
Cet attribut calculé repère les demandes de service résolues sans échange ultérieur avec le client ni retard important nécessitant une réaffectation à un autre agent. La logique exacte peut être complexe, mais elle consiste généralement à vérifier que le temps de cycle est court et qu’aucune réouverture ni demande d’information du client n’a suivi le premier échange. Cet attribut sert de base au KPI du taux de résolution au premier contact.
Pourquoi est-ce important ?
Il s’agit d’une mesure importante de l’efficacité du service et de la satisfaction client, car elle indique si les problèmes sont résolus rapidement et complètement.
Où trouver ces données
Calculé à partir de l’ordre et de l’horodatage des activités dans le journal d’événements de chaque dossier.
Exemples
truefalse
|
|||
|
Score CSAT
CustomerSatisfactionScore
|
Score de satisfaction communiqué par le client après la résolution du dossier. | ||
|
Description
Cet attribut contient la note 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 du client quant à la qualité du service. Ces données sont essentielles pour le Dashboard des tendances de satisfaction client et le KPI du score CSAT moyen après résolution, qui relient la performance du processus aux résultats pour les clients.
Pourquoi est-ce important ?
Mesure directement la satisfaction client et permet à l’organisation de mettre en relation le déroulement du processus avec l’avis des clients afin de définir des améliorations.
Où trouver ces données
Ces données proviennent généralement d’une entité d’enquête associée, telle que Customer Voice, puis sont reliées à l’entité Case (incident).
Exemples
5341
|
|||
|
Transmis à un niveau supérieur
IsEscalated
|
Indique 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. Une escalade intervient lorsque l’assistance de premier niveau ne parvient pas à résoudre un problème et qu’une équipe plus expérimentée ou un spécialiste doit prendre le relais. Le suivi de cet indicateur est essentiel pour le Dashboard des parcours d’escalade internes et le KPI du taux d’escalade interne. Il permet de repérer les causes des escalades et les points faibles des premiers niveaux d’assistance.
Pourquoi est-ce important ?
Mesure directement la fréquence des escalades, met en évidence les difficultés de résolution dès le premier contact et indique les domaines où améliorer les processus ou les compétences des agents.
Où trouver ces données
Correspond au champ « Is Escalated » (isescalated) de l’entité Case (incident).
Exemples
truefalse
|
|||
Activités du service client
| Activité | Description | ||
|---|---|---|---|
|
Cas attribué
|
Cette activité correspond à l’attribution d’un cas à une file d’attente ou à un utilisateur chargé de le traiter. Le système enregistre explicitement les changements de propriétaire du cas, qui peuvent être suivis dans les journaux d’audit. | ||
|
Pourquoi est-ce important ?
Le suivi des attributions est essentiel pour analyser la répartition de la charge de travail, repérer les retards liés à l’attribution et évaluer l’efficacité du routage. Il permet notamment de savoir à quelle vitesse les cas sont dirigés vers la bonne équipe ou la bonne personne.
Où trouver ces données
L’événement est enregistré lorsque la valeur du champ « ownerid » de l’entité « Incident » change. L’horodatage de la modification figure dans les journaux d’audit.
Données à recueillir
Extrayez des journaux d’audit les modifications horodatées du champ « ownerid ».
Type d’événement
explicit
|
|||
|
Cas clôturé
|
Il s’agit de la clôture administrative définitive de l’enregistrement du cas. Elle peut avoir lieu en même temps que la résolution ou plus tard. Cette activité est enregistrée lorsque le statut du cas passe à « Closed ». | ||
|
Pourquoi est-ce important ?
Cet événement marque la fin définitive du cycle de vie du processus dans le système. Le temps écoulé entre « Resolved » et « Closed » peut révéler une charge administrative ou des retards dans la finalisation des enregistrements.
Où trouver ces données
L’événement est enregistré lorsque le champ « statecode » de l’entité « Incident » passe à « Canceled » (2) ou à un statut de clôture personnalisé. L’horodatage figure dans l’historique d’audit.
Données à recueillir
Suivez l’horodatage auquel le champ « statecode » passe à son statut final (par exemple, Canceled/Closed).
Type d’événement
explicit
|
|||
|
Cas résolu
|
Cette étape importante correspond au moment où l’agent considère que le problème du client est réglé. Dans Dynamics 365, il s’agit d’une action explicite qui crée un enregistrement d’activité « Case Resolution » associé au cas. | ||
|
Pourquoi est-ce important ?
En tant qu’événement de fin principal associé à la réussite du traitement, cette activité est essentielle pour calculer les délais et les taux de résolution. Elle entre dans le calcul de presque tous les indicateurs de service client.
Où trouver ces données
Cet événement correspond à la création d’un enregistrement d’activité « Resolution » (Case Resolution). L’horodatage « actualend » de cet enregistrement indique le moment de la résolution.
Données à recueillir
Utilisez l’horodatage « actualend » ou « createdon » de l’enregistrement d’activité « Resolution » associé.
Type d’événement
explicit
|
|||
|
Cas transmis à un niveau supérieur
|
Cette activité correspond à la transmission officielle d’un cas à un niveau d’assistance supérieur ou à une autre équipe. Elle peut résulter d’une action explicite de l’utilisateur, qui réattribue le cas à une file d’escalade ou à un utilisateur désigné. | ||
|
Pourquoi est-ce important ?
Le suivi des escalades est essentiel pour l’indicateur « Internal Escalation Rate » et pour repérer les causes profondes des problèmes que l’assistance de première ligne ne peut pas résoudre. Il met en évidence les faiblesses du processus et les besoins de formation.
Où trouver ces données
L’événement peut être déduit du changement du champ « ownerid » vers une file d’escalade ou une équipe désignée. Il peut également correspondre à une action personnalisée explicite qui signale que le cas a été transmis à un niveau supérieur.
Données à recueillir
Repérez l’horodatage du changement du champ « ownerid » vers une file d’escalade connue.
Type d’événement
inferred
|
|||
|
Demande créée
|
Cette activité marque le début du processus de service client, au moment où un nouvel enregistrement de cas est créé dans le système. Il s’agit d’un événement explicite, enregistré avec un horodatage précis lors de la première sauvegarde de l’enregistrement de l’entité « Incident ». | ||
|
Pourquoi est-ce important ?
En tant qu’événement de début principal, cette activité est essentielle pour calculer la durée totale du cycle de vie d’un cas et comprendre l’évolution du volume de cas. Elle sert de point de référence à toutes les analyses ultérieures du processus.
Où trouver ces données
Cet événement est extrait de l’horodatage « createdon » de l’entité « Incident » (cas) pour chaque nouvel enregistrement.
Données à recueillir
Utilisez l’horodatage « createdon » de l’enregistrement Incident.
Type d’événement
explicit
|
|||
|
Minuteur SLA démarré
|
Indique le démarrage du minuteur d’un accord de niveau de service (SLA) pour le cas. Le minuteur mesure le temps par rapport à un indicateur de service défini, comme « First Response By » ou « Resolve By ». Cet événement explicite est géré par le moteur SLA de Dynamics 365. | ||
|
Pourquoi est-ce important ?
Cette activité est fondamentale pour suivre la conformité aux SLA et savoir à quel moment le délai de service commence à courir. Elle permet directement de vérifier si les objectifs de service sont atteints.
Où trouver ces données
L’événement est enregistré dans l’entité « SLA KPI Instance », liée à l’entité « Incident ». L’horodatage « createdon » de l’enregistrement SLA KPI Instance concerné marque le début du délai.
Données à recueillir
Utilisez l’horodatage de création de l’enregistrement « SLA KPI Instance » associé au cas.
Type d’événement
explicit
|
|||
|
Cas pris en charge par un agent depuis la file d’attente
|
Cet événement se produit lorsqu’un agent prend activement un cas dans une file d’attente partagée pour commencer à le traiter. Cette action délibérée de l’utilisateur est distincte de l’attribution du cas à la file d’attente par le système. | ||
|
Pourquoi est-ce important ?
Cette activité permet de mesurer le temps réel pendant lequel un cas attend dans une file avant qu’un agent ne commence à le traiter. Elle est essentielle pour repérer les goulots d’étranglement dans les files d’attente et comprendre la proactivité des agents.
Où trouver ces données
L’événement est suivi lorsqu’un utilisateur renseigne le champ « workedbyid » de l’entité « QueueItem » associée au cas, ou lorsque le propriétaire du cas passe d’une file d’attente à un utilisateur.
Données à recueillir
Repérez l’horodatage auquel le champ « workedbyid » de QueueItem est renseigné.
Type d’événement
explicit
|
|||
|
Cas réactivé
|
Cet événement 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 signalé que le problème n’était pas réglé. Le statut du cas passe alors de « Resolved » à « Active ». | ||
|
Pourquoi est-ce important ?
Cette activité est essentielle pour repérer les reprises et analyser le taux de résolution dès le premier contact. Un nombre élevé de réactivations signale que les solutions initiales sont incomplètes ou inefficaces.
Où trouver ces données
L’événement est enregistré lorsque le champ « statecode » de l’entité « Incident » passe de « Resolved » (1) à « Active » (0). L’horodatage de ce changement figure dans l’historique d’audit.
Données à recueillir
Suivez dans les journaux d’audit l’horodatage du changement de « statecode » de Resolved à Active.
Type d’événement
explicit
|
|||
|
Catégorie 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. Le système enregistre explicitement cette modification dans les journaux d’audit. | ||
|
Pourquoi est-ce important ?
Le suivi des changements de catégorie est essentiel pour l’indicateur « Service Request Recategorization Rate ». Des changements fréquents signalent des problèmes lors du tri initial, qui peuvent entraîner un routage incorrect et des retards.
Où trouver ces données
L’événement est extrait de l’historique d’audit de l’entité « Incident », en particulier des modifications du champ « subjectid » ou d’autres champs de catégorisation personnalisés.
Données à recueillir
Extrayez des journaux d’audit les modifications horodatées du champ « subjectid ».
Type d’événement
explicit
|
|||
|
Enquête de satisfaction envoyée
|
Indique l’envoi d’une enquête de satisfaction au client, généralement déclenché automatiquement après la résolution d’un cas. L’événement est habituellement enregistré sous la forme d’un courriel sortant ou d’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 en fonction du parcours suivi par le cas.
Où trouver ces données
L’activité peut être déduite 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 cas.
Données à recueillir
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 le moment où l’agent a besoin d’informations supplémentaires du client pour poursuivre le traitement. Elle est souvent déduite du passage du cas à un statut d’attente ou de l’envoi d’un courriel depuis la chronologie du cas. | ||
|
Pourquoi est-ce important ?
Cette activité est essentielle pour mesurer les retards imputables au client et comprendre l’indicateur « Customer Information Wait Time ». Elle permet d’isoler le temps passé à attendre des informations externes.
Où trouver ces données
L’activité peut être déduite du changement du champ « statuscode » de l’entité « Incident » vers une valeur telle que « On Hold », avec le motif « Waiting for Customer ». L’horodatage de ce changement de statut est utilisé.
Données à recueillir
Suivez l’horodatage du changement de statuscode vers un statut désigné comme « waiting for customer ».
Type d’événement
inferred
|
|||
|
Problème examiné par un agent
|
Cette activité correspond au travail de l’agent pour comprendre et diagnostiquer le problème du client. Elle est déduite, par exemple, de l’association d’un article de la base de connaissances au cas, ce qui indique que des recherches ont été effectuées. | ||
|
Pourquoi est-ce important ?
Le suivi de cette activité permet de mesurer l’utilisation des ressources de connaissances et leur effet sur les délais de résolution. Il indique si les agents s’appuient sur les outils disponibles pour résoudre les problèmes efficacement.
Où trouver ces données
L’activité est déduite de la création d’un enregistrement dans l’entité « IncidentKnowledgeBaseRecord », qui associe un article de la base de connaissances à un cas. L’horodatage de création de cet enregistrement est utilisé.
Données à recueillir
Utilisez l’horodatage auquel un article de la base de connaissances est associé à l’incident.
Type d’événement
inferred
|
|||
|
Solution proposée au client
|
Cette activité indique que l’agent a élaboré une solution et l’a communiquée au client. Elle est généralement déduite de l’envoi d’un courriel depuis la chronologie du cas ou du passage au statut « Pending Customer Confirmation ». | ||
|
Pourquoi est-ce important ?
Cette étape marque le passage de l’examen du problème à sa résolution. L’analyse du temps écoulé 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 à la solution proposée.
Où trouver ces données
L’activité peut être déduite de l’horodatage d’un enregistrement d’activité « Email » sortant associé au cas, ou du passage du champ statuscode à un statut précédant la résolution.
Données à recueillir
Utilisez l’horodatage d’une activité de courriel sortant ou du changement de statut vers « Solution Proposed ».
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à démarrer ?
Ce modèle de données vous aide à lancer votre démarche de Process Mining et à améliorer l’efficacité de vos opérations de service client. Commencez dès aujourd’hui à optimiser vos flux de travail pour offrir une meilleure expérience à vos clients.
Optimisez votre service client : augmentez la résolution au premier contact et réduisez les coûts dès maintenant
Repérez les goulots d’étranglement et résolvez 80 % des demandes dès le premier contact pour améliorer la satisfaction de vos clients.
Aucune carte bancaire requise. La configuration ne prend que quelques minutes.