Gestione escalation customer care: come valutarla

La qualità nella gestione delle escalation del customer care misura quanto bene viene gestita una conversazione dopo che ha lasciato il suo primo responsabile. Va valutata con criteri propri, attribuendo ogni errore al punto in cui è stato generato.

In breve

• Tempo di gestione, aderenza allo script e CSAT grezzo sono tutti fuorvianti su un’escalation.
• Il passaggio di consegne è un evento valutabile, con due responsabili.
• Il vero risparmio nasce dal chiedersi se l’escalation avrebbe dovuto esistere.
• Le escalation sono troppo rare perché un piccolo campione ne mostri l’andamento.

Che cosa conta come escalation, e perché la sua definizione decide i suoi dati

Prima di valutare le escalation bisogna mettersi d’accordo su che cosa sia un’escalation, e la maggior parte dei team di assistenza applica, senza rendersene conto, tre definizioni incompatibili allo stesso tempo. Il cliente chiede di parlare con un responsabile. Un operatore riassegna un ticket a una coda di specialisti. Scatta una regola perché un livello di servizio stava per essere violato. Tutte e tre vengono chiamate escalation, operativamente non hanno nulla in comune, e farne la media produce un numero su cui nessuno può agire.

Scelga una definizione, la metta per iscritto e si assicuri che venga registrata sul ticket, invece di essere ricostruita in seguito da un tag che qualcuno ha aggiunto a memoria. Il criterio utile è la responsabilità: un’escalation è qualsiasi conversazione la cui responsabilità passa ad altri perché chi ne è responsabile non può risolverla con l’autorità, le informazioni o le competenze che ha. Questo esclude una riassegnazione di routine per motivi di capacità e include il caso in cui nessuno ha spostato il ticket, ma un supervisore ha dovuto autorizzare l’esito.

Il tipo conta, perché decide a chi spetta la questione della qualità.

Perché la sua scheda di valutazione abituale sbaglia su un ticket escalato

La maggior parte dei team valuta le escalation con la scheda che ha già, proprio perché è la scheda che ha già. Produce numeri, quindi nessuno si accorge che diversi criteri hanno smesso di misurare qualcosa.

Il problema non è che le escalation siano più difficili. È che i criteri standard sono stati pensati intorno a presupposti che un’escalation fa saltare: che l’operatore incontri il cliente per la prima volta, che il cliente sia neutrale, che la risoluzione più rapida sia la migliore e che una buona risposta esista dentro il copione standard. Su un ticket escalato nessuno di questi presupposti regge. Prima di cambiare qualcosa, conviene avere chiaro che cosa la sua scheda di valutazione QA dichiara davvero di misurare.

Criterio per criterio, ecco che cosa si rompe.

Gestione escalation nel customer care: che cosa valutare invece

Sei criteri portano quasi tutto il segnale su un ticket escalato. Ognuno richiede una prova che un secondo revisore possa indicare nella trascrizione; altrimenti ha scritto aggettivi e non una rubrica di valutazione.

1. Assimilazione del contesto. Chi ha preso in carico ha letto lo storico prima di rispondere? La prova è precisa: ha ripreso qualcosa che il cliente aveva detto prima senza farselo ripetere. La prova del contrario è ancora più facile da trovare, ed è il punto successivo.
2. La domanda ripetuta. Chi ha preso in carico ha chiesto un’informazione che è già nello storico? Numero d’ordine, email dell’account, che cosa è andato storto. È binario, al revisore servono dieci secondi, e gli operatori non lo contestano mai perché la trascrizione chiude la questione.
3. Riconoscimento senza scaricare la colpa. Il cliente ha bisogno che l’errore venga nominato. A far fallire questo criterio non è la mancanza di scuse, è lo scaricabarile: dare la colpa all’operatore precedente, al sistema, alla policy o al cliente. Indicare un collega come causa davanti a un cliente dovrebbe essere un errore bloccante.
4. Affidabilità degli impegni. Chi ha preso in carico ha promesso qualcosa che l’azienda farà davvero, entro una data in cui accadrà davvero? È il criterio che, quando fallisce, genera l’escalation successiva, quindi merita un peso elevato.
5. Uso dell’autorità per cui è stata fatta l’escalation. Un’escalation che si chiude con la stessa risposta, data da qualcuno più senior, è costata due operatori e non ha dato nulla al cliente. O chi ha preso in carico ha usato un margine di discrezionalità che il primo operatore non aveva, o il percorso di escalation è solo una formalità.
6. Chiusura del cerchio. Il cliente è stato informato dell’esito, e l’operatore di origine è stato informato di come si è risolto il caso? La seconda metà viene saltata quasi ovunque, e saltarla garantisce che lo stesso operatore generi la stessa escalation la settimana dopo.

Calibrare prima dell’introduzione

Le escalation sono esattamente le conversazioni su cui i revisori non sono d’accordo, perché sono cariche di emotività e perché la risposta giusta dipende spesso da un contesto che la trascrizione contiene solo a metà. Organizzi una sessione di calibrazione su tre ticket escalati prima che i criteri entrino in uso. Se i suoi revisori non riescono a mettersi d’accordo sul fatto che chi ha preso in carico abbia usato una vera discrezionalità, gli operatori di sicuro non accetteranno il punteggio. Il formato è lo stesso di qualsiasi altra sessione di calibrazione che conduce (in inglese), con le escalation come unico campione.

Valutare il passaggio di consegne, non solo la risoluzione

Chieda a un team di assistenza dove le escalation vanno storte e le descriverà la risoluzione. Legga cento conversazioni escalate e scoprirà che il danno è stato fatto quasi sempre nei novanta secondi del trasferimento. La tesi della Harvard Business Review sul ridurre lo sforzo del cliente invece di cercare di stupirlo vale qui con una forza particolare, perché un’escalation è già un secondo tentativo e un passaggio di consegne fatto male la trasforma in un terzo.

Il passaggio di consegne è un evento valutabile di per sé, e ha due responsabili. Lo valuti come un blocco a parte, attribuendo il lato di chi invia all’operatore di origine e il lato di chi riceve a chi prende in carico. Tenerli separati è il punto essenziale, perché è l’unico modo in cui il punteggio arriva alla persona giusta.

Lato di chi invia

• Il motivo dell’escalation è registrato nel ticket, a parole, e non solo come tag.
• Quanto già tentato è riassunto, così chi riceve non lo ripete.
• Il cliente è stato avvisato che il passaggio stava avvenendo, del perché e, all’incirca, di quando aspettarsi una risposta. Un trasferimento silenzioso è un errore anche se la risoluzione è perfetta.
• Non è stato promesso nulla a nome del team che riceve che quel team non abbia accettato.

Lato di chi riceve

• Lo storico è stato letto prima di inviare la prima risposta. Il test della domanda ripetuta lo stabilisce.
• L’attesa è stata riconosciuta. Il cliente è già rimasto in coda due volte.
• Al cliente non è stato chiesto di rispiegare il problema come modo per aprire la conversazione.
• Se il ticket è stato rimandato indietro o spostato di nuovo, il motivo è stato registrato con la stessa cura del primo passaggio.

Valutando così il passaggio di consegne si ottengono subito due numeri, entrambi più utili del solo tasso di escalation. Il tasso di domande ripetute è la quota di conversazioni escalate in cui chi ha ricevuto ha chiesto un’informazione già presente nello storico. Il tasso di rimbalzo è la quota di escalation rimandate indietro o inoltrate di nuovo prima della risoluzione, che di solito è un difetto di instradamento più che una mancanza individuale. Nessuno dei due richiede un sondaggio, ed entrambi si contano dallo storico delle conversazioni che già possiede. Se sta costruendo un insieme di misure più ampio, questi due affiancano gli altri modi per misurare la qualità delle conversazioni (in inglese).

Il problema dell’attribuzione: chi ha davvero causato questa escalation?

È la questione di equità che decide se riuscirà a gestire un programma QA di cui gli operatori si fidano (in inglese), e quasi nessuna guida sulle escalation la affronta.

La maggior parte delle escalation nasce a monte. Quando una conversazione arriva a uno specialista o a un supervisore, la decisione che l’ha causata è già stata presa: da un primo contatto in cui è sfuggito qualcosa, da una policy a cui nessuno in prima linea può derogare, da un guasto di prodotto o di sistema, o da un’aspettativa creata da qualcun altro. Valutare chi gestisce l’escalation per il fatto stesso che l’escalation esista è l’ingiustizia più comune nel controllo qualità dell’assistenza, e gli operatori la notano subito.

La soluzione è una regola e un’abitudine.

La regola. Chi gestisce l’escalation viene valutato solo sull’escalation. Se l’escalation avrebbe dovuto avvenire è un rilievo separato, attribuito a un responsabile diverso e registrato a parte. Non lasci mai che un solo punteggio porti entrambi i giudizi, perché nel momento in cui succede, chi gestisce il lavoro più difficile ottiene i punteggi peggiori.

L’abitudine. Ogni revisione di un’escalation è in realtà doppia. Apra la conversazione escalata e apra il contatto che l’ha generata. Poi classifichi l’origine in una di quattro categorie:

• Gestione. Il primo operatore aveva le informazioni e l’autorità e non le ha usate. Questa è responsabilità di una persona e si può correggere con il coaching.
• Policy. L’operatore ha fatto esattamente ciò che diceva la policy, e la policy ha prodotto un cliente arrabbiato. Questa spetta a chi è responsabile della policy, e fare coaching all’operatore per questo è peggio che inutile.
• Sistema o prodotto. Qualcosa era guasto, lento o sbagliato. Va nel backlog dello sviluppo o delle operations, non in un colloquio individuale.
• Aspettativa. Una promessa fatta altrove, dal pricing, dal marketing, da un ticket precedente o da un avviso di disservizio, non ha retto all’impatto con la realtà.

Due accorgimenti mantengono onesta la classificazione. L’origine non deve essere indicata da chi gestisce l’escalation, che ha un interesse evidente, e nemmeno dall’operatore di origine. È una decisione del revisore. E quando l’origine è policy, sistema o aspettativa, nessun punteggio individuale cambia, ed è la parte da dire ad alta voce al lancio. Man mano che le classificazioni si accumulano, diventano la base di una vera analisi delle cause radice invece di un’ipotesi mensile.

Questa escalation avrebbe dovuto esserci?

Vale la pena migliorare la qualità della gestione. Ridurre il volume delle escalation vale di più, perché un’escalation evitata non costa nulla da gestire bene, e perché ogni escalation evitabile è una parte di insoddisfazione del cliente che ha prodotto da solo.

Per questo, aggiunga a ogni revisione di escalation un verdetto, separato dal punteggio. Tre opzioni, e la formulazione conta, perché lo scopo è rendere visibile la categoria di mezzo.

• Evitabile. Il primo operatore aveva l’autorità, le informazioni e gli strumenti per risolvere. Nulla di strutturale glielo impediva. È un rilievo di coaching, e in un programma sano dovrebbe essere una piccola parte del totale.
• Strutturale. Nessuno al primo livello avrebbe potuto risolvere, per un’autorizzazione che non ha, un sistema a cui non accede o una policy a cui non può derogare. È la categoria importante. Non è un problema dell’operatore, è un problema di progettazione, e ogni ticket in questa categoria è un candidato per spostare l’autorità un livello più in basso.
• Legittima. L’escalation è il processo che funziona. Serviva davvero una competenza specialistica. Non c’è nulla da correggere, e non va contata come difetto nei numeri di nessuno.

La categoria strutturale è dove stanno i soldi, ed è invisibile a ogni programma di escalation che valuta solo l’escalation in sé. Quando quaranta delle escalation dello scorso trimestre richiedevano tutte la stessa approvazione di rimborso che sta un livello sopra la prima linea, non ha davanti una lacuna di formazione. Ha davanti una soglia di approvazione fissata nel posto sbagliato, e può stimare il valore della correzione contando i ticket.

Una nota sui costi, volutamente senza cifre. È allettante moltiplicare le escalation per un costo medio di gestione e ricavarne un titolo. Non lo faccia, a meno di poter difendere i dati di partenza: un’escalation reale costa almeno il tempo di due persone, di solito l’attenzione di un supervisore, l’attesa vissuta dal cliente e la maggiore probabilità di abbandono che segue un recupero mal riuscito, e nessuno di questi elementi è costante tra un tipo di problema e l’altro. Conti i ticket nella categoria strutturale e descriva la correzione specifica di cui ha bisogno ogni gruppo. Questo argomento regge all’esame. Un costo per escalation inventato no.

Che cosa dicono gli andamenti delle escalation nel complesso

Un’escalation è una conversazione di coaching. Cento escalation, lette insieme, sono una mappa dei punti in cui la progettazione del suo servizio fallisce, e dicono cose che nessuna revisione singola può dire.

Cinque letture da fare ogni mese

• Concentrazione per argomento. Raggruppi le escalation in base a ciò che il cliente voleva, non al tag applicato dall’operatore. Pochi argomenti generano quasi sempre la maggior parte del volume, e di solito sono casi limite delle policy più che problemi complessi.
• Composizione delle origini nel tempo. Segua le quattro categorie di attribuzione come quote. Se la quota di gestione scende mentre quella strutturale resta piatta, il suo coaching funziona e il suo processo no.
• Escalation ripetute. Stesso cliente, stesso problema di fondo, escalato due volte. È il singolo indicatore più forte del fatto che la prima risoluzione era di facciata, e vale la pena rivedere a mano ogni caso.
• Tassi di rimbalzo e di domande ripetute per team ricevente. Mettono in luce i team che ricevono lavoro per cui non sono organizzati, il che è una questione di instradamento più che di qualità.
• Fascia oraria e dimensionamento. Le escalation che si concentrano ai cambi turno o nei buchi di copertura sono un rilievo sui turni, e nessuna quantità di coaching le sposterà.

Il problema del denominatore

Confrontare il tasso di escalation tra operatori è il modo più rapido per perdere la fiducia del team, perché chi lavora sulla coda più difficile fa più escalation. Il tasso di escalation va tenuto insieme agli altri KPI del customer care, ed è confrontabile solo all’interno della stessa coda, dello stesso canale e di un mix di problemi simile, e anche allora appartiene a una conversazione più che a una classifica. Un tasso di escalation alto su un lavoro complesso può essere il comportamento corretto. Uno basso può significare che un operatore si rifiuta di fare escalation quando dovrebbe, che è l’errore più costoso, e si manifesterà invece sotto forma di nuovi contatti.

Perché il campionamento qui fa fatica

Le escalation sono rare per natura, ed è proprio questo che le rende difficili da rivedere bene. Un piccolo campione casuale delle conversazioni del mese, estratto nel modo in cui funziona la maggior parte del campionamento per il controllo qualità, conterrà pochissime escalation, e quelle presenti non saranno rappresentative degli argomenti che le generano. La maggior parte dei team reagisce scegliendo a mano le escalation da rivedere, il che introduce un’altra distorsione: trova quello che è andato a cercare. Rivedere ogni escalation invece di un campione è ciò che trasforma l’aneddoto in un andamento, ed è lo stesso argomento per cui una copertura del 100% rivela tendenze che un campionamento del 3% non potrebbe mai mostrare (in inglese).

È qui che la valutazione automatica dimostra il suo valore, una volta che i criteri descritti sopra esistono e i revisori sono d’accordo su di essi. L’Auto QA di Kaizo applica i suoi criteri di valutazione delle escalation a ogni conversazione escalata, non alle poche che finiscono nel campione, quindi la concentrazione per argomento e la composizione delle origini vengono contate e non stimate. Ancora più della copertura conta il fatto che ogni penalizzazione resta collegata al momento della conversazione che l’ha causata, così quando un operatore contesta un punteggio su un ticket che ha ereditato, il revisore può guardare lo scambio invece di discutere a memoria. Quello che emerge dal quadro complessivo alimenta poi le conversazioni di coaching (in inglese) che vale la pena fare, e manda silenziosamente in pensione quelle che non servono.

Domande frequenti

Che cos’è la gestione delle escalation?

La gestione delle escalation è il lavoro di risolvere una conversazione dopo che la responsabilità è passata da chi l’aveva ricevuta per primo, di solito perché il caso richiedeva più autorità, più competenza specialistica o una decisione che il primo operatore non poteva prendere. Comprende il trasferimento in sé, il recupero di un cliente già frustrato, l’affidabilità degli impegni presi e la chiusura del cerchio sia con il cliente sia con l’operatore di origine. Nel controllo qualità viene trattata come una categoria di lavoro a sé, perché i criteri che valutano un ticket di routine non si applicano in modo pulito a uno ereditato.

Come si gestisce bene un’escalation?

Legga tutto lo storico prima di rispondere, così il cliente non deve mai ripetersi. Dica che cosa è andato storto senza dare la colpa a un collega, a una policy o al cliente. Usi la discrezionalità per cui è stata fatta l’escalation, perché un’escalation che produce la stessa risposta da una persona più senior non ha aiutato nessuno. Si impegni solo su ciò che accadrà davvero, con date reali. Poi chiuda il cerchio due volte: comunichi l’esito al cliente e dica all’operatore che ha fatto l’escalation come si è risolto il caso, così la stessa escalation non si ripete la settimana dopo.

Qual è un esempio di escalation richiesta da un cliente?

Un operatore, seguendo la policy, rifiuta un rimborso; il cliente risponde che è inaccettabile e chiede di parlare con un responsabile. Il ticket passa a un supervisore che ha l’autorità per fare un’eccezione. È un’escalation gerarchica, richiesta dal cliente, ed è la forma più comune. Un altro esempio: una discrepanza di fatturazione che il primo livello non può vedere nei propri strumenti viene inoltrata a uno specialista dell’amministrazione. Questa è funzionale, nessuno ha sbagliato nulla, e non deve pesare sul primo operatore.

I ticket escalati vanno valutati con la stessa scheda di valutazione QA?

No. Almeno quattro criteri standard sono fuorvianti su un’escalation. Il tempo di gestione penalizza il lavoro più lento che l’escalation esiste per consentire, l’aderenza ai modelli premia il riutilizzo della risposta che il cliente ha già rifiutato, i criteri di apertura e saluto ignorano che la storia è già stata raccontata una volta, e i punteggi di soddisfazione valutano in parte il contatto precedente invece di quello attuale. Mantenga la correttezza e il rispetto delle policy, elimini o sostituisca il resto e aggiunga criteri per il passaggio di consegne, l’affidabilità degli impegni e l’uso dell’autorità.

Come si misura la qualità nella gestione delle escalation?

Usi quattro misure insieme, e nessuna da sola. Un punteggio basato sui criteri sulla conversazione escalata, che copra assimilazione del contesto, riconoscimento, affidabilità degli impegni, uso dell’autorità e chiusura del cerchio. Il tasso di domande ripetute, la quota di escalation in cui chi ha ricevuto ha chiesto qualcosa che era già nello storico. Il tasso di rimbalzo, la quota rimandata indietro o inoltrata di nuovo prima della risoluzione. E il tasso di escalation ripetute, la quota in cui lo stesso cliente fa escalation due volte sullo stesso problema, il segnale più chiaro che la prima risoluzione era di facciata.

Qual è un buon tasso di escalation?

Non esiste un benchmark che valga la pena citare, perché il numero dipende interamente da come definisce un’escalation, da qual è il suo prodotto e da quanta autorità è collocata al primo livello. Un team che conta come escalation ogni instradamento verso uno specialista riporterà un tasso diverse volte superiore a quello di un team che conta solo il coinvolgimento di un supervisore. Confronti il suo tasso con il suo stesso andamento e con code comparabili all’interno dell’azienda, e presti più attenzione al mix che al livello. Un tasso stabile con una quota decrescente di escalation evitabili è un programma che funziona.

Chi va valutato quando un ticket viene escalato?

Entrambe le persone, su aspetti diversi. L’operatore di origine viene valutato sul passaggio di consegne che ha inviato e sul fatto che la sua gestione abbia causato o meno l’escalation. Chi riceve viene valutato sull’escalation in sé e mai sul fatto che esista. Se l’escalation avrebbe dovuto avvenire viene registrato come rilievo separato, in una di quattro origini: gestione, policy, sistema o un’aspettativa creata altrove. Quando l’origine è policy, sistema o aspettativa, nessun punteggio individuale dovrebbe cambiare.

Termini correlati

• Che cos’è una rubrica di valutazione QA e come costruirla
• La scheda di valutazione QA: che cosa inserire
• Che cos’è la calibrazione QA e perché conta
• Analisi delle cause radice per i team di assistenza
• Come misurare la qualità delle conversazioni (in inglese)
• Che cosa significa davvero una copertura QA del 100% (in inglese)

Scopra quante delle sue escalation erano evitabili

Porti un mese di ticket escalati e la scheda di valutazione che usa oggi per valutarli. Le mostreremo dove sono nate quelle escalation, quante rientrano nella categoria strutturale che può eliminare riprogettando il processo, e che cosa cambia quando i criteri vengono applicati a tutte, non solo alle poche che finiscono nel campione.

Prenota una demo Scopri Agentic Auto QA