Il Suo Template dei dati del servizio clienti
Il Suo Template dei dati del servizio clienti
- Attributi consigliati da raccogliere
- Attività chiave da monitorare
- Indicazioni per l'estrazione da Microsoft Dynamics 365 Customer Service
Attributi del servizio clienti
| 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
|
|||
Attività del servizio clienti
| 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
|
|||
Guide all'estrazione
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.
Non è richiesta alcuna carta di credito. Configurazione in pochi minuti.