Le metriche dell'help desk offrono un modo concreto per comprendere le prestazioni quotidiane del proprio team di assistenza. Si concentrano su elementi misurabili dell'attività di assistenza IT, quali il numero di ticket ricevuti, il tempo necessario per rispondere, il grado di soddisfazione degli utenti dopo un'interazione o il costo di gestione di ciascuna richiesta.
Una buona serie di metriche ti aiuta a monitorare lo stato di salute delle tue operazioni di assistenza senza perderti nei dettagli tecnici. Puoi individuare rapidamente le tendenze nel volume dei ticket, identificare i rallentamenti nei tempi di prima risposta o vedere dove la qualità del servizio subisce un calo.
Di seguito troverai 19 metriche relative all’help desk e al service desk che dovrebbero essere misurate nel 2026, complete di formule, valori di riferimento e una guida per interpretare ciascuna di esse senza trarre conclusioni fuorvianti.
Punti chiave
- Gli indicatori dell’help desk raccolgono dati operativi: volume dei ticket, FRT, TTR. I KPI del service desk collegano tali misurazioni a obiettivi strategici con una soglia definita e un responsabile.
- Non tutte le metriche sono KPI: selezionare 5–7 indicatori allineati agli obiettivi aziendali evita il rumore dei dati senza una direzione precisa.
- Le quattro famiglie di metriche — produttività, qualità, prestazioni e costi — coprono diversi aspetti dell’erogazione del servizio e funzionano al meglio se utilizzate insieme.
- Il ciclo di miglioramento continuo inizia con la definizione di una linea di base, la fissazione degli obiettivi e l’analisi delle tendenze a intervalli regolari.
Cosa sono le metriche dell’help desk?
Le metriche dell’help desk sono indicatori quantificabili che valutano le prestazioni e l’efficacia dei team di assistenza. Raccolgono dati operativi quali il volume dei ticket, il tempo di prima risposta, i punteggi CSAT e il costo per ticket. Queste misurazioni aiutano a comprendere i modelli di carico di lavoro, la qualità del servizio e l’efficienza dei flussi di lavoro dell’assistenza.
Forniscono inoltre una visione oggettiva di come le richieste si muovono attraverso il processo di assistenza. I modelli nella domanda in entrata, i ritardi nella risposta o nella risoluzione e le fluttuazioni nel feedback degli utenti diventano visibili quando le metriche vengono monitorate con costanza.
Metriche dell’help desk e KPI: qual è la differenza?
Sebbene presentino alcune somiglianze, le metriche dell’help desk e gli indicatori chiave di prestazione (KPI) hanno scopi e obiettivi diversi.
-
Una metrica è un singolo dato che riflette ciò che è accaduto nel processo di assistenza. Può trattarsi di una misurazione temporale, di un conteggio o di un punteggio — ad esempio, il tempo di prima risposta (FRT), il volume dei ticket o il tempo di risoluzione (TTR).
-
Un KPI è un indicatore strategico costruito a partire da una o più metriche e collegato a un obiettivo definito. I KPI valutano se le prestazioni soddisfano l’obiettivo previsto. Prendono i dati grezzi e li collegano ai risultati che contano per il service desk e l’organizzazione.
Una metrica riporta i dati; un KPI valuta. Tutti i KPI utilizzano le metriche, ma non tutte le metriche sono KPI.
Ad esempio, FRT e TTR sono metriche operative, ma quando si imposta un obiettivo come “rispondere in media entro 15 minuti” o “risolvere gli incidenti standard entro otto ore”, diventano parte di un KPI che monitora l’efficienza. Le stesse metriche supportano anche un KPI incentrato sulla soddisfazione quando le si collega alle tendenze del CSAT, poiché le risposte o le risoluzioni lente sono spesso correlate a valutazioni più basse da parte degli utenti.
Perché i KPI del service desk sono importanti
Il monitoraggio dei KPI corretti del service desk fornisce ai team IT una base solida per prendere decisioni che altrimenti sarebbero basate solo sull’istinto. Nello specifico, essi supportano:
- Responsabilità: KPIchiari rendono visibili le prestazioni a livello di agenti, team e reparti. Tutti sanno cosa viene misurato e perché.
- Soddisfazione degli utenti: il monitoraggio di metriche come CSAT e FCR collega direttamente le operazioni IT all’esperienza che i dipendenti vivono quando hanno bisogno di assistenza.
- Efficienza operativa: KPI quali l’arretrato dei ticket, l’AHT e l’utilizzo degli agenti rivelano dove il lavoro si sta bloccando, prima che si trasformi in una crisi.
- Allineamento al business: quando i KPI sono allineati agli obiettivi aziendali, l’IT smette di essere un centro di costo e inizia a dimostrare il proprio valore in termini comprensibili alla leadership.
Monitorare le metriche senza collegarle a un obiettivo è utile per la diagnosi, ma poi arriva la fase operativa. “Migliorare la soddisfazione del cliente” come obiettivo non è sufficiente. Ciò che conta è se il CSAT cala costantemente in seguito a un tipo specifico di richiesta, o se la conformità agli SLA sta diminuendo per un determinato reparto — perché questi sono i segnali che portano a una decisione concreta: adeguare gli SLA, rivedere l’organico in quell’area o risolvere un collo di bottiglia nella coda.
L’utilizzo delle metriche dell’help desk per definire e adeguare i KPI è una best practice del service desk; è il modo per promuovere il miglioramento.
19 metriche dell’help desk che il vostro team dovrebbe monitorare (definizioni, formule, esempi)
Per garantire la chiarezza del quadro di riferimento, le metriche riportate in questo articolo sono raggruppate in quattro categorie.
Non è necessario misurare tutto per tenere sotto controllo un’attività di assistenza. L’obiettivo è selezionare le metriche che riflettono il modo di lavorare del vostro team, monitorarle con costanza e adeguare l’insieme man mano che il vostro service desk si evolve.
Questo elenco vi aiuta a confrontare gli indicatori all’interno della stessa categoria — produttività, qualità, prestazioni o impatto finanziario — in modo da poter decidere quali siano in linea con i risultati che desiderate migliorare.
Metriche di produttività
Gli indicatori di produttività misurano il rapporto tra il carico di lavoro e la capacità del team di elaborare i ticket a un ritmo costante. Ti aiutano a valutare la produttività, a identificare i punti di congestione nella coda e a determinare quando sono necessari adeguamenti in termini di organico, pianificazione o flusso di lavoro.
1. Volume dei ticket
Il volume dei ticket è il numero di incidenti o richieste che il supporto IT riceve e gestisce in un determinato periodo. Misura il carico di lavoro e l’efficienza del team di assistenza clienti.
-
Formula: per calcolare il volume dei ticket, è necessario monitorare il numero di ticket ricevuti dal team di assistenza in un determinato periodo.
È inoltre possibile suddividere il volume dei ticket per canale (e-mail, portale, telefono, chat), categoria, priorità, servizio, gruppo di clienti e periodo di tempo (ora/giorno/settimana). In questo modo, è possibile utilizzare questa metrica per correlare i picchi con i rilasci, apportare modifiche alla configurazione, stabilire soglie di allerta per aumenti anomali e altro ancora.
2. Arretrato dei ticket
L’arretrato dei ticket misura il numero totale di ticket che gli agenti non hanno risolto in un determinato periodo. Fornisce informazioni sul carico di lavoro del personale di supporto IT, sull’efficienza del sistema di assistenza e sulla soddisfazione dei clienti. L’analisi delle tendenze, affiancata da un modello di sondaggio sulla soddisfazione dei clienti, aiuta i team a stabilire le priorità dei problemi, ridurre i ritardi, migliorare la qualità delle risoluzioni, allocare le risorse in modo più intelligente e allineare le prestazioni dell’assistenza alle aspettative e ai risultati in continua evoluzione degli utenti.
Un arretrato elevato può indicare che il team di assistenza IT è sovraccarico di lavoro, con conseguenti ritardi nei tempi di risoluzione e scarsa soddisfazione dei clienti.
-
Formula: Backlog = Ticket aperti all’inizio del periodo + Nuovi ticket − Ticket risolti
-
Esempio: partendo da 50 ticket aperti, ricevendone 40 nuovi e risolvendone 60, si ottiene un arretrato di 30.
3. Utilizzo degli agenti
L’utilizzo degli agenti misura il tempo che un agente dell’assistenza IT dedica alle attività relative all’assistenza rispetto al proprio tempo di lavoro totale disponibile.
- Formula: Utilizzo (%) = (tempo dedicato alle attività di assistenza ÷ tempo di lavoro totale disponibile) × 100
Sebbene si tratti per lo più di un semplice rapporto, il dato può essere fuorviante se non si definisce cosa si intende per “tempo dedicato all’assistenza”. Due service desk che utilizzano la stessa formula possono ottenere tassi di utilizzo molto diversi a seconda del modo in cui monitorano il lavoro. Ecco perché questa metrica richiede un contesto più ampio rispetto al semplice calcolo.
Non tutto il lavoro relativo alla gestione degli incidenti risulta come tempo diretto dedicato ai ticket. Indagini, follow-up, discussioni interne, escalation e attività amministrative possono occupare una parte significativa della giornata. Se si tiene traccia solo del tempo registrato direttamente sui ticket, l’utilizzo potrebbe apparire inferiore al carico effettivo. Se invece si includono tutte le attività senza distinzioni, potrebbe risultare artificialmente elevato.
Tra i possibili approcci di misurazione figurano:
-
Tempo registrato dal sistema (tempo registrato in relazione ai ticket): preciso per la gestione dei ticket, ma non tiene conto dei costi generali come il coordinamento o la ricerca.
-
Contabilità del tempo di lavoro (fogli presenze o registri di presenza): offre una visione più ampia della giornata, ma presenta una minore granularità e si basa sull’accuratezza manuale.
Metriche di qualità
Le metriche di qualità valutano i risultati del service desk dal punto di vista dell’utente. Si concentrano sulla coerenza, sull’affidabilità e sul valore percepito dell’esperienza di assistenza. Questi indicatori aiutano a comprendere l’efficacia con cui il team risolve i problemi, se i livelli di servizio soddisfano le aspettative e come gli utenti valutano lo sforzo necessario per ottenere assistenza. Nel loro insieme, offrono una visione concreta della qualità del servizio che va oltre la semplice produttività o velocità.
4. Punteggio di soddisfazione del cliente (CSAT)
Il punteggio di soddisfazione del cliente misura il grado di soddisfazione dei clienti riguardo all’assistenza IT ricevuta. La metrica CSAT viene solitamente misurata chiedendo ai clienti di valutare il proprio livello di soddisfazione rispetto all’assistenza IT ricevuta, di solito su una scala da 1 a 5 o da 1 a 10.
Il CSAT è un indicatore anticipatore della qualità dell’esperienza e aiuta a identificare le aree di miglioramento. È consigliabile monitorare il CSAT regolarmente, idealmente dopo ogni interazione con i clienti.
-
Formula: si calcola dividendo il punteggio totale ricevuto per il numero totale di risposte e moltiplicando il risultato per 100 per ottenere un punteggio percentuale.
-
Esempio: se si ricevono 100 risposte con un punteggio totale di 400 su un massimo di 500, il punteggio CSAT sarà pari all’80% (400/500 x 100).
Il CSAT riflette anche il sentiment relativo all’intera esperienza, non solo alle prestazioni del reparto IT: ritardi causati da team esterni, processi poco chiari o decisioni politiche possono abbassare la valutazione anche quando l’operatore ha agito correttamente.
5. Net Promoter Score (NPS)
Il Net Promoter Score indica la probabilità che i clienti raccomandino un’azienda o i suoi prodotti/servizi ad altri. Si tratta di un indicatore ampiamente utilizzato che aiuta le organizzazioni a comprendere la fedeltà e la soddisfazione dei clienti. Inoltre, le organizzazioni lo utilizzano per confrontare le prestazioni di diversi prodotti o servizi e per valutare l’efficacia delle modifiche apportate alle iniziative relative all’esperienza del cliente.
L’NPS viene solitamente calcolato ponendo ai clienti un’unica domanda: "Su una scala da 0 a 10, quanto è probabile che consigli la nostra azienda/i nostri prodotti/servizi a un amico o a un collega?" In base alla risposta fornita, i clienti vengono poi classificati in tre categorie: Promotori (9-10), Passivi (7-8) e Detrattori (0-6).
-
Formula: sottrarre la percentuale dei Detrattori dalla percentuale dei Promotori. I Passivi non vengono considerati nel calcolo. Il punteggio risultante può variare da -100 a 100.
-
Esempio: se il 60% dei clienti è costituito da Promotori, il 20% da Passivi e il 20% da Detrattori, l’NPS sarebbe pari a 40 (60 - 20).
A differenza del CSAT, l’NPS viene solitamente inviato con minore frequenza e riflette l’esperienza accumulata. Gli utenti interpretano inoltre la domanda in modo diverso a seconda della cultura organizzativa, delle aspettative di servizio o del grado di visibilità dell’IT. Un NPS basso non riflette sempre le prestazioni recenti; potrebbe essere legato a problemi pregressi o a un’insoddisfazione più ampia nei confronti della tecnologia all’interno dell’azienda.
6. Conformità all’accordo sul livello di servizio (SLA)
La conformità all’Accordo sul livello di servizio misura il grado in cui un team di supporto IT soddisfa gli obiettivi e gli standard definiti nel proprio SLA. Uno SLA è un accordo formale tra il team di supporto IT e i propri clienti, che delinea i servizi dell’organizzazione, il livello di supporto previsto e i tempi di risoluzione dei problemi.
- Formula: Conformitàallo SLA (%) = (Numero di ticket conformi allo SLA ÷ Totale dei ticket soggetti allo SLA) × 100
- Esempio: se 950 ticket su 1.000 soddisfano l’obiettivo SLA, la conformità è del 95%.
Non tutti gli SLA riflettono le reali aspettative degli utenti. Obiettivi fissati a un livello troppo basso gonfiano il tasso di conformità, mentre quelli eccessivamente rigidi generano continui mancati raggiungimento che non rispecchiano le prestazioni effettive. Un approccio pratico consiste nell’analizzare le tendenze relative ai tipi di ticket, all’instradamento e alla gestione delle code, per poi adeguare le soglie con piccoli incrementi anziché passare direttamente a nuovi valori. È inoltre utile confrontare gli SLA con gli OLA interni, in modo che i team di assistenza non siano vincolati a promesse che i gruppi a monte non sono in grado di mantenere.
Anche la classificazione necessita di una rapida verifica, poiché categorie incoerenti distorcono i dati relativi alle risposte e alle risoluzioni. Un breve ciclo di calibrazione ogni pochi mesi di solito mantiene gli SLA realistici senza renderli troppo permissivi.
Recommended reading
Read Article
5 Service Level Agreement Metrics to Track Service Fulfillment
7. Customer Effort Score (CES)
Il Customer Effort Score misura la facilità con cui un utente è riuscito a risolvere il proprio problema o a completare una richiesta. Si concentra sulle difficoltà incontrate nel processo piuttosto che sul risultato finale.
Il Customer Effort Score viene solitamente misurato ponendo ai clienti una singola domanda dopo l’interazione con il team di assistenza: «Quanto impegno hai dovuto profondere per gestire la tua richiesta?». Ai clienti viene quindi chiesto di valutare la propria esperienza su una scala che va da «molto facile» a «molto difficile».
- Formula: media di tutte le valutazioni dello sforzo degli utenti (la scala dipende dalla struttura del sondaggio).
- Esempio: se i partecipanti al sondaggio attribuiscono una media di 2,1 su una scala di sforzo da 1 a 5 (1 = molto facile), il CES è pari a 2,1.
Il CES è fortemente influenzato dalla progettazione dei processi. Anche una prestazione eccellente da parte degli agenti non può compensare flussi di lavoro che richiedono approvazioni multiple, ripetizione delle informazioni, moduli lunghi o passaggi di consegne. Ciò rende il CES un indicatore sensibile degli attriti strutturali piuttosto che delle prestazioni individuali.
Metriche di prestazione
Le metriche di prestazione valutano la rapidità e l’efficacia con cui il team di assistenza gestisce il lavoro. Aiutano a comprendere la velocità di risposta, i modelli di risoluzione e l’andamento del carico di lavoro.
8. Tempo di prima risposta (FRT)
Tempo di prima risposta è il tempo impiegato da un team di assistenza IT per rispondere alla richiesta iniziale di assistenza da parte di un cliente. Non tiene conto del tempo necessario per risolvere il problema. Si tratta di un indicatore chiave di prestazione utilizzato per valutare la reattività dei team di assistenza IT.
- Formula: ora della prima risposta dell’agente − ora di creazione del ticket.
- Esempio: un ticket aperto alle 10:00 e a cui è stata data risposta alle 10:25 ha un FRT di 25 minuti.
Gli intervalli di FRT dipendono dal canale (e-mail, chat, portale). È opportuno esaminare i modelli di risposta naturali e adeguare l’obiettivo in modo che rifletta le aspettative reali senza essere gonfiato. Se il team modifica le regole di instradamento o passa a nuovi canali, è necessario rivedere l’obiettivo poiché il valore di riferimento potrebbe cambiare.
9. Risoluzione al primo contatto (FCR)
La risoluzione al primo contatto è la capacità di un team di assistenza IT di risolvere i problemi o le richieste dei clienti durante il primo contatto del cliente con il team di assistenza, senza necessità di ulteriori interventi.
- Formula: ( Ticket risolti in un unico contatto ÷ numero totale di ticket) × 100.
- Esempio: se 70 ticket su 100 vengono risolti al primo contatto, l’FCR è pari al 70%.
Quando si definiscono gli obiettivi di FCR, è opportuno verificare quali categorie possano effettivamente essere risolte al primo contatto e stabilire aspettative specifiche per ciascuna categoria, anziché fissare un unico obiettivo globale. È inoltre utile monitorare se la qualità dell’assistenza diminuisce quando si punta a un FCR più elevato; se le risoluzioni rapide comportano un aumento dei tassi di riapertura, l’obiettivo deve essere adeguato.
10. Tempo di risoluzione (TTR)
Il tempo di risoluzione misura iltempo necessario per risolvere completamente un ticket dal momento in cui viene aperto.
Per calcolare il TTR, sottrai l'ora in cui il cliente ha effettuato la richiesta dall'ora in cui il problema è stato risolto.
- Formula: ora di risoluzione − ora di creazione del ticket.
- Esempio: un ticket creato alle 9:00 e risolto alle 13:30 ha un TTR di 4,5 ore.
Il TTR misura il tempo complessivo necessario per risolvere il problema, compresi eventuali contatti di follow-up o escalation.
Il TTR varia notevolmente a seconda del tipo di incidente, quindi un unico parametro di riferimento spesso non rappresenta correttamente le prestazioni. Fissare un obiettivo globale troppo rigido costringe a costanti eccezioni, mentre uno troppo ampio nasconde i ritardi nelle categorie che contano davvero. L’approccio più affidabile consiste nell’analizzare i tempi di risoluzione storici per categoria o gravità e definire fasce che riflettano la variazione reale.
11. Tempo medio di gestione (AHT)
Il tempo medio di gestione (AHT) misura il tempo medio impiegato da un addetto all’assistenza IT per gestire una richiesta, compreso il tempo dedicato alla conversazione con il cliente e a qualsiasi attività correlata, come la ricerca o la documentazione.
- Formula: Tempo totale di gestione ÷ numero di ticket gestiti.
- Esempio: se un agente impiega 120 minuti per gestire 6 ticket, l’AHT è pari a 20 minuti.
È importante bilanciare l’AHT con altre metriche, in particolare con gli indicatori di qualità dell’assistenza come la soddisfazione del cliente, e utilizzarlo come parametro di tendenza piuttosto che come obiettivo rigido, per evitare di distorcere il comportamento.
Ad esempio, un addetto all’assistenza IT potrebbe essere in grado di gestire rapidamente le richieste; tuttavia, se non fornisce soluzioni efficaci o se i clienti non sono soddisfatti delle interazioni, l’AHT da solo potrebbe non fornire un quadro completo della qualità dei servizi di assistenza IT.
12. Tasso di escalation
Il tasso di escalation è la percentuale di richieste inoltrate a livelli superiori di assistenza o gestione. Misura la frequenza con cui i problemi non possono essere risolti dal team di assistenza iniziale e richiedono un ulteriore intervento.
- Formula: (Numero di ticket inoltrati ÷ numero totale di ticket) × 100.
- Esempio: se 15 ticket su 200 vengono inoltrati, il tasso di inoltro è pari al 7,5%.
Il tasso di escalation fornisce un quadro attendibile solo quando la logica di instradamento è stabile. Qualsiasi modifica alle regole di triage, alla struttura delle code o alle responsabilità dei team può alterare il tasso da un giorno all’altro, facendo apparire la metrica peggiore o migliore senza alcun reale cambiamento nelle prestazioni. Quando si regolano le soglie, verificare se le escalation derivano da carenze di competenze, disallineamenti nelle categorie o limiti di autorizzazione troppo rigidi. Imposta intervalli accettabili per categoria o gravità, anziché applicare un valore unico. Se il tasso scende troppo, verifica che i casi non vengano mantenuti al livello 1 solo per proteggere la metrica.
13. Gravità dell’incidente
La gravità dell’incidente misura l’impatto di un incidente IT sulle operazioni, sui servizi o sui clienti dell’organizzazione. Classifica gli incidenti in base al livello di interruzione o all’impatto che hanno sull’attività aziendale.
- Formula: non esiste una formula unica; la gravità viene assegnata utilizzando criteri predefiniti. Monitorare il numero di ticket che rientrano in ciascun livello di gravità (mensilmente o trimestralmente) consente di individuare tempestivamente eventuali cambiamenti nello stato di salute del sistema o problemi ricorrenti ad alto impatto.
- Esempio: un'interruzione che interessa tutti gli utenti potrebbe avere gravità 1; un bug che interessa un solo utente potrebbe avere gravità 4.
Esistono generalmente quattro livelli di gravità degli incidenti:
- Critico: incidenti che causano un'interruzione significativa o l'interruzione completa di un processo aziendale, sistema o servizio critico e richiedono una risoluzione immediata.
- Alta: incidenti che causano un'interruzione moderata dei processi aziendali o dei servizi e richiedono una risoluzione tempestiva.
- Medio: incidenti che causano un'interruzione minore e richiedono una risoluzione entro un lasso di tempo ragionevole.
- Basso: incidenti che causano interruzioni minime o nulle e possono essere risolti con procedure di routine.
Per assegnare un livello di gravità a un incidente, è necessario basarsi sul suo impatto e sulla sua urgenza. È possibile prendere in considerazione fattori quali il numero di utenti coinvolti, la criticità del sistema o del servizio e il potenziale impatto sui ricavi.
I dati relativi alla gravità sono utili solo se le categorie vengono applicate in modo coerente. Se le soglie sono vaghe, si verifica un’inflazione della gravità o una sottoclassificazione che si diffonde lungo la coda e distorce il TTR, le prestazioni degli SLA e l’allocazione delle risorse. Una revisione periodica degli esempi per ciascuna categoria aiuta a mantenere stabile il modello.
Metriche finanziarie
Le metriche finanziarie mostrano l’impatto economico della gestione del service desk. Aiutano a quantificare il costo della gestione della domanda, a confrontare le prestazioni interne con i benchmark e a supportare le decisioni di bilancio relative al personale, agli strumenti e al miglioramento dei processi.
14. Costo per ticket
Il costo per ticket è il costo medio necessario per risolvere un ticket di assistenza IT. Aiuta le organizzazioni a comprendere l’impatto finanziario dei propri processi di assistenza IT e può orientare le decisioni relative all’allocazione delle risorse e all’efficienza.
- Formula: Costototale dell’assistenza ÷ Numero totale di ticket gestiti
- Esempio: se i costi mensili di assistenza ammontano a 40.000 $ e il team risolve 5.000 ticket, il costo per ticket è pari a 8 $.
I team decidono se includere i costi indiretti (formazione, abbonamenti software, addebiti interni). L’importante è mantenere il modello coerente affinché le tendenze rimangano affidabili.
Se monitorato nel tempo, questo dato può fornire informazioni sull’efficacia delle modifiche ai processi o degli investimenti tecnologici. Ad esempio, se viene implementato un nuovo strumento o processo di help desk e il costo per ticket diminuisce nel tempo, ciò può essere interpretato come un segno che l’investimento ha avuto successo.
15. ROI
ROI è l’acronimo di Return on Investment(ritorno sull’investimento), che misura l’efficienza di un investimento. Le organizzazioni lo utilizzano per valutare i rendimenti finanziari degli investimenti in infrastrutture IT, software o altri progetti legati alla tecnologia.
- Formula: ( Beneficio stimato − Costo dell’investimento) ÷ Costo dell’investimento
- Esempio: se un sistema di automazione dei flussi di lavoro costa 10.000 dollari e riduce il carico di lavoro in misura tale da evitare 25.000 dollari di costi aggiuntivi per il personale, il ROI è pari al 150%.
I benefici possono essere diretti (riduzione delle ore di lavoro) o indiretti (maggiore FCR che riduce i tempi di inattività dell’azienda). L’aspetto fondamentale è definire i benefici in anticipo, in modo che i calcoli del ROI non si basino su ipotesi a posteriori.
Monitorare il ROI nel tempo consente alle aziende di determinare se l’investimento ha avuto successo e se sono giustificati ulteriori investimenti in tecnologie simili.
IA e metriche di deviazione
Le metriche relative all’IA e alla deviazione monitorano la percentuale di richieste di assistenza risolte senza il coinvolgimento degli operatori, tramite self-service, basi di conoscenza e agenti virtuali. Mostrano in quali punti l’automazione assorbe la domanda, con quale efficacia gli utenti risolvono i problemi autonomamente e quali parti della coda non raggiungono mai un operatore umano. Man mano che il self-service e la risoluzione assistita dall’IA assumono una quota sempre maggiore delle attività di assistenza, questi indicatori rivelano se tale cambiamento riduce il carico di lavoro degli agenti o lo sposta a valle.
16. Tasso di deviazione dei ticket
Il tassodi deviazione dei ticket misura la percentuale di potenziali ticket risolti tramite il self-service prima che raggiungano un operatore. Riflette l’efficacia con cui le basi di conoscenza, i portali e gli agenti virtuali assorbono la domanda che altrimenti finirebbe in coda.
-
Formula: Tasso di deviazione (%) = (Interazioni deviate ÷ (Interazioni deviate + Ticket creati)) × 100
-
Esempio: se il self-service risolve 300 problemi e vengono comunque creati 700 ticket, il tasso di deviazione è pari al 30% (300 ÷ 1.000 × 100).
La deviazione ha senso solo quando l’interazione deviata risolve effettivamente il problema dell’utente. La consultazione di una base di conoscenza o una sessione con un chatbot che termina senza una risposta può essere registrata come deviazione, mentre il problema di fondo rimane irrisolto, gonfiando così il tasso. Abbina la deviazione a un segnale di follow-up — un contatto ripetuto entro un breve lasso di tempo, una risposta alla domanda “È stato utile?” o un ticket successivo sullo stesso argomento — per confermare che i ticket evitati riflettano problemi risolti.
17. Tasso di successo del self-service
Il tasso di successo del self-service misura la percentuale di utenti che risolvono il proprio problema tramite i canali di self-service dopo aver iniziato la ricerca da lì. Esso isola l’efficacia della knowledge base e del portale dal traffico complessivo, mostrando se i contenuti che gli utenti trovano risolvono effettivamente la loro richiesta.
-
Formula: Tasso di successo del self-service (%) = (Sessioni di self-service concluse con una risoluzione ÷ Totale sessioni di self-service) × 100
-
Esempio: se 800 delle 2.000 sessioni sul portale si concludono senza un ticket di follow-up o un contatto con un agente, il tasso di successo è del 40%.
L’attribuzione rappresenta la sfida principale. Un utente potrebbe leggere un articolo, uscire dal sito e risolvere il problema altrove, oppure abbandonare la sessione e aprire un ticket ore dopo. Definire una finestra di risoluzione e collegare le sessioni ai contatti successivi garantisce l’affidabilità della metrica. Tassi di successo bassi di solito indicano lacune nei contenuti o problemi di ricerca, quindi segmenta la metrica per argomento per individuare dove la knowledge base è carente e dove nuovi articoli potrebbero risolvere il maggior numero di richieste.
18. Tasso di contenimento degli agenti virtuali
Il tasso di contenimento degli agenti virtuali misura la percentuale di conversazioni che un agente virtuale gestisce dall’inizio alla risoluzione senza passare il testimone a un operatore umano. Mostra quanta domanda conversazionale viene assorbita dall’automazione e dove si concentrano i modelli di escalation.
-
Formula: Tasso di contenimento (%) = (Conversazioni risolte dall’agente virtuale ÷ Totale delle conversazioni dell’agente virtuale) × 100
-
Esempio: se un agente virtuale gestisce 1.200 conversazioni e 480 si concludono senza escalation, il tasso di contenimento è del 40%.
Un tasso di contenimento elevato ha significato solo quando le conversazioni contenute si concludono con un utente soddisfatto. Le sessioni che si bloccano, entrano in loop o vengono abbandonate possono essere conteggiate come contenute pur spingendo gli utenti verso un altro canale, il che nasconde il reale carico di escalation. Monitorate il contenimento insieme alla soddisfazione post-conversazione e ai tassi di contatto ripetuto per confermare che un numero in aumento rifletta un intento risolto.
19. Tasso di risoluzione automatizzata
Il tasso di risoluzione automatizzata misura la percentuale di ticket risolti tramite flussi di lavoro automatizzati senza l’intervento di un operatore una volta che il ticket è stato creato. Esso rileva il valore dell’automazione applicata dopo l’accettazione — instradamento, categorizzazione e chiusura gestiti da regole o dall’intelligenza artificiale — distinguendolo dalla deviazione che avviene prima della creazione del ticket.
-
Formula: Tasso di risoluzione automatizzata (%) = (Ticket risolti tramite automazione ÷ Totale ticket risolti) × 100
-
Esempio: se 150 dei 1.000 ticket risolti vengono chiusi tramite automazione, il tasso di risoluzione automatizzata è pari al 15%.
Il confine tra risoluzione assistita dall’automazione e risoluzione completamente automatizzata determina questo dato. Un ticket che viene instradato e arricchito dall’automazione prima che un operatore lo chiuda è diverso da uno che viene chiuso dall’inizio alla fine senza l’intervento umano. Decidete quali casi considerare automatizzati prima di riportare il tasso e mantenete la definizione costante nel tempo, in modo che le tendenze rimangano comparabili. La segmentazione per tipo di richiesta mostra quali categorie sono ottime candidate all’automazione e quali dipendono ancora dal giudizio umano
Come utilizzare le metriche dell’help desk per migliorare le prestazioni del supporto IT
Un solido modello di misurazione aiuta i team di supporto IT a comprendere la domanda, la qualità del servizio e i costi operativi. Le metriche sulle prestazioni dell’help desk offrono inoltre ai manager un modo chiaro per collegare il lavoro quotidiano agli obiettivi aziendali più ampi. Se monitorate con costanza, guidano gli adeguamenti dei processi, le decisioni relative al personale e i miglioramenti del servizio.
Un approccio strutturato garantisce che le metriche mantengano il loro significato ed evita che i dati diventino solo rumore di fondo. Quattro passaggi pratici possono aiutarti a stabilire un processo solido:
-
Definisci i tuoi KPI ITSM in termini di obiettivi aziendali: stabilisci quale sia il successo. Se la priorità è una migliore esperienza utente, concentrati su CSAT, FCR o sulla distribuzione della gravità degli incidenti. Se l’obiettivo è l’efficienza, dai priorità a metriche come FRT, AHT e andamento del backlog. Stabilire prima di tutto obiettivi chiari previene il sovraccarico di metriche ed evita di inseguire numeri irrilevanti.
-
Implementate metodi di monitoraggio affidabili: utilizzate la vostra piattaforma ITSM per automatizzare la raccolta dei dati invece di affidarvi ai fogli di calcolo. Il monitoraggio automatizzato riduce gli errori, offre timestamp coerenti e supporta l’analisi delle tendenze su periodi più lunghi.
-
Assicuratevi che il team comprenda il significato di ciascuna metrica: gli agenti devono avere chiarezza su come le loro azioni influenzano i KPI. Brevi sessioni di formazione o linee guida interne aiutano a definire le aspettative: cosa si intende per prima risposta, come classificare la gravità o quando devono avvenire gli escalation. La coerenza rafforza l’accuratezza di tutte le metriche.
-
Utilizzate i vostri strumenti di reporting e analisi per esaminare e adeguare le prestazioni: i dashboard e i report programmati vi forniscono la base di riferimento necessaria per il miglioramento continuo. Esaminate le tendenze, individuate gli schemi ricorrenti e adeguate di conseguenza gli SLA, i livelli di personale o i flussi di lavoro.
Come monitorare le metriche dell’help desk con InvGate Service Management
InvGate Service Management semplifica l’automazione del monitoraggio delle metriche ed elimina la necessità di report manuali.
1- Creare dashboard in base al ruolo
I dashboard in InvGate Service Management si configurano tramite comandi "punta e clicca" e "trascina e rilascia".
Poiché InvGate Service Management supporta più help desk e diversi livelli di accesso, lo stesso vale per il livello di analisi, che fornisce strumenti di reportistica per coordinatori e amministratori in ciascuna area di responsabilità. Ciò elimina il problema dei dashboard “universali” che mostrano tutto a tutti e non sono utili a nessuno.
I dashboard possono inoltre essere condivisi con le parti interessate al di fuori del team del service desk, offrendo ai dirigenti aziendali una visibilità in tempo reale sulle prestazioni del servizio senza richiedere l’accesso alla piattaforma completa.
2- Definire gli obiettivi SLA come KPI attivi
È qui che avviene, a livello operativo, la conversione delle metriche in KPI.
In InvGate Service Management, le politiche SLA convertono metriche come FRT e TTR in obiettivi con logica di allerta. È sufficiente configurare la soglia — ad esempio, «Gli incidenti di livello P2 devono essere risolti entro 8 ore» — e il sistema monitora la conformità in tempo reale. Quando un ticket si avvicina al limite SLA, la piattaforma può attivare automaticamente una notifica, riassegnare il ticket, inoltrarlo al livello successivo o modificarne la priorità.
3- Automatizzare i report e i cicli di revisione
I report possono essere configurati per includere gli indicatori specifici che contano per il vostro service desk — come il FRT, la conformità allo SLA o il costo per ticket.
Per crearne uno, apri Report → Richieste → Nuovo report, scegli le metriche, specifica un intervallo di date e applica i filtri necessari. Una volta salvato, puoi pianificarne l’invio automatico utilizzando l’icona dell’orologio e selezionare la frequenza e i destinatari. I report possono essere inviati sia agli utenti con licenza che a quelli senza licenza, il che è utile quando si condividono aggiornamenti con altri team o manager.
I dashboard offrono una visione in tempo reale delle prestazioni. Possono essere personalizzati con widget relativi a backlog, escalation, tempi di risposta o metriche finanziarie per monitorare le operazioni quotidiane. Queste visualizzazioni aiutano a individuare tempestivamente eventuali scostamenti e favoriscono un processo decisionale più rapido.
Vuoi vedere come funziona nella pratica? Richiedi una prova gratuita di 30 giorni ed esplora InvGate Service Management e tutte le sue funzionalità.
KPI del service desk: come trasformare le metriche in obiettivi strategici
Monitorare 15 metriche non significa gestire 15 KPI. La distinzione è importante: le metriche forniscono una copertura diagnostica; i KPI promuovono la responsabilità e il miglioramento.
L’intervallo consigliato per la maggior parte dei team è di 5–7 KPI. Se sono meno di 5, si perde la copertura delle quattro famiglie. Se sono più di 7, diventa difficile identificare quali leve azionare quando le prestazioni calano.
Ecco un modello in tre fasi per convertire le metriche sopra indicate in KPI su cui il vostro team possa agire.
Fase 1: Selezionare metriche allineate a uno specifico obiettivo aziendale
Iniziate dal risultato su cui l’azienda deve incidere nel ciclo attuale, non dalle metriche. Esempi:
- Ridurre lo sforzo dell’utente → CES + FCR + Tasso di riapertura dei ticket.
- Ridurre i costi di assistenza → Costo per ticket + Tasso di risoluzione tramite self-service + Utilizzo degli agenti.
- Migliorare l’affidabilità degli SLA → Tasso di conformità agli SLA + FRT + TTR per priorità.
- Aumentare la soddisfazione degli utenti → CSAT + NPS + FCR.
Ogni obiettivo corrisponde a un insieme di metriche. I KPI sono quelle metriche a cui è associato un obiettivo.
Fase 2: Definire il valore di riferimento e la soglia
Un KPI senza un obiettivo rimane comunque una metrica. Per ciascun indicatore selezionato, stabilire a che livello si trova attualmente la prestazione (la linea di base) e a quale livello deve arrivare entro il ciclo di revisione (l’obiettivo). Il divario tra i due definisce l’obiettivo di miglioramento. Per indicazioni su come impostare obiettivi basati sugli SLA che siano realistici e allineati alle aspettative aziendali, consultare la guida alla creazione di SLA ITSM efficaci.
Fase 3: Assegnare un ciclo di revisione
I diversi KPI seguono ritmi di revisione diversi:
- Settimanali: arretrato dei ticket, FRT, TTR — metriche operative che richiedono un intervento rapido.
- Mensile: CSAT, tasso di conformità SLA, FCR — andamenti relativi a qualità e prestazioni che richiedono tempo per stabilizzarsi.
- Trimestrali: costo per ticket, utilizzo degli agenti, NPS, tasso di risoluzione tramite self-service — indicatori strategici che riflettono i cambiamenti strutturali nell’operatività del servizio.
Questa cadenza evita la trappola comune di esaminare tutto con la stessa frequenza: si rischia infatti di trascurare i segnali in rapida evoluzione (metriche operative) o di reagire in modo eccessivo alle fluttuazioni a breve termine (metriche strategiche).
Domande frequenti
Quali sono le metriche più importanti per l'help desk?
Le metriche più critiche per la maggior parte dei team sono FCR (First Contact Resolution, risoluzione al primo contatto), FRT (First Response Time, tempo di prima risposta), tasso di conformità agli SLA e CSAT. Insieme, questi indicatori coprono la velocità, la qualità della risoluzione, il rispetto degli impegni di servizio e la soddisfazione percepita dagli utenti. La scelta di quali di questi indicatori privilegiare come KPI dipende dall’obiettivo aziendale specifico su cui il team deve incidere nell’attuale ciclo di valutazione: un team che lavora alla riduzione dei costi darà un peso diverso all’utilizzo degli agenti e al costo per ticket rispetto a uno che si concentra sul miglioramento dell’esperienza utente.
Qual è la differenza tra metriche dell’help desk e KPI?
Una metrica è un dato operativo: misura ciò che è avvenuto nel processo di assistenza — ad esempio, il tempo medio di risoluzione. Un KPI è una metrica legata a un obiettivo specifico con un traguardo definito — ad esempio, risolvere il 90% degli incidenti di livello P2 entro 8 ore. Tutti i KPI utilizzano metriche, ma non tutte le metriche sono KPI. La distinzione è importante dal punto di vista operativo: le metriche forniscono una copertura diagnostica in tutto il service desk; i KPI guidano la responsabilità, gli avvisi e i cicli di miglioramento.
Come si misurano le prestazioni dell’help desk?
Combinando le metriche delle quattro famiglie: produttività (volume dei ticket, arretrati, utilizzo degli agenti), qualità (CSAT, NPS, conformità agli SLA, CES), prestazioni (FRT, TTR, FCR, tasso di riapertura dei ticket) e costo (costo per ticket, tasso di risoluzione tramite self-service). Misurare solo una di queste famiglie offre un quadro incompleto: un team con un TTR basso ma un costo per ticket elevato e un CSAT basso non sta ottenendo buoni risultati nel complesso. Le quattro famiglie insieme forniscono l’equilibrio necessario per prendere decisioni operative e strategiche oculate.
Qual è un buon tasso di FCR per un service desk?
Secondo il Service Quality Measurement Group, lo standard di settore per un tasso di FCR soddisfacente è compreso tra il 70% e il 79%. Tassi inferiori al 70% indicano che una percentuale significativa di ticket richiede più interazioni per essere risolta, il che influisce direttamente sul CSAT e fa aumentare il costo per contatto. Tassi superiori al 79% sono raggiungibili, ma dipendono fortemente dalla complessità del mix di richieste e dalla maturità dell’infrastruttura di self-service e della knowledge base.
