Il Suo data template per la gestione delle richieste di assistenza

Zendesk Support
Il Suo data template per la gestione delle richieste di assistenza

Il Suo data template per la gestione delle richieste di assistenza

Questo template offre una guida completa per estrarre i dati necessari ad analizzare il Suo processo di gestione delle richieste in Zendesk Support. Delinea gli attributi essenziali da raccogliere, le attività chiave da monitorare e consigli pratici su come estrarre queste informazioni direttamente dal Suo sistema. Utilizzi questa risorsa per costruire un event log robusto per le Sue iniziative di Process Mining.
  • Attributi consigliati per un'analisi completa
  • Attività chiave da monitorare per le richieste
  • Guida all'estrazione per i data di Zendesk Support
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi di gestione delle richieste di assistenza

Questi sono i campi dati raccomandati da includere nell'event log per un'analisi completa della gestione delle richieste in Zendesk Support.
5 Obbligatorio 7 Consigliato 10 Facoltativo
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
Obbligatorio Consigliato Facoltativo

Attività di gestione delle richieste di assistenza

Questi sono i passaggi chiave e le milestone del processo da acquisire nell'event log per una scoperta accurata del processo delle Sue richieste di assistenza.
7 Consigliato 6 Facoltativo
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
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i vostri `dati` da Zendesk Support.