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
Attributs du service client
| Nom | Description | ||
|---|---|---|---|
|
Demande de service
ServiceRequest
|
Identifiant unique de chaque demande de service client, cas ou ticket. | ||
|
Description
La demande de service est l’identifiant principal du cas. Elle relie toutes les activités et tous les événements associés à un même problème client, de sa création à sa clôture. Elle constitue le fil conducteur du parcours complet d’une interaction avec un client. En Process Mining, cet attribut est indispensable pour reconstituer le flux du processus. Chaque valeur unique de demande de service correspond à une instance du processus et permet d’analyser les temps de cycle, les parcours et les variations pour chaque cas. Il garantit que toutes les étapes, du premier contact à la résolution et à la clôture, sont correctement associées à la même demande du client.
Pourquoi est-ce important ?
Il s’agit de l’ID de cas essentiel qui relie toutes les étapes du processus et permet d’analyser le cycle de vie complet de chaque interaction avec le service client.
Où trouver ces données
Il s’agit généralement du champ « number » de la table « sn_customerservice_case » dans ServiceNow CSM.
Exemples
CS0010001CS0010045CS0010112
|
|||
|
Heure de l’événement
EventTime
|
Horodatage précis indiquant le moment où une activité ou un événement donné s’est produit. | ||
|
Description
L’heure de l’événement indique la date et l’heure auxquelles une activité a été réalisée. Cet horodatage est indispensable pour ordonner les événements chronologiquement et calculer les durées entre les différentes étapes du processus. Dans une analyse de Process Mining, cet attribut sert à calculer toutes les métriques temporelles, notamment les temps de cycle, les temps d’attente et les durées de traitement. Il permet aux analystes de repérer les goulots d’étranglement en identifiant les activités précédées de longs délais et de mesurer la performance au regard des accords de niveau de service (SLA). Des horodatages exacts et cohérents sont indispensables à la fiabilité de l’analyse.
Pourquoi est-ce important ?
Cet horodatage est essentiel pour ordonner correctement les événements et calculer toutes les métriques de performance, notamment les temps de cycle et les goulots d’étranglement.
Où trouver ces données
Cela correspond généralement au champ « sys_created_on » des tables d’audit et d’historique de ServiceNow (par exemple, « sys_audit »).
Exemples
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
Nom de l’activité
ActivityName
|
Nom d’un événement ou d’une tâche spécifique survenu au cours du cycle de vie de la demande de service. | ||
|
Description
Le nom de l’activité décrit une étape du processus de service client, par exemple « Demande de service créée », « Demande attribuée à un agent » ou « Solution proposée ». Ces activités sont extraites des journaux système ou des mises à jour de tables afin de reconstituer la chronologie des événements pour chaque demande de service. Cet attribut est essentiel pour visualiser la cartographie du processus, repérer les goulots d’étranglement et comprendre le flux de travail. L’analyse de l’ordre et de la fréquence des activités permet aux analystes de découvrir les parcours courants, les écarts et les reprises ou les pertes d’efficacité. Le niveau de détail des activités définies influe directement sur la profondeur des analyses que le modèle de processus peut fournir.
Pourquoi est-ce important ?
Cet attribut est au cœur de la cartographie du processus : il définit les étapes et les tâches dont l’ordre et la durée sont analysés.
Où trouver ces données
Il s’agit d’un attribut conceptuel dérivé des tables d’audit du système (par exemple, « sys_audit ») ou du suivi des changements d’état et des mises à jour de champs clés dans la table « sn_customerservice_case ».
Exemples
Demande de service crééeDemande affectée à un agentInformations demandées au clientDemande de service résolue
|
|||
|
Agent affecté
AssignedAgent
|
Agent du service client actuellement chargé de traiter la demande de service. | ||
|
Description
Cet attribut identifie l’utilisateur responsable de la demande de service à un moment donné. Il change souvent au cours du cycle de vie du cas, lorsque la demande est transmise à différents agents ou spécialistes. L’analyse de l’agent affecté est essentielle pour comprendre la répartition de la charge de travail, la performance des agents et les transferts. Elle permet de répondre à des questions telles que : quels agents traitent les cas les plus complexes ? À quelle fréquence les cas sont-ils réattribués ? Certains agents sont-ils associés à des délais de résolution plus longs ou à une satisfaction client plus élevée ? Cet attribut est essentiel au Dashboard « Transferts et réaffectations entre agents ».
Pourquoi est-ce important ?
Suit la responsabilité des agents et permet d’analyser la charge de travail, la performance et la fréquence des réaffectations, souvent révélatrices de difficultés dans le processus.
Où trouver ces données
Cela correspond au champ « assigned_to » de la table « sn_customerservice_case ».
Exemples
Beth AnglinDavid LooAbel Tuter
|
|||
|
Catégorie
Category
|
Classification principale de la demande de service, par exemple « Facturation » ou « Problème technique ». | ||
|
Description
La catégorie regroupe les demandes de service selon la nature de la question ou du problème du client. Cette classification est généralement définie lors de la création de la demande et aide à l’acheminer vers le groupe d’affectation approprié. Cet attribut est essentiel pour segmenter l’analyse du processus. En filtrant par catégorie, les analystes peuvent comparer les flux de processus associés aux différents types de demandes. Par exemple, le processus de résolution d’un problème de facturation peut être très différent de celui d’un problème technique. Cet attribut permet de segmenter les données dans presque tous les Dashboards.
Pourquoi est-ce important ?
Permet de ventiler l’analyse par type de demande et de repérer les catégories davantage sujettes aux retards, aux escalades ou aux manquements aux SLA.
Où trouver ces données
Cela correspond au champ « category » de la table « sn_customerservice_case ».
Exemples
Demande d’information / aideCommandesProblèmes liés aux produitsFacturation
|
|||
|
État
State
|
État actuel de la demande de service au cours de son cycle de vie. | ||
|
Description
L’attribut d’état décrit la situation d’une demande de service à un moment donné, par exemple « New », « In Progress », « Awaiting Info », « Resolved » ou « Closed ». Les changements de ce champ servent souvent à définir les activités du modèle de processus. L’analyse de l’état donne une vue d’ensemble de l’avancement des cas. Elle permet de mesurer le temps passé dans certains états, comme « Awaiting Info », qui peut être une source importante de retard. Elle aide également à définir les points de départ et d’arrivée d’indicateurs clés tels que « Délai entre la résolution et la clôture ».
Pourquoi est-ce important ?
Indique l’état d’une demande à tout moment et aide à repérer le temps passé dans des états improductifs tels que « On Hold » ou « Awaiting Information ».
Où trouver ces données
Cela correspond au champ « state » de la table « sn_customerservice_case ».
Exemples
NouveauEn coursInformations utilisateur attenduesRésoluClôturé
|
|||
|
Groupe d’affectation
AssignmentGroup
|
Équipe ou service responsable de la demande de service. | ||
|
Description
Le groupe d’affectation désigne la file d’attente ou l’équipe à laquelle une demande de service est attribuée. Selon la nature du problème, les demandes sont souvent acheminées entre différents groupes, par exemple un centre d’assistance de niveau 1, une équipe technique spécialisée ou un service de facturation. Cet attribut est essentiel pour analyser les transferts entre services et repérer les goulots d’étranglement au niveau des équipes. Il permet de visualiser la circulation du travail entre les différents domaines fonctionnels et peut mettre en évidence les groupes surchargés ou qui ont besoin d’une formation complémentaire. Il contribue directement aux Dashboards « Transferts et réaffectations entre agents » et « Flux du processus ».
Pourquoi est-ce important ?
Indique quelle équipe est responsable du travail, ce qui est essentiel pour analyser la performance et la charge des équipes ainsi que les transferts entre services.
Où trouver ces données
Cela correspond au champ « assignment_group » de la table « sn_customerservice_case ».
Exemples
Centre de servicesDemandes de facturationAssistance technique de niveau 2
|
|||
|
Priorité
Priority
|
Niveau de priorité de la demande de service, qui détermine son degré d’urgence. | ||
|
Description
La priorité indique l’importance d’une demande de service et le degré d’urgence de son traitement. Elle est souvent déterminée en fonction de l’impact de la demande sur le client et de son urgence. Les valeurs courantes vont de critique à faible. En Process Mining, la priorité est une dimension utile pour filtrer et comparer les résultats. Elle permet aux analystes de vérifier si les demandes prioritaires sont effectivement traitées plus rapidement que les demandes moins prioritaires et si les manquements aux SLA sont plus fréquents pour certains niveaux de priorité. Cet attribut est fondamental pour le Dashboard « Temps de cycle de bout en bout des demandes de service ».
Pourquoi est-ce important ?
Permet de segmenter les demandes de service selon leur degré d’urgence et de vérifier que les problèmes critiques sont traités plus rapidement que les autres.
Où trouver ces données
Cela correspond au champ « priority » de la table « sn_customerservice_case ».
Exemples
1 - Critique2 - Élevée3 - Modérée4 - Faible
|
|||
|
SLA dépassé
IsSlaBreached
|
Indicateur booléen qui précise si la demande de service a dépassé l’objectif défini dans le contrat de niveau de service (SLA). | ||
|
Description
Cet attribut calculé indique si une demande de service a été résolue dans le délai convenu. Il prend généralement la valeur 'True' lorsque le délai de résolution dépasse l’objectif du SLA, et 'False' dans le cas contraire. Il permet ainsi de déterminer clairement, pour chaque cas, si le SLA a été respecté. Cet attribut est essentiel au Dashboard « Tendances du respect et du dépassement des SLA » et à l’indicateur « Taux de respect des SLA ». Il simplifie l’analyse en permettant de filtrer et de compter directement les cas où le SLA a été dépassé. Vous pouvez ainsi repérer les types de demandes, les niveaux de priorité ou les équipes les plus souvent associés à ces dépassements.
Pourquoi est-ce important ?
Indique clairement si un cas a été traité dans les délais, une information fondamentale pour mesurer et présenter le respect des SLA.
Où trouver ces données
Calculé à partir du champ 'made_sla' de la table 'task_sla', ou obtenu en comparant le délai de résolution réel au délai prévu.
Exemples
truefalse
|
|||
|
Canal
Channel
|
Canal de communication utilisé pour soumettre la demande de service. | ||
|
Description
Le canal indique le moyen utilisé par le client pour soumettre sa demande, par exemple par e-mail, par téléphone, via un portail web ou par chat. Les caractéristiques du processus et les attentes des clients peuvent varier considérablement d’un canal à l’autre. L’analyse du processus par canal permet d’évaluer l’efficacité de chaque moyen de communication. Elle peut, par exemple, révéler si les demandes soumises par téléphone sont plus souvent résolues dès le premier contact ou si celles envoyées par e-mail ont tendance à présenter des temps de cycle plus longs. Elle contribue directement au Dashboard « Efficacité des canaux de communication ».
Pourquoi est-ce important ?
Aide à évaluer l’efficacité et les résultats des différents canaux d’interaction avec les clients, comme le téléphone, l’e-mail ou le portail web.
Où trouver ces données
Cela correspond généralement au champ « contact_type » de la table « sn_customerservice_case ».
Exemples
TéléphoneE-mailLibre-serviceChat
|
|||
|
Client
Customer
|
Nom ou identifiant du client ou de l’entreprise à l’origine de la demande de service. | ||
|
Description
Cet attribut identifie la partie prenante externe, une personne ou une organisation, à laquelle s’adresse la demande de service. Il fournit le contexte client de chaque cas. L’attribut client permet d’analyser le processus de service du point de vue du client. Il peut servir à repérer les clients qui rencontrent davantage de problèmes ou subissent des délais plus longs. Il peut également être associé à d’autres données client, comme le segment ou la valeur, afin de prioriser les améliorations du processus. Vous pouvez, par exemple, vérifier si les clients à forte valeur bénéficient d’un service plus rapide.
Pourquoi est-ce important ?
Associe le processus à des clients précis et permet d’analyser les niveaux de service et la fréquence des problèmes pour les comptes clés ou les segments de clientèle.
Où trouver ces données
Il peut s’agir du champ « caller_id », « opened_for » ou « account » de la table « sn_customerservice_case », qui fait référence aux tables des utilisateurs ou des entreprises.
Exemples
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
Code de résolution
ResolutionCode
|
Code indiquant le résultat final ou la manière dont la demande de service a été résolue. | ||
|
Description
Le code de résolution est une valeur structurée que l’agent sélectionne lorsqu’il résout un cas. Il précise la nature de la solution, par exemple « Résolu par l’utilisateur », « Erreur connue », « Doublon » ou « Aucune action nécessaire ». Cet attribut est utile à l’analyse des causes profondes. En étudiant la fréquence des différents codes de résolution, les organisations peuvent repérer les problèmes récurrents, les lacunes de connaissances ou les problèmes liés aux produits. Ces informations peuvent ensuite servir à apporter des améliorations et à réduire le volume de certains types de demandes de service.
Pourquoi est-ce important ?
Renseigne sur les résultats des demandes de service et contribue à l’analyse des causes profondes ainsi qu’au repérage des problèmes récurrents.
Où trouver ces données
Cela correspond au champ « close_code » ou à un champ personnalisé de code de résolution dans la table « sn_customerservice_case ».
Exemples
Résolu (solution de contournement)Résolu (définitivement)Non résolu (client sans réponse)Clôturé/résolu par le demandeur
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Horodatage indiquant la dernière extraction ou actualisation des données depuis le système source. | ||
|
Description
Cet attribut enregistre la date et l’heure de la dernière extraction des données. Il indique leur fraîcheur et permet aux utilisateurs de savoir s’ils consultent des informations presque en temps réel ou un instantané historique. Lors de l’analyse, ces métadonnées sont essentielles pour comprendre la période couverte par l’ensemble de données. Elles aident les utilisateurs à interpréter correctement les Dashboards et les indicateurs clés de performance, en sachant, par exemple, que les données sont à jour à l’heure précédente ou à la veille.
Pourquoi est-ce important ?
Indique la fraîcheur des données, un facteur essentiel pour que les analyses de Process Mining restent pertinentes et à jour.
Où trouver ces données
Cet horodatage est généré et ajouté lors du processus d’extraction, de transformation et de chargement des données (ETL).
Exemples
2023-11-20T08:00:00Z
|
|||
|
Nombre de réaffectations
ReassignmentCount
|
Nombre total de fois où la demande de service a été réattribuée à un autre agent ou groupe. | ||
|
Description
Cet attribut est un compteur qui augmente chaque fois que le champ « assigned_to » ou « assignment_group » change. Il mesure simplement le nombre de transferts internes d’un cas. Le nombre de réaffectations mesure directement les difficultés rencontrées dans le processus. Il constitue un indicateur clé du Dashboard « Transferts et réaffectations entre agents » et de l’indicateur « Nombre moyen de transferts entre agents par demande ». Un nombre élevé de réaffectations signale souvent des problèmes d’acheminement initial, des lacunes dans les compétences des agents ou des cas difficiles à catégoriser, autant de facteurs qui allongent les délais de résolution.
Pourquoi est-ce important ?
Mesure directement les inefficacités du processus en comptant les transferts. Un nombre élevé est souvent associé à des délais de résolution plus longs et à une insatisfaction des clients.
Où trouver ces données
Il s’agit du champ de métrique standard « reassignment_count » de la table « task », dont la table « sn_customerservice_case » hérite.
Exemples
0135
|
|||
|
Nombre de réouvertures
ReopenCount
|
Nombre de fois où le client a rouvert une demande de service résolue. | ||
|
Description
Ce compteur indique le nombre de fois où un cas est passé de l’état « Resolved » ou « Closed » à l’état « In Progress » ou « Open ». La réouverture d’un cas suggère que la solution initiale était inefficace ou incomplète. Cet attribut est un indicateur important des reprises et de la qualité de la résolution dès la première tentative. Un nombre élevé de réouvertures signale des problèmes dans le processus de résolution, par exemple des tickets clôturés trop tôt ou un problème sous-jacent du client qui n’a pas été entièrement traité. C’est un indicateur clé pour évaluer l’efficacité des solutions proposées.
Pourquoi est-ce important ?
Signale les échecs de résolution et les reprises. Un nombre élevé de réouvertures indique une faible qualité du processus de résolution et entraîne la frustration des clients.
Où trouver ces données
Cette information est souvent enregistrée dans un champ nommé 'reopen_count' de la table 'sn_customerservice_case' ou d’une table associée.
Exemples
012
|
|||
|
Reprises
IsRework
|
Indicateur booléen qui signale les reprises importantes, par exemple lorsqu’un cas est rouvert ou qu’une investigation est répétée. | ||
|
Description
Cet attribut calculé signale les cas qui présentent des signes d’inefficacité ou de répétition. Il peut être déclenché par des événements tels que 'Service Request Reopened' ou par la répétition, dans un même cas, d’une séquence d’activités comme 'Agent Starts Investigation' suivie de 'Solution Proposed'. Cet indicateur permet de repérer rapidement les cas problématiques et de mesurer le volume global de reprises dans le processus. Il contribue directement au Dashboard « Points de concentration des reprises et répétitions » et à l’indicateur « Taux de reprises ». Les analystes peuvent ainsi se concentrer sur les causes de l’inefficacité sans devoir repérer manuellement les séquences répétitives.
Pourquoi est-ce important ?
Permet de mesurer l’inefficacité du processus en signalant les cas qui comportent des boucles répétitives ou des réouvertures, afin de quantifier les reprises et de cibler les problèmes.
Où trouver ces données
Il s’agit d’un attribut calculé, dérivé lors de la transformation des données à partir de règles métier qui détectent les reprises, par exemple une valeur non nulle de 'ReopenCount' ou la répétition d’activités.
Exemples
truefalse
|
|||
|
Résolution au premier contact
IsFirstContactResolution
|
Indicateur booléen qui précise si la demande a été résolue par le premier agent auquel elle a été attribuée, sans transfert ni escalade. | ||
|
Description
Cet attribut calculé repère les demandes de service résolues efficacement dès le premier échange ou par le premier agent qui a traité le cas. La logique vérifie généralement qu’il n’y a eu aucune réattribution ('ReassignmentCount' vaut 0), aucune activité 'Internal Escalation Triggered' et aucune demande d’informations complémentaires adressée au client. Cet attribut mesure directement un indicateur essentiel du service client et alimente le Dashboard et l’indicateur « Taux de résolution au premier contact ». Il permet de quantifier facilement les résultats et d’analyser les facteurs, comme le canal ou la catégorie de demande, qui contribuent à la résolution au premier contact ou la compliquent.
Pourquoi est-ce important ?
Mesure directement l’efficacité de la première réponse. Un taux élevé de résolution au premier contact est étroitement lié à l’efficacité opérationnelle et à la satisfaction des clients.
Où trouver ces données
Il s’agit d’un attribut calculé, dérivé lors de la transformation des données à partir de règles telles que l’absence de réattribution ('ReassignmentCount' égal à zéro) et l’absence d’activité d’escalade.
Exemples
truefalse
|
|||
|
Système source
SourceSystem
|
Système à partir duquel les données ont été extraites. | ||
|
Description
Cet attribut indique l’origine des données, ce qui est particulièrement important lorsque les informations proviennent de plusieurs systèmes. Pour cette vue du processus, la valeur serait toujours « ServiceNow CSM ». En analyse, cet attribut contribue à la gouvernance des données et au diagnostic des problèmes. Lorsque plusieurs systèmes sources sont concernés, il permet de filtrer le processus pour comprendre son fonctionnement dans un système donné ou comparer les variations entre systèmes.
Pourquoi est-ce important ?
Précise l’origine des données, ce qui clarifie leur provenance dans les environnements comportant plusieurs systèmes et facilite leur gouvernance.
Où trouver ces données
Valeur statique ajoutée lors de la transformation des données pour indiquer l’origine de l’ensemble de données.
Exemples
ServiceNow CSM
|
|||
Activités du service client
| Activité | Description | ||
|---|---|---|---|
|
Demande affectée à un agent
|
Cette activité a lieu lorsqu’une demande de service est affectée à un agent précis pour enquête et résolution. Elle est déduite de la modification du champ assigned_to dans l’enregistrement du dossier. | ||
|
Pourquoi est-ce important ?
Cette étape est essentielle pour mesurer les délais de première réponse et la répartition de la charge de travail entre les agents. Le suivi des réattributions de ce champ met en évidence les inefficacités du processus et les éventuels goulots d’étranglement liés à la disponibilité des agents.
Où trouver ces données
Déduite de l’historique d’audit (sys_audit) de la table sn_customerservice_case, en suivant le renseignement ou la modification du champ assigned_to.
Données à recueillir
Détecter toute modification de la valeur du champ « assigned_to » dans l’historique d’audit du dossier.
Type d’événement
inferred
|
|||
|
Demande de service clôturée
|
Cette dernière activité marque la clôture officielle de l’enregistrement de la demande de service, souvent après une période de confirmation suivant la résolution. Elle est enregistrée lorsque l’état du cas passe à « Closed » et que l’horodatage closed_at est renseigné. | ||
|
Pourquoi est-ce important ?
En tant que fin définitive du processus, cette activité est indispensable au calcul du cycle de vie complet du cas. L’analyse du délai entre « Resolved » et « Closed » révèle les tâches administratives ou les retards.
Où trouver ces données
Déduite de l’historique d’audit lorsque le champ d’état de la table sn_customerservice_case prend la valeur « Closed ». Le champ closed_at est renseigné au même moment.
Données à recueillir
Détecter le passage du champ « state » à « Closed » et utiliser l’horodatage correspondant.
Type d’événement
inferred
|
|||
|
Demande de service créée
|
Cette activité marque le début du processus de service client, lorsqu’un nouveau dossier est officiellement enregistré dans le système. L’événement est explicitement enregistré à l’insertion d’un nouvel enregistrement dans la table sn_customerservice_case. | ||
|
Pourquoi est-ce important ?
Point de départ de chaque dossier, cette activité est essentielle au calcul du temps de cycle de bout en bout et à l’analyse du volume de demandes reçues. Elle déclenche toutes les étapes suivantes du processus ainsi que les compteurs de SLA.
Où trouver ces données
Cet événement correspond à la création d’un enregistrement dans la table sn_customerservice_case. L’horodatage provient du champ sys_created_on.
Données à recueillir
Horodatage de création de l’enregistrement (sys_created_on) dans la table sn_customerservice_case.
Type d’événement
explicit
|
|||
|
Demande de service résolue
|
Cette étape importante indique que l’agent de service a terminé son travail et que le problème est considéré comme résolu. Elle est enregistrée lorsque l’état du cas passe à « Resolved » et que l’horodatage resolved_at est renseigné. | ||
|
Pourquoi est-ce important ?
Cette activité marque la fin du processus de résolution actif. Elle est essentielle au calcul des temps de cycle de résolution et au suivi du respect des SLA. Elle constitue le point final de nombreux indicateurs clés de performance.
Où trouver ces données
Déduite de l’historique d’audit lorsque le champ d’état de la table sn_customerservice_case prend la valeur « Resolved ». Le champ resolved_at est généralement renseigné au même moment.
Données à recueillir
Détecter le passage du champ « state » à « Resolved » et utiliser l’horodatage correspondant.
Type d’événement
inferred
|
|||
|
Escalade interne déclenchée
|
Correspond à l’escalade formelle d’une demande de service vers un niveau d’assistance ou de gestion supérieur afin qu’elle soit résolue. Elle peut être déduite du transfert vers une équipe de niveau supérieur ou de l’activation d’un indicateur. | ||
|
Pourquoi est-ce important ?
Le suivi des escalades aide à repérer les faiblesses du processus, les lacunes de connaissances de l’assistance de première ligne et les types de cas complexes. C’est un indicateur important des difficultés rencontrées dans le processus et de l’insatisfaction des clients.
Où trouver ces données
Peut être déduite du journal d’audit en détectant le changement du champ « assignment_group » vers une équipe d’escalade connue, ou la modification du champ « escalation » dans l’enregistrement du cas.
Données à recueillir
Détecter la modification du champ « escalation » ou le transfert vers un groupe « assignment_group » de niveau supérieur.
Type d’événement
inferred
|
|||
|
Demande catégorisée et priorisée
|
Cette activité correspond au tri initial : la demande de service est classée et reçoit un niveau de priorité qui détermine son degré d’urgence et son routage. Elle est déduite des modifications apportées aux champs de catégorie, de sous-catégorie ou de priorité dans l’historique d’audit du dossier. | ||
|
Pourquoi est-ce important ?
L’analyse de cette activité aide à repérer les retards dans le tri des dossiers et à vérifier que les demandes sont correctement orientées et traitées selon leur degré d’urgence. Elle influe sur le délai avant la première affectation et sur l’efficacité globale de la résolution.
Où trouver ces données
Déduite de l’historique d’audit (sys_audit) de la table sn_customerservice_case, en suivant notamment le premier renseignement ou les modifications des champs de catégorie et de priorité.
Données à recueillir
Détecter la première valeur renseignée ou toute modification des champs « category » ou « priority ».
Type d’événement
inferred
|
|||
|
Demande de service rouverte
|
Cet événement se produit lorsqu’une demande de service précédemment résolue repasse à un état actif, parce que le problème est réapparu ou que la solution n’a pas fonctionné. Il est détecté lorsque l’état passe de « Resolved » à « Work in Progress ». | ||
|
Pourquoi est-ce important ?
Les cas rouverts mesurent directement la qualité de la résolution et sont une cause majeure de reprises. L’analyse de ces événements est essentielle pour améliorer le taux de résolution dès le premier contact et la satisfaction client.
Où trouver ces données
Déduite de l’historique d’audit de la table sn_customerservice_case en repérant le passage du champ d’état de « Resolved » à une valeur active.
Données à recueillir
Détecter le passage du champ « state » de « Resolved » à une valeur active telle que « Work in Progress ».
Type d’événement
inferred
|
|||
|
Enquête de satisfaction envoyée au client
|
Correspond à l’envoi d’une enquête de satisfaction au client après la résolution d’un cas. Cet événement est généralement enregistré lors de la création d’un enregistrement d’enquête associé au cas. | ||
|
Pourquoi est-ce important ?
Cette activité permet de mettre en relation les modes d’exécution du processus et les commentaires des clients. Savoir si et quand les enquêtes sont envoyées est important pour analyser l’efficacité de la boucle de retour.
Où trouver ces données
Il s’agit d’un événement explicite enregistré dans une table dédiée aux enquêtes, telle que asmt_assessment_instance, qui contient une référence à l’enregistrement du cas source.
Données à recueillir
Création d’un enregistrement dans la table « asmt_assessment_instance » associé au cas.
Type d’événement
explicit
|
|||
|
Groupe d’affectation modifié
|
Indique que la responsabilité d’un dossier a été transférée d’une équipe à une autre. Cet événement est déduit du suivi des modifications du champ assignment_group dans l’enregistrement du dossier. | ||
|
Pourquoi est-ce important ?
Le suivi des changements de groupe d’affectation est essentiel pour analyser les transferts entre services et repérer les problèmes de routage récurrents. Une fréquence élevée de cette activité peut révéler un manque de clarté dans la répartition des responsabilités ou la définition des processus.
Où trouver ces données
Déduite de l’historique d’audit (sys_audit) de la table sn_customerservice_case, en suivant les modifications du champ assignment_group.
Données à recueillir
Détecter toute modification de la valeur du champ « assignment_group » dans l’historique d’audit du dossier.
Type d’événement
inferred
|
|||
|
Informations demandées au client
|
Cet événement se produit lorsqu’un agent a besoin d’informations complémentaires du client pour poursuivre le traitement et place le cas en attente. Il est déduit du passage de l’état à une valeur telle que « Awaiting User Info » ou « On Hold ». | ||
|
Pourquoi est-ce important ?
Cette activité est essentielle à l’analyse des « délais d’attente des informations client ». Elle permet d’isoler les retards dus à des dépendances externes et de les distinguer du temps de traitement interne.
Où trouver ces données
Déduite de l’historique d’audit de la table sn_customerservice_case lorsque le champ d’état prend une valeur indiquant que des informations du client sont attendues (par exemple, « Awaiting Info »).
Données à recueillir
Détecter le passage du champ « state » à une valeur désignée comme « en attente du client ».
Type d’événement
inferred
|
|||
|
Informations reçues du client
|
Cette activité marque le moment où le client fournit les informations demandées, ce qui permet à l’agent de reprendre le traitement. Elle est déduite du passage de l’état du cas de « Awaiting User Info » à une valeur active. | ||
|
Pourquoi est-ce important ?
Cet événement met fin à la période d’attente du client et permet de mesurer précisément ses délais de réponse. Il aide à repérer les types de cas ou les clients associés aux délais les plus longs.
Où trouver ces données
Déduite de l’historique d’audit de la table sn_customerservice_case lorsque le champ d’état passe d’une valeur telle que « Awaiting Info » à une valeur active comme « Work in Progress ».
Données à recueillir
Détecter le passage du champ « state » d’une valeur « en attente du client » à une valeur active.
Type d’événement
inferred
|
|||
|
L’agent commence l’investigation
|
Cette activité indique qu’un agent a commencé à traiter activement la demande de service. Elle est généralement déduite du passage de l’état du cas d’une valeur telle que « New » ou « Assigned » à « Work in Progress ». | ||
|
Pourquoi est-ce important ?
Cet événement permet de distinguer le temps passé dans la file d’attente du temps de traitement actif. L’analyse du délai entre l’attribution du cas et le début de l’investigation révèle si les agents tardent à prendre en charge les nouveaux cas.
Où trouver ces données
Déduite du passage du champ d’état du cas à une valeur correspondant à un traitement actif, comme « Work in Progress ». Les valeurs d’état exactes peuvent être configurées et doivent être vérifiées.
Données à recueillir
Détecter le passage du champ « state » d’une valeur d’attente à une valeur active (par exemple, de « New » à « Work in Progress »).
Type d’événement
inferred
|
|||
|
SLA non respecté
|
Indique le moment où une demande de service ne respecte pas un accord de niveau de service défini, par exemple le délai de résolution. Cet événement est calculé en comparant le temps de résolution à l’échéance prévue dans le SLA. | ||
|
Pourquoi est-ce important ?
Le repérage des SLA non respectés est fondamental pour le suivi de la conformité et de la performance. Cet événement aide à déterminer quelles étapes du processus ou quels types de cas contribuent le plus aux manquements aux SLA.
Où trouver ces données
Calculé à partir des enregistrements de la table task_sla associés au cas. Un manquement est constaté si le champ has_breached vaut true ou si actual_elapsed_time dépasse planned_duration.
Données à recueillir
Vérifier l’indicateur « has_breached » dans l’enregistrement task_sla associé.
Type d’événement
calculated
|
|||
|
Solution proposée
|
Cette activité marque le moment où un agent a trouvé une solution et l’a communiquée au client pour confirmation. Elle est souvent déduite du passage de l’état à une valeur telle que « Awaiting Acceptance » ou de l’ajout d’une note de travail spécifique. | ||
|
Pourquoi est-ce important ?
Cette étape marque la transition entre l’investigation et la confirmation et la résolution. L’analyse du temps d’attente de la confirmation du client peut révéler des possibilités de simplifier les dernières étapes du traitement d’un cas.
Où trouver ces données
Déduite du journal d’audit de la table sn_customerservice_case lorsque l’état prend une valeur indiquant qu’une solution a été proposée (par exemple, « Proposed Solution »). Cette valeur peut varier selon la configuration.
Données à recueillir
Détecter le passage du champ « state » à une valeur telle que « Proposed Solution » ou « Awaiting Acceptance ».
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à commencer ?
Utilisez ce modèle pour préparer vos données et repérer les possibilités d’amélioration de vos opérations de service client. Vous pourrez ainsi optimiser le processus et mieux répondre aux besoins des clients.
Améliorez dès aujourd’hui l’efficacité de votre service client
Améliorez la satisfaction client et atteignez un taux de résolution au premier contact de 80 %.
Aucune carte bancaire requise. Commencez en quelques minutes.