Il Suo data template per la gestione delle richieste di assistenza
Il Suo data template per la gestione delle richieste di assistenza
- Attributi consigliati per un'analisi completa
- Attività chiave da monitorare per le richieste
- Guida all'estrazione per i data di Zendesk Support
Attributi di gestione delle richieste di assistenza
| Nome | Descrizione | ||
|---|---|---|---|
|
Activity
ActivityName
|
Il nome dell'attività o dell'evento aziendale verificatosi per una richiesta di assistenza. | ||
|
Descrizione
L'Attività rappresenta un passaggio o un evento distinto nel ciclo di vita della richiesta di assistenza, come 'Richiesta creata', 'Richiesta assegnata all'agente' o 'Richiesta risolta'. Queste attività derivano dalle modifiche registrate nel registro di controllo (audit log) dei ticket di Zendesk, che traccia le variazioni di campi come lo stato, l'assegnatario, la priorità e l'aggiunta di commenti. L'analisi delle attività è il cuore del Process Mining. Consente di visualizzare la mappa del processo, identificare i colli di bottiglia tra le fasi e analizzare i cicli di rework. Comprendendo la sequenza e la frequenza delle attività, le aziende possono individuare inefficienze e opportunità di miglioramento del processo.
Perché è importante
Questo attributo definisce le fasi del processo, consentendo la visualizzazione delle mappe di processo e l'analisi del flusso, delle varianti e della conformità.
Dove trovare
Questo è derivato concettualmente dagli eventi registrati nell'API Zendesk Ticket Audits. Ad esempio, una modifica nel campo 'status' da 'new' a 'open' può essere mappata come un'attività di tipo 'Richiesta esaminata'.
Esempi
Richiesta di Servizio CreataAgente riassegnatoRichiesta di Servizio Risolta
|
|||
|
ID Richiesta di Servizio
ServiceRequestId
|
L'identificativo univoco per ogni ticket di richiesta di assistenza all'interno di Zendesk. | ||
|
Descrizione
L'ID della richiesta di assistenza, spesso chiamato ID Ticket in Zendesk, funge da chiave primaria per ogni caso. Collega tra loro tutte le attività, i commenti e i cambi di stato correlati, dal momento in cui viene creata la richiesta fino alla sua chiusura. Ciò consente una tracciabilità completa, end-to-end, del ciclo di vita di ogni singola richiesta. Nell'analisi di Process Mining, questo attributo è fondamentale. Definisce il "caso", permettendo la ricostruzione dei flussi, l'identificazione delle varianti e il calcolo delle metriche a livello di caso, come il tempo di ciclo. Ogni evento nel dataset deve essere associato a un ID della richiesta per comprenderne il contesto all'interno del processo globale.
Perché è importante
Questo è l'identificativo del caso essenziale che collega tutti gli eventi nel percorso di una richiesta, rendendo possibile l'analisi del processo end-to-end.
Dove trovare
API Zendesk Tickets, campo 'id'.
Esempi
102451024610247
|
|||
|
Ora di Inizio
EventTimestamp
|
La data e l'ora precise in cui si è verificata l'attività. | ||
|
Descrizione
Event Timestamp (o orario di inizio) registra il momento esatto in cui si svolge un'attività, come l'assegnazione di un agente o la risoluzione di un ticket. Questi dati provengono dal log di audit di Zendesk. Questo attributo è vitale per ogni analisi temporale. Serve a ordinare gli eventi, calcolare la durata tra le attività, misurare i tempi di attesa e analizzare il tempo totale di ciclo del caso. È fondamentale per individuare i bottleneck e valutare il rispetto degli obiettivi temporali come gli SLA.
Perché è importante
Questo timestamp ordina gli eventi cronologicamente ed è fondamentale per tutte le analisi di durata, performance e colli di bottiglia.
Dove trovare
API Zendesk Ticket Audits, campo 'created_at' per ogni evento di audit.
Esempi
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
Sistema di Origine
SourceSystem
|
Indica il sistema da cui sono stati estratti i dati. | ||
|
Descrizione
Questo attributo specifica l'origine dei dati delle richieste. Per questa vista di processo, il valore sarà sempre 'Zendesk Support', identificandolo come il sistema di riferimento (system of record) per tutte le attività di gestione del servizio. In ambienti con più sistemi integrati, questo campo è fondamentale per la data lineage e la risoluzione dei problemi. Garantisce che le analisi siano correttamente circoscritte al sistema desiderato e aiuta a differenziare i dati quando vengono uniti da varie fonti.
Perché è importante
Identifica il sistema d'origine dei dati, garantendone la tracciabilità ed evitando confusioni in caso di integrazione di più sistemi.
Dove trovare
Questo è un valore statico ('Zendesk Support') aggiunto durante l'estrazione e la trasformazione dei dati.
Esempi
Zendesk Support
|
|||
|
Ultimo `Data Update`
LastDataUpdate
|
Il timestamp che indica l'ultima volta in cui i dati sono stati aggiornati dal sistema sorgente. | ||
|
Descrizione
Questo attributo registra la data e l'ora dell'estrazione dati più recente da Zendesk Support. Fornisce il contesto sull'aggiornamento dei dati analizzati, assicurando che gli utenti sappiano quanto sia attuale la vista del processo. Per il monitoraggio continuo e la reportistica, questa informazione è vitale. Consente agli analisti e agli utenti aziendali di capire se stanno guardando dati quasi in tempo reale o un'istantanea di un periodo precedente, influenzando la validità delle loro conclusioni.
Perché è importante
Fornisce il contesto fondamentale sulla freschezza dei dati, indicando quanto è aggiornata l'analisi.
Dove trovare
Questo è un campo di metadati generato e apposto sul dataset al momento dell'estrazione dei dati.
Esempi
2023-10-27T08:00:00Z
|
|||
|
Canale della richiesta
RequestChannel
|
Il canale attraverso il quale è stata inviata la richiesta (ad es. Email, Form Web, Telefono). | ||
|
Descrizione
Questo attributo identifica la fonte di invio della richiesta. Zendesk rileva come è stato creato un ticket, se via email, portale web, integrazione API, chat o altri canali. Ciò fornisce il contesto sul metodo di interazione del cliente. Il Canale di richiesta è una dimensione di analisi molto efficace. Supporta la dashboard "Efficienza dei canali di richiesta" consentendo confronti tra tempi di risoluzione, valutazioni di soddisfazione e tassi di rework sui diversi canali. Questo aiuta le aziende a ottimizzare i canali di supporto e a indirizzare gli utenti verso quelli più efficienti.
Perché è importante
Aiuta ad analizzare l'efficienza e i risultati dei vari canali di supporto, permettendo miglioramenti mirati.
Dove trovare
API Zendesk Tickets, oggetto 'via' e la sua proprietà 'channel'.
Esempi
webemailapichat
|
|||
|
Nome Agente
AgentName
|
Il nome dell'agente assegnato alla richiesta al momento dell'evento. | ||
|
Descrizione
Questo attributo identifica l'agente di supporto responsabile della gestione della richiesta. L'agente assegnato può cambiare più volte durante il ciclo di vita del ticket e questo campo registra chi era responsabile in ogni fase. Il Nome Agente è fondamentale per l'analisi delle performance. Consente di filtrare e segmentare i dati per valutare la distribuzione del carico di lavoro, i tempi di risoluzione per agente e la frequenza delle riassegnazioni. Questo aiuta a costruire la dashboard "Performance di Agenti e Team" e a comprendere il contributo individuale all'efficienza complessiva del processo.
Perché è importante
Questo attributo è fondamentale per analizzare le performance degli agenti, la distribuzione del carico di lavoro e l'impatto delle riassegnazioni sui tempi di risoluzione.
Dove trovare
API Zendesk Users, unendo l' 'assignee_id' dalla risposta dell'API Tickets.
Esempi
Jane DoeJohn SmithEmily Jones
|
|||
|
Priorità Richiesta
RequestPriority
|
Il livello di priorità assegnato alla richiesta, ad esempio Bassa, Normale, Alta o Urgente. | ||
|
Descrizione
La priorità della richiesta indica l'urgenza e spesso determina i tempi di risoluzione e le policy SLA applicate. Può essere impostata dal sistema o dall'utente e modificata dall'agente. Questo attributo è cruciale per la segmentazione e l'analisi delle cause profonde. Aiuta a verificare se i casi urgenti siano effettivamente risolti prima di quelli a bassa priorità ed è un fattore chiave nelle dashboard sulle tendenze delle escalation e sull'aderenza agli SLA.
Perché è importante
Consente di segmentare le richieste per urgenza, aspetto fondamentale per analizzare la conformità SLA e assicurare che i problemi critici siano gestiti con priorità.
Dove trovare
API Zendesk Tickets, campo 'priority'.
Esempi
BassoNormaleElevatoUrgente
|
|||
|
Stato Richiesta
RequestStatus
|
Lo stato della richiesta di assistenza al momento dell'evento (ad es. Nuovo, Aperto, In attesa). | ||
|
Descrizione
Lo stato della richiesta rappresenta la fase del ticket in un dato momento (Nuovo, Aperto, In sospeso, In attesa, Risolto, Chiuso). I cambiamenti di stato sono i trigger principali per creare le attività nell'Event Log. L'analisi del tempo trascorso nei vari stati è fondamentale per lo studio dei bottleneck. Permette di capire dove i ticket si bloccano (es. troppo tempo in 'In attesa'). Analizzare le transizioni di stato è inoltre essenziale per scoprire i loop di rilavorazione.
Perché è importante
Il monitoraggio dello stato è fondamentale per comprendere l'avanzamento della richiesta e identificare quanto tempo viene trascorso in stati di attesa o attivi.
Dove trovare
API Zendesk Tickets, campo 'status'.
Esempi
NuovoApertoIn SospesoRisoltoChiuso
|
|||
|
Tag del ticket
TicketTags
|
Un elenco di tag applicati alla richiesta di assistenza per finalità di categorizzazione e routing. | ||
|
Descrizione
I tag sono etichette flessibili che possono essere aggiunte ai ticket manualmente dagli agenti o automaticamente tramite regole aziendali. Servono a fornire un contesto o categorie specifiche a un ticket che potrebbero non essere coperte da campi standard come Tipo o Priorità. I tag sono attributi estremamente versatili per l'analisi di Process Mining. Possono essere utilizzati per filtrare scenari molto specifici, tracciare workflow personalizzati o identificare le cause profonde dei problemi. Ad esempio, un tag 'VIP' potrebbe essere usato per analizzare il processo per i clienti chiave, mentre un tag 'bug_prodotto' potrebbe servire a tracciare il ciclo di vita dei rapporti sui difetti.
Perché è importante
Offre un modo flessibile per sezionare i dati, permettendo analisi approfondite su sotto-processi o attributi specifici dei ticket.
Dove trovare
API Zendesk Tickets, campo 'tags'. Si tratta di un array di stringhe.
Esempi
richiesta_commercialeproblema_fatturazionerichiesta_funzionalitàcliente_vip
|
|||
|
Team assegnato
AssignedTeam
|
Il team o il gruppo di supporto assegnato alla richiesta. | ||
|
Descrizione
Questo attributo indica quale team o gruppo all'interno dell'organizzazione di supporto è responsabile della richiesta. In Zendesk, questi sono definiti 'Gruppi'. I ticket vengono spesso assegnati prima a un gruppo e poi presi in carico da un singolo agente. L'analisi per Team assegnato è essenziale per comprendere le performance e il carico di lavoro a livello di gruppo. Aiuta a capire quali team gestiscono determinati tipi di richieste, i loro tempi medi di risoluzione e i tassi di rispetto degli SLA. È una dimensione primaria per la dashboard "Performance di Agenti e Team".
Perché è importante
Permette di analizzare le performance dei team, il bilanciamento del carico e l'efficienza del routing tra i diversi gruppi di supporto.
Dove trovare
API Zendesk Groups, unendo il 'group_id' dalla risposta dell'API Tickets.
Esempi
Supporto di primo livelloSupporto TecnicoFatturazione
|
|||
|
Tipo di Servizio
ServiceType
|
La categoria o il tipo di richiesta (ad es. Incidente, Domanda, Problema, Task). | ||
|
Descrizione
Il Tipo di Servizio categorizza la natura della richiesta di assistenza. Zendesk utilizza un campo 'tipo' per distinguere tra le diverse interazioni di supporto. Questa classificazione iniziale aiuta a smistare il ticket al team corretto e ad applicare i processi appropriati. Questo attributo è fondamentale per filtrare e confrontare i dati. Consente agli analisti di esaminare i flussi di processo per diverse tipologie di richieste, che spesso presentano percorsi di risoluzione e SLA molto diversi tra loro. Si tratta di una dimensione chiave per la dashboard "Performance di Agenti e Team", utile a individuare quali operatori gestiscono meglio specifiche tipologie di richieste.
Perché è importante
Categorizza le richieste per consentire analisi separate di processi diversi, come incident rispetto a semplici domande, che seguono percorsi differenti.
Dove trovare
API Zendesk Tickets, campo 'type'.
Esempi
questionincidentproblemtask
|
|||
|
Conteggio riassegnazioni agente
AgentReassignmentCount
|
Il numero totale di volte in cui una richiesta è stata riassegnata da un agente a un altro. | ||
|
Descrizione
Questo attributo è un contatore che aumenta ogni volta che il campo 'assignee_id' di un ticket cambia. Un elevato numero di riassegnazioni per un singolo ticket può indicare vari problemi di processo, come un instradamento iniziale errato, mancanza di competenze dell'agente o richieste troppo complesse per essere gestite da un solo operatore. Si tratta di una metrica chiave per misurare l'efficienza del processo e supporta direttamente il KPI "Tasso di riassegnazione degli agenti". Analizzare i casi con conteggi elevati può rivelare opportunità per migliorare le regole di instradamento, la formazione o le risorse della knowledge base, garantendo che i ticket arrivino alla persona giusta più velocemente.
Perché è importante
Aiuta a quantificare i passaggi interni e identifica gli attriti nel processo, poiché tassi elevati di riassegnazione causano spesso ritardi.
Dove trovare
Calcolato contando il numero di modifiche al campo 'assignee_id' per ogni ticket.
Esempi
013
|
|||
|
È Risoluzione al Primo Contatto
IsFirstContactResolution
|
Un indicatore (flag) che segnala se la richiesta è stata risolta dal primo agente assegnato senza riassegnazioni o risposte da parte dell'utente. | ||
|
Descrizione
La First Contact Resolution (FCR) indica che il problema di un cliente è stato risolto in un'unica interazione. Questo attributo è un flag booleano (vero/falso) che risulta positivo se il ticket è stato risolto dal primo agente senza riassegnazioni e con una sola risposta. Questo attributo supporta direttamente il KPI 'Tasso di risoluzione al primo contatto'. Analizzare i casi di successo FCR aiuta a definire standard di eccellenza, mentre analizzare i fallimenti rivela necessità di formazione, miglioramenti nella knowledge base o un triage iniziale più efficace.
Perché è importante
Misura la capacità di risolvere i problemi al primo contatto, fattore determinante per la soddisfazione del cliente e l'efficienza interna.
Dove trovare
Si tratta di un attributo calcolato complesso. Richiede l'analisi dell'event log per verificare le riassegnazioni degli agenti e il numero di risposte pubbliche fornite.
Esempi
truefalse
|
|||
|
È una Rilavorazione
IsRework
|
Un indicatore che risulta vero se la richiesta di assistenza è stata riaperta dopo essere stata risolta. | ||
|
Descrizione
Questo flag booleano identifica i casi che hanno subito rework. Una richiesta di assistenza è solitamente considerata rework se il suo stato passa da 'Risolto' a uno stato aperto, indicando che la risoluzione iniziale non era sufficiente. Questo attributo è essenziale per calcolare il KPI "Tasso di rework delle richieste" e per la dashboard "Analisi delle attività di rework e riapertura". Contrassegnando i casi di rework, gli analisti possono isolare questi flussi inefficienti, scoprire le cause profonde delle riaperture e lavorare per migliorare la risoluzione al primo contatto.
Perché è importante
Identifica i fallimenti del processo in cui la risoluzione non era definitiva, evidenziando problemi di qualità che impattano sulla soddisfazione.
Dove trovare
Calcolato analizzando la sequenza degli stati del ticket. Una transizione da 'risolto' a 'aperto' indica una rilavorazione.
Esempi
truefalse
|
|||
|
Nome dell'utente
RequestorName
|
Il nome dell'utente finale o del cliente che ha inviato la richiesta. | ||
|
Descrizione
Questo attributo identifica la persona che ha avviato la richiesta di assistenza. Collegare la richiesta a un cliente specifico offre una visione del processo di supporto incentrata sull'utente. Nell'analisi dei processi, il richiedente può essere utilizzato per analizzare modelli relativi a specifici clienti o segmenti di clientela. Ad esempio, si potrebbe indagare se determinati clienti riscontrano tempi di risoluzione più lunghi o hanno tassi di rework più elevati, il che potrebbe indicare problemi con un prodotto o servizio che stanno utilizzando.
Perché è importante
Collega il processo al cliente, permettendo di analizzare problemi specifici, richieste ricorrenti e livelli di soddisfazione per singolo utente.
Dove trovare
API Zendesk Users, unendo il 'requester_id' dalla risposta dell'API Tickets.
Esempi
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Nome policy SLA
SlaPolicyName
|
Il nome della policy di Service Level Agreement (SLA) applicata alla richiesta. | ||
|
Descrizione
Questo attributo identifica la specifica policy SLA che regola i tempi target di risposta e risoluzione. Una policy è solitamente determinata da fattori come la priorità, il tipo di richiesta o il livello di abbonamento del cliente. Conoscere la policy SLA applicata è fondamentale per la dashboard "Analisi della conformità e delle violazioni SLA". Fornisce il contesto necessario per valutare le performance, poiché policy diverse hanno target differenti. Ciò consente una valutazione corretta dell'adempimento degli obiettivi di servizio specifici per ogni ticket.
Perché è importante
Fornisce il contesto per l'analisi SLA, identificando quali target sono stati applicati alla richiesta per un reporting di conformità accurato.
Dove trovare
API Zendesk Ticket Metrics. I dati SLA sono spesso associati alle metriche del ticket.
Esempi
Urgente - Risposta in 1 oraStandard - Risoluzione in 24 oreSLA Clienti Premium
|
|||
|
Ora di Fine
EndTime
|
La data e l'ora precise in cui l'attività è stata completata. | ||
|
Descrizione
L'Ora di fine segna il completamento di un'attività. Per molti eventi in Zendesk, la durata è istantanea, quindi l'Ora di fine coincide con l'Ora di inizio. Tuttavia, per attività basate sullo stato come 'Richiesta messa In attesa', l'Ora di fine corrisponde al momento in cui il ticket viene tolto da quello stato. Questo attributo è essenziale per calcolare la durata di attività specifiche, elemento chiave per l'analisi dei colli di bottiglia. Confrontando l'Ora di inizio e l'Ora di fine di un'attività, è possibile misurarne direttamente il tempo di esecuzione, aiutando a individuare quali fasi richiedono più tempo.
Perché è importante
Consente il calcolo della durata delle singole attività, cruciale per identificare i bottleneck e misurare l'efficienza di ogni passaggio.
Dove trovare
Spesso coincide con lo StartTime per gli eventi discreti. Per le durate di stato, è il timestamp dell'evento successivo che modifica lo stato.
Esempi
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
Organizzazione del richiedente
RequestorOrganization
|
L'organizzazione o l'azienda a cui appartiene il richiedente. | ||
|
Descrizione
Questo attributo collega la richiesta a una specifica organizzazione cliente. È particolarmente rilevante negli scenari di supporto B2B, dove gli SLA e i contratti di assistenza sono spesso definiti a livello aziendale. L'analisi dei dati per organizzazione consente una visione delle performance di supporto a livello di impresa. Può aiutare a identificare le organizzazioni che generano un alto volume di ticket, che riscontrano problemi ricorrenti o che hanno bassi punteggi di soddisfazione. È uno strumento prezioso per l'account management e per identificare i trend di salute dei clienti.
Perché è importante
Permette l'analisi dei servizi B2B raggruppando le richieste per azienda, essenziale per gestire le relazioni con i clienti e gli SLA a livello corporate.
Dove trovare
API Zendesk Organizations, unendo l' 'organization_id' dalla risposta dell'API Tickets.
Esempi
Acme CorporationGlobal Tech Inc.Innovare Soluzioni
|
|||
|
SLA Violato
IsSlaBreached
|
Un indicatore che segnala se la richiesta di assistenza ha violato uno degli obiettivi SLA. | ||
|
Descrizione
Questo attributo è un flag booleano o categorico che mostra l'esito dello SLA per un ticket. Può indicare stati come 'Rispettato', 'Violato' o 'Attivo'. Viene determinato confrontando i tempi effettivi di risposta o risoluzione con i target definiti nella policy SLA. È un attributo critico per la dashboard "Analisi della conformità e delle violazioni SLA". Consente di visualizzare facilmente il numero di ticket conformi rispetto a quelli non conformi. Analisi successive possono poi concentrarsi sulle caratteristiche dei ticket violati per identificare le cause profonde, come lunghi tempi di attesa o riassegnazioni eccessive.
Perché è importante
Misura direttamente la performance rispetto agli impegni presi, indicatore chiave della qualità del servizio e della soddisfazione del cliente.
Dove trovare
Derivato dalle API delle metriche dei ticket di Zendesk, che forniscono informazioni sullo stato degli SLA per ogni ticket.
Esempi
RaggiuntoViolatoAttivo
|
|||
|
Tempo di ciclo della richiesta di servizio
ServiceRequestCycleTime
|
La durata totale dalla creazione della richiesta di assistenza fino alla sua risoluzione finale. | ||
|
Descrizione
Questa metrica calcolata misura il tempo di elaborazione end-to-end di una richiesta. Viene calcolata come la differenza temporale tra l'attività 'Richiesta risolta' e 'Richiesta creata'. È uno dei KPI di alto livello più importanti per qualsiasi processo di supporto. Questo attributo supporta direttamente il KPI "Tempo di ciclo medio delle richieste" e la dashboard "Tempo di ciclo End-to-End". L'analisi di questa metrica su diverse dimensioni, come il tipo di richiesta o la priorità, aiuta a identificare quali fattori hanno il maggiore impatto sull'efficienza complessiva.
Perché è importante
Questo è un KPI primario per misurare l'efficienza complessiva del processo e la customer experience, indicando quanto tempo è necessario per fornire una risoluzione.
Dove trovare
Calcolato come la differenza tra il timestamp del primo evento e quello dell'ultimo (risoluzione).
Esempi
259200s (3 giorni)86400s (1 giorno)3600s (1 ora)
|
|||
|
Valutazione di Soddisfazione
SatisfactionRating
|
Il punteggio di soddisfazione fornito dal richiedente dopo la risoluzione del ticket. | ||
|
Descrizione
Questo attributo cattura il feedback del cliente sulla sua esperienza di supporto, solitamente raccolto tramite un sondaggio dopo che un ticket è stato risolto. Le valutazioni comuni sono 'Buono' o 'Cattivo', a volte accompagnate da un commento. La valutazione della soddisfazione è una metrica di risultato fondamentale. Correlare i modelli di processo con i punteggi di soddisfazione può rivelare quali comportamenti del processo portano a clienti soddisfatti o insoddisfatti. Ad esempio, l'analisi potrebbe mostrare che elevati tassi di riassegnazione o lunghi tempi di risoluzione sono fortemente correlati a valutazioni di soddisfazione negative.
Perché è importante
Crea un legame diretto tra l'esecuzione del processo e i risultati per il cliente, aiutando a capire quali comportamenti influenzano la soddisfazione.
Dove trovare
API Zendesk Tickets, campo 'satisfaction_rating.score' o 'satisfaction_rating.reason'.
Esempi
BuonoScarsoOfferto
|
|||
Attività di gestione delle richieste di assistenza
| Activity | Descrizione | ||
|---|---|---|---|
|
Obiettivo SLA violato
|
Questa attività segna il momento in cui una richiesta di assistenza non rispetta un target SLA definito, come il tempo di prima risposta o di risoluzione. Zendesk registra questo come un evento esplicito quando un target viene mancato. | ||
|
Perché è importante
Questo è un evento critico per il monitoraggio della conformità ed è un input chiave per il KPI del tasso di aderenza agli SLA. Identifica i mancati rispetti degli impegni di servizio.
Dove trovare
Rilevato dall'evento 'SLABreach' nei log di Zendesk. L'evento specifica quale metrica SLA è stata violata.
Acquisisci
Identificato tramite l'evento esplicito 'SLABreach' nei dati del ticket.
Tipo di evento
explicit
|
|||
|
Richiesta Assegnata all'Agente
|
Questa attività si verifica quando una richiesta viene assegnata a uno specifico agente per la prima volta. Si desume da un evento di 'Modifica' nell'audit log del ticket in cui il campo 'assignee_id' viene compilato partendo da null o da un ID di gruppo. | ||
|
Perché è importante
Segna l'inizio del lavoro attivo da parte di un agente ed è fondamentale per misurare i tempi di risposta iniziali, il ritardo della prima assegnazione e la distribuzione del carico di lavoro.
Dove trovare
Dedotto dal primo evento 'Change' sul campo 'assignee_id' in cui viene impostato un ID utente specifico.
Acquisisci
Dedotto dal primo evento di modifica che assegna il ticket a un agente.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Chiusa
|
Rappresenta la chiusura definitiva. Un ticket diventa 'chiuso' automaticamente dopo un certo periodo in stato 'risolto' e non può più essere riaperto. | ||
|
Perché è importante
Questa attività segna la fine definitiva del processo di richiesta assistenza. Fornisce l'endpoint finale per il calcolo della durata completa del caso.
Dove trovare
Dedotto da un evento 'Change' sul campo 'status' in cui il nuovo valore è 'closed'.
Acquisisci
Dedotto da un evento 'Change' nel log in cui lo stato diventa 'chiuso'.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Creata
|
Segna l'inizio del ciclo di vita della richiesta quando viene creato un nuovo ticket. Viene rilevato come evento 'Create', fornendo l'orario di inizio certo del processo. | ||
|
Perché è importante
Questa attività funge da evento di inizio principale per ogni richiesta, il che la rende essenziale per calcolare i tempi di ciclo end-to-end e analizzare i volumi di richieste in entrata.
Dove trovare
Questo è registrato come tipo di evento 'Create' nell'audit log di Zendesk. Il timestamp di questo evento è l'ora di creazione del ticket.
Acquisisci
Rilevato direttamente dall'evento 'Create' nel log di audit del ticket.
Tipo di evento
explicit
|
|||
|
Richiesta di Servizio Riaperta
|
Avviene quando un utente risponde a una richiesta già 'risolta', riportandola allo stato 'aperto'. Indica che la soluzione proposta non è stata efficace. | ||
|
Perché è importante
Questa attività è l'indicatore principale del rework. Analizzarne la frequenza aiuta a misurare la qualità della risoluzione e a identificare le cause dell'insoddisfazione dei clienti.
Dove trovare
Dedotto da un evento 'Change' in cui lo stato passa da 'risolto' a 'aperto'.
Acquisisci
Dedotto da un cambio di stato da 'risolto' a 'aperto'.
Tipo di evento
inferred
|
|||
|
Richiesta di Servizio Risolta
|
Questa attività indica che l'agente ha fornito una soluzione e ha cambiato lo stato del ticket in 'risolto'. La richiesta è considerata completata dal punto di vista dell'agente, ma può ancora essere riaperta dal richiedente. | ||
|
Perché è importante
Questa è una milestone fondamentale che segna la fine del lavoro attivo dell'agente. Il tempo impiegato per raggiungere questo stato è una misura primaria dell'efficienza di risoluzione.
Dove trovare
Dedotto da un evento 'Change' sul campo 'status' in cui il nuovo valore è 'solved'.
Acquisisci
Dedotto da un evento 'Change' nel log in cui lo stato diventa 'risolto'.
Tipo di evento
inferred
|
|||
|
Risposta Pubblica Inviata
|
Questa attività segna ogni comunicazione inviata da un agente al richiedente. Viene acquisita come evento esplicito di 'Commento' nei dati dei ticket Zendesk dove l'attributo 'public' è vero. | ||
|
Perché è importante
Questi eventi sono fondamentali per analizzare la frequenza delle comunicazioni, misurare i tempi di risposta degli agenti e identificare il numero di interazioni necessarie per la risoluzione.
Dove trovare
Questo è un evento esplicito di 'Commento' nei dati del ticket. I dettagli includono l'attributo 'public: true', che lo distingue dalle note interne.
Acquisisci
Rilevato dagli eventi 'Comment' del ticket in cui il flag 'public' è vero.
Tipo di evento
explicit
|
|||
|
Agente riassegnato
|
Rappresenta il passaggio di proprietà del ticket da un agente all'altro. Viene dedotto da ogni evento 'Change' sul campo 'assignee_id' successivo al primo. | ||
|
Perché è importante
Tracciare le riassegnazioni è fondamentale per calcolare il KPI del tasso di riassegnazione, utile a identificare inefficienze, routing errati o lacune nelle competenze.
Dove trovare
Dedotto dagli eventi 'Change' sul campo 'assignee_id', escludendo la primissima assegnazione.
Acquisisci
Dedotto dal secondo e dai successivi eventi 'Change' sul campo 'assignee_id'.
Tipo di evento
inferred
|
|||
|
Nota Interna Aggiunta
|
Indica l'aggiunta di una nota interna o un commento visibile solo agli agenti. Viene registrato come evento 'Comment' con attributo 'public' impostato su false. | ||
|
Perché è importante
Il monitoraggio delle note interne offre una panoramica sulla collaborazione tra agenti o team, che può essere fonte di ritardo o la chiave per risolvere i problemi in modo efficiente.
Dove trovare
Questo è un evento esplicito di 'Commento' nei dati del ticket. I dettagli includono l'attributo 'public: false', che indica una nota interna.
Acquisisci
Rilevato dagli eventi 'Comment' del ticket in cui il flag 'public' è falso.
Tipo di evento
explicit
|
|||
|
Priorità Modificata
|
Indica l'aggiornamento del livello di priorità (es. 'Bassa', 'Normale', 'Alta'). Viene registrato come evento 'Change' sul campo 'priority'. | ||
|
Perché è importante
L'analisi dei cambi di priorità aiuta a individuare le richieste la cui urgenza aumenta nel tempo, permettendo di valutare se la prioritizzazione iniziale sia efficace.
Dove trovare
Registrato come evento 'Change' sul campo 'priority' nel log di audit, con indicazione del valore precedente e di quello nuovo.
Acquisisci
Dedotto dagli eventi 'Change' sul campo 'priority' nel log di audit.
Tipo di evento
inferred
|
|||
|
Richiesta messa in attesa
|
Questa attività si verifica quando lo stato della richiesta viene modificato in 'in attesa', indicando solitamente che l'agente attende informazioni dal richiedente o da terze parti. Si desume da un evento di cambio stato. | ||
|
Perché è importante
Questo aiuta a isolare e misurare i tempi di attesa che sono al di fuori del controllo diretto del team di supporto, offrendo una visione più accurata del tempo di gestione dell'agente.
Dove trovare
Dedotto da un evento 'Change' sul campo 'status' in cui il nuovo valore è 'on-hold'.
Acquisisci
Dedotto da un evento 'Change' nel log in cui lo stato diventa 'in attesa'.
Tipo di evento
inferred
|
|||
|
Richiesta Scalata
|
Rappresenta l'escalation formale a un livello superiore o a un altro team. Spesso viene dedotto dal cambio del gruppo assegnato o da un campo personalizzato. | ||
|
Perché è importante
Monitorare le escalation aiuta a identificare richieste complesse, bisogni formativi per gli agenti di primo livello e problemi sistemici.
Dove trovare
Questo non è un evento standard. Deve essere desunto da una modifica nel campo 'group_id' verso un gruppo di escalation o da una variazione in un campo personalizzato del ticket usato per il tracciamento delle escalation.
Acquisisci
Dedotto da un cambio di 'group_id' o di un campo escalation personalizzato.
Tipo di evento
inferred
|
|||
|
Target SLA applicato
|
Indica il momento in cui una policy SLA viene applicata al ticket, ovvero quando le proprietà del ticket corrispondono alle condizioni della policy attiva. | ||
|
Perché è importante
Tracciare quando viene applicato uno SLA è cruciale per monitorare la conformità, analizzare potenziali violazioni e comprendere la timeline di servizio prevista per i diversi tipi di richiesta.
Dove trovare
Rilevato dall'evento 'SLAPolicyApplied' nei log di Zendesk. Specifica quale policy è stata applicata.
Acquisisci
Identificato tramite l'evento esplicito 'SLAPolicyApplied' nei dati del ticket.
Tipo di evento
explicit
|
|||