Il Suo Template Dati per il Customer Service
Il Suo Template Dati per il Customer Service
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione
Attributi` del Servizio Clienti
| Nome | Descrizione | ||
|---|---|---|---|
|
Richiesta di Servizio
ServiceRequest
|
L'identificativo unico per ogni richiesta di customer service, caso o ticket. | ||
|
Descrizione
La Richiesta di Servizio è l'identificatore primario del caso che collega tutte le attività e gli eventi correlati per un singolo problema del cliente, dalla creazione alla chiusura. Agisce come filo conduttore centrale per tracciare il percorso end-to-end di un'interazione con il cliente. Nel Process Mining, questo attributo è fondamentale per ricostruire il flusso di processo. Ogni valore univoco della Richiesta di Servizio rappresenta un'istanza del processo, consentendo l'analisi dei tempi di ciclo, dei percorsi e delle variazioni caso per caso. Assicura che tutti i passaggi, dal contatto iniziale alla risoluzione finale e alla chiusura, siano correttamente associati alla stessa richiesta del cliente.
Perché è importante
Questo è l'ID Caso essenziale che collega tutti i passaggi del processo, rendendo possibile analizzare il ciclo di vita completo di ogni interazione di customer service.
Dove trovare
Questo è tipicamente il campo 'number' dalla tabella 'sn_customerservice_case' in ServiceNow CSM.
Esempi
CS0010001CS0010045CS0010112
|
|||
|
Timestamp Evento
EventTime
|
Il timestamp preciso che indica quando si è verificata un'attività o un evento specifico. | ||
|
Descrizione
Event Time registra la data e l'ora in cui un'attività è stata eseguita. Questo Nell'analisi di
Perché è importante
Questo timestamp è critico per sequenziare correttamente gli eventi e calcolare tutte le metriche di performance, come tempi di ciclo e bottleneck.
Dove trovare
Ciò corrisponde tipicamente al campo 'sys_created_on' nelle tabelle di audit e cronologia di ServiceNow (ad es. 'sys_audit').
Esempi
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
Nome attività
ActivityName
|
Il nome di un evento o di un'attività specifica che si è verificata all'interno del ciclo di vita della richiesta di servizio. | ||
|
Descrizione
Il Nome Attività descrive un passaggio nel processo di customer service, come 'Richiesta di Servizio Creata', 'Richiesta Assegnata all'Agente' o 'Soluzione Proposta'. Queste attività vengono estratte dai log di sistema o dagli aggiornamenti delle tabelle per costruire una sequenza cronologica di eventi per ogni richiesta di servizio. Questo attributo è cruciale per visualizzare la mappa di processo, identificare i bottleneck e comprendere il flusso di lavoro. Analizzando la sequenza e la frequenza delle attività, gli analisti possono scoprire percorsi di processo comuni, deviazioni e aree di rilavorazione o inefficienza. La granularità delle attività definite influisce direttamente sulla profondità degli insight che si possono ottenere dal modello di processo.
Perché è importante
Questo attributo costituisce la spina dorsale della mappa di processo, definendo i passaggi e le attività specifiche di cui vengono analizzate la sequenza e la durata.
Dove trovare
Questo è un attributo concettuale derivato dalle tabelle di audit del sistema (ad es. 'sys_audit') o monitorando i cambiamenti di stato e gli aggiornamenti dei campi chiave nella tabella 'sn_customerservice_case'.
Esempi
Richiesta di Servizio CreataRichiesta Assegnata all'AgenteInformazioni Richieste al ClienteRichiesta di Servizio Risolta
|
|||
|
Agente Assegnato
AssignedAgent
|
L'agente di servizio individuale attualmente assegnato per gestire la richiesta di servizio. | ||
|
Descrizione
Questo attributo identifica l'utente responsabile della richiesta di servizio in un dato momento. Spesso cambia durante il ciclo di vita del caso man mano che la richiesta viene passata tra diversi agenti o specialisti. Analizzare l'Agente Assegnato è fondamentale per comprendere la distribuzione del carico di lavoro, le prestazioni degli agenti e i passaggi di consegne. Aiuta a rispondere a domande come quali agenti gestiscono i casi più complessi, con quale frequenza i casi vengono riassegnati e se certi agenti sono associati a tempi di risoluzione più lunghi o a una maggiore soddisfazione del cliente. Questo è cruciale per la dashboard 'Passaggi di Consegne e Riassegnazioni Agenti'.
Perché è importante
Traccia la responsabilità dell'agente, consentendo l'analisi del carico di lavoro, delle prestazioni e della frequenza delle riassegnazioni, il che spesso indica attrito nel processo.
Dove trovare
Ciò corrisponde al campo 'assigned_to' nella tabella 'sn_customerservice_case'.
Esempi
Beth AnglinDavid LooAbel Tuter
|
|||
|
Categoria
Category
|
La classificazione primaria della richiesta di servizio, come 'Fatturazione' o 'Problema Tecnico'. | ||
|
Descrizione
La Categoria fornisce un raggruppamento di alto livello per le richieste di servizio basato sulla natura della richiesta o del problema del cliente. Questa classificazione viene tipicamente effettuata quando la richiesta viene creata per la prima volta e aiuta a indirizzarla al gruppo di assegnazione corretto. Questo attributo è essenziale per segmentare l'analisi del processo. Filtrando per Categoria, gli analisti possono confrontare i flussi di processo per diversi tipi di richieste. Ad esempio, il processo di risoluzione per un problema di 'Fatturazione' potrebbe essere molto diverso da quello di un 'Problema Tecnico'. Questo è un attributo chiave per quasi tutte le dashboard per sezionare i dati.
Perché è importante
Consente di suddividere l'analisi per tipo di richiesta, rivelando se determinate categorie sono più soggette a ritardi, escalation o violazioni SLA.
Dove trovare
Ciò corrisponde al campo 'category' nella tabella 'sn_customerservice_case'.
Esempi
Richiesta / AiutoOrdiniProblemi di ProdottoFatturazione
|
|||
|
Gruppo di Assegnazione
AssignmentGroup
|
Il team o il dipartimento responsabile della richiesta di servizio. | ||
|
Descrizione
Il Gruppo di Assegnazione rappresenta la coda o il team a cui è assegnata una richiesta di servizio. Le richieste vengono spesso instradate tra diversi gruppi, come un help desk di Livello 1, un team tecnico specializzato o un dipartimento di fatturazione, a seconda della natura del problema. Questo attributo è essenziale per analizzare i passaggi di consegne inter-dipartimentali e identificare i bottleneck a livello di team. Aiuta a visualizzare come il lavoro fluisce tra diverse aree funzionali e può evidenziare gruppi sovraccarichi o che richiedono formazione aggiuntiva. Questo supporta direttamente le dashboard 'Passaggi di Consegne e Riassegnazioni Agenti' e 'Flusso di Processo'.
Perché è importante
Identifica quale team è responsabile del lavoro, il che è fondamentale per analizzare le prestazioni del team, i carichi di lavoro e i
Dove trovare
Ciò corrisponde al campo 'assignment_group' nella tabella 'sn_customerservice_case'.
Esempi
Service DeskRichieste di FatturazioneSupporto Tecnico Tier 2
|
|||
|
Priorità
Priority
|
Il livello di priorità della richiesta di servizio, che ne influenza l'urgenza. | ||
|
Descrizione
La Priorità indica l'importanza e l'urgenza richiesta per gestire una richiesta di servizio. È spesso determinata da una combinazione dell'impatto della richiesta sul cliente e della sua urgenza. I valori comuni vanno da Critica a Bassa. Nel Process Mining, la Priorità è una dimensione potente per il filtraggio e il confronto. Permette agli analisti di verificare se le richieste ad alta priorità vengono effettivamente elaborate più velocemente di quelle a bassa priorità, e di vedere se le violazioni degli SLA sono più comuni per certi livelli di priorità. Questo è fondamentale per la dashboard 'Tempo di Ciclo End-to-End della Richiesta di Servizio'.
Perché è importante
Ciò consente di segmentare le richieste di servizio per urgenza, il che è essenziale per verificare che le questioni critiche vengano gestite più rapidamente di quelle non critiche.
Dove trovare
Ciò corrisponde al campo 'priority' nella tabella 'sn_customerservice_case'.
Esempi
1 - Critico2 - Alto3 - Moderate4 - Basso
|
|||
|
SLA Violato
IsSlaBreached
|
Un flag booleano che indica se la richiesta di servizio ha superato l'obiettivo definito nell'accordo sul livello di servizio (SLA). | ||
|
Descrizione
Questo attributo calcolato indica se una richiesta di servizio è stata risolta entro il lasso di tempo concordato. È tipicamente 'Vero' se il tempo di risoluzione ha superato l'obiettivo SLA e 'Falso' altrimenti. Questo fornisce un risultato binario chiaro per le prestazioni SLA su ogni caso. Questo attributo è essenziale per la dashboard 'Aderenza SLA e Trend delle Violazioni' e il KPI 'Tasso di Aderenza SLA'. Semplifica l'analisi consentendo il filtraggio diretto e il conteggio dei casi violati, rendendo facile identificare quali tipi di richieste, priorità o team sono più associati alle violazioni SLA.
Perché è importante
Fornisce una chiara risposta sì o no sul fatto che un caso abbia rispettato la sua scadenza, il che è fondamentale per misurare e rendicontare la conformità agli SLA.
Dove trovare
Calcolato in base al campo 'made_sla' della tabella 'task_sla', o derivato confrontando il tempo di risoluzione effettivo con il tempo di risoluzione pianificato.
Esempi
truefalse
|
|||
|
Stato
State
|
Lo stato attuale della richiesta di servizio nel suo ciclo di vita. | ||
|
Descrizione
L'attributo Stato descrive lo stato operativo di una richiesta di servizio in qualsiasi momento, come 'Nuovo', 'In Corso', 'In Attesa di Info', 'Risolto' o 'Chiuso'. I cambiamenti in questo campo sono spesso utilizzati per definire le attività nel modello di processo. L'analisi dello Stato fornisce una visione di alto livello di dove si trovano i casi nel processo. Viene utilizzato per identificare quanto tempo i casi trascorrono in certi stati, come 'In Attesa di Info', che può essere una fonte significativa di ritardo. Aiuta anche a definire i punti di inizio e fine per KPI chiave come 'Tempo di Risoluzione alla Chiusura'.
Perché è importante
Indica lo
Dove trovare
Ciò corrisponde al campo 'state' nella tabella 'sn_customerservice_case'.
Esempi
NuovoIn CorsoIn attesa di informazioni dall'utenteRisoltoChiuso
|
|||
|
Canale
Channel
|
Il canale di comunicazione attraverso il quale è stata avviata la richiesta di servizio. | ||
|
Descrizione
Il Canale indica il metodo utilizzato dal cliente per inviare la propria richiesta, per esempio, 'Email', 'Telefono', 'Portale Web' o 'Chat'. Diversi canali possono avere caratteristiche di processo e aspettative del cliente significativamente diverse. L'analisi del processo per Canale aiuta a valutare l'efficacia di ciascun metodo di comunicazione. Per esempio, può rivelare se le richieste inviate tramite 'Telefono' hanno un tasso di risoluzione al primo contatto più elevato o se le richieste via 'Email' tendono ad avere tempi di ciclo più lunghi. Questo supporta direttamente la dashboard 'Efficacia del Canale di Comunicazione'.
Perché è importante
Aiuta a determinare l'efficienza e i risultati dei diversi canali di interazione con il cliente, come telefono, email o portale web.
Dove trovare
Ciò corrisponde tipicamente al campo 'contact_type' nella tabella 'sn_customerservice_case'.
Esempi
TelefonoEmailSelf-serviceChat
|
|||
|
Cliente
Customer
|
Il nome o l'identificativo del cliente o dell'azienda che ha avviato la richiesta di servizio. | ||
|
Descrizione
Questo attributo identifica lo stakeholder esterno, sia esso un individuo o un'organizzazione, per cui è stata fatta la richiesta di servizio. Fornisce il contesto del cliente per ogni caso. Nell'analisi, l'attributo Cliente permette una visione customer-centric del processo di servizio. Può essere utilizzato per identificare se alcuni clienti riscontrano più problemi o ritardi più lunghi, e può essere unito ad altri dati del cliente, come il segmento o il valore, per prioritizzare gli sforzi di miglioramento del processo. Per esempio, si potrebbe verificare se i clienti di alto valore ricevono un servizio più rapido.
Perché è importante
Collega il processo a clienti specifici, consentendo l'analisi dei livelli di servizio e della frequenza dei problemi per account chiave o segmenti di clientela.
Dove trovare
Questo potrebbe essere il campo 'caller_id', 'opened_for' o 'account' nella tabella 'sn_customerservice_case', che fanno riferimento a tabelle di utenti o aziende.
Esempi
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
Codice di Risoluzione
ResolutionCode
|
Un codice che indica l'esito finale o come è stata risolta la richiesta di servizio. | ||
|
Descrizione
Il Codice di Risoluzione è un valore strutturato selezionato dall'agente al momento della risoluzione di un caso. Fornisce dettagli specifici sulla soluzione, come 'Risolto dall'Utente', 'Errore Noto', 'Duplicato' o 'Nessuna Azione Necessaria'. Questo attributo è prezioso per l'analisi delle cause profonde. Analizzando la frequenza dei diversi codici di risoluzione, le organizzazioni possono identificare problemi ricorrenti, lacune di conoscenza o problemi di prodotto. Queste informazioni possono quindi essere utilizzate per guidare miglioramenti che riducono il volume di certi tipi di richieste di servizio.
Perché è importante
Fornisce insight sui risultati delle richieste di servizio, il che è cruciale per l'analisi delle cause profonde e l'identificazione di problemi ricorrenti.
Dove trovare
Ciò corrisponde al campo 'close_code' o a un campo codice di risoluzione personalizzato nella tabella 'sn_customerservice_case'.
Esempi
Risolto (soluzione temporanea)Risolto (definitivamente)Non Risolto (Cliente Irrispondente)Chiuso/Risolto dal Richiedente
|
|||
|
Conteggio Riaperture
ReopenCount
|
Il numero di volte in cui una richiesta di servizio risolta è stata riaperta dal cliente. | ||
|
Descrizione
Questo contatore tiene traccia di quante volte un caso è passato da uno stato 'Risolto' o 'Chiuso' a uno stato 'In Lavorazione' o 'Aperto'. Un caso riaperto suggerisce che la soluzione iniziale non è stata efficace o completa. Questo attributo è un forte indicatore di rilavorazione e della qualità della risoluzione al primo tentativo. Un elevato conteggio delle riaperture indica problemi nel processo di risoluzione, come agenti che chiudono i ticket prematuramente o che non affrontano completamente il problema sottostante del cliente. È una metrica chiave per comprendere l'efficacia delle soluzioni proposte.
Perché è importante
Indica risoluzioni fallite e rilavorazioni. Un numero elevato di riaperture segnala una scarsa qualità nel
Dove trovare
Questo è spesso tracciato in un campo chiamato 'reopen_count' nella tabella 'sn_customerservice_case' o in una tabella correlata.
Esempi
012
|
|||
|
Conteggio Riassegnazioni
ReassignmentCount
|
Il numero totale di volte in cui la richiesta di servizio è stata riassegnata a un agente o gruppo diverso. | ||
|
Descrizione
Questo attributo è un contatore che si incrementa ogni volta che i campi 'assigned_to' o 'assignment_group' cambiano. Fornisce una metrica semplice per la quantità di trasferimenti interni subiti da un caso. Il Conteggio delle Riassegnazioni è una misura diretta dell'attrito del processo e un input chiave per la dashboard 'Passaggi di Consegne e Riassegnazioni Agenti' e il KPI 'Passaggi di Consegne Agenti Medi per Richiesta'. Un elevato numero di riassegnazioni spesso indica problemi con l'instradamento iniziale, lacune nelle competenze degli agenti o casi difficili da categorizzare, tutti fattori che portano a tempi di risoluzione più lunghi.
Perché è importante
Misura direttamente l'inefficienza del
Dove trovare
Questo è un campo metrica standard, 'reassignment_count', nella tabella 'task', che 'sn_customerservice_case' estende.
Esempi
0135
|
|||
|
È Risoluzione al Primo Contatto
IsFirstContactResolution
|
Un flag booleano che indica se la richiesta è stata risolta dal primo agente assegnato senza trasferimenti o escalation. | ||
|
Descrizione
Questo attributo calcolato identifica le richieste di servizio che sono state risolte in modo efficiente durante la prima interazione o dal primo agente che ha gestito il caso. La logica di solito verifica condizioni come zero riassegnazioni ('ReassignmentCount' è 0), nessuna attività di 'Escalation Interna Avviata' e nessuna richiesta di ulteriori informazioni dal cliente. Questo attributo misura direttamente una metrica critica del customer service e supporta la dashboard e il KPI 'Tasso di Risoluzione al Primo Contatto'. Permette una facile quantificazione delle prestazioni FCR e aiuta nell'analisi dei fattori, come canale o categoria di richiesta, che contribuiscono o ostacolano il raggiungimento della risoluzione al primo contatto.
Perché è importante
Misura direttamente l'efficienza della risposta iniziale. Un alto tasso di FCR è fortemente legato sia all'efficienza operativa che all'alta soddisfazione del cliente.
Dove trovare
Questo è un attributo calcolato. Viene derivato durante la trasformazione dei dati in base a regole, come 'ReassignmentCount' pari a zero e nessuna attività di escalation.
Esempi
truefalse
|
|||
|
È una Rilavorazione
IsRework
|
Un flag booleano che indica se si sono verificate rilavorazioni significative, come un `case` riaperto o un'indagine ripetuta. | ||
|
Descrizione
Questo è un attributo calcolato che segnala i casi che mostrano schemi di inefficienza o ripetizione. La logica per questo flag potrebbe essere attivata da eventi come 'Richiesta di Servizio Riaperta' o se una sequenza chiave di attività, come 'Agente Inizia Indagine' seguita da 'Soluzione Proposta', si verifica più volte all'interno dello stesso caso. Questo flag è prezioso per identificare rapidamente i casi problematici e quantificare il livello complessivo di rilavorazione nel processo. Supporta direttamente la dashboard 'Hotspot di Rilavorazione e Ripetizione' e il KPI 'Tasso di Rilavorazione', consentendo agli analisti di concentrarsi sui fattori di inefficienza senza dover identificare manualmente i pattern ripetitivi.
Perché è importante
Aiuta a quantificare l'inefficienza del
Dove trovare
Questo è un attributo calcolato. Viene derivato durante la trasformazione dei dati applicando una logica di business che rileva pattern di rilavorazione, come un 'ReopenCount' non nullo o attività ripetute.
Esempi
truefalse
|
|||
|
Sistema di Origine
SourceSystem
|
Il sistema da cui i dati sono stati estratti. | ||
|
Descrizione
Questo attributo identifica l'origine dei dati, il che è particolarmente importante in ambienti dove le informazioni sono aggregate da più sistemi. Per questa vista del processo, il valore sarebbe costantemente 'ServiceNow CSM'. Nell'analisi, questo aiuta nella data governance e nella risoluzione dei problemi. Quando sono coinvolti più sistemi di origine, permette di filtrare il processo per capire come opera all'interno di un sistema specifico o per confrontare le variazioni di processo tra diversi sistemi.
Perché è importante
Fornisce un contesto essenziale sull'origine dei dati, garantendo chiarezza in ambienti multisistema e supportando la data governance.
Dove trovare
Questo è un valore statico aggiunto durante il processo di trasformazione dei dati per etichettare l'origine del dataset.
Esempi
ServiceNow CSM
|
|||
|
Tempo di Elaborazione
ProcessingTime
|
La durata del tempo trascorso lavorando attivamente su un'attività. | ||
|
Descrizione
Il Tempo di Elaborazione, conosciuto anche come tempo attivo o tempo di servizio, misura la durata di un'attività dal suo inizio alla sua fine. Rappresenta il tempo che un agente o un sistema impiega per svolgere attivamente un compito, in contrapposizione al tempo di attesa tra un compito e l'altro. Nel Process Mining, questa metrica è fondamentale per distinguere tra tempo a valore aggiunto e tempo di attesa senza valore aggiunto. L'analisi del tempo di elaborazione aiuta a identificare quali compiti specifici richiedono più tempo e dove ci sono opportunità per l'automazione o la formazione per migliorare l'efficienza. È una metrica fondamentale per l'analisi dei bottleneck.
Perché è importante
Misura il tempo di lavoro attivo per un'attività, aiutando a distinguere il tempo a valore aggiunto dal tempo di attesa improduttivo nel processo.
Dove trovare
Questo è un attributo calcolato, tipicamente derivato come la differenza tra l'EndTime e lo StartTime di un'attività.
Esempi
PT15MPT2H30MP1D
|
|||
|
Ultimo `Data Update`
LastDataUpdate
|
Il timestamp che indica l'ultima estrazione o aggiornamento dei dati dal sistema di origine. | ||
|
Descrizione
Questo attributo registra la data e l'ora dell'estrazione dati più recente. Fornisce contesto sull'aggiornamento dei dati analizzati, assicurando che gli utenti siano consapevoli se stanno visualizzando informazioni quasi in tempo reale o una snapshot storica. Durante l'analisi, questo è un pezzo critico di metadati per comprendere l'intervallo di tempo del dataset. Aiuta gli utenti a interpretare correttamente dashboard e KPI, sapendo, ad esempio, che i dati sono aggiornati all'ultima ora o al giorno precedente.
Perché è importante
Indica la freschezza dei
Dove trovare
Questo timestamp viene generato e aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL).
Esempi
2023-11-20T08:00:00Z
|
|||
Attività di Servizio Clienti
| Activity | Descrizione | ||
|---|---|---|---|
|
Escalation Interna Avviata
|
Rappresenta l'escalation formale di una richiesta di servizio a un livello superiore di supporto o gestione per la risoluzione. Questo può essere desunto da un cambiamento nel gruppo di assegnazione a un team di livello superiore o dall'impostazione di un flag. | ||
|
Perché è importante
Tracciare le escalation aiuta a identificare le debolezze di processo, le lacune di conoscenza nel supporto di primo livello e i tipi di casi complessi. Questo è un indicatore chiave di attrito del processo e insoddisfazione del cliente.
Dove trovare
Può essere inferito dal
Acquisisci
Rilevare il cambiamento nel campo 'escalation' o un passaggio a un
Tipo di evento
inferred
|
|||
|
Richiesta Assegnata all'Agente
|
Questa attività si verifica quando una richiesta di servizio viene assegnata a un agente specifico per indagine e risoluzione. Viene acquisita inferendo il cambiamento nel campo assigned_to sul record del caso. | ||
|
Perché è importante
Questo è un traguardo critico per misurare i tempi di risposta iniziali e la distribuzione del carico di lavoro degli agenti. Il tracciamento delle riassegnazioni di questo campo evidenzia inefficienze di processo e potenziali bottleneck nella disponibilità degli agenti.
Dove trovare
Inferito dalla cronologia di audit (
Acquisisci
Rilevare il cambiamento di valore per il campo 'assigned_to' nel
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Chiusa
|
Questa è l'attività finale, che segna la chiusura formale del record della richiesta di servizio, spesso dopo un periodo di conferma post-risoluzione. Viene acquisita quando lo stato del caso cambia in 'Chiuso' e il timestamp closed_at viene impostato. | ||
|
Perché è importante
Essendo la fine definitiva del
Dove trovare
Inferito dalla cronologia di audit quando il campo
Acquisisci
Rilevare il cambiamento di
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Creata
|
Questa attività segna l'inizio del processo di customer service, quando un nuovo caso viene formalmente registrato nel sistema. Questo evento viene acquisito esplicitamente quando un nuovo record viene inserito nella tabella sn_customerservice_case. | ||
|
Perché è importante
Essendo il punto di partenza per ogni
Dove trovare
Questo evento corrisponde alla creazione di un record nella tabella sn_customerservice_case. Il timestamp è preso dal campo sys_created_on.
Acquisisci
Timestamp di creazione del record (sys_created_on) nella tabella sn_customerservice_case.
Tipo di evento
explicit
|
|||
|
Richiesta di Servizio Risolta
|
Questo è un traguardo chiave che indica che l'agente di servizio ha completato il lavoro e il problema è considerato risolto. Questo viene acquisito quando lo stato del caso viene cambiato in 'Risolto' e il timestamp resolved_at viene popolato. | ||
|
Perché è importante
Questa attività segna la fine del processo di risoluzione attivo ed è cruciale per calcolare i tempi di ciclo di risoluzione e l'aderenza agli SLA. Serve come punto di riferimento primario per molti KPI di efficienza.
Dove trovare
Inferito dalla cronologia di audit quando il campo
Acquisisci
Rilevare il cambiamento di
Tipo di evento
inferred
|
|||
|
Agente Avvia Indagine
|
Questa attività indica che un agente ha iniziato attivamente a lavorare sulla richiesta di servizio. Si desume tipicamente quando lo stato del caso cambia da uno status come 'Nuovo' o 'Assegnato' a 'In Lavorazione'. | ||
|
Perché è importante
Questo evento aiuta a distinguere il tempo di coda dal tempo di lavoro attivo. L'analisi della durata tra l'assegnazione e l'inizio dell'indagine rivela ritardi nell'acquisizione di nuovi casi da parte degli agenti.
Dove trovare
Desunto dal cambiamento del campo stato del caso a uno stato di lavoro attivo, come 'In Lavorazione'. I valori specifici dello stato possono essere configurati e dovrebbero essere verificati.
Acquisisci
Rilevare il cambiamento nel campo
Tipo di evento
inferred
|
|||
|
Gruppo di assegnazione modificato
|
Indica che la responsabilità per un `case` è stata trasferita da un team all'altro. Questo `event` viene inferito monitorando le modifiche al campo `assignment_group` all'interno del record del `case`. | ||
|
Perché è importante
Tracciare i cambiamenti nei gruppi di assegnazione è cruciale per analizzare i passaggi di consegne inter-dipartimentali e identificare problemi sistematici di routing. Un'alta frequenza di questa attività può indicare una proprietà poco chiara o definizioni di processo insufficienti.
Dove trovare
Inferito dalla cronologia di audit (
Acquisisci
Rilevare il cambiamento di valore per il campo
Tipo di evento
inferred
|
|||
|
Informazioni Ricevute dal Cliente
|
Questa attività segna il punto in cui il cliente fornisce le informazioni richieste, permettendo all'agente di riprendere il lavoro. Ciò si desume quando lo stato del caso passa da 'In Attesa di Info Utente' a uno stato attivo. | ||
|
Perché è importante
Questo evento conclude il periodo di attesa del cliente, consentendo una misurazione precisa dei tempi di risposta del cliente. Aiuta a identificare quali tipi di casi o clienti sono associati ai ritardi più lunghi.
Dove trovare
Inferito dalla cronologia di audit della tabella
Acquisisci
Rilevare il cambiamento nel campo
Tipo di evento
inferred
|
|||
|
Informazioni Richieste al Cliente
|
Si verifica quando un agente richiede informazioni aggiuntive al cliente per procedere e pone il caso in uno stato di sospensione. Ciò si desume da un cambiamento di stato a un valore come 'In Attesa di Info Utente' o 'In Sospeso'. | ||
|
Perché è importante
Questa attività è cruciale per l'analisi dei 'Tempi di Attesa per Informazioni del Cliente'. Isola i ritardi di processo causati da dipendenze esterne, separandoli dal tempo di elaborazione interno.
Dove trovare
Inferito dalla cronologia di audit della tabella
Acquisisci
Rilevare il cambiamento nel campo
Tipo di evento
inferred
|
|||
|
Richiesta Categorizzata e Prioritizzata
|
Rappresenta il triage iniziale in cui la richiesta di servizio viene classificata e le viene assegnato un livello di priorità per determinarne l'urgenza e l'instradamento. Ciò si desume dalle modifiche ai campi categoria, sottocategoria o priorità nel log di audit del record del caso. | ||
|
Perché è importante
L'analisi di questa attività aiuta a identificare i ritardi nel
Dove trovare
Inferito dalla cronologia di audit (
Acquisisci
Rilevare il primo valore impostato o il cambiamento di valore per i campi 'category' o 'priority'.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Riaperta
|
Si verifica quando una richiesta di servizio precedentemente risolta torna a uno stato attivo perché il problema si è ripresentato o la soluzione è stata inefficace. Ciò si desume rilevando un cambiamento di stato da 'Risolto' a 'In Lavorazione'. | ||
|
Perché è importante
I casi riaperti sono una misura diretta della qualità della risoluzione e un motore primario del lavoro di rielaborazione. Analizzare questi eventi è fondamentale per migliorare i tassi di risoluzione al primo contatto e la soddisfazione del cliente.
Dove trovare
Inferito dalla cronologia di audit della tabella
Acquisisci
Rilevare il cambiamento di
Tipo di evento
inferred
|
|||
|
SLA Violato
|
Rappresenta il momento in cui una richiesta di servizio non riesce a soddisfare un Service Level Agreement definito, come il tempo di risoluzione. Questo è un evento calcolato, derivato confrontando il tempo di risoluzione con il tempo di fine pianificato dell'SLA. | ||
|
Perché è importante
Identificare le violazioni SLA è fondamentale per il monitoraggio della
Dove trovare
Calcolato analizzando i record nella tabella
Acquisisci
Verificare il flag 'has_breached' sul record
Tipo di evento
calculated
|
|||
|
Soluzione Proposta
|
Questa attività segna il momento in cui un agente ha identificato una soluzione e l'ha comunicata al cliente per la sua conferma. Spesso si desume da un cambiamento di stato a un valore come 'In Attesa di Accettazione' o da una specifica nota di lavoro. | ||
|
Perché è importante
Questo traguardo separa la fase di indagine dalla fase di conferma e risoluzione. L'analisi del tempo trascorso in attesa di conferma da parte del cliente può rivelare opportunità per ottimizzare le fasi di chiusura di un caso.
Dove trovare
Inferito dal
Acquisisci
Rilevare il cambiamento nel campo
Tipo di evento
inferred
|
|||
|
Sondaggio Cliente Inviato
|
Rappresenta l'invio di un sondaggio di soddisfazione del cliente in seguito alla risoluzione di un caso. Questo evento viene tipicamente acquisito quando un record di istanza di sondaggio viene creato e associato al caso. | ||
|
Perché è importante
Questa attività aiuta a correlare i pattern di esecuzione del processo con il feedback del cliente. Capire quando e se i sondaggi vengono inviati è importante per analizzare l'efficacia del ciclo di feedback.
Dove trovare
Questo è un evento esplicito registrato in una tabella specifica per i sondaggi come asmt_assessment_instance, che contiene un riferimento al record del caso di origine.
Acquisisci
Creazione di un record nella tabella 'asmt_assessment_instance' collegata al caso.
Tipo di evento
explicit
|
|||