Template dati per la Gestione delle Richieste

Jira Service Management
Template dati per la Gestione delle Richieste

Template dati per la Gestione delle Richieste

Questo template offre un approccio strutturato per raccogliere i dati necessari all'analisi dei processi. Delinea attributi e attività da tracciare e guida all'estrazione delle info dal sistema. Lo utilizzi per velocizzare la preparazione dei dati.
  • Attributi consigliati per un'analisi completa
  • Attività chiave da tracciare per la scoperta dei processi
  • Guida all'estrazione dei dati per Jira Service Management
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi di Gestione delle Richieste di Servizio

Questi sono i campi dati consigliati per un'analisi completa della gestione delle richieste di servizio.
5 Obbligatorio 5 Consigliato 10 Facoltativo
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
Obbligatorio Consigliato Facoltativo

Attività di Gestione delle Richieste di Servizio

Questi sono i passaggi chiave del processo e le tappe fondamentali da acquisire nel suo event log per un'accurata scoperta e ottimizzazione del processo.
5 Consigliato 8 Facoltativo
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
Consigliato Facoltativo

Guide all'Estrazione

Come estrarre i suoi dati da Jira Service Management