Il Suo Template dei dati del servizio clienti

Microsoft Dynamics 365 Customer Service
Il Suo Template dei dati del servizio clienti

Il Suo Template dei dati del servizio clienti

Questo Template offre un approccio strutturato alla raccolta dei dati essenziali necessari per un'analisi approfondita del processo di assistenza clienti. Indica gli attributi fondamentali da raccogliere, le attività chiave da monitorare e fornisce indicazioni su come estrarre queste informazioni in modo efficace.
  • Attributi consigliati da raccogliere
  • Attività chiave da monitorare
  • Indicazioni per l'estrazione da Microsoft Dynamics 365 Customer Service
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi del servizio clienti

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del processo di servizio clienti.
5 Obbligatorio 7 Consigliato 8 Facoltativo
Nome Descrizione
Richiesta di assistenza
ServiceRequest
L'identificativo univoco di una richiesta di assistenza, nota anche come caso o ticket.
Descrizione

La Service Request funge da identificativo principale e collega tutte le attività relative a una singola richiesta o a un singolo problema del cliente. Agisce come Case ID per il Process Mining, garantendo una visione completa e coerente di ogni interazione con il cliente, dalla creazione alla chiusura. L'analisi per Service Request consente di monitorare il percorso end-to-end, misurare i tempi di risoluzione e individuare pattern tra casi simili.

Perché è importante

È il Case ID essenziale che collega tutti gli eventi correlati in una singola istanza di processo, rendendo possibile l'analisi end-to-end del processo.

Dove reperirlo

È la chiave primaria dell'entità Case (incident) in Microsoft Dynamics 365 Customer Service.

Esempi
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
Attività
ActivityName
Il nome dello specifico evento aziendale che si è verificato in un determinato momento per una richiesta di assistenza.
Descrizione

Questo attributo descrive un singolo passaggio o una modifica di stato all'interno del processo di customer service, come «Case Created», «Agent Investigated Issue» o «Case Resolved». Queste attività costituiscono la struttura portante della mappa di processo e consentono di visualizzare e analizzare il flusso del processo. Ogni attività, combinata con un timestamp, crea un evento che definisce la sequenza del processo.

Perché è importante

Le attività definiscono i passaggi del processo. Analizzare la sequenza e la frequenza delle attività è fondamentale per comprendere i flussi di processo, individuare le deviazioni e trovare i colli di bottiglia.

Dove reperirlo

In genere viene ricavata associando le modifiche di stato («statuscode») o eventi specifici provenienti da entità correlate, come Task, Email o Phone Call, a un nome di attività standardizzato.

Esempi
Caso creatoAgente ha analizzato il problemaSoluzione proposta al clienteCaso chiuso
Ora di inizio
EventTime
Il timestamp che indica quando si è verificata l'attività.
Descrizione

Questo attributo registra la data e l'ora precise in cui si è svolta una specifica attività. È essenziale per ordinare correttamente gli eventi e per tutte le analisi basate sul tempo, inclusi il calcolo dei tempi di ciclo, delle durate e dei tempi di attesa tra le attività. Un timestamp accurato e coerente è fondamentale per l'integrità dell'analisi di Process Mining.

Perché è importante

Questo timestamp ordina cronologicamente gli eventi e consente tutti i calcoli basati sulla durata, fondamentali per l'analisi delle prestazioni e l'identificazione dei colli di bottiglia.

Dove reperirlo

Corrisponde a campi come «createdon» o «modifiedon» dell'entità Case (incident) o di entità correlate alle attività, ad esempio Email, Task o Phone Call.

Esempi
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
Sistema di origine
SourceSystem
Identifica il sistema di origine dal quale sono stati estratti i dati.
Descrizione

Questo attributo specifica l'origine dei dati degli eventi. Per questo processo identificherà sempre Microsoft Dynamics 365 Customer Service come sistema di origine. In ambienti con più sistemi, questo campo è fondamentale per distinguere le fonti dei dati e garantire la tracciabilità dei dati.

Perché è importante

Fornisce una tracciabilità chiara dei dati, fondamentale per la governance dei dati e per la risoluzione delle incoerenze, soprattutto nelle analisi che combinano più sistemi.

Dove reperirlo

In genere è un valore statico aggiunto durante l'estrazione e la trasformazione dei dati per indicare l'origine del dataset.

Esempi
Microsoft Dynamics 365 Customer Service
Ultimo aggiornamento dei dati
LastDataUpdate
Il timestamp dell'ultimo aggiornamento o dell'ultima estrazione dei dati dal sistema di origine.
Descrizione

Questo attributo indica quando i dati sono stati estratti l'ultima volta da Microsoft Dynamics 365. Viene utilizzato per comprendere l'aggiornamento dei dati analizzati ed è essenziale per le attività di reporting e monitoraggio. Consente agli utenti di conoscere la tempestività dei dati quando interpretano Dashboard e analisi.

Perché è importante

Informa gli utenti sull'aggiornamento dei dati, un aspetto fondamentale per prendere decisioni aziendali tempestive e accurate sulla base dell'analisi del processo.

Dove reperirlo

Questo valore viene generato e applicato al dataset al momento dell'estrazione dei dati.

Esempi
2023-10-27T08:00:00Z
Canale
Channel
Il canale di comunicazione attraverso il quale è stata avviata la richiesta di assistenza.
Descrizione

Questo attributo identifica l'origine dell'interazione con il cliente, ad esempio Phone, Email, Web Portal o Chat. Canali diversi presentano spesso flussi di processo, aspettative dei clienti e livelli di complessità della risoluzione differenti. Analizzare il processo per canale aiuta a ottimizzare i Workflow specifici del canale e l'allocazione delle risorse.

Perché è importante

Fornisce informazioni sull'impatto dei diversi canali di contatto con il cliente sull'efficienza del processo, sui tempi di risoluzione e sulla soddisfazione del cliente.

Dove reperirlo

Corrisponde al campo «Case Origin» («caseorigincode») dell'entità Case (incident).

Esempi
TelefonoE-mailWebChat
Motivo dello stato
StatusReason
Fornisce un motivo più dettagliato dello stato attuale della richiesta di assistenza.
Descrizione

Sebbene un caso abbia uno stato generale come «Active» o «Resolved», il motivo dello stato fornisce un contesto più specifico, ad esempio «Information Provided» o «Problem Solved». Questo attributo è fondamentale per comprendere le sfumature del modo e delle ragioni per cui i casi avanzano nel loro ciclo di vita. Ad esempio, può distinguere i casi risolti con successo da quelli annullati dal cliente, un elemento essenziale per un'analisi accurata degli esiti.

Perché è importante

Offre una visione dettagliata dell'esito di un caso e delle ragioni delle modifiche di stato, consentendo un'analisi più precisa dei percorsi di risoluzione e delle cause principali.

Dove reperirlo

Corrisponde al campo «Status Reason» («statuscode») dell'entità Case (incident).

Esempi
In corsoIn sospesoProblema risoltoInformazioni fornite
Nome del cliente
CustomerName
Il nome del cliente o dell'account associato alla richiesta di assistenza.
Descrizione

Questo attributo identifica il cliente che ha avviato la richiesta di assistenza. Consente di analizzare il processo da una prospettiva incentrata sul cliente e di individuare quali clienti inviano più richieste, sperimentano i tempi di risoluzione più lunghi o presentano i problemi più complessi. È essenziale per gestire le relazioni con i clienti e migliorare l'erogazione del servizio per ciascun cliente.

Perché è importante

Consente un'analisi a livello di cliente per individuare pattern, migliorare il servizio per gli account strategici e comprendere il percorso del cliente.

Dove reperirlo

È il campo di ricerca «Customer» («customerid») dell'entità Case (incident), che può puntare a un record Account o Contact.

Esempi
Global Tech Inc.Jane DoeInnovate Solutions
Nome dell'agente
AgentName
Il nome dell'agente del customer service o dell'utente responsabile dell'attività.
Descrizione

Questo attributo identifica l'agente specifico o l'utente di sistema che ha eseguito un'attività, ad esempio prendere in carico un elemento da una coda o risolvere un caso. È fondamentale per analizzare le prestazioni degli agenti, la distribuzione del carico di lavoro e l'allocazione delle risorse. Monitorando le attività a livello di agente, le organizzazioni possono individuare i migliori risultati, le esigenze di formazione e gli squilibri nel carico di lavoro.

Perché è importante

Consente di analizzare le prestazioni individuali e del team, contribuisce a bilanciare il carico di lavoro e individua opportunità di coaching per migliorare la qualità complessiva del servizio.

Dove reperirlo

Corrisponde al campo «Owner» («ownerid») dell'entità Case (incident), collegato all'entità System User («systemuser»).

Esempi
Alice SmithBob JohnsonSistema
Priorità
Priority
Il livello di priorità assegnato alla richiesta di assistenza, che ne indica l'urgenza.
Descrizione

Questo attributo definisce l'urgenza di una richiesta di assistenza, generalmente classificata come Low, Normal, High o Urgent. La priorità viene utilizzata per determinare l'ordine di gestione dei casi e spesso stabilisce gli obiettivi SLA. Analizzare l'impatto della priorità sul flusso del processo, sull'allocazione delle risorse e sui tempi di risoluzione è fondamentale per garantire una gestione tempestiva dei problemi critici.

Perché è importante

Aiuta a comprendere se le richieste ad alta priorità vengono elaborate più rapidamente e raggiungono i relativi obiettivi, nonché in che modo i livelli di priorità influenzano le prestazioni complessive del processo.

Dove reperirlo

Corrisponde al campo «Priority» («prioritycode») dell'entità Case (incident).

Esempi
BassaNormaleAlta
Tempo obiettivo di risoluzione SLA
SlaTargetResolutionTime
Il tempo obiettivo concordato contrattualmente per risolvere la richiesta di assistenza.
Descrizione

Questo attributo specifica la durata obiettivo entro la quale una richiesta di assistenza dovrebbe essere risolta in base allo SLA attivo. Costituisce il parametro di riferimento rispetto al quale vengono misurate le prestazioni effettive. Questo valore è fondamentale per la Dashboard SLA Compliance Monitoring e per il calcolo del KPI SLA Compliance Rate, mettendo in evidenza i casi in cui il processo non rispetta gli impegni di servizio.

Perché è importante

È il principale parametro di riferimento per misurare le prestazioni del servizio rispetto agli impegni assunti e consente direttamente di analizzare la conformità agli SLA e le violazioni.

Dove reperirlo

Questo valore è determinato dalla configurazione dello SLA in Dynamics 365 ed è associato a un caso tramite le SLA KPI Instances.

Esempi
2592008640014400
Tipo di richiesta di assistenza
ServiceRequestType
La categoria o classificazione principale della richiesta di assistenza.
Descrizione

Questo attributo categorizza la richiesta di assistenza in base alla sua natura, ad esempio «Billing Inquiry», «Technical Support» o «Product Feedback». È fondamentale per segmentare l'analisi del processo e comprendere come vengono gestiti i diversi tipi di richiesta. L'analisi per tipo può rivelare che alcune categorie presentano tempi di risoluzione più lunghi, tassi di escalation più elevati o seguono percorsi di processo differenti.

Perché è importante

Consente di segmentare il processo per individuare colli di bottiglia specifici per tipo, esigenze di risorse e opportunità di miglioramento, supportando strategie migliori di instradamento e gestione.

Dove reperirlo

Queste informazioni sono spesso memorizzate nel campo «Subject» («subjectid») o in un campo categoria personalizzato dell'entità Case (incident).

Esempi
Richiesta di fatturazioneSupporto tecnicoFeedback sul prodottoGestione dell'account
È oggetto di escalation
IsEscalated
Un flag che indica se la richiesta di assistenza è stata sottoposta a escalation.
Descrizione

Questo attributo booleano indica se una richiesta di assistenza è stata sottoposta a escalation. Le escalation si verificano quando il supporto di primo livello non riesce a risolvere un problema e richiede l'intervento di un team più senior o di uno specialista. Monitorare questo flag è fondamentale per la Dashboard Internal Escalation Pathways e per il KPI Internal Escalation Rate, poiché aiuta a individuare le cause principali delle escalation e le debolezze dei livelli iniziali di supporto.

Perché è importante

Misura direttamente la frequenza delle escalation, mettendo in evidenza i problemi relativi alla risoluzione al primo contatto e indicando le aree in cui è necessario migliorare il processo o le competenze degli agenti.

Dove reperirlo

Corrisponde al campo «Is Escalated» («isescalated») dell'entità Case (incident).

Esempi
truefalse
È oggetto di rilavorazione
IsRework
Un flag calcolato che indica se un caso ha comportato attività di rilavorazione.
Descrizione

Questo flag booleano identifica i casi che contengono loop di rilavorazione o attività ripetute, come più eventi «Information Requested From Customer» o un evento «Case Reactivated» successivo alla risoluzione. Viene calcolato analizzando la sequenza delle attività alla ricerca di pattern che indichino inefficienze o l'incapacità di risolvere correttamente il problema al primo tentativo. Questo attributo è fondamentale per la Dashboard Rework and Repeat Contact Analysis.

Perché è importante

Aiuta a quantificare e isolare le inefficienze del processo, consentendo agli analisti di concentrarsi sulle cause principali del lavoro ripetuto e degli sforzi sprecati.

Dove reperirlo

Calcolato rilevando sequenze specifiche di attività, ad esempio Resolved -> Reactivated, o attività ripetute all'interno di un caso mediante le analisi di Process Mining.

Esempi
truefalse
ID dell'articolo della knowledge base
KnowledgeArticleId
L'identificativo di un articolo della knowledge base collegato alla richiesta di assistenza.
Descrizione

Questo attributo acquisisce l'ID di qualsiasi articolo della knowledge base utilizzato o collegato durante la risoluzione di una richiesta di assistenza. Fornisce una misura diretta dell'efficacia con cui gli agenti utilizzano la knowledge base per risolvere i problemi dei clienti. Questi dati sono fondamentali per la Dashboard Knowledge Article Utilization e per il relativo KPI, poiché aiutano a valutare il valore e la completezza della knowledge base.

Perché è importante

Monitora l'utilizzo della knowledge base e aiuta a comprendere se gli agenti sfruttano le risorse disponibili per risolvere i problemi più rapidamente e con maggiore coerenza.

Dove reperirlo

Queste informazioni si trovano nella relazione tra le entità Case (incident) e Knowledge Article (knowledgearticle).

Esempi
KA-01337KA-02048
Prodotto coinvolto
ProductInvolved
Il prodotto associato alla richiesta di assistenza del cliente.
Descrizione

Questo attributo identifica il prodotto o servizio specifico a cui si riferisce il problema del cliente. Consente di segmentare il processo di assistenza per prodotto e di individuare se determinati prodotti generano più richieste di supporto, presentano problemi più complessi o richiedono competenze specialistiche da parte degli agenti. Questa analisi aiuta a migliorare i prodotti e a pianificare le risorse.

Perché è importante

Consente un'analisi del processo specifica per prodotto, utile per individuare problemi ricorrenti, migliorare la documentazione di supporto e allocare efficacemente le risorse specialistiche.

Dove reperirlo

Corrisponde al campo di ricerca «Product» («productid») dell'entità Case (incident).

Esempi
Stampante Alpha-100Software CRM ZetaPiano dati Omega
Punteggio CSAT
CustomerSatisfactionScore
Il punteggio di soddisfazione fornito dal cliente dopo la risoluzione del caso.
Descrizione

Questo attributo contiene la valutazione numerica o categoriale fornita dal cliente in un sondaggio sulla soddisfazione (CSAT), generalmente raccolta dopo la chiusura di una richiesta di assistenza. È una misura diretta della percezione del cliente rispetto alla qualità del servizio. Questi dati sono essenziali per la Dashboard Customer Satisfaction Trends e per il KPI Average Post-Resolution CSAT Score, poiché collegano le prestazioni del processo ai risultati per il cliente.

Perché è importante

Fornisce una misura diretta della soddisfazione del cliente, consentendo all'organizzazione di correlare i comportamenti del processo al sentiment del cliente e di promuovere miglioramenti.

Dove reperirlo

In genere proviene da un'entità di sondaggio correlata, come Customer Voice, ed è collegato all'entità Case (incident).

Esempi
5341
Risoluzione al primo contatto
IsFirstContactResolution
Un flag che indica se la richiesta è stata risolta durante il primo contatto.
Descrizione

Questo attributo calcolato identifica le richieste di assistenza risolte senza ulteriori interazioni con il cliente o ritardi significativi che richiedano la riassegnazione dell'agente. Definire la logica esatta può essere complesso, ma in genere comporta la verifica di un tempo di ciclo breve e dell'assenza di riaperture o attività di richiesta da parte del cliente dopo l'interazione iniziale. Costituisce la base per il KPI First Contact Resolution Rate.

Perché è importante

È una misura fondamentale dell'efficienza del servizio e della soddisfazione del cliente, poiché evidenzia la capacità di risolvere i problemi rapidamente e in modo completo.

Dove reperirlo

Calcolato sulla base della sequenza e della tempistica delle attività nell'event log di ciascun caso.

Esempi
truefalse
SLA violato
IsSlaBreached
Un flag calcolato che indica se la richiesta di assistenza ha superato l'obiettivo SLA.
Descrizione

Questo flag booleano viene determinato confrontando il tempo effettivo di risoluzione di una richiesta di assistenza con il relativo «SLA Target Resolution Time». Viene impostato su true se il tempo effettivo è superiore al tempo obiettivo. Questo attributo è fondamentale per la Dashboard SLA Compliance Monitoring e per il calcolo del KPI SLA Compliance Rate, poiché fornisce un esito binario chiaro sulle prestazioni SLA di ciascun caso.

Perché è importante

Fornisce un esito chiaro, positivo o negativo, del rispetto dello SLA per ogni caso, semplificando il filtraggio, l'aggregazione e l'analisi delle cause principali delle violazioni.

Dove reperirlo

Calcolato confrontando «ServiceRequestCycleTime» con «SlaTargetResolutionTime».

Esempi
truefalse
Team proprietario
OwnerTeam
Il team che attualmente è proprietario della richiesta di assistenza.
Descrizione

Questo attributo identifica il team responsabile della richiesta di assistenza. Una richiesta può essere assegnata a un singolo agente oppure a un team, ovvero a una coda. L'analisi per team è fondamentale per comprendere le prestazioni a livello di team, la distribuzione del carico di lavoro tra diversi livelli o specializzazioni del supporto e le variazioni del processo tra i team.

Perché è importante

Consente di analizzare le prestazioni a livello di team, un aspetto essenziale per gestire efficacemente i livelli di supporto e i gruppi specializzati.

Dove reperirlo

Deriva dal campo «Owner» («ownerid») dell'entità Case (incident) quando il proprietario è un record Team anziché un System User.

Esempi
Supporto di livello 1Ufficio fatturazioneSpecialisti tecnici
Obbligatorio Consigliato Facoltativo

Attività del servizio clienti

Queste sono le fasi chiave e le principali tappe del processo da acquisire nell’Event Log per un’individuazione e un’ottimizzazione accurate del servizio clienti.
6 Consigliato 7 Facoltativo
Attività Descrizione
Caso assegnato
Questa attività rappresenta l’assegnazione di un caso a una coda o a un utente specifico per la gestione. Il sistema registra esplicitamente le modifiche al proprietario del caso, che possono essere tracciate tramite i log di audit del sistema.
Perché è importante

Monitorare le assegnazioni è fondamentale per analizzare la distribuzione del carico di lavoro, identificare i ritardi legati all’assegnazione e comprendere l’efficienza dell’instradamento. Aiuta a rispondere a domande come quanto rapidamente i casi vengono indirizzati al team o alla persona corretti.

Dove reperirlo

Acquisito monitorando le modifiche al campo 'ownerid' dell’entità 'Incident'. Il timestamp della modifica è disponibile nei log della cronologia di audit.

Acquisizione

Estrarre dai log di audit le modifiche con timestamp al campo 'ownerid'.

Tipo di evento explicit
Caso chiuso
Questa è la chiusura amministrativa definitiva del record del caso, che può avvenire contemporaneamente alla risoluzione oppure in un momento successivo. L'attività viene acquisita tramite la modifica dello stato del caso in «Closed».
Perché è importante

Rappresenta la conclusione assoluta del ciclo di vita del processo nel sistema. Il tempo trascorso tra «Resolved» e «Closed» può indicare attività amministrative aggiuntive o ritardi nella finalizzazione dei record.

Dove reperirlo

Viene acquisita tramite la modifica del campo «statecode» dell'entità «Incident» in «Canceled» (2) oppure in uno stato di chiusura personalizzato. Il timestamp è disponibile nella cronologia di audit.

Acquisizione

Monitorare il timestamp della modifica di «statecode» allo stato terminale finale, ad esempio Canceled/Closed.

Tipo di evento explicit
Caso creato
Questa attività segna l’inizio del processo di Customer Service, quando nel sistema viene creato un nuovo record di caso. La creazione è un evento esplicito, registrato con un timestamp specifico al primo salvataggio del record dell’entità 'Incident'.
Perché è importante

In quanto evento iniziale principale, questa attività è essenziale per calcolare la durata complessiva del ciclo di vita del caso e comprendere le tendenze relative ai volumi dei casi. Costituisce il punto di riferimento per tutte le analisi successive del processo.

Dove reperirlo

Questo evento viene acquisito dal timestamp 'createdon' dell’entità 'Incident' (Case) per ogni nuovo record.

Acquisizione

Utilizzare il timestamp 'createdon' del record Incident.

Tipo di evento explicit
Caso risolto
Questa è una milestone fondamentale, che rappresenta il momento in cui l'agente considera risolto il problema del cliente. In Dynamics 365 corrisponde a un'azione esplicita che crea un record di attività «Case Resolution» associato al caso.
Perché è importante

In quanto principale evento finale associato al successo, questa attività è essenziale per calcolare i tempi di risoluzione e i tassi di successo. Costituisce una componente critica di quasi tutti i KPI del customer service.

Dove reperirlo

Questo evento corrisponde alla creazione di un record di attività «Resolution» («Case Resolution»). Il timestamp «actualend» di questo record indica il momento della risoluzione.

Acquisizione

Utilizzare il timestamp «actualend» o «createdon» del record di attività «Resolution» associato.

Tipo di evento explicit
Caso sottoposto a escalation
Rappresenta l’escalation formale di un caso verso un livello di supporto superiore o un team diverso. Può trattarsi di un’azione esplicita dell’utente che riassegna il caso a una coda o a un utente designato per le escalation.
Perché è importante

Monitorare le escalation è fondamentale per il KPI «Internal Escalation Rate» e per individuare le cause principali dei problemi che il supporto di primo livello non riesce a risolvere. Questa attività mette in evidenza le debolezze del processo e le opportunità di formazione.

Dove reperirlo

Viene dedotta dalla modifica del campo «ownerid» associata a una coda o a un team designato per le escalation. Può anche corrispondere a un'azione personalizzata esplicita che contrassegna il caso come oggetto di escalation.

Acquisizione

Identificare una modifica con timestamp del campo «ownerid» associata a una coda nota per le escalation.

Tipo di evento inferred
Timer SLA avviato
Indica l’attivazione di un timer relativo a un Service Level Agreement (SLA) per il caso, che inizia a misurare il tempo rispetto a una metrica di servizio definita, come 'First Response By' o 'Resolve By'. Si tratta di un evento esplicito gestito dal motore SLA di Dynamics 365.
Perché è importante

Questa attività è fondamentale per monitorare la conformità agli SLA e comprendere da quando decorre il tempo previsto per gli impegni di servizio. Supporta direttamente l’analisi del rispetto degli obiettivi di servizio.

Dove reperirlo

Registrato nell’entità 'SLA KPI Instance', correlata all’entità 'Incident'. Il timestamp 'createdon' del record SLA KPI Instance pertinente indica l’inizio.

Acquisizione

Utilizzare il timestamp di creazione del record 'SLA KPI Instance' associato al caso.

Tipo di evento explicit
Agente ha analizzato il problema
Rappresenta l’attività dell’agente volta a comprendere e diagnosticare il problema del cliente. Si tratta di un’attività dedotta, spesso identificata dal collegamento di un articolo della knowledge base al caso da parte dell’agente, a indicare che è stata svolta un’attività di ricerca.
Perché è importante

Monitorare questa attività aiuta a misurare l’utilizzo delle risorse della knowledge base e il relativo impatto sui tempi di risoluzione. Offre visibilità sull’effettivo utilizzo degli strumenti disponibili da parte degli agenti per risolvere i problemi in modo efficiente.

Dove reperirlo

Deducibile dalla creazione di un record nell’entità 'IncidentKnowledgeBaseRecord', che collega un articolo della knowledge base a un caso. Viene utilizzato il timestamp di creazione del record.

Acquisizione

Utilizzare il timestamp in cui un articolo della knowledge base viene associato all’Incident.

Tipo di evento inferred
Caso riattivato
Si verifica quando un caso precedentemente risolto viene riaperto automaticamente o manualmente, in genere perché il cliente ha risposto o ha segnalato che il problema non è stato risolto. Si tratta di un comportamento standard del sistema, che modifica lo stato del caso da «Resolved» a «Active».
Perché è importante

Questa attività è fondamentale per identificare le rilavorazioni e analizzare il «First Contact Resolution Rate». Un numero elevato di riattivazioni indica soluzioni iniziali incomplete o inefficaci.

Dove reperirlo

Viene acquisita tramite la modifica del campo «statecode» dell'entità «Incident» da «Resolved» (1) nuovamente a «Active» (0). Il timestamp della modifica viene registrato nella cronologia di audit.

Acquisizione

Monitorare il timestamp della modifica di «statecode» da Resolved ad Active nei log di audit.

Tipo di evento explicit
Categorizzazione del caso modificata
Questo evento si verifica quando un agente modifica la categoria o l’oggetto di un caso dopo la sua creazione iniziale. Si tratta di una modifica esplicita tracciata dalla funzionalità di audit del sistema.
Perché è importante

Monitorare la ricategorizzazione è essenziale per il KPI 'Service Request Recategorization Rate'. Una frequenza elevata indica problemi nel triage iniziale, che causano instradamenti errati e ritardi.

Dove reperirlo

Acquisito dalla cronologia di audit dell’entità 'Incident', monitorando in particolare le modifiche al campo 'subjectid' o ad altri campi personalizzati di categorizzazione.

Acquisizione

Estrarre dai log di audit le modifiche con timestamp al campo 'subjectid'.

Tipo di evento explicit
Elemento della coda preso in carico dall’agente
Questo evento si verifica quando un agente preleva attivamente un caso da una coda condivisa per iniziare a lavorarci. Si tratta di un’azione deliberata dell’utente, distinta dall’assegnazione del caso alla coda da parte del sistema.
Perché è importante

Questa attività consente di misurare il tempo effettivo di attesa di un caso in coda prima che un agente inizi a lavorarci. È fondamentale per identificare i colli di bottiglia nelle code e comprendere la proattività degli agenti.

Dove reperirlo

Tracciato quando un utente aggiorna il campo 'workedbyid' dell’entità 'QueueItem' associata al caso oppure quando il proprietario del caso passa da una coda a un utente.

Acquisizione

Identificare il timestamp in cui il campo 'workedbyid' di QueueItem viene valorizzato.

Tipo di evento explicit
Informazioni richieste al cliente
Questa attività indica il momento in cui l’agente necessita di ulteriori informazioni dal cliente per procedere. Spesso viene dedotta dal passaggio dello stato del caso a uno stato di 'waiting' oppure dall’invio di un’e-mail in uscita dalla timeline del caso.
Perché è importante

È fondamentale per misurare i ritardi legati al cliente e comprendere il KPI 'Customer Information Wait Time'. Aiuta a isolare il tempo di processo trascorso in attesa di input esterni.

Dove reperirlo

Può essere dedotta da una modifica del campo 'statuscode' dell’entità 'Incident' a un valore come 'On Hold', con motivo 'Waiting for Customer'. Viene utilizzato il timestamp della modifica di stato.

Acquisizione

Monitorare il timestamp della modifica di statuscode a uno stato designato come 'waiting for customer'.

Tipo di evento inferred
Soluzione proposta al cliente
Questa attività indica che l'agente ha elaborato una soluzione e l'ha comunicata al cliente. In genere viene dedotta da un'e-mail in uscita inviata dalla timeline del caso oppure dalla modifica dello stato in «Pending Customer Confirmation».
Perché è importante

Questa milestone segna il passaggio dall'analisi alla risoluzione. Analizzare il tempo trascorso tra la proposta e la conferma di una soluzione può far emergere ritardi nella risposta del cliente o problemi relativi alle correzioni proposte.

Dove reperirlo

Può essere dedotta dal timestamp di un'attività «Email» in uscita associata al caso oppure dalla modifica di «statuscode» a uno stato precedente alla risoluzione.

Acquisizione

Utilizzare il timestamp di un'attività e-mail in uscita oppure la modifica dello stato in «Solution Proposed».

Tipo di evento inferred
Sondaggio sulla soddisfazione inviato
Indica l'invio di un sondaggio sulla soddisfazione del cliente, generalmente attivato automaticamente dopo la risoluzione di un caso. Di norma viene acquisito come e-mail in uscita o come attività di sondaggio Customer Voice.
Perché è importante

Questa attività collega il processo operativo ai risultati dell'esperienza cliente. Consente di analizzare i punteggi di soddisfazione nel contesto del percorso seguito dal caso.

Dove reperirlo

Viene dedotta dalla creazione di un'attività «Email» in uscita contenente un link al sondaggio oppure da un record di attività «Customer Voice survey invite» associato al caso.

Acquisizione

Utilizzare il timestamp di creazione del record di attività associato al sondaggio.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'estrazione

Come ottenere i dati da Microsoft Dynamics 365 Customer Service

Pronto a iniziare?

Utilizzi questo Template dati per avviare il Suo percorso di Process Mining e ottenere nuove efficienze nelle operazioni di assistenza clienti. Inizi oggi a ottimizzare i Suoi Workflow per offrire esperienze cliente migliori.

Ottimizzi il servizio clienti: aumenti l'FCR e riduca subito i costi

Identifichi i colli di bottiglia e raggiunga una risoluzione al primo contatto dell'80% per clienti più soddisfatti.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Configurazione in pochi minuti.