Il template dei dati del servizio clienti
Il template dei dati del servizio clienti
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione dei dati da Microsoft Dynamics 365 Customer Service
Attributi del servizio clienti
| 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
|
|||
Attività del servizio clienti
| 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
|
|||
Guide all’estrazione
È 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.
Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.