Come creare un report sui ticket di supporto: passo dopo passo

Un report sui ticket di supporto è principalmente un problema di definizioni. Ticket creati, ticket risolti, tempo di prima risposta e tempo di risoluzione sembrano tutti concetti autoesplicativi. Ognuno di essi ha invece più di un significato ufficiale all'interno dello stesso help desk.

Definisci chiaramente le regole di conteggio e il report si scriverà da solo. Salta questo passaggio e due persone oneste otterranno lo stesso export ma si troveranno in disaccordo di ore.

Questa guida spiega cosa includere nel report, i quattro punti in cui le definizioni si biforcano e come crearlo a partire dall'export dei ticket.

Cosa includere in un report sui ticket di supporto

Il solo volume non dice quasi nulla. È la disposizione che rende i numeri affidabili da interpretare.

Elemento	Perché è presente
Ticket creati nel periodo	Il lato della domanda
Ticket risolti nel periodo	Il lato dell'offerta, in base a una regola di stato definita
Backlog a fine periodo	Tutto ciò che non è risolto o chiuso
Tempo di prima risposta	In base a un orario definito e a una definizione stabilita
Tempo di risoluzione	Prima o totale, indicata esplicitamente
Ticket riaperti	Il segnale di qualità che gli altri numeri nascondono
Ticket senza risposta	Il punto in cui il processo ha fallito del tutto
Un intervallo di date e un ambito definiti	Quali canali, brand e code sono inclusi

Due righe hanno un peso maggiore di quanto la loro dimensione lasci intendere. I ticket riaperti e quelli senza risposta sono i punti in cui un report smette di essere un semplice tabellone segnapunti e diventa davvero utile.

Zendesk pubblica le formule sottostanti, il che rende le definizioni verificabili anziché una questione di opinioni. La sua guida di riferimento a metriche e attributi descrive ciascuna di esse.

Partiamo dal caso più semplice. I ticket risolti corrispondono al "numero di ticket risolti o chiusi", quindi la metrica copre due stati anziché uno.

Il "tempo di prima risposta" ha due definizioni ufficiali

Questa è la biforcazione che causa più disaccordi, e il fornitore stesso mette in guardia a riguardo.

La documentazione SLA di Zendesk lo dice chiaramente in una riga: "Non confondere il tempo di risposta SLA con la metrica nativa del tempo di risposta di Zendesk".

La metrica nativa è rigorosa su chi risponde. Zendesk dichiara che "il tempo di prima risposta è calcolato esclusivamente in base alle risposte degli agenti". Le azioni automatiche e quelle relative ai bot "non vengono prese in considerazione nel calcolo del tempo di prima risposta".

La metrica SLA, invece, non lo è. In questo caso, il tempo di prima risposta è "il tempo che intercorre tra la creazione del ticket e il primo commento pubblico di un agente (o la risposta automatica)". Zendesk aggiunge che "le metriche sul tempo di risposta vengono soddisfatte se si imposta un trigger per inviare una risposta automatica con un commento pubblico".

Mettendo insieme queste due definizioni, la conseguenza è evidente. Un risponditore automatico può soddisfare il vostro obiettivo SLA mentre il tempo di prima risposta nativo continua a scorrere.

Quindi, un report che mostra il 98% di raggiungimento degli SLA e una mediana del tempo di prima risposta di quattro ore non si sta contraddicendo. Sta riportando due cose diverse, entrambe in modo corretto.

Ci sono due eccezioni minori che vale la pena conoscere. Prendiamo il caso in cui un agente crea il ticket e il primo commento è pubblico. La guida di riferimento alle metriche di durata specifica che il secondo timestamp "si sposta al secondo commento pubblico dell'agente".

Inoltre, i ticket condivisi non vengono conteggiati. Zendesk sottolinea che quando un agente commenta pubblicamente da un altro account utilizzando la condivisione dei ticket, "questo non viene conteggiato ai fini del tempo di prima risposta del tuo account".

Anche il "tempo di risoluzione" ne ha due

La stessa scissione interessa le metriche di risoluzione, e in questo caso entrambe le versioni sono fornite di default.

Il tempo di prima risoluzione è la "durata tra la creazione del ticket e la sua prima risoluzione", che termina "la prima volta che lo stato del ticket viene impostato su risolto".

Il tempo di risoluzione totale è la "durata tra la creazione del ticket e la sua risoluzione più recente". Termina "l'ultima volta che lo stato del ticket è stato impostato su risolto".

Per un ticket risolto una sola volta, i due valori sono identici. Per un ticket risolto, riaperto e risolto di nuovo, divergono in base al tempo richiesto dal secondo ciclo.

Questo è esattamente il motivo per cui i ticket riaperti devono far parte del report. Zendesk li definisce come ticket "riaperti dopo essere stati risolti" e segnala che la metrica "non include i ticket risolti e riaperti durante lo stesso aggiornamento".

C'è un effetto di secondo ordine che spesso sfugge. La media giornaliera dei ticket risolti li conteggia "solo se sono attualmente risolti o chiusi". Di conseguenza, un ticket riaperto oggi esce silenziosamente dal conteggio dei risolti del mese scorso.

Un report generato a giugno, quindi, non corrisponderà a quello generato ad agosto. Non si è rotto nulla; è semplicemente cambiato lo stato sottostante.

Altre due metriche separano il tempo di attesa da quello di lavorazione. Il tempo di attesa del richiedente è il tempo combinato negli stati nuovo, aperto e in attesa, mentre il tempo di attesa dell'agente è il tempo combinato nello stato in sospeso.

Questa coppia di metriche risponde alla domanda a cui una media di risoluzione non può rispondere. I lunghi tempi di risoluzione causati dall'attesa del cliente rappresentano un problema diverso rispetto ai lunghi tempi causati dalla lunghezza della coda.

Ore solari o ore lavorative

Ogni dato relativo a risposte e risoluzioni esiste su due diversi orari, e sceglierne uno non è facoltativo.

Zendesk memorizza entrambi. Dopo la prima risposta pubblica, "il sistema calcola il tempo di prima risposta in ore solari e ore lavorative". Entrambe le metriche "vengono memorizzate con i dati del ticket".

L'impostazione predefinita che visualizzate non è neutrale. Zendesk segnala che i report predefiniti di Explore "mostrano le informazioni nei report predefiniti in ore solari". Le metriche sulle ore lavorative "sono disponibili e possono essere utilizzate nei report personalizzati".

Quindi, un team che lavora dalle nove alle cinque sembrerà lento nel report predefinito. Un ticket che arriva il venerdì alle 18:00 accumula circa 63 ore solari prima del lunedì mattina, ma quasi zero ore lavorative.

I canali di conversazione in tempo reale aggiungono un'ulteriore complicazione. La metrica del tempo di prima risposta (in secondi) per la messaggistica e la chat "ignora le impostazioni delle ore lavorative della messaggistica e delle ore di attività della chat dal vivo".

Inoltre, gli SLA sui tempi di risposta in chat sono facoltativi. Zendesk dichiara che gli SLA sui tempi di risposta per la chat dal vivo "sono disattivati per impostazione predefinita", quindi la loro assenza è uno stato di configurazione piuttosto che una prestazione perfetta.

Come procedere manualmente

Opzione 1: Una scheda per famiglia di metriche

Esporta l'elenco dei ticket con i campi delle metriche, quindi suddividi volume, tempo di risposta e tempo di risoluzione in schede separate prima di riepilogare qualsiasi dato.

Mantieni le colonne delle ore solari e delle ore lavorative affiancate anziché sceglierne una sola al momento dell'esportazione. Ti verrà sicuramente richiesta anche l'altra.

Calcola le mediane anziché le medie per le metriche temporali. Una manciata di ticket lasciati aperti durante un giorno festivo trascinerà la media verso un valore che non rispecchia la realtà di nessun ticket.

Il limite principale è che un foglio di calcolo non può vedere la cronologia degli stati. Ottieni lo stato corrente di ciascun ticket, quindi il comportamento di riapertura deve derivare dal conteggio dei riaperti anziché da una ricostruzione.

Opzione 2: Una scheda delle definizioni, scritta per prima

Registra la definizione del tempo di risposta, l'orario di riferimento, la metrica di risoluzione, la regola di stato per i risolti, i canali inclusi nell'ambito e l'intervallo di date.

Poi registra ciò che il report non dichiara. Mettere per iscritto che il raggiungimento degli SLA e il tempo di prima risposta nativo misurano cose diverse impedisce a un collega ben intenzionato di citarli come se fossero un unico numero.

Il limite è quello solito. Documentare una regola non significa applicarla, e il trimestre successivo qualcuno ricostruirà la tabella pivot a memoria.

Opzione 3: Segmentare prima di calcolare la media

Suddividi per canale prima di calcolare qualsiasi metrica temporale. I ticket via e-mail, chat e telefono hanno dinamiche diverse, e una mediana combinata non descriverebbe accuratamente nessuno di essi.

Quindi escludi o contrassegna i ticket che distorcono i dati. I ticket in attesa di risposta da parte del cliente per settimane devono essere inseriti in una riga a parte, anziché all'interno della media di risoluzione.

Mostra cosa hai escluso e in quale quantità. Un lettore che non vede il filtro presumerà che non ne sia stato applicato alcuno.

Il limite è che la segmentazione moltiplica il lavoro. Tre canali per due orari per due metriche di risoluzione significano dodici numeri da gestire contemporaneamente.

Il limite comune. Tutte e tre le opzioni presuppongono che l'esportazione copra un unico intervallo di date su un'unica base temporale per ogni coda. Intervalli misti tra le schede rappresentano l'errore silenzioso più comune in questo tipo di report.

Dove il processo manuale rallenta

Il primo report sui ticket di supporto richiede un pomeriggio. Il quarto richiede più tempo, perché nel frattempo l'help desk è cambiato.

Viene attivato un nuovo canale, quindi la mediana combinata si sposta per motivi non legati alle prestazioni. Le ore lavorative vengono modificate per una nuova area geografica, e ogni dato storico sulle ore lavorative si sposta di conseguenza.

Poi si presenta l'effetto riapertura. I numeri del trimestre precedente non corrispondono più, e spiegare il perché richiede più tempo che ricostruire il report da zero.

C'è un quarto costo che emerge solo sotto pressione. Qualcuno chiede se il supporto sia diventato più veloce in questo trimestre. Una risposta onesta richiede che vengano prima definiti l'orario, la definizione e il mix di canali.

Per quanto riguarda la soddisfazione dei clienti, consulta la nostra guida su come creare un report NPS. Se il problema è il volume stesso, la nostra guida pratica su come creare un agente IA per il supporto clienti pre-vendita copre l'aspetto della deviazione dei ticket.

Come crearlo con Powerdrill Bloom

Passo 1: Carica l'export dei tuoi ticket

Carica l'export dei ticket, o gli export dei ticket e degli SLA insieme. Powerdrill Bloom analizza le colonne al momento del caricamento, in modo che timestamp vuoti, formati di data misti e ticket senza una prima risposta emergano prima ancora di calcolare qualsiasi mediana.

Passo 2: Descrivi il report in linguaggio naturale

Indica le definizioni anziché ricostruirle. Specifica la definizione del tempo di risposta, l'orario di riferimento, quale metrica di risoluzione desideri, la regola di stato per i risolti e i canali inclusi nell'ambito.

Then ask the questions that catch the errors. Ask how many tickets have no agent reply at all. Ask which tickets were reopened. Ask for medians per channel rather than one blended figure.

Passo 3: Esporta il grafico, il report o la presentazione

Estrai la tabella delle metriche per canale, o un grafico dei ticket creati rispetto a quelli risolti con il backlog sullo sfondo. Le slide che riportano le definizioni accanto ai numeri vengono generate nella stessa sessione.

Errori comuni

Citare il raggiungimento degli SLA come tempo di prima risposta. Uno accetta una risposta automatica, mentre l'altro esclude completamente le azioni automatizzate.

Confrontare le ore solari con le ore lavorative. Il report predefinito fornisce le prime, mentre il vostro obiettivo era probabilmente impostato sulle seconde.

Utilizzare la media per i tempi di risposta e risoluzione. Pochi ticket abbandonati spostano la media verso un valore che nessun ticket reale occupa.

Unire i canali. Le mediane di chat ed e-mail differiscono per natura, e l'unione nasconde entrambe.

Riportare il tempo di risoluzione senza specificare quale. Il tempo di prima risoluzione e quello di risoluzione totale sono metriche memorizzate separatamente, non varianti di arrotondamento.

Considerare definitivo il conteggio dei risolti. I conteggi dei risolti includono solo i ticket attualmente risolti o chiusi, quindi le riaperture modificano il passato.

Escludere i ticket senza risposta. Sono definiti come ticket con meno di una risposta da parte dell'agente, e rappresentano il fallimento più evidente che il report possa evidenziare.

Conclusione

Definisci la risposta, specifica l'orario, scegli la prima risoluzione o quella totale, stabilisci la regola di stato, segmenta per canale e mostra i ticket riaperti e quelli senza risposta. In questo modo otterrai un report sui ticket di supporto su cui è possibile agire concretamente.

Ciò che il report potrebbe non fare è confrontarsi in modo pulito con i numeri di un'altra azienda. Le definizioni sono configurabili, quindi un benchmark letto da qualche parte è stato quasi certamente misurato con regole diverse dalle tue.

Monitoralo invece rispetto alla tua cronologia, in base a un insieme fisso di regole. Questa è la versione che ti dice se qualcosa è effettivamente migliorato.

Se ricostruirlo ogni mese ti porta via un'intera giornata, prova Powerdrill Bloom sul tuo export di ticket. Vedi anche la pagina del generatore di report IA e lo strumento di sintesi della voce del cliente.

Domande frequenti

Perché il raggiungimento dei miei SLA non corrisponde al tempo di prima risposta?

Misurano eventi diversi. Il tempo di prima risposta SLA di Zendesk può essere soddisfatto da una risposta automatica, mentre la metrica nativa del tempo di prima risposta esclude completamente le azioni automatizzate e dei bot.

Dovrei riportare il tempo di prima risoluzione o il tempo di risoluzione totale?

Riporta quello che decidi di indicare. Il tempo di prima risoluzione termina la prima volta che un ticket viene impostato su risolto. Il tempo di risoluzione totale termina l'ultima volta, quindi i ticket riaperti separano i due valori.

Le metriche di supporto sono misurate in ore solari o lavorative?

Vengono memorizzate entrambe. I report predefiniti di Explore di Zendesk mostrano le ore solari, mentre le metriche sulle ore lavorative sono disponibili per i report personalizzati.

Perché il conteggio dei risolti del trimestre scorso è cambiato?

I conteggi dei risolti includono i ticket che sono attualmente risolti o chiusi. Un ticket riaperto dopo la fine del periodo viene escluso dal conteggio di quel periodo.

Posso confrontare il mio tempo di risoluzione con un benchmark di settore?

Solo approssimativamente. Le definizioni, l'orario e il mix di canali sono tutti configurabili, quindi un dato pubblicato è stato probabilmente misurato con regole diverse dalle tue.