Il template dei dati del servizio clienti

Microsoft Dynamics 365 Customer Service
Il template dei dati del servizio clienti

Il template dei dati del servizio clienti

Questo template offre un metodo strutturato per raccogliere i dati essenziali necessari a un’analisi approfondita del processo di assistenza clienti. Indica gli attributi fondamentali da raccogliere e le attività principali da monitorare, oltre a fornire indicazioni su come estrarre efficacemente queste informazioni.
  • Attributi consigliati da raccogliere
  • Attività principali da monitorare
  • Indicazioni per l’estrazione dei dati 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 analizzare in modo completo il processo di assistenza clienti.
5 Obbligatorio 7 Consigliato 8 Facoltativo
Nome Descrizione
Richiesta di assistenza
ServiceRequest
Identificativo univoco di una richiesta di assistenza clienti, chiamata anche caso o ticket.
Descrizione

La richiesta di assistenza è l’identificativo principale che collega tutte le attività relative a una singola domanda o a un problema del cliente. Nel Process Mining funge da ID del caso, garantendo una visione completa e coerente di ogni interazione, dalla creazione alla chiusura. Analizzare i dati per richiesta di assistenza consente di seguire il percorso end-to-end, misurare i tempi di risoluzione e individuare schemi ricorrenti tra casi simili.

Perché è importante

È l’ID del caso essenziale che collega tutti gli eventi correlati in un’unica istanza di processo, rendendo possibile l’analisi end-to-end.

Dove reperirli

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

Esempi
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
Attività
ActivityName
Nome dell’evento aziendale specifico verificatosi in un determinato momento per una richiesta di assistenza.
Descrizione

Questo attributo descrive un singolo passaggio o una modifica di stato nel processo di assistenza clienti, come 'Caso creato', 'Problema analizzato dall’operatore' o 'Caso risolto'. Queste attività costituiscono la struttura della mappa del processo e ne consentono la visualizzazione e l’analisi del flusso. Associando un timestamp a ciascuna attività si crea un evento che definisce la sequenza del processo.

Perché è importante

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

Dove reperirli

In genere si ricava associando le modifiche di stato (statuscode) o eventi specifici provenienti da entità correlate, come Tasks, Emails o Phone Calls, a un nome di attività standardizzato.

Esempi
Caso creatoProblema analizzato dall’operatoreSoluzione proposta al clienteCaso chiuso
Ora di inizio
EventTime
Timestamp che indica quando si è verificata l’attività.
Descrizione

Questo attributo registra la data e l’ora esatte in cui si è svolta una specifica attività. È essenziale per ordinare correttamente gli eventi e per tutte le analisi basate sul tempo, compreso il calcolo dei tempi di ciclo, delle durate e delle attese tra un’attività e l’altra. Timestamp accurati e coerenti sono fondamentali per garantire l’affidabilità dell’analisi di Process Mining.

Perché è importante

Questo timestamp ordina gli eventi cronologicamente e consente tutti i calcoli delle durate, fondamentali per analizzare le prestazioni e individuare i colli di bottiglia.

Dove reperirli

Corrisponde a campi come 'createdon' o 'modifiedon' dell’entità Case (incident) o delle entità di attività correlate, 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 da cui sono stati estratti i dati.
Descrizione

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

Perché è importante

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

Dove reperirli

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

Esempi
Microsoft Dynamics 365 Customer Service
Ultimo aggiornamento dei dati
LastDataUpdate
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. Serve a valutarne l’aggiornamento ed è essenziale per la reportistica e il monitoraggio. Permette agli utenti di tenere conto della data di aggiornamento dei dati quando interpretano le Dashboard e le analisi.

Perché è importante

Indica quanto sono aggiornati i dati, un’informazione essenziale per prendere decisioni aziendali tempestive e accurate sulla base dell’analisi dei processi.

Dove reperirli

Questo valore viene generato e registrato nel set di dati al momento dell’estrazione.

Esempi
2023-10-27T08:00:00Z
Canale
Channel
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 telefono, e-mail, portale web o chat. I diversi canali presentano spesso flussi di processo, aspettative dei clienti e livelli di complessità nella risoluzione distinti. Analizzare il processo per canale aiuta a ottimizzare i flussi di lavoro specifici e l’allocazione delle risorse.

Perché è importante

Mostra in che modo i diversi canali di contatto con i clienti incidono sull’efficienza del processo, sui tempi di risoluzione e sulla soddisfazione dei clienti.

Dove reperirli

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

Esempi
TelefonoE-mailWebChat
Motivo dello stato
StatusReason
Fornisce una spiegazione più dettagliata dello stato corrente della richiesta di assistenza.
Descrizione

Un caso può avere uno stato generale come 'Active' o 'Resolved'; il motivo dello stato fornisce informazioni più specifiche, ad esempio 'Information Provided' o 'Problem Solved'. Questo attributo è fondamentale per comprendere le diverse modalità e ragioni per cui i casi avanzano nel loro ciclo di vita. Può, per esempio, distinguere i casi risolti con successo da quelli annullati dal cliente, un aspetto essenziale per un’analisi accurata degli esiti.

Perché è importante

Fornisce informazioni dettagliate sull’esito di un caso e sulle ragioni delle modifiche di stato, consentendo un’analisi più precisa dei percorsi di risoluzione e delle cause profonde.

Dove reperirli

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

Esempi
In corsoIn sospesoProblema risoltoInformazioni fornite
Nome del cliente
CustomerName
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 dal punto di vista del cliente e di individuare chi invia più richieste, chi attende più a lungo una risoluzione o chi presenta i problemi più complessi. È essenziale per gestire le relazioni con i clienti e migliorare il servizio offerto a ciascuno.

Perché è importante

Consente di analizzare i dati a livello di cliente, individuare schemi ricorrenti, migliorare il servizio per i clienti strategici e comprendere il percorso del cliente.

Dove reperirli

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

Esempi
Global Tech Inc.Jane DoeInnovate Solutions
Nome dell’operatore
AgentName
Nome dell’operatore del servizio clienti o dell’utente responsabile dell’attività.
Descrizione

Questo attributo identifica l’operatore o l’utente di sistema che ha svolto un’attività, ad esempio prelevare un elemento da una coda o risolvere un caso. È fondamentale per analizzare le prestazioni degli operatori, la distribuzione del carico di lavoro e l’allocazione delle risorse. Monitorando le attività a livello di singolo operatore, le organizzazioni possono individuare chi ottiene i risultati migliori, le esigenze di formazione e gli squilibri nel carico di lavoro.

Perché è importante

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

Dove reperirli

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

Esempi
Alice SmithBob JohnsonSistema
Priorità
Priority
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 bassa, normale, alta o urgente. La priorità determina 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 che i problemi critici vengano gestiti tempestivamente.

Perché è importante

Aiuta a capire se le richieste ad alta priorità vengono gestite più rapidamente e raggiungono gli obiettivi, nonché in che modo i livelli di priorità incidono sulle prestazioni complessive del processo.

Dove reperirli

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

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

Questo attributo specifica la durata entro cui la richiesta di assistenza dovrebbe essere risolta in base all’accordo sul livello di servizio (SLA) in vigore. Costituisce il valore di riferimento per misurare le prestazioni effettive. È fondamentale per la Dashboard di monitoraggio della conformità agli SLA e per calcolare il KPI del tasso di conformità agli SLA, evidenziando i casi in cui il processo non rispetta gli impegni di servizio.

Perché è importante

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

Dove reperirli

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

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

Questo attributo classifica la richiesta di assistenza in base alla sua natura, ad esempio 'Richiesta di fatturazione', 'Supporto tecnico' o 'Feedback sul prodotto'. È fondamentale per segmentare l’analisi e comprendere come vengono gestiti i diversi tipi di richiesta. L’analisi per tipologia può rivelare che alcune categorie richiedono tempi di risoluzione più lunghi, comportano più escalation o seguono percorsi di processo diversi.

Perché è importante

Consente di segmentare il processo per individuare colli di bottiglia, esigenze di risorse e opportunità di miglioramento specifici per ciascun tipo di richiesta, favorendo strategie più efficaci di instradamento e gestione.

Dove reperirli

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

Esempi
Richiesta di fatturazioneSupporto tecnicoFeedback sul prodottoGestione dell’account
ID articolo della knowledge base
KnowledgeArticleId
Identificativo di un articolo della knowledge base collegato alla richiesta di assistenza.
Descrizione

Questo attributo registra l’ID di ogni articolo della knowledge base utilizzato o collegato durante la risoluzione di una richiesta di assistenza. Consente di misurare direttamente quanto gli operatori utilizzino la knowledge base per risolvere i problemi dei clienti. Questi dati sono fondamentali per la Dashboard Utilizzo degli articoli della knowledge base e per il relativo KPI, che aiutano a valutare il valore e la completezza della knowledge base.

Perché è importante

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

Dove reperirli

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

Esempi
KA-01337KA-02048
Prodotto interessato
ProductInvolved
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 capire se alcuni prodotti generano più richieste, presentano problemi più complessi o richiedono competenze specialistiche agli operatori. L’analisi aiuta a migliorare i prodotti e a pianificare le risorse.

Perché è importante

Consente di analizzare i processi per prodotto, individuare problemi ricorrenti, migliorare la documentazione di supporto e assegnare in modo efficace le risorse specialistiche.

Dove reperirli

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

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

Questo attributo contiene il punteggio numerico o la valutazione categoriale raccolti tramite un sondaggio sulla soddisfazione del cliente (CSAT), in genere dopo la chiusura di una richiesta di assistenza. Misura direttamente la percezione del cliente sulla qualità del servizio. Questi dati sono essenziali per la Dashboard Andamento della soddisfazione dei clienti e per il KPI Punteggio CSAT medio dopo la risoluzione, che mettono in relazione le prestazioni del processo con i risultati per i clienti.

Perché è importante

Misura direttamente la soddisfazione dei clienti e consente all’organizzazione di correlare le modalità operative del processo con il loro giudizio, così da orientare i miglioramenti.

Dove reperirli

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

Esempi
5341
Rilavorazione
IsRework
Indicatore calcolato che segnala se un caso ha comportato attività di rilavorazione.
Descrizione

Questo indicatore booleano individua i casi con cicli di rilavorazione o attività ripetute, come più eventi 'Information Requested From Customer' o un evento 'Case Reactivated' dopo la risoluzione. Si calcola analizzando la sequenza delle attività per individuare schemi che segnalano inefficienze o una risoluzione non corretta al primo tentativo. Questo attributo è fondamentale per la Dashboard Analisi delle rilavorazioni e dei contatti ripetuti.

Perché è importante

Aiuta a quantificare e isolare le inefficienze del processo, consentendo agli analisti di concentrarsi sulle cause profonde del lavoro ripetuto e delle risorse sprecate.

Dove reperirli

Si calcola individuando, tramite le analisi di Process Mining, sequenze specifiche di attività (ad esempio, Resolved -> Reactivated) o attività ripetute all’interno di un caso.

Esempi
truefalse
Risoluzione al primo contatto
IsFirstContactResolution
Indicatore che segnala se la richiesta è stata risolta al primo contatto.
Descrizione

Questo attributo calcolato individua le richieste di assistenza risolte senza ulteriori interazioni con il cliente né ritardi significativi che richiedano la riassegnazione a un altro operatore. Definire la logica esatta può essere complesso, ma in genere si verifica che il tempo di attraversamento sia breve e che, dopo il contatto iniziale, non vi siano riaperture o richieste di informazioni da parte del cliente. È alla base del KPI Tasso di risoluzione al primo contatto.

Perché è importante

È un indicatore fondamentale dell’efficienza del servizio e della soddisfazione dei clienti, perché mostra la capacità di risolvere i problemi rapidamente e in modo completo.

Dove reperirli

Si calcola in base alla sequenza e alla tempistica delle attività nell’event log di ciascun caso.

Esempi
truefalse
Sottoposto a escalation
IsEscalated
Indicatore che segnala se la richiesta di assistenza è stata inoltrata a un livello superiore.
Descrizione

Questo attributo booleano indica se una richiesta di assistenza è stata oggetto di un’escalation. Le escalation si verificano quando il supporto di primo livello non riesce a risolvere un problema e occorre l’intervento di un team più esperto o di uno specialista. Monitorare questo indicatore è essenziale per la Dashboard Percorsi di escalation interni e per il KPI Tasso di escalation interna, che aiutano a individuare le cause profonde delle escalation e le lacune nei livelli iniziali di supporto.

Perché è importante

Misura direttamente la frequenza delle escalation, mettendo in evidenza i problemi di risoluzione al primo contatto e le aree in cui occorre migliorare i processi o le competenze degli operatori.

Dove reperirli

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

Esempi
truefalse
Team responsabile
OwnerTeam
Team attualmente responsabile della richiesta di assistenza.
Descrizione

Questo attributo identifica il team responsabile della richiesta di assistenza. La richiesta può essere assegnata a un singolo operatore o a un team (coda). L’analisi per team è fondamentale per comprendere le prestazioni dei singoli gruppi, la distribuzione del carico di lavoro tra i diversi livelli di supporto o le aree di specializzazione e le differenze nei processi adottati dai team.

Perché è importante

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

Dove reperirli

Deriva dal campo 'Owner' (ownerid) dell’entità Case (incident), quando il responsabile è un record Team e non un utente di sistema.

Esempi
Supporto di primo livelloUfficio fatturazioneSpecialisti tecnici
Violazione SLA
IsSlaBreached
Indicatore calcolato che segnala se la richiesta di assistenza ha superato il tempo previsto dallo SLA.
Descrizione

Questo indicatore booleano si ottiene confrontando il tempo effettivo di risoluzione di una richiesta di assistenza con il relativo 'SLA Target Resolution Time'. Assume il valore true se il tempo effettivo supera quello previsto. Questo attributo è fondamentale per la Dashboard Monitoraggio della conformità agli SLA e per calcolare il KPI Tasso di conformità agli SLA, poiché fornisce un esito chiaro, positivo o negativo, per ogni caso.

Perché è importante

Indica chiaramente se ogni caso ha rispettato lo SLA, facilitando il filtraggio, l’aggregazione e l’analisi delle cause profonde delle violazioni.

Dove reperirli

Si calcola confrontando 'ServiceRequestCycleTime' con 'SlaTargetResolutionTime'.

Esempi
truefalse
Obbligatorio Consigliato Facoltativo

Attività del servizio clienti

Queste sono le fasi e le tappe fondamentali del processo da registrare nell’event log per individuare e ottimizzare con precisione il processo di assistenza 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 che se ne occuperà. Il sistema registra esplicitamente le modifiche al proprietario del caso, che possono essere rilevate nei registri di audit.
Perché è importante

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

Dove reperirli

L’evento viene acquisito monitorando le modifiche al campo 'ownerid' dell’entità 'Incident'. Il timestamp della modifica è disponibile nei registri della cronologia di audit.

Acquisizione

Estrarre dai registri di audit le modifiche al campo 'ownerid' con i relativi timestamp.

Tipo di evento explicit
Caso chiuso
Questa è la chiusura amministrativa definitiva del record del caso, che può avvenire contemporaneamente alla risoluzione o in un momento successivo. L’attività viene acquisita quando lo stato del caso passa a 'Closed'.
Perché è importante

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

Dove reperirli

L’evento viene acquisito quando il campo 'statecode' dell’entità 'Incident' passa a 'Canceled' (2) o a uno stato personalizzato di chiusura. Il timestamp è disponibile nella cronologia di audit.

Acquisizione

Monitorare il timestamp in cui 'statecode' passa allo stato terminale finale, ad esempio Canceled/Closed.

Tipo di evento explicit
Caso creato
Questa attività segna l’inizio del processo di assistenza clienti, quando nel sistema viene creato un nuovo record del caso. Si tratta di 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 l’andamento dei volumi. Costituisce il riferimento per tutte le analisi successive del processo.

Dove reperirli

L’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 tappa fondamentale indica il momento in cui l’operatore considera risolto il problema del cliente. In Dynamics 365 corrisponde a un’azione esplicita che crea un record di attività 'Case Resolution' collegato al caso.
Perché è importante

In quanto principale evento finale che indica il successo, questa attività è essenziale per calcolare i tempi e i tassi di risoluzione. È un elemento fondamentale di quasi tutti i KPI del servizio clienti.

Dove reperirli

L’evento corrisponde alla creazione di un record di attività 'Resolution' (Case Resolution). Il timestamp 'actualend' del 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 a un livello di supporto superiore o a un altro team. 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 'Tasso di escalation interna' e per individuare le cause profonde dei problemi che il supporto di primo livello non riesce a risolvere. Consente di evidenziare le criticità del processo e le opportunità di formazione.

Dove reperirli

L’evento viene dedotto da una modifica del campo 'ownerid' verso una coda o un team designato per le escalation. Può anche derivare da un’azione personalizzata esplicita che contrassegna il caso come sottoposto a escalation.

Acquisizione

Individuare una modifica con timestamp del campo 'ownerid' verso una coda di escalation nota.

Tipo di evento inferred
Timer SLA avviato
Indica l’attivazione del timer dell’accordo sul livello di servizio (SLA) per il caso, che inizia a misurare il tempo rispetto a una metrica di servizio definita, come 'First Response By' o 'Resolve By'. È un evento esplicito gestito dal motore SLA di Dynamics 365.
Perché è importante

Questa attività è fondamentale per monitorare la conformità agli SLA e capire quando inizia a decorrere il tempo previsto dagli impegni di servizio. Consente di analizzare direttamente se gli obiettivi di servizio vengono raggiunti.

Dove reperirli

L’evento viene registrato nell’entità 'SLA KPI Instance', collegata 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
Caso prelevato dalla coda dall’operatore
L’evento si verifica quando un operatore preleva attivamente un caso da una coda condivisa per iniziare a gestirlo. È un’azione intenzionale 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 del caso in coda prima che un operatore inizi a lavorarci. È fondamentale per individuare i colli di bottiglia nelle code e comprendere quanto gli operatori intervengano tempestivamente.

Dove reperirli

L’evento viene rilevato 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

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

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

Questa attività è fondamentale per individuare le rilavorazioni e analizzare il 'Tasso di risoluzione al primo contatto'. Un numero elevato di riattivazioni indica che le soluzioni iniziali sono incomplete o inefficaci.

Dove reperirli

L’evento viene acquisito quando il campo 'statecode' dell’entità 'Incident' passa da 'Resolved' (1) a 'Active' (0). Il timestamp della modifica è registrato nella cronologia di audit.

Acquisizione

Monitorare nei registri di audit il timestamp della modifica di 'statecode' da Resolved ad Active.

Tipo di evento explicit
Categoria del caso modificata
L’evento si verifica quando, dopo la creazione iniziale del caso, un operatore ne modifica la categoria o l’oggetto. È una modifica esplicita, registrata dalla funzione di audit del sistema.
Perché è importante

Monitorare le ricategorizzazioni è essenziale per il KPI 'Tasso di ricategorizzazione delle richieste di assistenza'. Una frequenza elevata indica problemi nella classificazione iniziale, che possono causare instradamenti errati e ritardi.

Dove reperirli

L’evento viene 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 registri di audit le modifiche al campo 'subjectid' con i relativi timestamp.

Tipo di evento explicit
Informazioni richieste al cliente
Questa attività indica che l’operatore ha bisogno di ulteriori informazioni dal cliente per procedere. Spesso viene dedotta dal passaggio del caso a uno stato di attesa oppure dall’invio di un’e-mail in uscita dalla cronologia del caso.
Perché è importante

È fondamentale per misurare i ritardi imputabili al cliente e comprendere il KPI 'Tempo di attesa delle informazioni del cliente'. Aiuta a isolare il tempo del processo trascorso in attesa di informazioni esterne.

Dove reperirli

L’attività 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 dello stato.

Acquisizione

Monitorare il timestamp della modifica di statuscode a uno stato designato come 'in attesa del cliente'.

Tipo di evento inferred
Problema analizzato dall’operatore
Rappresenta il lavoro svolto dall’operatore per comprendere e diagnosticare il problema del cliente. È un’attività dedotta, spesso identificata dal collegamento di un articolo della Knowledge Base al caso, che indica l’avvenuta ricerca di informazioni.
Perché è importante

Monitorare questa attività aiuta a misurare l’utilizzo delle risorse informative e il loro impatto sui tempi di risoluzione. Permette di capire se gli operatori sfruttano gli strumenti disponibili per risolvere i problemi in modo efficiente.

Dove reperirli

L’attività viene dedotta 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 di associazione dell’articolo della Knowledge Base all’Incident.

Tipo di evento inferred
Soluzione proposta al cliente
Questa attività indica che l’operatore ha individuato una soluzione e l’ha comunicata al cliente. In genere viene dedotta dall’invio di un’e-mail dalla cronologia del caso o dal passaggio allo stato 'Pending Customer Confirmation'.
Perché è importante

Questa tappa segna il passaggio dall’analisi alla risoluzione. Analizzare il tempo tra la proposta e la conferma della soluzione può far emergere ritardi nella risposta del cliente o problemi relativi alle soluzioni proposte.

Dove reperirli

L’attività può essere dedotta dal timestamp di un record di attività 'Email' in uscita associato al caso oppure dalla modifica di statuscode a uno stato precedente alla risoluzione.

Acquisizione

Utilizzare il timestamp di un’attività e-mail in uscita o della modifica dello stato a 'Solution Proposed'.

Tipo di evento inferred
Sondaggio di soddisfazione inviato
Indica l’invio di un sondaggio sulla soddisfazione del cliente, in genere attivato automaticamente dopo la risoluzione di un caso. Di solito 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 del cliente. Consente di analizzare i punteggi di soddisfazione in relazione al percorso seguito dal caso.

Dove reperirli

L’attività viene dedotta dalla creazione di un’attività 'Email' in uscita contenente un collegamento 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à relativo 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 di dati per avviare il percorso di Process Mining e individuare nuove opportunità di efficienza nelle attività di assistenza clienti. Inizi oggi a ottimizzare i flussi di lavoro per offrire un’esperienza migliore ai clienti.

Ottimizzi l’assistenza clienti: aumenti la risoluzione al primo contatto e riduca subito i costi

Individui i colli di bottiglia e raggiunga una risoluzione all’80% al primo contatto, per clienti più soddisfatti.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.