Il vostro Template dati per la gestione delle Service Request
Il vostro Template dati per la gestione delle Service Request
- Attributi consigliati per un'analisi completa
- Attività chiave da tracciare per la scoperta dei processi
- Guida all'estrazione dei dati dal Suo sistema sorgente
Attributi di gestione delle Service Request
| Nome | Descrizione | ||
|---|---|---|---|
|
ID Richiesta di Servizio
ServiceRequestID
|
L'identificatore univoco per ogni richiesta di servizio. | ||
|
Descrizione
L'ID della Service Request identifica univocamente ogni richiesta inviata da utenti o sistemi. Funge da filo conduttore che collega tutti gli eventi successivi, dalla registrazione alla chiusura, permettendo un'analisi completa del percorso di ogni richiesta.
Perché è importante
Questo è l'identificatore essenziale del caso che collega tutte le attività correlate in un'unica istanza, permettendo l'analisi del processo end-to-end.
Dove trovare
Questa è la chiave primaria dell'oggetto Service Request, spesso indicata come ServiceReqNumber nella tabella ServiceReq.
Esempi
SR-0012345SR-0012346SR-0012347
|
|||
|
Nome attività
ActivityName
|
Il nome dell'evento o dell'attività verificatisi in un momento specifico del ciclo di vita della richiesta. | ||
|
Descrizione
Questo attributo descrive un passaggio specifico o un cambio di stato, come 'Richiesta inviata per approvazione'. Analizzare la sequenza e la frequenza delle attività è fondamentale per mappare il flusso e identificare deviazioni dallo standard.
Perché è importante
Definisce le fasi nella mappa di processo, consentendo di visualizzare e analizzare il flusso, identificare rilavorazioni, bottleneck e deviazioni.
Dove trovare
In genere deriva da cambi di stato, voci di diario o descrizioni di eventi dell'Audit Log in Ivanti Service Manager.
Esempi
Richiesta di Servizio CreataRichiesta approvataRichiesta di Servizio RisoltaRichiesta di Servizio Chiusa
|
|||
|
Timestamp Evento
EventTime
|
Il timestamp che indica quando una specifica attività o un evento si è verificato. | ||
|
Descrizione
L'Event Time è la data e l'ora esatta in cui un'attività è stata registrata nel sistema. Questo timestamp è fondamentale per sequenziare correttamente gli eventi e costituisce la base per ogni analisi temporale, come il calcolo dei cycle time e dei tempi di attesa.
Perché è importante
Questo timestamp è essenziale per ordinare gli eventi cronologicamente e calcolare tutte le metriche di durata, fondamentali per l'analisi delle performance.
Dove trovare
Presente nei log di audit, nelle voci di giornale (es. Journal.CreatedDateTime) o nei record di cambio stato.
Esempi
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
Sistema di Origine
SourceSystem
|
Il sistema da cui i dati sono stati estratti. | ||
|
Descrizione
Questo attributo identifica l'origine dei dati. In questa vista il valore è costante, indicando che i dati provengono da Ivanti Service Manager. È importante in ambienti multi-sistema per garantire la tracciabilità e il contesto dei dati.
Perché è importante
Fornisce il contesto sulla provenienza dei dati, garantendo che le analisi siano attribuite al sistema sorgente corretto, specie in ambienti multi-sistema.
Dove trovare
Questo è solitamente un valore statico aggiunto durante il processo di estrazione dati per etichettare l'origine del dataset.
Esempi
Ivanti Service Manager
|
|||
|
Ultimo `Data Update`
LastDataUpdate
|
Il timestamp dell'ultimo aggiornamento dei dati dal sistema sorgente. | ||
|
Descrizione
Questo attributo indica quando i dati sono stati estratti l'ultima volta da Ivanti Service Manager, fornendo indicazioni chiare sulla freschezza e sul periodo temporale delle informazioni analizzate.
Perché è importante
Informa l'utente sulla freschezza dei dati, essenziale per prendere decisioni basate sulle performance più recenti.
Dove trovare
Questo valore viene generato e associato al dataset al momento dell'estrazione dei dati.
Esempi
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
|
|||
|
Agente Assegnato
AssignedAgent
|
L'utente o l'agente individuale assegnato alla richiesta di servizio. | ||
|
Descrizione
L'Agente assegnato è la persona specifica responsabile della lavorazione della richiesta. Questo attributo permette analisi a livello individuale, utili per la gestione delle prestazioni, il bilanciamento del carico di lavoro e l'identificazione di opportunità di formazione. Monitorare le riassegnazioni tra agenti è fondamentale per calcolare KPI come le 'Riassegnazioni medie per richiesta' e comprendere le inefficienze del processo.
Perché è importante
Consente di analizzare il carico di lavoro individuale e i pattern di riassegnazione, segnalando possibili necessità di formazione o problemi nel routing iniziale.
Dove trovare
Solitamente si trova in un campo come 'Owner' sull'oggetto Service Request. Può cambiare a ogni riassegnazione e va tracciato nell'Event Log.
Esempi
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
|
|||
|
Ora Fine Evento
EventEndTime
|
Il timestamp che indica quando un'attività è stata completata. | ||
|
Descrizione
L'ora di fine evento segna il completamento di un'attività. La durata tra l'Ora evento (inizio) e l'Ora fine evento rappresenta il tempo di elaborazione dell'attività specifica. Questo è fondamentale per identificare quali passaggi richiedono più tempo, aiutando a individuare inefficienze e aree di miglioramento.
Perché è importante
Permette il calcolo della durata delle singole attività, fondamentale per identificare colli di bottiglia e task troppo lunghi.
Dove trovare
Potrebbe non esistere come campo distinto. Spesso corrisponde all'orario di inizio dell'attività successiva nella sequenza per lo stesso caso.
Esempi
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
|
|||
|
Priorità
Priority
|
Il livello di priorità assegnato alla richiesta di servizio. | ||
|
Descrizione
La priorità indica l'urgenza di una richiesta (es. 'Bassa', 'Media', 'Alta', 'Critica'). Questo attributo è fondamentale per valutare se il processo gestisce correttamente i ticket prioritari. L'analisi confronta cycle time e aderenza agli SLA tra i vari livelli di priorità.
Perché è importante
Fondamentale per valutare l'efficacia della strategia di priorità e garantire che i ticket urgenti siano risolti più velocemente di quelli a bassa priorità.
Dove trovare
Campo standard dell'oggetto Service Request, solitamente denominato 'Priority'.
Esempi
1 - Critico2 - Alto3 - Medio4 - Basso
|
|||
|
Scadenza SLA
SLADeadline
|
Il timestamp entro cui si prevede la risoluzione della richiesta. | ||
|
Descrizione
La Scadenza SLA è la data e l'ora entro cui una richiesta deve essere risolta per rispettare gli accordi. Questo obiettivo dipende da fattori come priorità e tipo di richiesta. Il confronto tra tempo di risoluzione effettivo e scadenza è la base per misurare il rispetto degli SLA.
Perché è importante
È il parametro di riferimento per misurare le prestazioni reali, supportando il calcolo dell'aderenza agli SLA e l'identificazione delle richieste a rischio.
Dove trovare
Spesso è un campo calcolato all'interno di Ivanti, memorizzato in campi relativi allo SLA o all'offerta, come 'ResolutionTargetDateTime'.
Esempi
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
Stato della richiesta di servizio
ServiceRequestStatus
|
Lo stato della richiesta al momento dell'evento. | ||
|
Descrizione
Questo attributo cattura lo stato della richiesta, come 'Registrata', 'In corso', 'In attesa', 'Risolta' o 'Chiusa'. I cambi di stato definiscono spesso le attività nel log del processo. Analizzare il tempo trascorso in ogni stato rivela eventuali colli di bottiglia.
Perché è importante
Offre un'istantanea dello stato della richiesta in ogni momento, essenziale per calcolare il tempo trascorso in ogni fase e identificare gli stalli.
Dove trovare
Campo standard dell'oggetto Service Request, solitamente denominato 'Status'.
Esempi
RegistratoAttivoIn attesa del clienteEvasoChiuso
|
|||
|
Stato SLA
SLAStatus
|
Indica se la richiesta è stata risolta entro la scadenza prevista dallo SLA. | ||
|
Descrizione
Questo è un attributo derivato che contrassegna ogni richiesta come 'Rispettata' o 'Violata' in base al tempo di risoluzione rispetto alla scadenza SLA. È la base del Dashboard sulle prestazioni SLA e confronta il ResolutionDateTime con la SLADeadline.
Perché è importante
Misura direttamente le prestazioni rispetto agli impegni di servizio, essenziale per valutare la qualità e mantenere la fiducia degli utenti.
Dove trovare
Calcolato confrontando 'ResolutionDateTime' con 'SLADeadline'. Se ResolutionDateTime <= SLADeadline, lo stato è 'Met'; altrimenti è 'Breached'.
Esempi
RaggiuntoViolato
|
|||
|
Team assegnato
AssignedTeam
|
Il team o gruppo di supporto attualmente assegnato alla gestione della richiesta. | ||
|
Descrizione
Questo attributo identifica il team responsabile della richiesta in un dato momento. Analizzare i passaggi tra i team e il carico di lavoro di ciascuno è cruciale per individuare i colli di bottiglia e valutare le prestazioni complessive.
Perché è importante
Traccia responsabilità e passaggi di consegne, aiutando ad analizzare i ritardi tra i team, il bilanciamento del carico e i colli di bottiglia del processo.
Dove trovare
Queste informazioni sono solitamente memorizzate in un campo come 'OwnerTeam' sull'oggetto Service Request o nei record di assegnazione correlati.
Esempi
IT Service DeskOperazioni di ReteHR SupportFacility Management
|
|||
|
Tempo di Ciclo
CycleTime
|
Il tempo totale dalla creazione della richiesta alla sua risoluzione finale. | ||
|
Descrizione
Il Cycle Time misura la durata dal primo evento ('Service Request Created') all'evento di risoluzione ('Service Request Resolved'). È uno dei KPI più importanti per l'efficienza del processo ed è ampiamente utilizzato nelle dashboard per monitorare le performance globali e i trend temporali.
Perché è importante
Questo è un KPI primario per misurare l'efficienza del processo end-to-end e riflette direttamente l'esperienza di servizio dal punto di vista dell'utente.
Dove trovare
Calcolato sottraendo il timestamp di creazione da quello di risoluzione per ogni richiesta.
Esempi
25920000060480000086400000
|
|||
|
Timestamp di risoluzione
ResolutionDateTime
|
La data e l'ora in cui la richiesta di servizio è stata ufficialmente risolta. | ||
|
Descrizione
Questo è un attributo a livello di caso che segna il timestamp finale di consegna del servizio, prima della chiusura formale. È il punto finale per calcolare il tempo di ciclo end-to-end ed è critico per misurare l'efficienza e il rispetto degli SLA.
Perché è importante
Definisce il punto finale per il calcolo del cycle time del processo, indicatore chiave dell'efficienza nell'erogazione del servizio.
Dove trovare
Un campo timestamp specifico sull'oggetto Service Request, spesso denominato 'ResolvedDateTime' o simile.
Esempi
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
Tipo di Richiesta di Servizio
ServiceRequestType
|
La classificazione o categoria della richiesta di servizio. | ||
|
Descrizione
Questo attributo categorizza la richiesta, ad esempio 'Hardware Request' o 'Software Installation'. È una dimensione critica per l'analisi, permettendo di confrontare performance e SLA tra diversi tipi di servizio per allocare le risorse più efficacemente.
Perché è importante
Segmentare il processo per tipo di richiesta permette analisi mirate, rivelando se certi tipi di richieste sono più inclini a ritardi, rilavorazioni o violazioni degli SLA.
Dove trovare
Solitamente un campo del business object Service Request (es. 'Service' o 'Category'). Consulti la documentazione Ivanti per i nomi specifici come 'SvcReqTmplLink_Category'.
Esempi
Richiesta nuovo hardwareAccesso softwareModifica accountRichiesta informazioni
|
|||
|
Canale
Channel
|
Il metodo o il canale attraverso cui è stata inviata la richiesta. | ||
|
Descrizione
Il canale indica come è stata creata la richiesta, ad esempio tramite portale Self-Service, e-mail, telefono o automaticamente da un altro sistema. Analizzare volumi e tempi di risoluzione per canale permette di capire quali sono più efficienti e quali richiedono interventi di ottimizzazione o formazione.
Perché è importante
Aiuta a comprendere il comportamento degli utenti e l'efficienza dei canali, orientando la strategia di erogazione e le opportunità di automazione.
Dove trovare
Spesso è memorizzato in un campo di tipo 'Source' o 'CreatedBy' sull'oggetto Service Request.
Esempi
Self ServiceEmailTelefonoInput Diretto
|
|||
|
Categoria di risoluzione
ResolutionCategory
|
Classificazione del tipo di risoluzione fornita per la richiesta. | ||
|
Descrizione
La Categoria di risoluzione offre un modo strutturato per classificare come è stata risolta una richiesta. Spesso è una classificazione gerarchica (es. Categoria, Sottocategoria) utile per l'analisi delle cause radice e dei trend. Ad esempio, può evidenziare problemi ricorrenti o azioni comuni, utili per migliorare i servizi o creare articoli della Knowledge Base.
Perché è importante
Offre insight sulla natura delle risoluzioni, aiutando a identificare problemi ricorrenti, opportunità di miglioramento e candidati all'automazione.
Dove trovare
Spesso memorizzato in campi di categorizzazione compilati alla chiusura, come 'ResolutionCategory' o codici di chiusura personalizzati.
Esempi
Formazione utente necessariaSoftware distribuitoHardware riparatoAccesso concesso
|
|||
|
Conteggio assegnazioni
AssignmentCount
|
Il numero totale di volte in cui una richiesta è stata assegnata o riassegnata. | ||
|
Descrizione
Questa metrica calcola le attività legate all'assegnazione per ogni richiesta. Un numero elevato di riassegnazioni, il cosiddetto 'ping-pong dei ticket', indica inefficienze nell'instradamento o scarsa chiarezza nelle responsabilità dei team.
Perché è importante
Quantifica i passaggi di consegne inefficienti e i problemi di instradamento. Un conteggio elevato indica chiaramente tempi di risoluzione prolungati e la frustrazione degli utenti.
Dove trovare
Calcolato contando le occorrenze delle attività legate alle assegnazioni per ogni ServiceRequestID univoco durante la preparazione dei dati.
Esempi
12345
|
|||
|
Conteggio Riaperture
ReopenCount
|
Il numero di volte in cui una richiesta di servizio già risolta è stata riaperta. | ||
|
Descrizione
Questo attributo è un contatore che aumenta ogni volta che una richiesta torna 'Attiva' da uno stato 'Risolto'. Un numero elevato indica scarsa qualità della risoluzione al primo colpo o problemi ricorrenti, alimentando il KPI di Rilavorazione.
Perché è importante
Misura direttamente le rilavorazioni ed è un indicatore chiave della qualità della risoluzione. Valori alti suggeriscono che la soluzione iniziale non è stata efficace.
Dove trovare
In genere è un campo contatore sull'oggetto Service Request che aumenta tramite una business rule. Potrebbe chiamarsi 'ReopenCounter'.
Esempi
0123
|
|||
|
Dipartimento del richiedente
RequestorDepartment
|
Il dipartimento aziendale dell'utente che ha inviato la richiesta di servizio. | ||
|
Descrizione
Questo attributo identifica il dipartimento dell'utente che ha avviato la richiesta, come 'Sales' o 'Finance'. Permette di analizzare qualità e domanda tra le diverse aree dell'organizzazione per capire chi subisce più ritardi.
Perché è importante
Consente di analizzare il consumo e la qualità del servizio per business unit, aiutando a identificare problemi o tendenze specifici di ogni dipartimento.
Dove trovare
Queste informazioni vengono solitamente recuperate dal profilo utente del richiedente. Il campo potrebbe essere 'Department' nell'oggetto Profile.Employee.
Esempi
FinanzaVenditeMarketingTecnologia dell'Informazione
|
|||
|
È una Rilavorazione
IsRework
|
Flag booleano che indica se la richiesta di servizio ha comportato attività di rilavorazione. | ||
|
Descrizione
Questo flag calcolato è impostato su true se una richiesta mostra segni di rilavorazione, come la riapertura o la ripetizione di attività in loop. Semplifica il calcolo del KPI sul tasso di rilavorazione e facilita il filtraggio dei casi inefficienti.
Perché è importante
Permette di identificare e quantificare facilmente le richieste che richiedono sforzi extra non pianificati, evidenziando problemi di qualità.
Dove trovare
Derivato dai dati. La logica può basarsi sull'attributo 'ReopenCount' maggiore di zero o sul rilevamento di sequenze specifiche, come eventi multipli di assegnazione agente.
Esempi
truefalse
|
|||
|
Nome Fornitore
VendorName
|
Il nome del fornitore esterno coinvolto nella risoluzione della richiesta. | ||
|
Descrizione
Questo attributo identifica il fornitore esterno coinvolto. È essenziale per misurare e confrontare le prestazioni dei fornitori nel dashboard dedicato, aiutando a gestire le relazioni e i ritardi causati da terzi.
Perché è importante
Permette di analizzare le performance dei fornitori esterni e il loro impatto sui tempi complessivi di risoluzione, supportando il vendor management.
Dove trovare
Potrebbe essere un campo su un oggetto attività associato alla richiesta, o un campo specifico sulla richiesta stessa se viene assegnato un fornitore.
Esempi
Dell SupportOracle ConsultingMicrosoft Premiernull
|
|||
Attività di gestione delle Service Request
| Activity | Descrizione | ||
|---|---|---|---|
|
Richiesta assegnata al team
|
La richiesta viene assegnata a un team di supporto specifico. Si rileva osservando il popolamento o la modifica del campo 'OwnerTeam' nel record della richiesta. | ||
|
Perché è importante
Questo evento è cruciale per analizzare le prestazioni a livello di team, la distribuzione del carico e i tempi di passaggio tra i team, individuando i colli di bottiglia.
Dove trovare
Tracciato dalle modifiche nel campo 'OwnerTeam' nella cronologia di audit o nel giornale della richiesta.
Acquisisci
Evento di aggiornamento del campo 'OwnerTeam', solitamente registrato nell'audit trail.
Tipo di evento
explicit
|
|||
|
Richiesta Assegnata all'Agente
|
Un agente specifico prende in carico la richiesta. Questa attività viene solitamente dedotta quando il campo 'Owner' viene popolato o aggiornato per la prima volta. | ||
|
Perché è importante
Questo segna la fine dell'attesa iniziale in coda. Misurare la durata prima di questa attività aiuta a identificare problemi di allocazione delle risorse.
Dove trovare
Dedotto dal popolamento o dalla modifica del campo 'Owner', visibile nella cronologia di audit.
Acquisisci
Il primo timestamp in cui il campo 'Owner' viene popolato con il nome di un agente dopo la creazione o l'assegnazione al team.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Chiusa
|
La richiesta è ufficialmente chiusa e non sono possibili altre azioni. Spesso avviene automaticamente dopo un periodo prefissato nello stato 'Risolto', segnando la fine definitiva del ciclo di vita. | ||
|
Perché è importante
Questa attività segna la fine definitiva del processo. Il tempo tra 'Risolto' e 'Chiuso' può evidenziare ritardi nelle conferme o nei processi automatici del sistema.
Dove trovare
Dedotto dal cambio del campo 'Status' in 'Closed', con il relativo timestamp.
Acquisisci
Rilevamento dell'aggiornamento del campo 'Status' in 'Closed' dalla cronologia di audit.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Creata
|
Questa attività segna l'inizio del ciclo di vita: una nuova richiesta viene inviata e registrata in Ivanti. L'evento avviene alla creazione di un nuovo record nell'oggetto Service Request, generando un ID univoco. | ||
|
Perché è importante
Questo è l'evento di inizio principale del processo. Analizzare il tempo da questo punto alla risoluzione è fondamentale per misurare i tempi di ciclo e l'efficienza.
Dove trovare
Viene acquisito dal timestamp di creazione del record della Service Request (es. campo CreatedDateTime nell'oggetto ServiceReq).
Acquisisci
L'evento di creazione del record nella tabella ServiceReq, identificato dal timestamp di creazione.
Tipo di evento
explicit
|
|||
|
Richiesta di Servizio Risolta
|
La richiesta è considerata risolta e la soluzione è stata consegnata all'utente. È una milestone fondamentale catturata dal cambio di stato in 'Risolto', che solitamente ferma il conteggio dello SLA. | ||
|
Perché è importante
Questo è un endpoint critico per misurare il tempo di risoluzione e il rispetto degli SLA. La durata dalla creazione a questa attività è un KPI fondamentale.
Dove trovare
Dedotto dal cambio del campo 'Status' in 'Resolved', con il relativo timestamp.
Acquisisci
Rilevamento dell'aggiornamento del campo 'Status' in 'Resolved' dalla cronologia di audit.
Tipo di evento
inferred
|
|||
|
Fornitore esterno coinvolto
|
L'evasione della richiesta è stata affidata a un fornitore esterno o a terze parti. In genere è registrata da un cambio di stato in 'In attesa di terze parti' o simile. | ||
|
Perché è importante
Questa attività è essenziale per misurare le prestazioni dei fornitori e il loro impatto sul tempo di ciclo totale, supportando il Dashboard sulla durata delle attività dei fornitori esterni.
Dove trovare
Dedotto dal cambio di stato in 'Waiting for 3rd Party' o 'Pending Vendor'.
Acquisisci
Rilevamento del cambio di stato in una fase designata come 'in attesa del fornitore'.
Tipo di evento
inferred
|
|||
|
Informazioni fornite dall'utente
|
Il richiedente ha fornito le informazioni necessarie, permettendo all'agente di riprendere il lavoro. Questo avviene quando la richiesta esce dallo stato 'In attesa del cliente' per tornare a uno stato attivo. | ||
|
Perché è importante
Questo evento chiude il ciclo delle richieste di informazioni. Il tempo tra la richiesta e la ricezione dei dati è una componente critica dei ritardi e dei loop di rilavorazione.
Dove trovare
Dedotto quando il campo 'Status' passa da 'Waiting for Customer' a uno stato attivo come 'Active' o 'In Progress'.
Acquisisci
Rilevamento di un cambio di stato da 'in attesa dell'utente' a uno stato attivo.
Tipo di evento
inferred
|
|||
|
Informazioni richieste all'utente
|
L'agente assegnato necessita di ulteriori informazioni dal richiedente per procedere. Questo evento viene registrato quando lo stato della richiesta viene aggiornato in 'In attesa del cliente'. | ||
|
Perché è importante
Questa attività evidenzia i ritardi causati da informazioni iniziali incomplete. Monitorarne frequenza e durata è fondamentale per l'analisi dell'impatto delle richieste di informazioni.
Dove trovare
Dedotto dal cambio di stato in 'Waiting for Customer' o 'Pending'.
Acquisisci
Rilevamento del cambio di stato in una fase designata come 'in attesa dell'utente'.
Tipo di evento
inferred
|
|||
|
Priorità Modificata
|
La priorità della richiesta è stata aggiornata dopo la creazione. Questo evento viene acquisito dall'Audit Log o dalla cronologia che traccia le modifiche ai campi. | ||
|
Perché è importante
Tracciare i cambi di priorità è vitale per la panoramica sull'efficacia della prioritizzazione. Aiuta a capire se le escalation sono gestite correttamente e se la priorità iniziale era accurata.
Dove trovare
Questo è un evento esplicito catturato dalla cronologia di audit del record della Service Request, che registra le modifiche al campo 'Priority'.
Acquisisci
Evento di aggiornamento del campo 'Priority' registrato nell'audit trail del sistema.
Tipo di evento
explicit
|
|||
|
Richiesta approvata
|
La richiesta ha ottenuto tutte le approvazioni e può procedere all'evasione. L'evento viene registrato alla conclusione positiva del workflow di approvazione, con conseguente cambio di stato. | ||
|
Perché è importante
Questa attività segna una milestone chiave, indicando la fine della fase di approvazione e l'inizio dell'evasione. Permette di misurare l'efficienza del processo di approvazione stesso.
Dove trovare
Dedotto dal cambio di stato da 'Waiting for Approval' ad 'Approved' o 'Fulfilled'. Può essere anche un evento esplicito nel business object FRS_Approval.
Acquisisci
Variazione del campo 'Status' della richiesta da uno stato di approvazione a uno attivo.
Tipo di evento
inferred
|
|||
|
Richiesta di servizio annullata
|
La richiesta di servizio è stata annullata dall'utente o da un agente prima della risoluzione. È uno stato finale alternativo catturato da un cambio di stato in 'Annullato' o 'Ritirato'. | ||
|
Perché è importante
Rappresenta una terminazione non standard del processo. Analizzare perché le richieste vengono annullate può rivelare problemi nel processo stesso o nuove esigenze utente.
Dove trovare
Dedotto dal cambio del campo 'Status' in 'Cancelled'.
Acquisisci
Rilevamento dell'aggiornamento del campo 'Status' in 'Cancelled' dalla cronologia di audit.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Evasa
|
Tutte le attività necessarie per evadere la richiesta sono state completate dall'agente o dal sistema. Si registra tramite il passaggio allo stato 'Fulfilled', che precede solitamente lo stato finale 'Resolved'. | ||
|
Perché è importante
Questa milestone segna il completamento del lavoro tecnico. È un punto chiave per misurare il tempo di gestione attiva prima della conferma finale.
Dove trovare
Dedotto dal cambio del campo 'Status' in 'Fulfilled'.
Acquisisci
Rilevamento del cambio di stato in 'Fulfilled' (Evasa) dalla cronologia del record.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Riaperta
|
Riattivazione di una richiesta precedentemente risolta perché il problema persiste o la soluzione non era soddisfacente. Si registra quando lo stato passa da 'Resolved' a uno attivo come 'Active' o 'Assigned'. | ||
|
Perché è importante
Questa attività indica direttamente rilavorazioni e bassa qualità della risoluzione al primo tentativo. Analizzare le riaperture aiuta a individuare i punti deboli e migliorare il KPI del tasso di rilavorazione.
Dove trovare
Dedotto dalla cronologia di audit quando il campo 'Status' passa da 'Resolved' o 'Closed' a uno stato attivo.
Acquisisci
Passaggio di stato da terminale ('Resolved', 'Closed') a uno aperto ('Active', 'Assigned').
Tipo di evento
inferred
|
|||
|
Richiesta inviata per approvazione
|
La richiesta è stata inviata per le approvazioni necessarie prima dell'evasione. In genere si desume dal cambio di stato in 'Inviato' o 'In attesa di approvazione', che attiva un workflow. | ||
|
Perché è importante
Tracciare questa attività aiuta a identificare ritardi nella fase di approvazione. Lunghe attese qui rappresentano un collo di bottiglia che impatta sui tempi totali e sulla soddisfazione.
Dove trovare
Dedotto dal cambio di stato in 'Submitted' o 'Waiting for Approval'. Può essere recuperato anche dai business object FRS_Approval o FRS_ApprovalVoteTracking.
Acquisisci
Variazione del campo 'Status' della richiesta a uno stato di approvazione in sospeso.
Tipo di evento
inferred
|
|||