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

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

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

Ce modèle de données fournit les étapes nécessaires à la collecte des informations essentielles nécessaires à l'analyse de vos processus de service client. Il décrit les attributs de données essentiels, définit les activités clés à suivre et offre des conseils pour extraire ces informations de votre système source. Utilisez cette ressource pour préparer vos données avec précision et efficacité pour le Process Mining.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d'extraction
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 du service client.
3 Obligatoire 6 Recommandé 9 Facultatif
Nom Descriptionn
Demande de service
ServiceRequest
L'identifiant unique pour chaque demande de service client, cas ou ticket.
Descriptionn

La Demande de Service est l'identifiant de dossier principal qui relie toutes les activités et événements liés à un seul problème client, de la création à la clôture. Elle sert de élément central pour suivre le parcours complet d'une interaction client.\n\nEn Process Mining, cet attribut est indispensable pour reconstruire le flux de processus. Chaque valeur unique de Demande de Service représente une instance du processus, permettant l'analyse des temps de cycle, des parcours et des variations au cas par cas. Il garantit que toutes les étapes, du contact initial à la résolution finale et à la clôture, sont correctement associées à la même demande client.

Pourquoi est-ce important ? :

C'est l'identifiant de cas principal qui connecte toutes les étapes du processus, permettant l'analyse du cycle de vie complet de chaque interaction de service client.

Source des 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
L'horodatage précis indiquant quand une activité ou un événement spécifique s'est produit.
Descriptionn

L'horodatage de l'événement (Event Time) enregistre la date et l'heure auxquelles une activité a été effectuée. Cet horodatage est indispensable pour ordonner les événements chronologiquement et pour calculer les durées entre les différentes étapes du processus.

Dans l'analyse du Process Mining, cet attribut est utilisé pour calculer toutes les métriques temporelles, y compris les temps de cycle, les temps d'attente et les durées de traitement. Il permet aux analystes d'identifier les points de blocage en trouvant les activités précédées de longs retards et de mesurer les performances par rapport aux accords de niveau de service (SLA). Des horodatages précis et cohérents sont essentiels pour une analyse fiable.

Pourquoi est-ce important ? :

Cet horodatage est indispensable pour séquencer correctement les événements et calculer toutes les métriques de performance, telles que les temps de cycle et les points de blocage.

Source des données :

Ceci correspond généralement au champ 'sys_created_on' dans les 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
Le nom d'un événement ou d'une tâche spécifique survenu au cours du cycle de vie de la demande de service.
Descriptionn

Le nom de l'activité décrit une étape du processus de service client, comme 'Demande de service créée', 'Demande affectée à un agent' ou 'Solution proposée'. Ces activités sont extraites des journaux système ou des mises à jour de table pour construire une séquence chronologique d'événements pour chaque demande de service.\n\nCet attribut est impératif pour visualiser la cartographie des processus, identifier les points de blocage et comprendre le flux de travail. En analysant la séquence et la fréquence des activités, les analystes peuvent découvrir les parcours de processus courants, les écarts et les zones de remaniement ou d'inefficacité. La granularité des activités définies a un impact direct sur la profondeur des informations qui peuvent être obtenues du modèle de processus.

Pourquoi est-ce important ? :

Cet attribut constitue l'pilier central de la cartographie des processus, définissant les étapes et les tâches spécifiques dont la séquence et la durée sont analysées.

Source des données :

C'est un attribut conceptuel dérivé des tables d'audit système (par exemple, 'sys_audit') ou par le suivi des changements d'état et des mises à jour des champs clés dans la table 'sn_customerservice_case'.

Exemples
Demande de service crééeDemande assignée à l'agentInformations demandées au clientDemande de service résolue
Agent assigné
AssignedAgent
L'agent de service individuel actuellement affecté au traitement de la demande de service.
Descriptionn

Cet attribut identifie l'utilisateur responsable de la demande de service à un moment donné. Il change souvent tout au long du cycle de vie du cas à mesure que la demande est transférée entre différents agents ou spécialistes.\n\nL'analyse de l'Agent Affecté est indispensablele pour comprendre la répartition de la charge de travail, la performance des agents et les transferts. Elle aide à répondre à des questions telles que quels agents gèrent les cas les plus complexes, à quelle fréquence les cas sont réaffectés, « what-if » certains agents sont associés à des temps de résolution plus longs ou à une satisfaction client plus élevée. C'est impératif pour le tableau de bord 'Transferts d'agents et réaffectations'.

Pourquoi est-ce important ? :

Suivi de la responsabilité des agents, permettant l'analyse de la charge de travail, des performances et de la fréquence des réaffectations, ce qui indique souvent une friction dans le processus.

Source des données :

Ceci correspond au champ 'assigned_to' de la table 'sn_customerservice_case'.

Exemples
Beth AnglinDavid LooAbel Tuter
Catégorie
Category
La classification principale de la demande de service, telle que 'Facturation' ou 'Problème technique'.
Descriptionn

La Catégorie fournit un regroupement de haut niveau pour les demandes de service basé sur la nature de la demande ou du problème du client. Cette classification est généralement effectuée lors de la création initiale de la demande et aide à l'acheminer vers le groupe d'affectation correct.\n\nCet attribut est indispensable pour segmenter l'analyse des processus. En filtrant par Catégorie, les analystes peuvent comparer les flux de processus pour 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'. C'est un attribut clé pour la quasi-totalité des dashboards pour segmenter les données.

Pourquoi est-ce important ? :

Permet de ventiler l'analyse par type de demande, révélant si certaines catégories sont plus sujettes aux retards, aux escalades ou aux non-respects de SLA.

Source des données :

Ceci correspond au champ 'category' de la table 'sn_customerservice_case'.

Exemples
Demande / AideCommandesProblèmes de produitFacturation
État
State
Le statut ou l'état actuel de la demande de service dans son cycle de vie.
Descriptionn

L'attribut État décrit le statut opérationnel d'une demande de service à tout moment, tel que 'Nouveau', 'En cours', 'En attente d'informations', 'Résolu' ou 'Clôturé'. Les changements dans ce champ sont souvent utilisés pour définir les activités dans le modèle de processus.\n\nL'analyse de l'État offre une vue d'ensemble de la position des cas dans le processus. Elle est utilisée pour identifier combien de temps les cas passent dans certains états, comme 'En attente d'informations', ce qui peut être une source significative de retard. Elle aide également à définir les points de début et de fin pour les KPI clés comme le 'Temps de résolution à la clôture'.

Pourquoi est-ce important ? :

Indique le statut d'une demande à tout moment, aidant à identifier le temps passé dans des états non productifs comme 'En attente' ou 'En attente d'informations'.

Source des données :

Ceci correspond au champ 'state' de la table 'sn_customerservice_case'.

Exemples
NouveauEn coursEn attente d'informations utilisateurRésoluClôturé
Groupe d'assignation
AssignmentGroup
L'équipe ou le département responsable de la demande de service.
Descriptionn

Le Groupe d'affectation représente la file d'attente ou l'équipe à laquelle une demande de service est attribuée. Les demandes sont souvent acheminées entre différents groupes, tels qu'un service d'assistance de niveau 1, une équipe technique spécialisée ou un service de facturation, selon la nature du problème.\n\nCet attribut est indispensable pour analyser les transferts interdépartementaux et identifier les points de blocage au niveau de l'équipe. Il aide à visualiser comment le travail circule entre les différentes zones fonctionnelles et peut mettre en évidence les groupes surchargés ou nécessitant une formation supplémentaire. Cela contribue directement au les dashboards 'Transferts d'agents et réaffectations' et 'Flux de processus'.

Pourquoi est-ce important ? :

Identifie quelle équipe est responsable du travail, ce qui est impératif pour analyser les performances des équipes, les charges de travail et les transferts de processus entre départements.

Source des données :

Ceci correspond au champ 'assignment_group' de la table 'sn_customerservice_case'.

Exemples
Centre de servicesDemandes de facturationSupport technique de niveau 2
Priorité
Priority
Le niveau de priorité de la demande de service, qui influence son urgence.
Descriptionn

La Priorité indique l'importance et l'urgence requise pour traiter une demande de service. Elle est souvent déterminée par une combinaison de l'impact de la demande sur le client et de son urgence. Les valeurs courantes vont de Critique à Faible.\n\nEn Process Mining, la Priorité est une dimension essentielle pour le filtrage et la comparaison. Elle permet aux analystes de vérifier si les demandes de haute priorité sont effectivement traitées plus rapidement que celles de faible priorité, et de voir si les violations de SLA sont plus fréquentes pour certains niveaux de priorité. C'est indispensable pour le tableau de bord 'Temps de cycle complet des demandes de service'.

Pourquoi est-ce important ? :

Cela permet de segmenter les demandes de service par urgence, ce qui est indispensable pour vérifier que les problèmes critiques sont traités plus rapidement que les problèmes non critiques.

Source des données :

Ceci correspond au champ 'priority' de la table 'sn_customerservice_case'.

Exemples
1 - Critique2 - Élevée3 - Modérée4 - Faible
SLA dépassé
IsSlaBreached
Un indicateur booléen précisant si la demande de service a dépassé sa cible d'accord de niveau de service (SLA) définie.
Descriptionn

Cet attribut calculé indique si une demande de service a été résolue dans le délai convenu. Il est généralement 'Vrai' si le temps de résolution a dépassé l'objectif SLA et 'Faux' dans le cas contraire. Cela fournit un résultat binaire clair pour la performance SLA de chaque cas.\n\nCet attribut est indispensable pour le tableau de bord 'Tendances d'adhérence et de violation des SLA' et le KPI 'Taux d'adhérence aux SLA'. Il simplifie l'analyse en permettant le filtrage et le dénombrement directs des cas non conformes, facilitant l'identification des types de demandes, des priorités ou des équipes les plus souvent associés aux violations de SLA.

Pourquoi est-ce important ? :

Fournit une réponse claire par oui ou par non quant à savoir si un cas a respecté son délai, ce qui est indispensable pour mesurer et rendre compte de la conformité aux SLA.

Source des données :

Calculé sur la base du champ 'made_sla' de la table 'task_sla', ou dérivé en comparant le temps de résolution réel au temps de résolution prévu.

Exemples
truefaux
Canal
Channel
Le canal de communication par lequel la demande de service a été initiée.
Descriptionn

Le Canal indique la méthode utilisée par le client pour soumettre sa demande, par exemple, 'E-mail', 'Téléphone', 'Portail Web' ou 'Chat'. Différents canaux peuvent avoir des caractéristiques de processus et des attentes client significativement différentes.\n\nL'analyse du processus par Canal aide à évaluer l'efficacité de chaque méthode de communication. Par exemple, elle peut révéler si les demandes soumises par 'Téléphone' ont un taux de résolution au premier contact plus élevé ou si les demandes par 'E-mail' ont tendance à avoir des temps de cycle plus longs. Cela contribue directement au le tableau de bord 'Efficacité des canaux de communication'.

Pourquoi est-ce important ? :

Aide à déterminer l'efficacité et les résultats des différents canaux d'interaction client, tels que le téléphone, l'e-mail ou le portail web.

Source des données :

Ceci correspond généralement au champ 'contact_type' de la table 'sn_customerservice_case'.

Exemples
TéléphoneE-mailSelf-serviceChat
Client
Customer
Le nom ou l'identifiant du client ou de l'entreprise qui a initié la demande de service.
Descriptionn

Cet attribut identifie la partie prenante externe, qu'il s'agisse d'un individu ou d'une organisation, pour laquelle la demande de service est destinée. Il fournit le contexte client pour chaque cas.\n\nEn analyse, l'attribut Client permet une vue du processus de service orientée client. Il peut être utilisé pour identifier si certains clients rencontrent plus de problèmes ou des retards plus longs, et peut être joint à d'autres données client, comme le segment ou la valeur, pour prioriser les efforts d'amélioration des processus. Par exemple, on pourrait vérifier si les clients à forte valeur reçoivent un service plus rapide.

Pourquoi est-ce important ? :

Lie le processus à des clients spécifiques, permettant l'analyse des niveaux de service et de la fréquence des problèmes pour les comptes clés ou les segments de clientèle.

Source des données :

Cela pourrait être le champ 'caller_id', 'opened_for' ou 'account' sur la table 'sn_customerservice_case', qui référencent des tables d'utilisateurs ou d'entreprises.

Exemples
John SmithACME CorporationGlobal Tech Inc.
Code de Résolution
ResolutionCode
Un code indiquant le résultat final ou la manière dont la demande de service a été résolue.
Descriptionn

Le Code de Résolution est une valeur structurée sélectionnée par l'agent lors de la résolution d'un cas. Il fournit des détails spécifiques sur la solution, tels que 'Résolu par l'utilisateur', 'Erreur connue', 'Duplicata' ou 'Aucune action nécessaire'.\n\nCet attribut est précieux pour l'analyse des causes profondes. En analysant la fréquence des différents codes de résolution, les organisations peuvent identifier les problèmes récurrents, les lacunes de connaissances ou les problèmes de produit. Ces informationsns peuvent ensuite être utilisées pour apporter des améliorations qui réduisent le volume de certains types de demandes de service.

Pourquoi est-ce important ? :

Fournit un aperçu des résultats des demandes de service, ce qui est impératif pour l'analyse des causes profondes et l'identification des problèmes récurrents.

Source des données :

Ceci correspond au champ 'close_code' ou à un champ de code de résolution personnalisé de la table 'sn_customerservice_case'.

Exemples
Résolu (solution de contournement)Résolu (définitivement)Non résolu (client non réactif)Clôturé/Résolu par l'appelant
Dernière mise à jour des données
LastDataUpdate
L'horodatage indiquant la dernière extraction ou le dernier rafraîchissement des données depuis le système source.
Descriptionn

Cet attribut consigne la date et l'heure de la dernière extraction de données. Il fournit un contexte sur la la réactualisation des données analysées, garantissant que les utilisateurs savent s'ils consultent des informations quasi-temps réel ou un instantané historique.\n\nLors de l'analyse, il s'agit d'une métadonnée essentielle pour comprendre la fenêtre temporelle de l'ensemble de données. Elle aide les utilisateurs à interpréter correctement les dashboards et les KPI, en sachant, par exemple, que les données sont à jour de la dernière heure ou de la veille.

Pourquoi est-ce important ? :

Indique la la réactualisation des données, ce qui est impératif pour la pertinence et l'actualité des informations du Process Mining.

Source des données :

Ce horodatage est généré et ajouté pendant le processus d'extraction, de transformation et de chargement des données (ETL).

Exemples
2023-11-20T08:00:00Z
Est un reprises
IsRework
Un indicateur booléen qui signale si des reprises de travail importantes ont eu lieu, comme un dossier rouvert ou une enquête répétée.
Descriptionn

Cet attribut calculé signale les cas présentant des modèles d'inefficacité ou de répétition. La logique de ce drapeau peut être déclenchée par des événements tels que 'Demande de service réouverte' ou si une séquence clé d'activités, comme 'L'agent commence l'investigation' suivie de 'Solution proposée', se produit plusieurs fois dans le même cas.\n\nCe drapeau est très utile pour identifier rapidement les cas problématiques et quantifier le niveau global de remaniement dans le processus. Il prend directement en charge le tableau de bord 'Points chauds de remaniement et de répétition' et le KPI 'Taux de remaniement', permettant aux analystes de se concentrer sur les facteurs d'inefficacité sans avoir besoin d'identifier manuellement les modèles répétitifs.

Pourquoi est-ce important ? :

Aide à quantifier l'inefficacité des processus en signalant les dossiers avec des boucles répétitives ou des événements de réouverture, ce qui facilite la mesure et le ciblage des reprises de travail.

Source des données :

C'est un attribut calculé. Il est dérivé lors de la transformation des données en appliquant une logique métier qui détecte les modèles de remaniement, tels qu'un 'ReopenCount' non nul ou des activités répétées.

Exemples
truefaux
Est-ce une Résolution au Premier Contact
IsFirstContactResolution
Un indicateur booléen indiquant si la demande a été résolue par le premier agent assigné sans transferts ni escalades.
Descriptionn

Cet attribut calculé identifie les demandes de service qui ont été résolues efficacement lors de la première interaction ou par le premier agent ayant traité le cas. La logique vérifie généralement des conditions telles que zéro réaffectation ('ReassignmentCount' est 0), aucune activité 'Escalade interne déclenchée' et aucune demande d'informations supplémentaires de la part du client.\n\nCet attribut mesure directement une indicateur clé du service client et soutient le tableau de bord et le KPI 'Taux de résolution au premier contact'. Il permet une quantification facile de la performance RPT et aide à analyser les facteurs, tels que le canal ou la catégorie de demande, qui contribuent ou entravent la résolution au premier contact.

Pourquoi est-ce important ? :

Mesure directement l'efficacité de la réponse initiale. Un taux de FCR élevé est fortement lié à l'efficacité opérationnelle et à une satisfaction client élevée.

Source des données :

C'est un attribut calculé. Il est dérivé lors de la transformation des données sur la base de règles, telles que le 'ReassignmentCount' étant zéro et l'absence d'activités d'escalade.

Exemples
truefaux
Nombre de Réaffectations
ReassignmentCount
Le nombre total de fois où la demande de service a été réaffectée à un agent ou un groupe différent.
Descriptionn

Cet attribut est un compteur qui s'incrémente chaque fois que le champ 'assigned_to' ou 'assignment_group' change. Il fournit une métrique simple de la quantité de transferts internes qu'un cas a subis.\n\nLe Compteur de réaffectations est une mesure directe de la friction de processus et un élément clé pour le tableau de bord 'Transferts d'agents et réaffectations' et le KPI 'Nombre moyen de transferts d'agents par demande'. Un nombre élevé de réaffectations indique souvent des problèmes de routage initial, des lacunes de compétences des agents ou des cas difficiles à catégoriser, qui entraînent tous des temps de résolution plus longs.

Pourquoi est-ce important ? :

Mesure directement l'inefficacité du processus en comptant les transferts. Un nombre élevé est souvent corrélé à des temps de résolution plus longs et à l'insatisfaction client.

Source des données :

C'est un champ métrique standard, 'reassignment_count', sur la table 'task', dont 'sn_customerservice_case' hérite.

Exemples
0135
Nombre de réouvertures
ReopenCount
Le nombre de fois qu'une demande de service résolue a été rouverte par le client.
Descriptionn

Ce compteur suit le nombre de fois qu'un cas est passé d'un état 'Résolu' ou 'Clôturé' à un état 'En cours' ou 'Ouvert'. Un cas rouvert suggère que la solution initiale n'était pas efficace ou complète.\n\nCet attribut est un indicateur fort de remaniement et de qualité de la résolution au premier contact. Un nombre élevé de réouvertures signale des problèmes dans le processus de résolution, tels que des agents clôturant prématurément les tickets ou ne traitant pas entièrement le problème sous-jacent du client. C'est une métrique clé pour comprendre l'efficacité des solutions proposées.

Pourquoi est-ce important ? :

Indique les résolutions échouées et les reprises de travail. Un nombre élevé de réouvertures signale une mauvaise qualité du processus de résolution et entraîne une frustration client.

Source des données :

Ceci est souvent suivi dans un champ nommé 'reopen_count' sur la table 'sn_customerservice_case' ou une table associée.

Exemples
012
Système source
SourceSystem
Le système d'où les données ont été extraites.
Descriptionn

Cet attribut identifie l'origine des données, ce qui est particulièrement important dans les environnements où les informations sont agrégées à partir de plusieurs systèmes. Pour cette vue de processus, la valeur serait constamment 'ServiceNow CSM'.\n\nEn analyse, cela aide à la gouvernance des données et au dépannage. Lorsque plusieurs systèmes sources sont impliqués, cela permet de filtrer le processus pour comprendre comment il fonctionne au sein d'un système spécifique ou pour comparer les variations de processus entre différents systèmes.

Pourquoi est-ce important ? :

Fournit un contexte essentiel sur l'origine des données, assurant la clarté dans les environnements multi-systèmes et facilitant la gouvernance des données.

Source des données :

C'est une valeur statique ajoutée pendant le processus de transformation des données pour étiqueter l'origine de l'ensemble de données.

Exemples
ServiceNow CSM
Obligatoire Recommandé Facultatif

Activités (Activities) du service client

Voici les étapes de processus et les jalons clés à capturer dans votre `journal d'événements` pour une `découverte de processus` précise.
5 Recommandé 9 Facultatif
Activité Descriptionn
Demande assignée à l'agent
Cette activité se produit lorsqu'une demande de service est affectée à un agent spécifique pour investigation et résolution. Elle est capturée en déduisant le changement dans le champ assigned_to de l'enregistrement du cas.
Pourquoi est-ce important ? :

C'est une étape cruciale pour mesurer les temps de réponse initiaux et la distribution de la charge de travail des agents. Le suivi des réaffectations de ce champ met en évidence les inefficacités de processus et les points de blocage potentiels en matière de disponibilité des agents.

Source des données :

Inféré de l'historique d'audit (sys_audit) pour la table sn_customerservice_case en suivant le moment où le champ assigned_to est renseigné ou modifié.

Capture

Détecter le changement de valeur pour le champ 'assigned_to' dans le journal d'audit du dossier.

Type d'événement inferred
Demande de service créée
Cette activité marque le début du processus de service client, lorsqu'un nouveau cas est formellement enregistré dans le système. Cet événement est capturé explicitement lors de l'insertion d'un nouvel enregistrement dans la table sn_customerservice_case.
Pourquoi est-ce important ? :

En tant que point de départ pour chaque cas, cette activité est indispensablele pour calculer le temps de cycle complet et analyser les volumes d'entrée des demandes. Elle sert de déclencheur pour tous les processus en aval et les chronomètres SLA.

Source des données :

Cet événement correspond à la création d'un enregistrement dans la table sn_customerservice_case. L'horodatage est tiré du champ sys_created_on.

Capture

Horodatage de création de l'enregistrement (sys_created_on) dans la table sn_customerservice_case.

Type d'événement explicit
Demande de service fermée
C'est l'activité finale, marquant la clôture formelle de l'enregistrement de la demande de service, souvent après une période de confirmation post-résolution. Elle est capturée lorsque l'état du cas passe à 'Clôturé' et que l'horodatage closed_at est défini.
Pourquoi est-ce important ? :

En tant que fin définitive du processus, cette activité est indispensablele pour calculer le cycle de vie complet du dossier. L'analyse du temps entre 'Résolu' et 'Clôturé' révèle les frais administratifs ou les retards.

Source des données :

Inféré de l'historique d'audit lorsque le champ état de la table sn_customerservice_case est défini sur 'Clôturé'. Le champ closed_at est renseigné en même temps.

Capture

Détecter le changement d'état à 'Clôturé' et utiliser l'horodatage correspondant.

Type d'événement inferred
Demande de service résolue
C'est une étape clé indiquant que l'agent de service a terminé le travail et que le problème est considéré comme résolu. Cela est capturé lorsque l'état du cas passe à 'Résolu' et que l'horodatage resolved_at est renseigné.
Pourquoi est-ce important ? :

Cette activité marque la fin du processus de résolution active et est indispensablele pour le calcul des temps de cycle de résolution et du respect des SLA. Elle sert de point d'extrémité principal pour de nombreux KPI d'efficacité.

Source des données :

Inféré de l'historique d'audit lorsque le champ état de la table sn_customerservice_case est défini sur 'Résolu'. Le champ resolved_at est généralement renseigné en même temps.

Capture

Détecter le changement d'état à 'Résolu' et utiliser l'horodatage correspondant.

Type d'événement inferred
Escalade interne déclenchée
Représente l'escalade formelle d'une demande de service à un niveau de support ou de gestion supérieur pour résolution. Cela peut être déduit d'un changement de groupe d'affectation vers une équipe de niveau supérieur ou de l'activation d'un indicateur.
Pourquoi est-ce important ? :

Le suivi des escalades aide à identifier les faiblesses des processus, les lacunes de connaissances dans le support de première ligne et les types de cas complexes. C'est un indicateur clé de la friction des processus et de l'insatisfaction client.

Source des données :

Peut être inféré à partir du journal d'audit en détectant un changement dans le 'assignment_group' vers une équipe d'escalade connue, ou un changement dans le champ 'escalation' sur l'enregistrement du dossier.

Capture

Détecter un changement dans le champ 'escalade' ou un passage à un 'assignment_group' de niveau supérieur.

Type d'événement inferred
Demande catégorisée et priorisée
Représente le triage initial où la demande de service est classifiée et se voit attribuer un niveau de priorité pour déterminer son urgence et son acheminement. Cela est déduit des changements apportés aux champs de catégorie, sous-catégorie ou priorité dans le journal d'audit de l'enregistrement du cas.
Pourquoi est-ce important ? :

L'analyse de cette activité aide à identifier les retards dans le triage des dossiers et garantit que les demandes sont acheminées correctement et traitées en fonction de l'urgence. Cela a un impact sur le temps de la première affectation et l'efficacité globale de la résolution.

Source des données :

Inféré de l'historique d'audit (sys_audit) pour la table sn_customerservice_case, en suivant spécifiquement le renseignement initial ou les mises à jour des champs catégorie et priorité.

Capture

Détecter la première valeur définie ou le changement de valeur pour les champs 'catégorie' ou 'priorité'.

Type d'événement inferred
Demande de service réouverte
Se produit lorsqu'une demande de service précédemment résolue est ramenée à un état actif parce que le problème a réapparu ou que la solution était inefficace. Cela est déduit en détectant un changement d'état de 'Résolu' à 'Travail en cours'.
Pourquoi est-ce important ? :

Les cas réouverts sont une mesure directe de la qualité de la résolution et un facteur principal de la reprise du travail. L'analyse de ces événements est indispensablele pour améliorer les taux de résolution au premier contact et la satisfaction client.

Source des données :

Inféré de l'historique d'audit de la table sn_customerservice_case en identifiant une séquence où le champ état passe de 'Résolu' à un état actif.

Capture

Détecter le changement d'état de 'Résolu' à une valeur active comme 'En cours'.

Type d'événement inferred
Enquête de satisfaction client envoyée
Représente l'envoi d'une enquête de satisfaction client suite à la résolution d'un cas. Cet événement est généralement capturé lorsqu'un enregistrement d'instance d'enquête est créé et associé au cas.
Pourquoi est-ce important ? :

Cette activité aide à corréler les modèles d'exécution des processus avec les retours clients. Comprendre quand « what-if » les enquêtes sont envoyées est important pour analyser l'efficacité de la boucle de rétroaction.

Source des données :

Il s'agit d'un événement explicite enregistré dans une table spécifique aux enquêtes comme asmt_assessment_instance, qui contient une référence à l'enregistrement du cas source.

Capture

Création d'un enregistrement dans la table 'asmt_assessment_instance' liée au cas.

Type d'événement explicit
Groupe d'affectation changé
Indique que la responsabilité d'un dossier a été transférée d'une équipe à une autre. Cet événement est inféré en surveillant les modifications du champ assignment_group dans l'enregistrement du dossier.
Pourquoi est-ce important ? :

Le suivi des changements de groupes d'affectation est impératif pour analyser les transferts interdépartementaux et identifier les problèmes de routage systématiques. Une fréquence élevée de cette activité peut indiquer une propriété ou des définitions de processus peu claires.

Source des données :

Inféré de l'historique d'audit (sys_audit) pour la table sn_customerservice_case en suivant le moment où le champ assignment_group est modifié.

Capture

Détecter le changement de valeur pour le champ 'assignment_group' dans le journal d'audit du dossier.

Type d'événement inferred
Informations demandées au client
Se produit lorsqu'un agent a besoin d'informations supplémentaires du client pour poursuivre et place le cas dans un état d'attente. Cela est déduit d'un changement d'état vers une valeur telle que 'En attente d'informations utilisateur' ou 'En attente'.
Pourquoi est-ce important ? :

Cette activité est indispensablele pour l'analyse des 'Temps d'attente d'informations client'. Elle isole les retards de processus causés par des dépendances externes, les séparant du temps de traitement interne.

Source des données :

Inféré de l'historique d'audit de la table sn_customerservice_case lorsque le champ état passe à une valeur indiquant qu'il est en attente d'une saisie client (par exemple, 'En attente d'informations').

Capture

Détecter le changement dans le champ 'état' vers une valeur désignée 'en attente client'.

Type d'événement inferred
Informations reçues du client
Cette activité marque le moment où le client fournit les informations demandées, permettant à l'agent de reprendre le travail. Elle est déduite lorsque l'état du cas passe de 'En attente d'informations utilisateur' à un état actif.
Pourquoi est-ce important ? :

Cet événement conclut la période d'attente du client, permettant une mesure précise des temps de réponse client. Il aide à identifier quels types de cas ou quels clients sont associés aux retards les plus longs.

Source des données :

Inféré de l'historique d'audit de la table sn_customerservice_case lorsque le champ état passe d'un statut 'En attente d'informations' à un état actif comme 'En cours'.

Capture

Détecter le changement dans le champ 'état' d'une valeur 'en attente client' à nouveau vers une valeur active.

Type d'événement inferred
L'agent démarre l'enquête
Cette activité signifie qu'un agent a activement commencé à travailler sur la demande de service. Elle est généralement déduite lorsque l'état du cas passe d'un statut tel que 'Nouveau' ou 'Affecté' à 'Travail en cours'.
Pourquoi est-ce important ? :

Cet événement aide à distinguer le temps d'attente en file d'attente du temps de travail actif. L'analyse de la durée entre l'affectation et le début de l'investigation révèle des retards dans la prise en charge des nouveaux cas par les agents.

Source des données :

Déduit du changement du champ d'état du cas vers un état de travail actif, tel que 'Travail en cours'. Les valeurs d'état spécifiques peuvent être configurées et doivent être vérifiées.

Capture

Détecter le changement dans le champ 'état' d'une valeur en attente à une valeur active (par exemple, 'Nouveau' à 'En cours').

Type d'événement inferred
SLA Non Respecté
Représente le moment où une demande de service ne respecte pas un accord de niveau de service défini, tel que le temps de résolution. Il s'agit d'un événement calculé, dérivé en comparant le temps de résolution à l'heure de fin prévue du SLA.
Pourquoi est-ce important ? :

L'identification des non-respects de SLA est clée pour le suivi de la conformité et la gestion des performances. Cet événement aide à identifier les étapes du processus ou les types de dossiers qui contribuent le plus aux violations de SLA.

Source des données :

Calculé en analysant les enregistrements de la table task_sla liés au dossier. Un non-respect se produit si le champ has_breached est vrai, ou si le actual_elapsed_time dépasse le planned_duration.

Capture

Vérifier l'indicateur 'has_breached' sur l'enregistrement task_sla lié.

Type d'événement calculated
Solution Proposée
Cette activité marque le moment où un agent a identifié une solution et l'a communiquée au client pour sa confirmation. Elle est souvent déduite d'un changement d'état vers une valeur telle que 'En attente d'acceptation' ou d'une entrée spécifique dans le journal de travail.
Pourquoi est-ce important ? :

Cette étape sépare la phase d'investigation de la phase de confirmation et de résolution. L'analyse du temps passé à attendre la confirmation du client peut révéler des opportunités de rationaliser les étapes de clôture d'un cas.

Source des données :

Inféré du journal d'audit de la table sn_customerservice_case lorsque l'état passe à une valeur indiquant une solution proposée (par exemple, 'Solution proposée'). Cela peut varier selon l'implémentation).

Capture

Détecter le changement dans le champ 'état' vers une valeur comme 'Solution proposée' ou 'En attente d'acceptation'.

Type d'événement inferred
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de ServiceNow CSM