Il controllo qualità su Salesforce Service Cloud significa valutare le risposte scritte dall’operatore, il canale e lo stato in cui il caso è stato lasciato. Prima di tutto decida che cosa conta come conversazione, perché un caso contiene molti record collegati.
In breve
- Spesso il proprietario del caso non è chi ha scritto la risposta.
- Colleghi ogni criterio a un campo che esiste nella sua org.
- Definisca la popolazione del campione con un report.
- Decida prima del rollout come valutare i casi con più canali.
Che cosa significa davvero il controllo qualità su Salesforce Service Cloud
La maggior parte delle indicazioni sul QA presuppone un ticket: un cliente, un thread, un assegnatario, letto dall’alto in basso. Service Cloud non funziona così, e questa sola differenza strutturale è il motivo per cui i consigli generici sul QA tendono a crollare già nella prima settimana.
Un caso è un record. Ha campi come stato, origine, motivo, priorità e proprietario, anche se i valori di questi elenchi di selezione sono configurati dal suo amministratore e non fissati dalla piattaforma. Attorno a quel record si trova ciò che il cliente e l’operatore hanno fatto davvero: email, trascrizioni di chat o di messaggistica, post interni, attività e, dove l’org ha la voce attivata, i record delle chiamate. Il feed del caso mostra la cronologia di questa attività, ma una cronologia non è la stessa cosa di una conversazione. Mescola le risposte dell’operatore con voci di sistema, modifiche ai campi e post di persone che non hanno mai parlato con il cliente.
Per questo la prima domanda del controllo qualità su Service Cloud non è “che cosa dobbiamo valutare”. È che cosa chiamiamo conversazione. Esistono tre risposte difendibili, e ne deve scegliere una in modo deliberato:
- Solo lo scambio visibile al cliente. Ogni messaggio che il cliente poteva vedere, in ordine, ignorando i post interni e la cronologia dei campi. È l’equivalente più vicino al thread di un ticket e il più facile da spiegare a un operatore.
- Lo scambio più lo stato del record. Gli stessi messaggi, giudicati insieme al modo in cui il caso è stato classificato e chiuso. Adatto ai team in cui la qualità dei dati alimenta il reporting.
- L’intero caso, lavoro interno compreso. Messaggi, note interne, passaggi di consegne e attività. La visione più completa, e la più difficile da valutare in modo coerente, perché i revisori non sono d’accordo su quanto lavoro interno sia sufficiente.
Metta la risposta per iscritto prima di scrivere i criteri. Se non lo fa, ogni revisore sceglie in silenzio la propria, e si arriva allo schema di disaccordo che ogni responsabile QA conosce: due persone danno sessanta e ottantacinque allo stesso caso, e nessuna delle due sa dire perché. I meccanismi della scheda di valutazione che si appoggiano su questa scelta sono gli stessi di qualsiasi programma di controllo qualità dell’assistenza, e se non ne ha ancora costruito uno, parta da come costruire una scorecard qualità e poi torni qui.
Che cosa si può valutare in un caso, e che cosa no
Prima di scrivere i criteri, prenda un caso chiuso di recente e faccia l’inventario di ciò che contiene davvero. Lo faccia nella sua org e non partendo da un modello, perché ciò che è presente varia enormemente a seconda di come l’org è stata configurata.
Di solito disponibile
- Messaggi scritti dall’operatore. Le risposte via email, i turni di chat o di messaggistica e gli eventuali post pubblici. È la prova principale per tutto ciò che riguarda la comunicazione.
- Marcature temporali. Quando il cliente ha scritto, quando l’operatore ha risposto, quando è cambiato il proprietario, quando il caso è stato chiuso. Bastano per ragionare sulla reattività, con le avvertenze riportate più avanti.
- Valori dei campi alla chiusura. Stato, motivo, campi di prodotto o categoria e tutti i campi personalizzati che la sua org richiede. È ciò che rende un caso utilizzabile nei report, quindi fa legittimamente parte della qualità.
- Note e post interni. La qualità del passaggio di consegne, l’indagine, il ragionamento dietro l’escalation.
- Cronologia della proprietà. Chi ha avuto il caso e quando è passato di mano.
Spesso assente, e da verificare prima di promettere un criterio
- Voce. Se a un caso è collegata una chiamata e se esiste una trascrizione, e non solo una registrazione o una nota, dipende da come la voce è attivata nella sua org. Lo verifichi prima di scrivere un criterio che dipende dal contenuto della chiamata.
- Che cosa poteva vedere l’operatore. La sicurezza a livello di campo e le regole di condivisione fanno sì che la vista del revisore su un caso non sia necessariamente quella dell’operatore. Se un criterio presuppone che l’operatore avesse un’informazione a disposizione, verifichi che l’avesse davvero.
- Lo stato della knowledge base in quel momento. Se un articolo è cambiato dopo la chiusura del caso, l’operatore potrebbe aver avuto ragione rispetto alla versione che aveva.
- Tutto ciò che è successo fuori dal record. Una richiamata telefonica registrata come nota di una riga, una conversazione in uno strumento di chat, un passaggio diretto a un altro team. È lavoro reale ed è invisibile al controllo qualità.
La regola che ne deriva è breve. Se un criterio non può essere dimostrato da qualcosa che si trova nel caso, non è un criterio QA, è un’opinione. O trova il campo o il messaggio che lo dimostra, oppure lo toglie dalla scheda di valutazione e lo sposta nel coaching. Una scheda di valutazione operatore call center generica è un buon inventario di partenza, ma ogni sua riga deve superare questa prova rispetto al layout dei casi della sua org.
Come i dati del caso diventano criteri del controllo qualità su Salesforce Service Cloud
Questo è l’esercizio di mappatura da cui dipende la riuscita del programma. Per ogni criterio, indichi la prova, la verifica e la modalità di errore che si aspetta. L’ultima colonna è quella che i team saltano, ed è quella che prevede ogni discussione che avrà.
| Tipo di criterio | Prova nel caso | Come lo verifica un revisore | Dove si sbaglia |
|---|---|---|---|
| Accuratezza della risoluzione | L’ultimo messaggio dell’operatore, letto rispetto ai campi con cui il caso è stato chiuso | La risposta data corrisponde all’esito registrato, ed era corretta in quel momento | Lo stato viene impostato da un’automazione o da una macro, quindi il record dice risolto senza alcuna prova che lo sia |
| Rispetto dei processi | Campi obbligatori, note interne ed eventuali record di entitlement o di livello di servizio configurati nell’org | Confronti ciò che il caso registra con il processo documentato per quel tipo di caso | Il requisito si trova in una wiki invece che in un campo, quindi due revisori ne applicano due versioni diverse |
| Qualità della comunicazione | Solo i messaggi scritti dall’operatore, mai l’intero feed | Valuti il testo che il cliente poteva effettivamente leggere | I revisori assorbono il tono dai post interni e dalle voci di sistema e lo attribuiscono all’operatore |
| Reattività e impegno | Marcature temporali dei messaggi e dei cambi di proprietario | Misuri l’intervallo tra un messaggio del cliente e la risposta successiva dell’operatore | Tempo in coda, orario di lavoro e attesa di un altro team vengono tutti addebitati a chi in quel momento è proprietario del caso |
| Classificazione e qualità dei dati | Origine, motivo, tipo di record e i suoi campi di reporting | I valori descrivono ciò che è successo davvero nella conversazione | Gli operatori scelgono il valore che supera più in fretta la regola di convalida, e finora nessuno lo valutava |
| Instradamento | Cronologia della proprietà, appartenenza alle code, tipo di record | Il caso è arrivato subito al team giusto, e se no, perché | Un instradamento errato causato da una regola di instradamento viene valutato come errore dell’operatore |
In che cosa la valutazione di un caso differisce da quella di un ticket Zendesk
Molti responsabili delle operations di assistenza hanno fatto controllo qualità su Zendesk e ora devono farlo su Service Cloud, o su entrambi contemporaneamente. La filosofia della scheda di valutazione si trasferisce. I meccanismi no, e queste sono le sei differenze che costano più tempo. Se gestisce anche la parte Zendesk, i meccanismi specifici di quella piattaforma sono trattati a parte in controllo qualità per Zendesk.
| Dimensione | Ticket Zendesk | Caso Salesforce Service Cloud |
|---|---|---|
| L’unità di revisione | Un ticket è un thread. Richiedente, assegnatario e commenti si leggono come un’unica conversazione lineare | Un caso è un record. La conversazione si ricompone a partire da messaggi, trascrizioni ed elementi del feed collegati |
| Chi ha fatto il lavoro | L’assegnatario più gli autori dei commenti visibili | Il campo proprietario dice chi ha il caso adesso. La paternità va letta su ogni singolo messaggio |
| Canale | Di solito una proprietà del ticket stesso | I canali arrivano come record collegati diversi, e un caso può averne più di uno |
| Definire la popolazione del campione | Viste e filtri di ricerca | Un report o una visualizzazione elenco costruiti sui campi caso della sua org |
| Quanto è standard | L’insieme dei campi è sostanzialmente coerente tra un account e l’altro | Tipi di record, campi personalizzati e valori degli elenchi di selezione sono configurati per ogni org, quindi nessuna scheda di valutazione si trasferisce senza modifiche |
| Stato di chiusura | Un insieme breve e familiare di stati | I valori di stato, e ciò che ciascuno significa nell’operatività, sono definiti dal suo amministratore |
Come estrarre un campione che si può difendere
L’accusa più comune rivolta a un programma di controllo qualità è che il revisore abbia scelto i casi peggiori. Su Service Cloud è un’accusa facile da muovere, perché non esiste una coda di revisione naturale ed è davvero allettante lavorare sulla visualizzazione elenco già aperta.
Definisca prima la popolazione, in un report, e salvi il report. Un filtro che funziona è: data di chiusura all’interno del periodo di revisione, tipo di record o coda che identifica il lavoro che sta valutando, canale se valuta i canali separatamente, e un’esclusione per i casi senza alcun messaggio scritto da un operatore. Duplicati, casi chiusi automaticamente e casi che non sono mai arrivati a una persona sono rumore, e lasciarli nella popolazione gonfia o sgonfia in silenzio ogni media che pubblicherà in seguito.
Poi estragga il campione da quella popolazione e non dall’elenco. Due regole contano più della dimensione del campione:
- Randomizzi all’interno degli strati, non sull’intero insieme. Stratifichi per operatore e per tipo di caso, poi estragga a caso all’interno di ciascuno strato. Un campionamento casuale puro su un mese intero dà venti casi agli operatori più impegnati e uno all’operatore più nuovo, e così i punteggi individuali diventano incomparabili.
- Fissi il campione prima che qualcuno legga un caso. Estragga l’elenco, lo salvi e revisioni ciò che ha estratto. Un campione scelto dopo che il revisore ha scorso la popolazione non è un campione.
Valuti con onestà che cosa le dà davvero un campione manuale. Revisionare trenta casi per operatore al mese è una mole di lavoro seria, e dice comunque molto poco sui tipi di caso specifici che si verificano di rado e fanno più danni. Questo limite è una questione di aritmetica, non di impegno, ed è lo stesso vincolo che il manuale di ingegneria del NIST espone quando si chiede se una proporzione campionata di difettosi soddisfi un requisito: il campione deve essere abbastanza grande perché il test sia valido prima che la risposta significhi qualcosa. Ecco perché un punteggio campionato e un punteggio di qualità interno riportato alla direzione devono portare con sé l’intervallo di confidenza accanto al numero, ed ecco perché vale la pena sapere dove il campionamento nel controllo qualità smette di poter rispondere alla domanda.
Chi ha scritto la risposta: l’attribuzione su un caso passato di mano
Ecco il problema a cui nessun modello la prepara, ed è quello che fa più danni alla fiducia degli operatori in un programma di controllo qualità su Service Cloud.
I casi si spostano. Vengono instradati, portati in escalation, riassegnati, presi da una coda, passati a un team specialistico e restituiti. Il campo proprietario registra chi ha il caso nel momento in cui lo guarda. Non registra chi ha scritto la risposta che ha irritato il cliente, né chi ha fatto l’indagine che ha risolto il problema. Se il suo processo di controllo qualità valuta un caso e attribuisce il risultato al proprietario, su ogni caso trasferito ha attribuito il lavoro di una persona a un’altra.
La conseguenza pratica è prevedibile e precisa. Gli operatori che gestiscono le escalation ereditano casi che stanno già andando male, e incassano i punteggi che ne derivano. Di solito sono le sue persone più capaci. Nel giro di un trimestre imparano che prendersi un caso difficile costa caro, e il comportamento che più voleva incoraggiare diventa quello che la sua classifica punisce.
Quattro regole per rimediare
- Valuti il messaggio, non il record. Ogni detrazione deve essere legata a uno specifico messaggio scritto dall’operatore, con marcatura temporale e autore, non al caso nel suo insieme.
- Attribuisca in base all’autore. Legga la paternità su ogni messaggio e non sul campo proprietario. Se il suo reporting non riesce a farlo, è la prima cosa da sistemare, prima di ritoccare un solo peso.
- Gestisca in modo esplicito i casi con più operatori. O valuta separatamente il contributo di ciascun operatore, o esclude il caso dalla valutazione individuale e lo usa per la revisione dei processi. Entrambe le scelte sono difendibili. Valutare in silenzio l’ultimo proprietario non lo è.
- Tenga la cronologia della proprietà accanto al punteggio. Quando un punteggio viene contestato, la prima domanda è sempre chi ha fatto cosa. Se ricostruire la risposta richiede venti minuti, la contestazione è già persa.
I casi trasferiti sono anche la fonte più ricca che ha per lavorare sui processi anziché sul coaching individuale. Un caso passato di mano quattro volte prima di essere risolto le sta dicendo qualcosa sull’instradamento, sugli entitlement o sui confini tra team, e questo appartiene all’analisi delle cause radice e non alla scheda di valutazione di qualcuno.
Valutare ogni caso invece di un campione
Una volta stabilito il metodo manuale, la domanda ovvia è se si possa smettere di campionare. Si può, e su Service Cloud l’argomento a favore è più forte che su un modello a ticket più semplice, perché i tipi di caso che contano di più sono spesso proprio quelli rari, che un campione non raggiunge mai. C’è una differenza reale tra una copertura del 100% (in inglese), che rivela tendenze che un campionamento del 3% non potrebbe mai mostrare, e una revisione mensile di trenta casi per operatore.
La copertura da sola, però, non è la parte interessante, e non è più nemmeno un elemento distintivo. Ogni fornitore di questa categoria ormai valuta tutto. La domanda che decide se un punteggio automatico regge al confronto con il suo team è se può dimostrare che il valutatore aveva ragione. Su Service Cloud, in particolare, questo significa quattro cose:
- Tracciabilità all’interno del caso. Una detrazione deve indicare il criterio e puntare al messaggio esatto, all’interno del caso, che l’ha generata. “Comunicazione: meno dieci” su un caso con quaranta elementi nel feed è inutilizzabile.
- La stessa prova usata dal valutatore. Chi controlla un punteggio deve vedere l’insieme di messaggi da cui il punteggio è stato calcolato, non un suo riassunto.
- Una procedura di contestazione. Un operatore deve poter contestare un punteggio (in inglese) e ottenere che qualcuno esamini il ragionamento. Se non può, il punteggio è un verdetto.
- Un accordo misurato prima che conti. Faccia girare il punteggio automatico accanto ai suoi revisori sugli stessi casi per qualche settimana e convalidi la valutazione (in inglese) prima di collegare il numero a qualcosa che ha conseguenze.
L’Auto QA di Kaizo applica ai casi i criteri della sua scheda di valutazione e mantiene il ragionamento collegato alla conversazione, così una detrazione contestata può essere ricondotta allo scambio che l’ha causata invece di essere discussa a memoria. Funziona su Service Cloud tramite l’integrazione Salesforce, descritta più nel dettaglio in Kaizo su Salesforce, accanto alla stessa integrazione per Zendesk, il che conta se gestisce il controllo qualità su entrambi durante una migrazione. Prenota una demo per vederlo sui suoi casi.
Un rollout che regge alla prima contestazione
I programmi di controllo qualità su Service Cloud falliscono sempre nello stesso punto: la prima volta che un operatore contesta seriamente un punteggio e il programma non sa rispondere. Organizzi il rollout in modo che la risposta esista prima della contestazione.
| Fase | Che cosa fa | Completata quando |
|---|---|---|
| 1. Definire l’unità | Scelga una delle tre definizioni di conversazione e la metta per iscritto. Faccia l’inventario di ciò che è effettivamente presente in un caso chiuso della sua org | Un revisore sa dire, senza esitazioni, quali record rientrano nel perimetro |
| 2. Collegare i criteri ai campi | Per ogni criterio, indichi la prova, la verifica e la modalità di errore prevista. Elimini ciò che non può dimostrare | Ogni criterio punta a un campo o a un tipo di messaggio che esiste |
| 3. Costruire il report della popolazione | Un report salvato che definisce l’insieme revisionabile, con esclusioni per i casi chiusi automaticamente e quelli senza operatore | Due persone che eseguono il report ottengono lo stesso numero di casi |
| 4. Valutazione in parallelo e calibrazione | Tre revisori valutano in modo indipendente gli stessi quindici casi, di cui almeno tre che hanno cambiato proprietario. Confrontate e discutete | Conosce il tasso di disaccordo dei suoi revisori, ed è in calo |
| 5. Pubblicare con una procedura di ricorso | Annunci insieme la scheda di valutazione, il metodo di campionamento e la procedura di ricorso. Un ricorso senza procedura è una lamentela | Gli operatori sanno descrivere la procedura senza doverla cercare |
| 6. Fare report, poi ricontrollare la mappatura | Riporti i punteggi accanto ai risultati operativi come riaperture ed escalation. Riveda la mappatura ogni trimestre | L’andamento dei punteggi spiega qualcosa che un manager sospettava già |
Riportare il punteggio di un caso perché qualcuno agisca
Un punteggio QA che resta solo in uno strumento di QA viene letto dal team QA. Perché valga lo sforzo, il punteggio deve stare accanto ai numeri operativi che la direzione dell’assistenza già guarda, e deve essere scomposto in un modo che indichi un’azione.
Tre scomposizioni fanno la maggior parte del lavoro sui dati di Service Cloud:
- Per tipo di caso o tipo di record, non solo per operatore. La qualità varia molto di più in base al tipo di lavoro che in base alla persona che lo svolge. Una media bassa su un tipo di record è un problema di processo, di conoscenze o di instradamento, e si può correggere a livello centrale.
- Per criterio, sull’intero team. Un criterio che fallisce in modo diffuso non è quasi mai un problema di coaching. È una policy poco chiara, un articolo mancante nella knowledge base o un criterio scritto male.
- Il punteggio rispetto al tasso di riapertura e di escalation. È la verifica della scheda di valutazione stessa. Se i casi con punteggio alto si riaprono nella stessa misura di quelli con punteggio basso, la scheda sta misurando qualcosa di diverso dalla qualità e va ripesata.
È questa terza scomposizione quella da proteggere. È ciò che impedisce a un programma di controllo qualità di scivolare in un rituale di conformità che tutti eseguono e nessuno usa. Affiancare i punteggi di qualità al quadro operativo è esattamente lo scopo di una vista di analisi dell’assistenza, ed è anche il modo più rapido per dimostrare a una direzione scettica che il programma di controllo qualità misura qualcosa di reale.
Domande frequenti
Salesforce Service Cloud include la valutazione QA di serie?
Service Cloud le dà la materia prima: il record del caso, i messaggi e le trascrizioni collegati, la cronologia dei campi e un livello di reporting su tutto questo. Una scheda di valutazione ponderata, una coda di revisione, la calibrazione tra revisori e una traccia dei ricorsi verificabile non fanno parte dell’oggetto caso standard. I team o costruiscono una versione leggera con campi personalizzati e report, che funziona finché il disaccordo tra revisori non diventa il collo di bottiglia, oppure aggiungono uno strumento di QA che legge i casi. Verifichi che cosa ha già configurato la sua org prima di dare per scontata l’una o l’altra cosa, perché la personalizzazione varia enormemente.
Che cosa si dovrebbe valutare in un caso Salesforce?
Solo ciò che il caso dimostra. In pratica: i messaggi scritti dall’operatore, le marcature temporali di quei messaggi e dei cambi di proprietario, i valori dei campi con cui il caso è stato chiuso e le note interne, se la sua definizione di conversazione le include. Tutto ciò che non può indicare nel record, come ciò che l’operatore sapeva in quel momento o una richiamata registrata come nota di una riga, appartiene al coaching e non a un punteggio.
In che cosa il QA su Service Cloud è diverso dal QA su Zendesk?
La filosofia della scheda di valutazione è la stessa, i meccanismi no. Un ticket Zendesk (in inglese) è un thread lineare con un assegnatario chiaro, quindi l’unità di revisione è evidente. Un caso Salesforce è un record con messaggi, trascrizioni ed elementi del feed collegati, quindi l’unità va definita da sé. Anche la paternità va letta sui singoli messaggi invece che presa dal campo proprietario e, dato che tipi di record e campi personalizzati sono configurati per ogni org, nessuna scheda di valutazione si trasferisce senza modifiche tra due org Salesforce.
Come si campionano i casi Salesforce per la revisione QA?
Costruisca un report salvato che definisce la popolazione, filtrando per data di chiusura, tipo di record o coda, canale dove pertinente, ed escludendo i casi senza alcun messaggio scritto da un operatore. Poi estragga a caso all’interno degli strati, per operatore e per tipo di caso, invece che a caso sull’intero mese, così ogni operatore contribuisce con un numero di casi comparabile. Fissi il campione prima che qualcuno apra un caso. Revisionare un elenco che ha già scorso non è campionamento.
A chi va il punteggio QA quando un caso cambia proprietario?
Non automaticamente al proprietario attuale, che è l’impostazione predefinita in cui cade la maggior parte dei programmi e quella che fa più danni. Attribuisca ogni messaggio valutato a chi l’ha scritto. Su un caso gestito da più persone, valuti separatamente il contributo di ciascun operatore oppure tolga il caso dalla valutazione individuale e lo usi per la revisione dei processi. Dare all’ultimo proprietario il punteggio di un lavoro che ha ereditato insegna ai suoi operatori migliori a evitare le escalation.
Si possono valutare email, chat e voce nello stesso caso?
Sì, ma decida l’approccio prima del rollout e non durante la prima contestazione. Un unico punteggio combinato su un caso che contiene un thread email e una trascrizione di chat è difficile da usare nel coaching, perché gli standard dei due canali sono davvero diversi. Valutare separatamente ogni segmento di canale e riportare i risultati separatamente di solito è più chiaro. Se è coinvolta la voce, verifichi prima se la sua org ha davvero trascrizioni allegate e non solo registrazioni, perché un criterio che dipende dal contenuto della chiamata non è applicabile senza di esse.
