Vai al contenuto

Metriche

QA: operatori penalizzati per ciò che non controllano

Errori di sistema, clienti che riattaccano ed escalation senza risposta non devono costare punti agli operatori. Come trovare questi criteri e correggerli bene.

· 15 min di lettura

Revisionato da Dominik Blattner, fondatore di Kaizo

In questa pagina

Quando un criterio dipende da un sistema che non ha funzionato, da un cliente che se n’è andato o da un team che non ha mai risposto, gli operatori perdono punti che non potevano controllare. Corregga la scheda di valutazione escludendo il criterio, segnandolo come non applicabile o reindirizzando il risultato a chi ne è responsabile.

In breve

  • Gli operatori individuano un criterio su cui non possono influire nel giro di circa un mese.
  • Il “non applicabile” deve esistere su ogni criterio e ridurre il denominatore.
  • Errori concentrati in una coda, in una fascia oraria o dopo un rilascio indicano un problema di sistema.
  • Un processo che non funziona deve far cambiare il processo, non il punteggio dell’operatore.

Perché un solo criterio non controllabile scredita l’intero punteggio

Quando gli operatori dell’assistenza descrivono un punteggio che ritengono ingiusto, tornano sempre le stesse quattro situazioni, e nessuna è davvero una discussione sul giudizio.

  • Un guasto di sistema ha fatto sì che un passaggio completato dall’operatore non venisse mai registrato, quindi il revisore non poteva vederlo e lo ha valutato come mancante.
  • Il cliente si è disconnesso prima della sequenza di chiusura, e ogni criterio di chiusura ha restituito uno zero automatico.
  • Un’escalation è andata a un supervisore che non ha mai risposto, e l’operatore ha perso i punti di risoluzione e di follow-up.
  • La voce di un cliente era difficile da capire, un indirizzo email è tornato con un errore di battitura, e un criterio sull’accuratezza dei dati lo ha registrato come violazione della privacy.

Prenda sul serio l’aritmetica del secondo caso, perché è il più chiaro. Se la sezione di chiusura contiene quattro criteri e una disconnessione ne azzera tre, allora è il comportamento del cliente, non quello dell’operatore, a decidere in quale fascia finisce l’operatore. Gli operatori che gestiscono i clienti più arrabbiati sono quelli a cui riattaccano più spesso, quindi chi fa il lavoro più difficile ottiene i punteggi peggiori.

Ne seguono due conseguenze, in quest’ordine. Primo, il punteggio smette di contenere informazione. Se un revisore non sa dirle se un 72 significa un lavoro scadente o un pomeriggio storto degli strumenti, nessuno a valle può usare quel numero per decidere. Secondo, e più costoso, il punteggio perde autorevolezza presso le persone che dovrebbe aiutare. Quando un operatore crede che il numero sia in parte arbitrario, ogni coaching legato a quel numero arriva già scontato. Non sta facendo coaching, sta negoziando, e ha perso le condizioni per gestire un programma QA di cui gli operatori si fidano (in inglese). Deming ha espresso il principio generale in modo più diretto di qualsiasi guida al QA: un cattivo sistema batterà sempre una brava persona, e misurare la persona con più severità non cambia chi dei due sta perdendo.

Non è un fallimento del team QA. I revisori lavorano dentro lo stesso modulo di tutti gli altri, e la maggior parte dei moduli offre loro due opzioni su un criterio che non poteva in alcun modo essere soddisfatto: bocciarlo, oppure promuoverlo in silenzio sperando che nessuno controlli. Sono entrambe sbagliate, e non esiste una terza scelta. È un problema di progettazione, che si risolve nei criteri di valutazione e non nella discussione sui criteri.

Come trovare i criteri dipendenti dal contesto nella sua scheda di valutazione

Prenda la sua attuale scheda di valutazione QA e la percorra una riga alla volta. Per ogni criterio, si ponga tre domande in quest’ordine.

  1. L’operatore avrebbe potuto superarlo con gli strumenti, i permessi e le informazioni che aveva in quel momento? Non con gli strumenti che avrebbe dovuto avere: con quelli che aveva davvero davanti.
  2. Per superarlo serve che qualcun altro agisca prima? Un altro team, un cliente, un processo batch, un’approvazione.
  3. Un operatore bravo potrebbe superarlo ogni singola volta, solo scegliendo di farlo? Se la risposta onesta è no, il criterio misura le circostanze oltre alla competenza.

Man mano, divida ogni criterio in tre gruppi. Pienamente controllabile, dove dovrebbe trovarsi la maggior parte dei criteri su soft skill e processi. Controllabile a condizione, cioè l’operatore lo controlla solo se vale una precondizione. Non controllabile, cioè il superamento dipende da qualcosa su cui l’operatore non ha alcuna influenza.

Il secondo gruppo è quello in cui c’è il lavoro da fare. Per ogni criterio controllabile a condizione, scriva la precondizione in una frase semplice: il cliente è rimasto in linea, lo strumento dei rimborsi funzionava, il team di secondo livello ha risposto entro il suo livello di servizio, la registrazione ha catturato tutta la chiamata. Queste frasi diventano gli attivatori del “non applicabile” che le serviranno più avanti, e scriverle è ciò che trasforma una vaga sensazione di ingiustizia in una regola che un revisore può applicare allo stesso modo due volte.

Lo faccia con gli operatori presenti

Faccia questo passaggio con due revisori e due operatori senior insieme, non come un esercizio del solo team QA. Gli operatori troveranno i criteri dipendenti dal contesto in una frazione del tempo, perché ci perdono punti da mesi e sanno citare il ticket esatto. Cambia anche il messaggio dell’esercizio: sta chiedendo ai colleghi di aiutarla a correggere il modulo invece di annunciare una correzione. Preveda due ore per una scheda di quindici criteri e si aspetti di trovare da due a cinque righe problematiche.

Le tre categorie di errori non controllabili

Quasi tutto ciò che troverà rientra in una di tre categorie, e la categoria le dice che cosa fare. La distinzione che conta è chi avrebbe potuto prevenire l’errore, perché è anche chi dovrebbe ricevere il risultato.

CategoriaCome si presentaCriteri di solito coinvoltiTrattamento predefinito
Sistemi e strumentiUn’interruzione o uno strumento lento, un passaggio completato mai scritto nel record, una registrazione o una trascrizione che si interrompe, un campo che non si è salvatoRispetto dei processi, documentazione, passaggi di verifica, tempi di attesa e di gestioneNon applicabile per quella conversazione, più un difetto aperto sul sistema
Comportamento del clienteIl cliente si disconnette prima della chiusura, rifiuta la verifica, non resta per il riepilogo, parla sopra l’operatore per tutto il tempo, arriva già furiosoSequenza di chiusura, verifica dell’identità, criteri legati alla soddisfazione, criteri su tono e interruzioniEscludere il criterio, o renderlo condizionato al fatto che il cliente sia rimasto e abbia partecipato
Team a monte e adiacentiUn’escalation senza risposta, un arretrato del secondo livello, una policy che vieta la soluzione di cui il cliente ha bisogno, un articolo della knowledge base sbagliato o mancante, una macro con un testo superatoRisoluzione, risoluzione al primo contatto, accuratezza, follow-up promessoValutare l’operatore solo su ciò che ha fatto con ciò che aveva, e reindirizzare il risultato al team responsabile

Escludere, segnare come non applicabile o reindirizzare

Tre correzioni, e scegliere quella sbagliata è ciò che fa fallire queste correzioni. Il criterio di scelta non è quanto fosse grave l’errore, ma quanto spesso il criterio è impossibile da soddisfare e chi è responsabile della causa.

Escluda il criterio quando non supera il test del controllo nella maggior parte dei casi. Se un criterio dipende da uno strumento inaffidabile, o dal fatto che il cliente si comporti in un certo modo, non è uno standard, è un lancio di moneta con un punteggio attaccato. Una regola pratica utile: se non farebbe mai coaching a qualcuno su quel punto, non lo valuti nemmeno.

Lo segni come non applicabile quando il criterio è normalmente controllabile ma in quella singola conversazione era davvero impossibile. È il caso più comune, e richiede due cose: un attivatore con un nome, preso dalle precondizioni scritte prima, e una prova nel record che l’attivatore si è verificato. Un orario di disconnessione precedente alla sequenza di chiusura è una prova. L’impressione di un revisore no.

Reindirizzi il risultato quando l’errore è reale, conta per il cliente e appartiene a qualcuno. Il cliente non ha ricevuto il rimborso, il che è un vero difetto di qualità che vale la pena conoscere, ma la causa era una policy che l’operatore non può scavalcare. Il risultato esce dal QA come difetto di processo con un responsabile e una data. Il punteggio dell’operatore non cambia.

C’è una quarta opzione a cui i team ricorrono e che dovrebbe rifiutare: bocciare il criterio e aggiungere un commento che dice che non era colpa dell’operatore. Il commento non cambia il numero, ed è il numero ad arrivare alla revisione mensile, alla classifica e al colloquio sulle performance. La comprensione in un campo di testo libero non è un controllo, e lascia all’operatore come unica strada quella di contestare il punteggio (in inglese).

Dia ai revisori l’autorità, poi la verifichi

I revisori devono poter applicare il “non applicabile” senza chiedere il permesso. I team che lo trasformano in un’escalation di fatto eliminano l’opzione, perché un revisore con quaranta revisioni da finire non aprirà un ticket per saltare una riga. Lo controlli invece a valle: riporti l’uso del “non applicabile” per revisore e per criterio, e metta i casi anomali all’ordine del giorno della prossima sessione di calibrazione. È una conversazione molto migliore di quella che ottiene imponendo bocciature false.

Perché il “non applicabile” deve essere un’opzione a pieno titolo su ogni criterio

Il “non applicabile” funziona solo se funziona l’aritmetica. Il punteggio deve essere i punti ottenuti divisi per i punti applicabili, non per l’intero modulo. Se si applicavano undici criteri su quindici e l’operatore ne ha superati otto, il punteggio è otto su undici. Se il modulo lascia tutti e quindici al denominatore, segnare una riga come non applicabile costa esattamente quanto bocciarla, i revisori se ne accorgono in una settimana e l’opzione non viene più usata. Molti team valutano già solo sulle domande applicabili. Altri hanno una casella “non applicabile” che non fa nulla, il che è peggio che non averla, perché sembra una soluzione.

Pensi a che cosa succede su un modulo senza un’opzione “non applicabile” funzionante. I revisori severi bocciano il criterio impossibile, quelli generosi lo promuovono, ed entrambi stanno indovinando una regola che non è mai stata scritta. Ha creato un disaccordo tra revisori che nessuna calibrazione (in inglese) risolverà, perché è strutturale e non percettivo: due revisori possono essere del tutto d’accordo su che cosa è successo e produrre comunque punteggi diversi. Gli operatori vivono allora il punteggio come una funzione di chi li ha valutati, che è il modo più rapido per far perdere credibilità a un programma QA.

Il danno ai dati dura di più. Un criterio promosso quando non è mai stato messo alla prova gonfia il tasso di superamento. Un criterio bocciato quando era impossibile crea un difetto che non è mai avvenuto. In entrambi i casi le statistiche di quel criterio diventano inutilizzabili, e sono proprio le statistiche che le servono per pesare la scheda di valutazione in modo sensato e individuare i problemi di sistema della prossima sezione.

Quattro requisiti, tutti economici:

  • Disponibile su ogni criterio, non su alcuni scelti. Quello che non ha attivato è quello che si romperà.
  • Un codice motivo da un elenco breve, cinque o sei opzioni, così l’uso si può contare. Il testo libero non si può contare.
  • Visibile all’operatore nella revisione, così vede che il revisore se n’è accorto. Metà del risentimento in tutta questa materia nasce dagli operatori convinti che nessuno se ne sia accorto.
  • Riportato ogni mese per criterio e per motivo.

Una soglia da adottare. Se un criterio risulta non applicabile in più di circa un terzo delle conversazioni, non appartiene a quella scheda di valutazione. Appartiene a una scheda specifica per canale o per coda, perché sta chiedendo a un unico modulo di valutare due tipi di lavoro diversi.

Come individuare il problema nei dati prima che glielo dica un operatore

I reclami sono un indicatore ritardato, e arrivano dagli operatori più sicuri di sé, non da quelli più colpiti. I dati arrivano prima, e il metodo funziona in un foglio di calcolo.

Per ogni criterio, prenda il tasso di bocciatura dell’ultimo trimestre, poi lo scomponga per fascia oraria, coda o competenza, canale, fascia di anzianità dell’operatore, e lo confronti con le date dei rilasci e dei cambi di policy. La competenza degli operatori è distribuita in modo abbastanza uniforme tra questi gruppi. I problemi di sistema no, e questa asimmetria è tutta la diagnosi. Un criterio bocciato nel 6% dei casi in generale, ma nel 35% in una coda tra le due e le cinque del pomeriggio, non le sta parlando di coaching.

Quattro schemi e che cosa significa di solito ciascuno:

  • Concentrato in una fascia oraria. Carenza di personale (in inglese), pressione sulla coda o un processo batch che blocca un sistema ogni pomeriggio. Verifichi che cos’altro succede a quell’ora prima di scrivere una nota di coaching.
  • Concentrato in una coda, competenza o canale. Uno strumento usato solo da quel gruppo, una regola di instradamento o una scheda di valutazione che non si adatta al lavoro di quel gruppo.
  • Un salto a partire da una data. Un rilascio, un cambio di policy o una modifica alla scheda di valutazione stessa. Un criterio che andava bene a marzo e viene bocciato di continuo da aprile non è diventato più difficile perché i suoi operatori sono peggiorati.
  • Distribuito in modo uniforme su tutti, compresi gli operatori migliori. Il criterio è ambiguo o impossibile. Se il suo decile migliore lo boccia più o meno quanto il decile peggiore, non sta misurando la competenza.

In questo metodo si nasconde un problema di campionamento, e vale la pena dirlo. Con il campione del 3% che usa la maggior parte dei programmi, non si può proprio fare. Scomponga un criterio per coda e per fascia oraria e la maggior parte delle celle è vuota, quindi lo schema che avrebbe scagionato l’operatore resta invisibile e a vincere la discussione è l’aneddoto. Questa è la ragione pratica per valutare tutto: una copertura del 100% rivela tendenze che un campionamento del 3% non potrebbe mai mostrare. Il punto non è vedere di più, è che il bias di selezione scompare, così un errore concentrato può essere riconosciuto come tale.

L’Auto QA di Kaizo valuta ogni conversazione con la sua scheda di valutazione e mantiene le prove collegate criterio per criterio, così può filtrare le bocciature di un criterio per coda e per fascia oraria e vedere se si concentrano prima che qualcuno riceva coaching su quel punto. Questa tracciabilità conta più della copertura: la domanda utile non è quante conversazioni sono state valutate, ma se può mostrare perché un criterio specifico è stato bocciato su una conversazione specifica. Sul lato della copertura, approfondisca in che cosa significa davvero la copertura QA al 100%.

Mandi il risultato al responsabile, non al punteggio dell’operatore

Tutto ciò che precede porta a un principio. Un risultato che risale a un processo che non funziona deve aggiornare il processo, non il punteggio della persona. Il QA legge più di qualsiasi altra funzione ciò che succede davvero ai clienti, e questo lo rende il miglior sistema di rilevamento dei difetti che la maggior parte delle organizzazioni di assistenza possiede. Spendere questo segnale in detrazioni di punti individuali significa sprecarlo.

I meccanismi sono ordinari, ed è proprio questo il punto:

  • Indichi il responsabile al momento della revisione. Prodotto, workforce management, secondo livello, knowledge base, policy. Farlo durante la revisione richiede pochi secondi. Ricostruirlo in una retrospettiva mensile richiede un pomeriggio e viene saltato.
  • Dia al risultato i campi di un difetto. Che cosa non ha funzionato, quanto spesso, in quali code, quanto costa in riaperture o tempi di gestione. Un risultato di processo con un numero attaccato viene corretto. Un reclamo no. È la normale root cause analysis, applicata alla scheda di valutazione invece che al ticket.
  • Sospenda il criterio finché il difetto è aperto, e lo dica apertamente ai colleghi. È il passaggio che recupera credibilità, perché dimostra che la scheda di valutazione risponde alle prove.
  • Riporti le correzioni accanto ai punteggi. Criteri sospesi, difetti aperti, difetti chiusi. Cambia la percezione di a che cosa serve il QA, e dà al team una seconda serie di numeri che non è il punteggio medio.

Ciò che resta dopo questo lavoro è la parte che l’operatore controlla davvero, l’unica che meriti un colloquio individuale. Il coaching smette di aprirsi con una disputa sull’equità del punteggio, e trasformare i dati QA in coaching (in inglese) diventa più facile, perché i risultati sono tutte cose che una persona può cambiare. Il Coaching AI di Kaizo costruisce le schede di coaching dai criteri valutati, quindi i criteri che esclude o rende condizionati smettono di generare rumore nel coaching oltre a smettere di togliere punti.

Due regole di manutenzione per chiudere. Versioni la scheda di valutazione ogni volta che rimuove o rende condizionato un criterio, e non ricalcoli mai i vecchi punteggi con le nuove regole, perché un punteggio di marzo è stato prodotto con il modulo di marzo. E annunci ogni modifica prima che entri in vigore, con il motivo. Una scheda di valutazione che si corregge in modo visibile viene trattata in modo molto diverso da una che compare in silenzio in una nuova versione ogni trimestre.

Domande frequenti

Gli operatori devono essere valutati su cose che non possono controllare?

No. Un criterio su cui l’operatore non può influire misura le circostanze e non le performance, e rende il punteggio totale inutilizzabile per il coaching o per le classifiche. L’errore può comunque valere la pena di essere registrato, ma va registrato a carico del sistema, della situazione del cliente o del team che lo ha causato. Divida ogni criterio in pienamente controllabile, controllabile a condizione e non controllabile, poi escluda, segni come non applicabile o reindirizzi di conseguenza.

Che cosa fare quando un operatore non supera il QA per un motivo che non dipende da lui?

Non lo corregga con una nota nei commenti, perché il commento non cambia il numero che arriva alla sua revisione. Se il criterio era impossibile in quella specifica conversazione, lo segni come non applicabile così esce dal denominatore. Se il criterio è regolarmente impossibile, lo tolga dalla scheda di valutazione. Se l’errore era reale ma causato da un altro team, mantenga il risultato, gli assegni un responsabile e lasci invariato il punteggio dell’operatore.

Come si gestisce una chiamata in cui il cliente ha riattaccato prima dello script di chiusura?

Attivi lo stato “non applicabile” su ogni criterio di chiusura, con l’orario della disconnessione come prova, invece di lasciare che restituiscano zeri automatici. Valuti le parti della conversazione che sono avvenute. Una disconnessione che azzera tre o quattro criteri di chiusura può spostare un operatore di un’intera fascia di performance solo per il comportamento del cliente, e colpisce di più gli operatori che gestiscono i clienti più difficili.

Una scheda di valutazione QA deve avere l’opzione “non applicabile”?

Sì, su ogni criterio, e deve togliere quel criterio dal denominatore, così il punteggio è dato dai punti ottenuti sui punti applicabili. Un’opzione “non applicabile” che lascia invariato il totale equivale aritmeticamente a una bocciatura, e i revisori smettono di usarla. Richieda un codice motivo da un elenco breve, mostri lo stato all’operatore nella revisione e riporti l’uso per revisore e per criterio, così la calibrazione può verificarlo.

Come si distingue un problema di sistema da un problema dell’operatore nei dati QA?

Scomponga il tasso di bocciatura di ogni criterio per fascia oraria, coda, canale, anzianità e data di rilascio. La competenza è distribuita in modo abbastanza uniforme tra questi gruppi, quindi un criterio bocciato molto più spesso in una coda, in una fascia oraria o a partire da una data di rilascio è quasi sempre un problema di sistema o di processo. Un criterio bocciato con tassi simili dagli operatori migliori e da quelli peggiori è ambiguo o impossibile.

Come si usa la root cause analysis nel controllo qualità?

Si chieda che cosa avrebbe dovuto essere vero perché l’operatore superasse il criterio, poi segua quella catena finché non arriva a qualcosa che ha un responsabile. Se la catena finisce in uno strumento che non ha salvato un campo, in un articolo della knowledge base sbagliato o in un’escalation senza risposta, il risultato appartiene a quel responsabile come difetto con una frequenza e un costo, e il criterio della scheda di valutazione va sospeso finché non viene corretto. Un risultato che risale a un processo che non funziona deve aggiornare il processo, non il punteggio della persona.

Termini correlati

Scopra quali criteri i suoi operatori non possono davvero superare

Porti la scheda di valutazione che usa oggi e un trimestre di conversazioni valutate. Le mostreremo quali criteri vengono bocciati secondo schemi che seguono le sue code e le sue date di rilascio, invece dei suoi operatori.

Prenota una demo Scopri come funziona il Coaching AI

In questa pagina

Lo veda sulle sue conversazioni

Valuteremo un campione dei suoi ticket reali secondo i suoi standard, così l'esempio è il suo.

Scelto da team di assistenza clienti in tutto il mondo

  • Foot Locker
  • SteelSeries
  • Canva
  • GetYourGuide
  • Instacart