Template dati per la Gestione delle Richieste
Template dati per la Gestione delle Richieste
- Attributi consigliati per un'analisi completa
- Attività chiave da tracciare per la scoperta dei processi
- Guida all'estrazione dei dati per Jira Service Management
Attributi di Gestione delle Richieste di Servizio
| Nome | Descrizione | ||
|---|---|---|---|
|
Activity
ActivityName
|
Il nome dello specifico `event` o `task` che si è verificato all'interno del ciclo di vita della richiesta di servizio. | ||
|
Descrizione
Descrive l'azione o la transizione di stato specifica (es. 'Richiesta creata'). Analizzare la sequenza di queste attività è il cuore del process mining. Permette di visualizzare mappe di processo, identificare colli di bottiglia e deviazioni dal flusso standard, elementi critici per l'efficienza e la conformità.
Perché è importante
Definisce le fasi del processo, consentendo la visualizzazione della mappa di processo e l'analisi dei pattern di workflow e delle deviazioni.
Dove trovare
Deriva solitamente dallo storico delle transizioni di stato. Ogni voce nel changelog di Jira per il campo stato rappresenta un'attività.
Esempi
Richiesta in TriageInformazioni richiesteSoluzione ImplementataRichiesta di Servizio Chiusa
|
|||
|
ID Richiesta di Servizio
ServiceRequestId
|
L'identificativo univoco, che funge da chiave primaria per tutti gli eventi correlati. | ||
|
Descrizione
L'ID della Richiesta, spesso chiamato Issue Key in Jira, identifica univocamente ogni ticket. È il filo conduttore che collega tutti gli eventi, consentendo un'analisi end-to-end completa. Nel process mining, questo ID è essenziale per la correlazione dei casi, garantendo che ogni attività e timestamp sia associato correttamente alla singola richiesta.
Perché è importante
Questo ID è l'identificativo fondamentale che unisce tutte le attività in un unico flusso end-to-end, rendendo possibile l'analisi del processo.
Dove trovare
Si tratta del campo 'chiave' (key) del ticket in Jira Service Management.
Esempi
SR-2023-001IT-45892HELP-105
|
|||
|
Ora di Inizio
EventTime
|
La data e l'ora precise in cui si è verificata una specifica attività o un evento. | ||
|
Descrizione
L'Ora di Inizio, o timestamp dell'evento, registra il momento esatto di ogni attività. È un componente critico per il process mining poiché fornisce il contesto temporale. Serve a ordinare gli eventi, calcolare le durate e misurare i tempi di ciclo totali. Senza timestamp precisi, è impossibile comprendere il flusso, identificare i ritardi o misurare l'efficienza reale del processo.
Perché è importante
Timestamp essenziale per ordinare gli eventi, calcolare i tempi di ciclo e identificare i colli di bottiglia.
Dove trovare
Timestamp associato ai cambi di stato nel changelog di Jira. L'ora di creazione è il campo 'creato'.
Esempi
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
|
|||
|
Sistema di Origine
SourceSystem
|
Il sistema da cui sono stati estratti i dati. | ||
|
Descrizione
Identifica l'origine dei dati (Jira Service Management). Diventa fondamentale quando si integrano dati da più sistemi. Aiuta a tracciare la provenienza dei dati e a garantirne la qualità, permettendo di confrontare processi che interagiscono con diverse piattaforme.
Perché è importante
Identifica l'origine dei dati, fondamentale per la data governance e per combinare dati di processo provenienti da più sistemi aziendali.
Dove trovare
Questo è tipicamente un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per etichettare l'origine del dataset.
Esempi
Jira Service ManagementJiraSM
|
|||
|
Ultimo `Data Update`
LastDataUpdate
|
Il timestamp che indica quando i dati sono stati aggiornati l'ultima volta dal sistema sorgente. | ||
|
Descrizione
Registra data e ora dell'ultima estrazione dati da Jira. Fornisce il contesto sull'aggiornamento dell'analisi. Conoscere la freschezza dei dati è essenziale per decisioni informate. Questo timestamp chiarisce se si visualizzano info in tempo reale o istantanee passate.
Perché è importante
Indica quanto sono recenti i dati, garantendo che le analisi siano basate su informazioni aggiornate.
Dove trovare
Campo di metadati generato dallo strumento di estrazione al termine dell'operazione.
Esempi
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Assegnatario
Assignee
|
L'utente o operatore attualmente assegnato al ticket. | ||
|
Descrizione
L'Assegnatario è il responsabile dell'azione successiva o della risoluzione. Il valore può cambiare più volte durante il ciclo di vita del ticket. Questo attributo è fondamentale per l'analisi dei carichi di lavoro e la gestione delle risorse. Consente di filtrare il processo per operatore, confrontare i tempi di risoluzione e identificare necessità di formazione o squilibri che causano colli di bottiglia.
Perché è importante
Vitale per analizzare il carico di lavoro degli operatori, misurare le performance e gestire le risorse.
Dove trovare
Corrisponde al campo 'assegnatario' del ticket Jira.
Esempi
Alice JohnsonBob WilliamsNon assegnato
|
|||
|
Data di scadenza dell'SLA
SlaDueDate
|
La data e l'ora entro cui la richiesta deve essere risolta secondo lo SLA. | ||
|
Descrizione
La Scadenza SLA è il termine ultimo per la risoluzione, basato su priorità e policy configurate in Jira Service Management. È fondamentale per monitorare le performance degli SLA. Confrontando il tempo di risoluzione reale con questa data, il sistema determina se la richiesta è puntuale o se rischia di violare i termini di servizio.
Perché è importante
Benchmark per misurare le performance. Supporta il calcolo della conformità agli SLA e aiuta a prioritizzare le attività.
Dove trovare
Le informazioni sugli SLA sono gestite da Jira Service Management e sono accessibili tramite API, spesso memorizzate in campi personalizzati aggiornati in tempo reale.
Esempi
2023-10-28T16:00:00Z2023-11-01T09:00:00Z
|
|||
|
Priorità Richiesta
RequestPriority
|
Il livello di priorità assegnato, come Bassa, Media, Alta o Critica. | ||
|
Descrizione
La Priorità della Richiesta indica l'urgenza e l'impatto aziendale di una richiesta di servizio. Questa classificazione determina l'ordine di gestione delle richieste e spesso detta i tempi di risoluzione target e gli SLA. Nell'analisi dei processi, la priorità è una dimensione chiave per la segmentazione. Consente di confrontare i tempi di ciclo e il rispetto degli SLA tra i diversi livelli di priorità, garantendo che le richieste ad alta priorità siano effettivamente elaborate più velocemente. Ciò aiuta a convalidare l'efficacia del sistema di prioritizzazione.
Perché è importante
Consente di segmentare l'analisi per garantire che le richieste ad alta priorità siano gestite più rapidamente e rispettino livelli di servizio più rigorosi.
Dove trovare
Corrisponde al campo 'priorità' del ticket Jira.
Esempi
MassimaElevatoMedioBasso
|
|||
|
Stato Richiesta
RequestStatus
|
Lo stato attuale della richiesta nel suo ciclo di vita. | ||
|
Descrizione
Rappresenta lo stato attuale del ticket (es. 'Aperto', 'In corso'). Offre un'istantanea istantanea. Mentre il log attività mostra lo storico, lo stato attuale serve ad analizzare il carico aperto. Ad esempio, permette di focalizzarsi sui ticket in attesa del fornitore da troppo tempo, evidenziando ritardi esterni.
Perché è importante
Fornisce un'istantanea attuale di ogni case, consentendo l'analisi del lavoro in corso (WIP) e l'identificazione di richieste bloccate o datate.
Dove trovare
Si tratta del campo 'stato' del ticket Jira.
Esempi
ApertoIn CorsoIn Sospeso ClienteRisolto
|
|||
|
Tipo di Richiesta
RequestType
|
La classificazione della richiesta, ad esempio 'Richiesta di accesso' o 'Problema hardware'. | ||
|
Descrizione
Il Tipo di Richiesta categorizza la richiesta di servizio in base alla sua natura. Si tratta di una dimensione fondamentale per l'analisi, poiché tipi diversi di richieste hanno spesso processi di risoluzione, SLA e requisiti di risorse distinti. Segmentando l'analisi del processo per Tipo di Richiesta, le organizzazioni possono personalizzare i miglioramenti per workflow specifici. Ad esempio, il bottleneck per una richiesta di 'Reset Password' sarà molto diverso da quello per il 'Provisioning di un nuovo server'. Questo attributo è essenziale per creare dashboard pertinenti come 'Qualità della risoluzione per categoria'.
Perché è importante
Essenziale per confrontare processi, carichi di lavoro e performance tra diverse categorie di richieste.
Dove trovare
Spesso corrisponde al campo 'issuetype' o a un campo personalizzato 'Tipo di richiesta' in Jira.
Esempi
Richiesta di un nuovo accountRichiedere supporto ITInserimento nuovo dipendente (onboarding)
|
|||
|
Canale
Channel
|
Il metodo di invio usato per la richiesta, come E-mail, Portale o API. | ||
|
Descrizione
L'attributo Canale identifica la porta d'ingresso della richiesta. I canali comuni in Jira Service Management sono il portale clienti, l'e-mail o la creazione diretta. Analizzare il processo per canale aiuta a capire il comportamento degli utenti. Può rivelare se le richieste da certi canali richiedono più tempo, suggerendo la necessità di migliorare i moduli del portale o le regole delle e-mail.
Perché è importante
Aiuta ad analizzare se il canale di invio influisce sui tempi di risoluzione, sulla chiarezza della richiesta o sull'efficienza complessiva del processo.
Dove trovare
Disponibile in Jira tramite il campo 'Tipo di canale della richiesta'. Potrebbe richiedere accessi API specifici.
Esempi
portalemailapi
|
|||
|
Durata coinvolgimento fornitore
VendorEngagementDuration
|
Il tempo totale trascorso in attesa di un fornitore esterno. | ||
|
Descrizione
Somma il tempo totale in cui una richiesta è stata gestita da un fornitore esterno. Si calcola tra l'inizio e la fine del coinvolgimento del partner. Essenziale per monitorare i ritardi dei fornitori. Aiuta a quantificare l'impatto di terze parti, fondamentale per gestire i partner e definire aspettative realistiche con i clienti.
Perché è importante
Isola e quantifica i ritardi causati da dipendenze esterne, fornendo dati per gestire le performance dei fornitori e migliorare le previsioni.
Dove trovare
Calcolato durante la trasformazione dei dati misurando il tempo intercorso tra gli eventi 'Vendor Engagement Started' e 'Vendor Engagement Ended'.
Esempi
172800604800259200
|
|||
|
È Riaperto
IsReopened
|
Un flag booleano che indica se una richiesta di servizio è stata riaperta dopo essere stata risolta. | ||
|
Descrizione
Questo flag vero/falso si attiva se il workflow include una riapertura del ticket. Si ottiene analizzando la sequenza di attività. È essenziale per calcolare il tasso di riapertura. Un valore alto indica scarsa qualità della risoluzione al primo colpo, causando rilavorazioni. Analizzare i ticket associati a questo flag aiuta a individuare aree critiche da migliorare.
Perché è importante
Misura direttamente il rework e la qualità della risoluzione al primo tentativo, che sono indicatori chiave dell'efficacia del processo e della soddisfazione del cliente.
Dove trovare
Calcolato durante la trasformazione dei dati verificando se la sequenza di attività per un case contiene una transizione 'Reopened' dopo una transizione 'Resolved'.
Esempi
truefalse
|
|||
|
Organization
Organization
|
L'organizzazione del cliente o il dipartimento del segnalatore. | ||
|
Descrizione
Raggruppa i segnalatori per organizzazione. Jira Service Management usa la funzione 'Organizzazioni' per gestire richieste di diversi clienti o team. L'analisi per organizzazione offre contesto aziendale, aiutando a capire quali settori usano più risorse, se ci sono problemi ricorrenti e se gli SLA sono rispettati uniformemente.
Perché è importante
Facilita l'analisi della domanda di servizi e delle performance per cliente o dipartimento interno, fornendo insight aziendali chiave.
Dove trovare
Dati provenienti dal campo 'Organizzazioni' di Jira Service Management.
Esempi
Acme CorporationDipartimento FinanziarioGlobal Tech Inc.
|
|||
|
Risoluzione
Resolution
|
L'esito finale o la conclusione di una richiesta risolta. | ||
|
Descrizione
Il campo Risoluzione indica il motivo della chiusura del ticket (es. 'Fatto', 'Duplicato'). Fornisce dettagli sull'esito oltre lo stato 'Chiuso'. Analizzare le risoluzioni aiuta a comprendere la qualità degli esiti. Ad esempio, molti 'Duplicati' possono indicare problemi nel processo di invio, mentre tracciare le riaperture aiuta a individuare soluzioni inefficaci.
Perché è importante
Fornisce contesto sull'esito di una richiesta, aiutando ad analizzare la qualità della risoluzione e a identificare i trend sui motivi di chiusura.
Dove trovare
Corrisponde al campo 'risoluzione' del ticket Jira, solitamente impostato al passaggio a uno stato di tipo 'completato'.
Esempi
CompletatoNon si faràDuplicatoRisolto
|
|||
|
Segnalante
Reporter
|
L'utente che ha creato o segnalato la richiesta. | ||
|
Descrizione
Il Segnalatore è la persona che ha inviato la richiesta. Questo attributo identifica lo stakeholder che ha avviato il processo. Nell'analisi, può essere utilizzato per comprendere i modelli di richiesta per utente o dipartimento. Aiuta a capire quali settori inviano più ticket o se certi utenti riscontrano problemi ricorrenti, facilitando una gestione proattiva e una formazione mirata.
Perché è importante
Identifica chi ha originato la richiesta, consentendo l'analisi dei volumi e dei tipi di richiesta per utente, dipartimento o cliente.
Dove trovare
Corrisponde al campo 'segnalatore' del ticket Jira.
Esempi
Charles DarwinMarie CurieIsaac Newton
|
|||
|
Stato SLA
SlaState
|
Indica se la richiesta di servizio ha rispettato, violato o rientra nello SLA definito. | ||
|
Descrizione
Lo Stato SLA è un attributo calcolato che classifica ogni richiesta in base alla performance rispetto alla scadenza. I valori includono 'Rispettato', 'Violato' o 'In corso', determinati confrontando il timestamp di risoluzione con la data di scadenza. È l'attributo principale per la dashboard sulla performance degli SLA e serve a calcolare il tasso di rispetto degli stessi. Fornisce una vista immediata della conformità, essenziale per la reportistica e il mantenimento della qualità del servizio.
Perché è importante
Fornisce un indicatore chiaro e immediato delle performance SLA, una misura critica della qualità del servizio e della conformità contrattuale.
Dove trovare
Calcolato durante la trasformazione dei dati. Se il tempo di risoluzione è precedente a 'SlaDueDate', lo stato è 'Met'; altrimenti è 'Breached'.
Esempi
RaggiuntoViolatoIn Corso
|
|||
|
Team assegnato
AssignedTeam
|
Il team o gruppo responsabile della gestione della richiesta. | ||
|
Descrizione
Specifica il team assegnato, un raggruppamento superiore rispetto al singolo operatore. Utile per confrontare le performance, ad esempio tra Supporto di Primo Livello e Network Operations. Consente di aggregare metriche per team nelle dashboard, facilitando confronti equi e aiutando a capire il contributo di ogni gruppo all'erogazione del servizio.
Perché è importante
Consente l'analisi delle performance e il bilanciamento del carico di lavoro a livello di team o dipartimento, anziché solo per singolo agente.
Dove trovare
Può essere un campo personalizzato Jira (es. 'Team') o derivare dal profilo dell'assegnatario.
Esempi
Supporto IT - Livello 1Team InfrastruttureSupporto Applicativo
|
|||
|
Tempo dal triage all'assegnazione
TriageToAssignmentTime
|
La durata tra il triage della richiesta e l'assegnazione a un operatore. | ||
|
Descrizione
Misura l'efficienza della fase iniziale di routing. È la differenza di tempo tra 'Richiesta assegnata' e 'Richiesta sottoposta a triage'. È alla base del KPI sul tempo medio di assegnazione. Una durata eccessiva indica spesso colli di bottiglia nel service desk, come carenza di personale per il triage o incertezze sulla destinazione corretta del ticket.
Perché è importante
Misura l'efficienza delle prime fasi cruciali della gestione delle richieste, evidenziando i ritardi prima ancora che il lavoro possa iniziare.
Dove trovare
Calcolato durante la trasformazione dei dati sottraendo il timestamp dell'evento 'Request Triaged' dall'evento 'Request Assigned'.
Esempi
3009001800
|
|||
|
Tempo di ciclo del caso
CaseCycleTime
|
Il tempo totale trascorso dalla creazione alla chiusura finale. | ||
|
Descrizione
Il Case Cycle Time è una metrica calcolata che misura la durata totale del ciclo di vita di una richiesta di servizio. In genere viene calcolato come differenza tra il timestamp di chiusura della richiesta e quello di creazione. Questo è uno dei KPI più importanti nel Process Mining, poiché supporta direttamente il KPI 'Average Service Request Cycle Time' e la dashboard 'Service Request End-to-End Cycle Time'. Fornisce una misura ad alto livello dell'efficienza complessiva del processo e dei tempi di attesa del cliente.
Perché è importante
KPI primario per misurare l'efficienza del processo e l'esperienza complessiva del cliente.
Dove trovare
Calcolato durante la trasformazione dei dati sottraendo il timestamp di creazione dal timestamp di chiusura finale per ogni case.
Esempi
864003600007200
|
|||
Attività di Gestione delle Richieste di Servizio
| Activity | Descrizione | ||
|---|---|---|---|
|
Richiesta Assegnata
|
Si verifica quando la richiesta viene assegnata a un operatore. Jira traccia le modifiche al campo 'Assegnatario', fornendo un timestamp preciso dell'assegnazione. | ||
|
Perché è importante
Milestone chiave per misurare il tempo di assegnazione e il carico di lavoro. Segna il passaggio dalla coda alla gestione attiva.
Dove trovare
Acquisito dalla cronologia del ticket cercando la prima istanza in cui il campo 'Assignee' viene impostato o modificato da non assegnato.
Acquisisci
Utilizzi il timestamp del primo cambio nel campo 'Assegnatario' nella cronologia del ticket.
Tipo di evento
explicit
|
|||
|
Richiesta di Servizio Chiusa
|
Rappresenta la chiusura amministrativa finale della richiesta di servizio, che spesso avviene automaticamente dopo un periodo prestabilito nello stato 'Risolto'. Questo è il punto terminale del ciclo di vita del ticket in Jira. | ||
|
Perché è importante
Evento finale del processo. Il tempo tra 'Risolto' e 'Chiuso' serve ad analizzare il carico amministrativo o le policy di chiusura automatica.
Dove trovare
Dedotto dalla cronologia del ticket. Il timestamp corrisponde al cambio di stato finale in 'Closed' o uno stato terminale equivalente.
Acquisisci
Identificare il timestamp dell'ultimo cambio di stato verso uno stato 'Closed'.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Creata
|
Segna l'inizio del ciclo di vita quando un utente invia una richiesta. In Jira, questo evento è registrato alla creazione di un ticket di tipo 'Service Request'. | ||
|
Perché è importante
Evento iniziale del processo. Essenziale per il calcolo del tempo di ciclo e per capire volumi e modelli di arrivo delle richieste.
Dove trovare
Evento esplicito registrato nella cronologia. Il timestamp è il campo 'creato' del ticket Jira.
Acquisisci
Utilizzi il timestamp di creazione del ticket dalla tabella 'issues' o dallo storico.
Tipo di evento
explicit
|
|||
|
Richiesta di Servizio Risolta
|
Contrassegna il momento ufficiale in cui la richiesta è considerata evasa e la soluzione registrata. Jira popola il campo 'Resolution Date' quando un ticket entra per la prima volta in uno stato della categoria 'Done'. | ||
|
Perché è importante
Milestone finale del processo, critica per calcolare i tempi di risoluzione e il rispetto degli SLA. Indica la fine del lavoro attivo.
Dove trovare
Evento esplicito. Il timestamp è il valore nel campo 'Data di risoluzione' di Jira, impostato al primo passaggio a uno stato 'Completato'.
Acquisisci
Utilizzi il campo 'resolutiondate' del ticket Jira, popolato automaticamente.
Tipo di evento
explicit
|
|||
|
Risoluzione proposta
|
In molti workflow del Service Desk, questo è un passaggio distinto in cui viene proposta una soluzione al richiedente per l'approvazione. Viene dedotto quando lo stato del ticket passa a una condizione come 'Pending Customer Acceptance' o 'Awaiting Confirmation'. | ||
|
Perché è importante
Questa attività isola il tempo di attesa del feedback cliente dopo la proposta di soluzione, distinguendolo dal tempo di lavoro interno.
Dove trovare
Dedotto dalla cronologia del ticket, acquisito al timestamp in cui lo stato cambia indicando che la soluzione è in attesa di validazione da parte del cliente.
Acquisisci
Identificare il timestamp del cambio di stato a 'Pending Customer Acceptance' o equivalente.
Tipo di evento
inferred
|
|||
|
Fine coinvolgimento fornitore
|
Rappresenta il momento in cui il fornitore esterno ha completato il proprio intervento e la richiesta di servizio viene restituita al team interno. Si deduce quando il ticket esce dallo stato 'In attesa del fornitore'. | ||
|
Perché è importante
Misurare la durata del coinvolgimento dei fornitori aiuta a gestirne le performance e a comprendere l'impatto di terze parti sui tempi di risoluzione complessivi.
Dove trovare
Dedotto dalla cronologia del ticket. Il timestamp corrisponde al momento in cui lo stato del ticket torna da uno stato 'vendor' a uno stato 'In Progress'.
Acquisisci
Identificare il timestamp in cui il campo 'status' passa da uno stato 'vendor' a uno stato 'active'.
Tipo di evento
inferred
|
|||
|
Informazioni Fornite
|
Si verifica quando il richiedente risponde con le informazioni necessarie, consentendo all'agente di riprendere il lavoro. Viene dedotto quando il ticket esce dallo stato 'Waiting for customer', spesso in seguito all'aggiunta di un commento da parte del richiedente. | ||
|
Perché è importante
Questa attività chiude il ciclo di comunicazione con il cliente. Il tempo tra la richiesta e la ricezione delle informazioni è cruciale per analizzare i tempi di attesa.
Dove trovare
Dedotto dalla cronologia del ticket. Il timestamp corrisponde al momento in cui lo stato del ticket torna da 'Waiting for customer' a uno stato 'In Progress'.
Acquisisci
Identificare il timestamp in cui il campo 'status' passa da uno stato 'waiting' a uno stato 'active'.
Tipo di evento
inferred
|
|||
|
Informazioni richieste
|
Contrassegna il momento in cui un agente richiede maggiori informazioni al richiedente per procedere con la risoluzione. Tipicamente viene dedotto dalla transizione del ticket a uno stato come 'Waiting for customer' o 'Pending Input'. | ||
|
Perché è importante
Cicli di 'Information Requested' frequenti o lunghi possono indicare invii iniziali poco chiari o comunicazioni inefficienti, rappresentando una fonte significativa di ritardi.
Dove trovare
Dedotto dalla cronologia del ticket. Il timestamp corrisponde al momento in cui lo stato del ticket passa a 'Waiting for customer' o uno stato equivalente.
Acquisisci
Identificare il timestamp in cui il campo 'status' assume un valore che indica l'attesa del cliente.
Tipo di evento
inferred
|
|||
|
Inizio coinvolgimento fornitore
|
Indica che la richiesta è stata scalata a un fornitore esterno. Si deduce da passaggi di stato come 'In attesa del fornitore' o 'Con terze parti'. | ||
|
Perché è importante
Tracciare il coinvolgimento dei fornitori è cruciale per identificare ritardi esterni fuori dal controllo del service desk.
Dove trovare
Dedotto dalla cronologia del ticket. Il timestamp corrisponde al momento in cui lo stato del ticket passa a uno stato designato come 'vendor'.
Acquisisci
Identificare il timestamp in cui il campo 'status' assume un valore come 'Waiting for Vendor'.
Tipo di evento
inferred
|
|||
|
Richiesta in Triage
|
Rappresenta la valutazione iniziale di una richiesta di servizio, in cui ne vengono determinati priorità, categoria e impatto. Questa attività viene solitamente dedotta da un cambio di stato, come il passaggio da 'Nuovo' a 'In corso' o a uno stato di 'Triage' dedicato. | ||
|
Perché è importante
Analizzare il tempo di triage aiuta a valutare l'efficienza del processo iniziale di gestione delle richieste. I ritardi in questa fase possono influire significativamente sui tempi di risoluzione complessivi e sul rispetto degli SLA.
Dove trovare
Dedotto dalla cronologia del ticket identificando il primo timestamp di un cambio di stato da una condizione iniziale 'New' o 'Open' a uno stato attivo come 'In Progress'.
Acquisisci
Identificare il primo cambio di stato da 'New' o da uno stato iniziale equivalente in base al workflow del progetto.
Tipo di evento
inferred
|
|||
|
Richiesta Riaperta
|
Questa attività cattura i casi in cui una richiesta già risolta torna attiva. Si deduce dal passaggio da uno stato risolto a uno aperto o in corso. | ||
|
Perché è importante
Monitorare le riaperture è critico per misurare la qualità e il tasso di risoluzione al primo colpo. Valori alti indicano soluzioni inefficaci.
Dove trovare
Dedotto dalla cronologia del ticket identificando una transizione di stato da una categoria 'Resolved' o 'Closed' a una categoria 'Open' o 'In Progress'.
Acquisisci
Cercare un cambio di stato da una categoria 'Done' a una categoria 'To Do' o 'In Progress'.
Tipo di evento
inferred
|
|||
|
Risoluzione confermata
|
Si verifica quando il richiedente accetta formalmente la soluzione proposta, innescando spesso una transizione automatica allo stato 'Resolved'. Questo evento viene solitamente dedotto da tale cambio di stato. | ||
|
Perché è importante
Convalida l'efficacia della soluzione e ferma il cronometro dello SLA. Aiuta a misurare quanto tempo impiegano i clienti a confermare la risoluzione.
Dove trovare
Dedotto dalla cronologia del ticket. Il timestamp corrisponde al passaggio di stato da 'Pending Customer Acceptance' a 'Resolved' o 'Closed'.
Acquisisci
Identificare il timestamp del cambio di stato da 'Pending Customer Acceptance' a uno stato 'Resolved' o 'Closed'.
Tipo di evento
inferred
|
|||
|
Soluzione Implementata
|
Indica che l'agente ha eseguito le azioni necessarie o sviluppato una soluzione per soddisfare la richiesta. Spesso viene dedotto da un cambio di stato in 'Pending Review' o direttamente in 'Resolved'. | ||
|
Perché è importante
Segna il completamento del lavoro di risoluzione. Il tempo che precede questa fase rappresenta la parte a maggior valore aggiunto del processo.
Dove trovare
Dedotto dalla cronologia del ticket, corrispondente al timestamp del cambio di stato in 'Resolved', 'Pending Acceptance' o uno stato simile di pre-chiusura.
Acquisisci
Identificare il timestamp in cui il campo 'status' assume un valore che indica il completamento del lavoro.
Tipo di evento
inferred
|
|||