Il QA della customer journey rivede tutto ciò che un cliente ha attraversato per risolvere un problema: ogni bot, agente AI, chat, telefonata e contatto con un operatore su quel problema entro una finestra stabilita. Invece di chiedersi se ogni conversazione era buona, si chiede se il percorso si è chiuso con il problema risolto, senza loop, contesto perso o richieste di parlare con una persona ignorate.
In breve
- Il QA delle conversazioni valuta un contatto. Il QA della customer journey valuta l’intero percorso che il cliente ha fatto per risolvere un problema, tra bot, agenti AI, canali e persone.
- La maggior parte degli errori dell’era AI sta tra una conversazione e l’altra: un “voglio parlare con un operatore” ignorato, un loop tra chat e telefono, un contesto perso, un ricontatto, un cliente che rinuncia in silenzio.
- Definisca un percorso come lo stesso cliente con lo stesso problema entro una finestra fissa, 7 giorni come impostazione predefinita.
- Misuri i percorsi risolti correttamente, i contatti per percorso, i passaggi falliti, il contesto perso, le richieste di un operatore accolte, l’abbandono silenzioso e il tempo di risoluzione.
- Riveda percorsi interi con una scheda di valutazione del percorso, li campioni in base a segnali di rischio e assegni a ogni percorso fallito un unico responsabile che ne corregga la causa.
Che cos’è il QA della customer journey?
Il QA della customer journey è un controllo qualità in cui l’unità di revisione è il problema del cliente, non la singola conversazione. Un revisore, o un controllo automatico, segue un cliente e un problema attraverso ogni punto di contatto (bot, agente AI, chat, email, telefono, operatore) entro una finestra stabilita e giudica se il percorso ha risolto il problema correttamente e senza sforzi inutili.
Il QA tradizionale legge un ticket e valuta l’operatore che lo ha gestito. Con gli agenti AI in prima linea, un solo problema diventa spesso tre o quattro contatti: una conversazione con il bot, un’escalation in chat, una telefonata, un’email di follow-up. Ogni contatto può superare la propria scheda di valutazione mentre il cliente passa tre giorni senza arrivare da nessuna parte.
Con “customer journey” e “agenti AI” si intendono spesso strumenti di marketing, come il Journey Creation Agent di Microsoft (in inglese), che costruisce percorsi via email, SMS e notifiche push a partire da un obiettivo scritto in linguaggio naturale. Questa guida parla di assistenza: verificare i percorsi che i clienti fanno davvero quando hanno bisogno di aiuto.
Perché valutare le singole conversazioni non vede dove fallisce l’assistenza nell’era AI?
Valutare le singole conversazioni non vede gli errori dell’era AI perché questi errori avvengono tra una conversazione e l’altra. Un bot che ignora “voglio parlare con un operatore”, una chat che rimanda il cliente al telefono, un passaggio che perde il numero d’ordine o un cliente che rinuncia in silenzio lasciano ogni conversazione apparentemente accettabile. Solo il percorso completo mostra il danno.
I clienti se lo aspettano. In un sondaggio Gartner su 5.728 clienti (dicembre 2023), il 64% ha dichiarato che preferirebbe che le aziende non usassero l’AI nel servizio clienti (in inglese), e la preoccupazione principale era che diventasse più difficile raggiungere una persona. Gartner raccomanda che un chatbot che non riesce a risolvere il problema passi la conversazione a una chat con un operatore che “riprenda da dove il chatbot si è fermato”. È un requisito di percorso.
Il rapporto sui chatbot nel credito al consumo del Consumer Financial Protection Bureau statunitense (in inglese) dà allo stesso schema il nome di “doom loop”, spesso causato da un problema che esce dalle capacità limitate del chatbot.
Cinque schemi di errore causano la maggior parte del danno:
| Schema di errore | Che cosa vive il cliente | Perché il punteggio della conversazione non lo vede | Segnale di percorso da osservare |
|---|---|---|---|
| “Voglio parlare con un operatore” ignorato | Chiede una persona, riceve altre risposte del bot o un vicolo cieco | Il bot è rimasto cortese e in tema, quindi la sua conversazione passa | Richiesta esplicita di un operatore senza alcun contatto umano nel percorso |
| Loop tra canali | La chat dice di chiamare, il telefono dice di usare la chat, nessuno risolve | Ogni contatto ha indirizzato “correttamente” il cliente da qualche parte | Stesso problema, 2 o più cambi di canale, nessuna risoluzione |
| Contesto perso in un passaggio | Ripete il numero d’ordine, il problema, i tentativi già fatti | L’operatore è stato cordiale e ha fatto le domande giuste | Il cliente fornisce due volte la stessa informazione nello stesso percorso |
| Ricontatto | Il problema era “risolto”, poi torna giorni dopo | La prima conversazione si è chiusa con una risposta sicura | Nuovo contatto sullo stesso problema entro la finestra |
| Abbandono silenzioso | Rinuncia a metà percorso, magari disdice o se ne va | Nessun reclamo, nessun sondaggio, il ticket si chiude come risolto | Il percorso finisce senza risoluzione e senza altri contatti |
Nei forum pubblici di assistenza i clienti descrivono il loop tra canali in una frase: la chat li rimanda al telefono, e al telefono li rimandano indietro o riattaccano. Né la trascrizione della chat né la telefonata, valutate da sole, risulterebbero fallite. Per gli errori dentro una singola conversazione con l’AI che le dashboard contano come successi, veda la nostra guida sugli errori silenziosi degli agenti AI.
Come si definisce una customer journey per il QA?
Definisca una customer journey come l’insieme dei contatti dello stesso cliente sullo stesso problema entro una finestra fissa, per esempio 7 giorni dal primo contatto. Prima di rivedere qualsiasi cosa servono tre regole scritte: come riconosce lo stesso cliente, come riconosce lo stesso problema e quando un percorso si considera concluso.
Stesso cliente. Usi l’identificativo più solido che ha: ID cliente o numero di conto, poi l’email verificata, poi il numero di telefono. Conti a parte le chat anonime invece di tirare a indovinare.
Stesso problema. Faccia corrispondere il tag di intento, il numero d’ordine o di pratica, oppure un ticket collegato. Quando i tag non sono affidabili, faccia confermare gli abbinamenti a un revisore su un campione, prima di tutto il resto.
La finestra. La scelga in base al tipo di problema, poi la tenga fissa:
| Tipo di problema | Finestra suggerita | Perché |
|---|---|---|
| Domande semplici su come fare o sull’account | 3 giorni | Se torna più tardi, di solito è una domanda nuova |
| Ordini, consegne, resi | 7 giorni | Copre l’attesa della consegna o la comparsa del rimborso |
| Fatturazione, rimborsi, contestazioni | 14 giorni | Una risposta sbagliata emerge al prossimo estratto conto o pagamento |
| Sinistri, disdette, casi regolamentati | 30 giorni | Processi lunghi con diversi passaggi obbligatori |
Queste finestre sono le nostre regole di partenza, non uno standard di settore. Tracci i giorni tra il primo e il secondo contatto sullo stesso problema e fissi la finestra nel punto in cui sono arrivati la maggior parte dei follow-up reali.
Come si chiude un percorso. Risolto (il problema reale è stato risolto e non è seguito nulla entro la finestra), abbandonato (il cliente si è fermato senza una risoluzione) o aperto (da rivedere più tardi). La risoluzione al primo contatto (in inglese) usa la stessa finestra di ricontatto ma guarda solo al primo contatto; il QA della customer journey giudica l’intero percorso.
Quali metriche a livello di percorso conviene misurare?
Misuri sette metriche di percorso: la quota di percorsi risolti correttamente, i contatti per percorso, il tasso di passaggi falliti, il tasso di contesto perso, le richieste di un operatore accolte, il tasso di abbandono silenzioso e il tempo di risoluzione del percorso. Insieme mostrano se i clienti vengono aiutati davvero, quanto sforzo costa loro e quale punto di passaggio si rompe più spesso. Le riporti per tipo di problema e per canale di ingresso.
| Metrica | Come si calcola | Regola di partenza (nostra, da adattare alla sua base) |
|---|---|---|
| Percorsi risolti correttamente | Percorsi in cui il problema reale è stato risolto correttamente / percorsi chiusi | Approfondire ogni tipo di problema sotto l’85% |
| Contatti per percorso | Tutti i contatti, su tutti i canali / percorsi | Approfondire ogni tipo di problema sopra 1,5 |
| Tasso di passaggi falliti | Passaggi che hanno perso il contesto, sono arrivati tardi o hanno rimandato indietro il cliente / passaggi rivisti | Obiettivo sotto il 5% |
| Tasso di contesto perso | Percorsi con più contatti in cui il cliente ha ripetuto un’informazione / percorsi con più contatti | Approfondire sopra il 5% |
| Richieste di un operatore accolte | Richieste esplicite di una persona seguite da un contatto umano / tutte le richieste di questo tipo | Obiettivo 95% o più |
| Tasso di abbandono silenzioso | Percorsi chiusi senza risoluzione e senza reclamo / percorsi chiusi | Rivedere un campione ogni settimana, qualunque sia il tasso |
| Tempo di risoluzione del percorso | Dal primo contatto alla risoluzione, mediana e 90° percentile | Osservare il 90° percentile |
Un tasso di contenimento (in inglese) alto può nascondere un percorso scadente: un cliente che lascia il bot e chiama il numero di assistenza conta comunque come contenuto. I contatti per percorso lo intercettano. E tenga distinto “risolto” da “risolto correttamente”: una risposta sbagliata ma sicura sembra risolta finché non arriva il ricontatto. Il nostro audit del tasso di risoluzione degli agenti AI mostra come verificarlo.
La scheda di valutazione del percorso (da copiare)
La scheda di valutazione del percorso è un breve insieme di criteri che hanno senso solo sull’intero percorso. Ogni criterio ha una condizione di errore chiara e indica i dati che servono al revisore. Valuti ogni conversazione con la sua scheda abituale, come sempre; valuti il percorso con questi criteri in aggiunta, così che l’una non sostituisca mai l’altra.
| # | Criterio di percorso | Che cosa conta come errore | Dati necessari |
|---|---|---|---|
| 1 | Il problema reale è stato risolto correttamente alla fine | Problema non risolto, risolto in modo sbagliato, oppure “risolto” e tornato entro la finestra | Tutti i contatti nella finestra, l’esito finale, la policy o l’articolo della knowledge base applicabile |
| 2 | Le richieste di un operatore sono state accolte (critico) | Il cliente ha chiesto una persona e non l’ha avuta, oppure l’ha avuta solo dopo averlo chiesto 2 o più volte | Trascrizioni del bot e dell’agente AI, registro delle escalation |
| 3 | Nessun loop tra bot, canali o team (critico) | Il cliente è stato rimandato a un canale o a un operatore che aveva già provato per lo stesso problema | Canale e gestore per ogni contatto, registro dell’instradamento |
| 4 | Il contesto è passato in ogni passaggio | Il cliente ha ripetuto un identificativo, il problema o i tentativi già fatti | Trascrizioni da entrambi i lati di ogni passaggio, eventuale riepilogo del passaggio |
| 5 | L’escalation è avvenuta sul segnale giusto | Escalation troppo tardiva (dopo ripetute risposte fallite) o passaggio a un operatore senza alcun motivo indicato | Regole di escalation, trascrizione nel punto del passaggio |
| 6 | Risposte coerenti tra canali e gestori | Due contatti hanno dato al cliente risposte diverse sulla stessa policy | Tutte le risposte date, la policy applicabile |
| 7 | Le promesse sono state mantenute | Una richiamata, un rimborso o un follow-up promesso in un contatto non è avvenuto | Promesse nelle trascrizioni, sistema ordini o pratiche |
| 8 | Lo sforzo era proporzionato | Più contatti o giorni di quanti ne richieda il tipo di problema (oltre la regola su contatti per percorso o tempi) | Numero di contatti, marcature temporali |
| 9 | La chiusura era esplicita | Il percorso è finito nel silenzio con il problema irrisolto (abbandono silenzioso) | Ultimo contatto, esito, eventuale disdetta o abbandono |
Regola di valutazione. Un percorso fallisce se fallisce il criterio 1, 2 o 3 (quelli critici). Altrimenti conti gli altri errori: 0 è superato, 1 è superato con un rilievo, 2 o più è fallito. Registri un solo segmento di causa radice per ogni errore: il bot, un agente AI specifico, la regola di instradamento o di passaggio, un canale, un operatore, oppure i contenuti di policy o di knowledge base. È questa attribuzione che trasforma un punteggio di percorso in una correzione.
Il criterio 4 è lo stesso controllo di continuità che la nostra guida su come valutare il passaggio tra AI e operatore tratta in profondità, un punto di passaggio alla volta. Per i percorsi in cui più agenti AI si passano un caso, la nostra guida all’orchestrazione degli agenti AI spiega gli schemi di instradamento dietro i criteri 3 e 5.
Come si campionano e si rivedono percorsi interi?
Campioni i percorsi su due livelli: riveda ogni percorso che fa scattare un segnale di rischio (una richiesta di operatore ignorata, 3 o più contatti, 2 o più canali, un loop o un abbandono), poi aggiunga un campione casuale di percorsi ordinari per misurare il vero tasso di errore. Riveda ogni percorso in ordine cronologico, su un’unica linea del tempo, con tutti i contatti affiancati.
Livello 1: percorsi segnalati dal rischio. Gli errori si concentrano qui, quindi li legga tutti, oppure un numero fisso per segnale ogni settimana:
- Una richiesta esplicita di una persona (“operatore”, “persona”, “parlare con qualcuno”) nella trascrizione di un bot o di un agente AI.
- 3 o più contatti, oppure 2 o più cambi di canale, sullo stesso problema.
- Un ricontatto dopo un contatto segnato come risolto.
- Un percorso che finisce senza risoluzione e senza altri contatti.
Livello 2: un campione casuale. I segnali mostrano dove guardare, non quanto spesso le cose vanno storte. Per riportare un tasso di errore difendibile, aggiunga un campione casuale di percorsi chiusi; da 150 a 400 al mese danno un margine di errore utilizzabile per un tipo di problema. Il nostro articolo sulla statistica del campionamento QA (in inglese) spiega perché i campioni più piccoli ingannano.
Come rivedere un percorso. Ricostruisca la linea del tempo: ogni contatto in ordine di data, con canale e gestore (bot, agente AI, operatore, menu telefonico). Legga il primo e l’ultimo contatto prima di quelli intermedi; la distanza tra ciò che il cliente ha chiesto e ciò con cui è rimasto è il verdetto. Poi percorra ogni punto di passaggio. Le telefonate hanno bisogno di una trascrizione o di un riepilogo per stare sulla stessa linea del tempo; molti contact center valutano già un campione di chiamate, e la revisione del percorso le colloca accanto ai contatti in chat e con il bot.
Il modello di revisione del percorso
Lo copi in un foglio di calcolo o in un modulo di revisione. Un blocco per percorso.
| Campo | Che cosa compilare |
|---|---|
| ID percorso | Un ID suo, oppure il numero del primo ticket |
| Cliente e problema | Identificativo del cliente, tipo di problema, numero d’ordine o di pratica |
| Finestra | Data del primo contatto, durata della finestra, stato finale (risolto, abbandonato, aperto) |
| Linea del tempo | Una riga per contatto: data e ora, canale, gestito da (bot, agente AI specifico, operatore, menu telefonico), che cosa è successo in una riga, contesto ricevuto (sì o no), esito |
| Segnali di rischio | Quali segnali del livello 1 sono scattati, se ce ne sono |
| Scheda del percorso | Superato o fallito sui criteri da 1 a 9, con il numero del contatto come prova |
| Verdetto | Superato, superato con rilievo, fallito |
| Segmento di causa radice | Bot, agente AI (nome), regola di instradamento o di passaggio, canale, operatore, policy o knowledge base |
| Responsabile e correzione | Chi è responsabile di quel segmento, la correzione concordata, la data di rilascio |
| Nuova verifica | La data in cui rivedrà di nuovo lo stesso tipo di percorso |
Un esempio pratico (illustrazione, numeri inventati per mostrare il calcolo)
Un team di assistenza gestisce 50.000 contatti al mese tra un chatbot, un agente AI in chat e via email, un numero di assistenza telefonica e gli operatori. Riuniti in percorsi con una finestra di 7 giorni, quei contatti formano 38.000 percorsi:
- 31.800 percorsi (84%) richiedono un solo contatto.
- 6.200 percorsi ne richiedono due o più, con 18.200 contatti in tutto (2,94 ciascuno).
- Contatti per percorso complessivi: 50.000 / 38.000 = 1,32.
Il QA delle conversazioni sembra in salute: il 91% delle conversazioni campionate supera la valutazione. Poi il responsabile QA rivede un campione casuale di 150 percorsi con più contatti. Ne falliscono 48 (32%):
| Causa radice | Percorsi falliti | Quota degli errori |
|---|---|---|
| Contesto perso nel passaggio dal bot all’operatore | 17 | 35% |
| Richiesta di un operatore ignorata o ritardata | 12 | 25% |
| Loop tra chat e telefono | 9 | 19% |
| Risoluzione sbagliata, il cliente è tornato | 6 | 13% |
| Risposte diverse sulla policy in chat e al telefono | 4 | 8% |
| Totale | 48 | 100% |
Dentro quei 48 percorsi falliti ci sono 141 conversazioni, e 118 di loro (84%) hanno superato la scheda di valutazione della conversazione. I percorsi sono falliti mentre la maggior parte delle conversazioni al loro interno passava.
Riportato sul totale, il 32% di 6.200 fa circa 1.980 percorsi falliti al mese. Il margine di errore al 95% è di circa più o meno 7,5 punti (1,96 × √(0,32 × 0,68 / 150) = 0,075), quindi il numero reale sta all’incirca tra 1.520 e 2.450. Vale la pena intervenire in entrambi i casi. E 29 dei 48 errori (60%) vengono da due punti di passaggio, il contenuto del passaggio e la regola sulle richieste di un operatore: è lì che vanno le prime correzioni.
Lo veda sulle sue conversazioni. Kaizo valuta il 100% delle sue conversazioni di assistenza, di operatori e agenti AI, con la sua scheda di valutazione, e collega ogni punteggio alle prove nella conversazione. Prenoti una demo.
Chi deve essere responsabile della qualità della customer journey?
Una sola persona dovrebbe essere responsabile della qualità del percorso dall’inizio alla fine, di solito l’Head of Support o il responsabile Support Operations, perché nessun responsabile di canale o di agente vede l’intero percorso. Questa persona detiene le metriche di percorso e la revisione settimanale. Ogni percorso fallito va poi al responsabile del segmento che lo ha causato.
| Ruolo | È responsabile di | Interviene su |
|---|---|---|
| Responsabile del percorso (Head of Support o Support Ops) | Le metriche di percorso, la scheda di valutazione del percorso, la revisione settimanale | Le priorità tra team; fa escalation quando una correzione si blocca |
| Responsabile dell’agente AI (per ogni bot o agente AI) | Le istruzioni dell’agente, la sua knowledge base e i segnali di escalation | Errori attribuiti a quell’agente: risposte sbagliate, richieste di un operatore ignorate |
| Responsabile di instradamento e passaggi | Regole di instradamento, contenuto del passaggio, trasferimento tra canali | Loop, contesto perso, escalation tardive |
| Responsabili di canale (chat, email, telefono) | Il processo e il personale di ogni canale | Loop tra canali, richiamate mancate, risposte incoerenti |
| Responsabile QA | Campionamento, calibrazione dei revisori, il modello di revisione | Punteggi di percorso affidabili; nuovi schemi di errore |
| Responsabile della knowledge base e delle policy | I contenuti da cui rispondono operatori e agenti AI | Risposte incoerenti tra canali |
Due regole evitano che diventi una riunione per trovare colpevoli. Ogni percorso fallito riceve esattamente un segmento di causa radice; il resto si registra come rilievi secondari. E la correzione dipende da chi ha sbagliato: una persona riceve coaching, un agente AI riceve una modifica alle istruzioni, alla knowledge base o ai segnali di escalation. Veda coaching delle persone e correzione degli agenti AI.
Come si correggono gli errori che il QA della customer journey trova?
Corregga gli errori di percorso nel punto di passaggio che li ha causati, non nella conversazione in cui sono emersi. La maggior parte delle correzioni sono modifiche di regole: un segnale di escalation, il contenuto di un passaggio, una policy che stabilisce quando una richiesta di operatore viene sempre accolta, oppure un’unica risposta condivisa su una policy per tutti i canali. Poi riveda lo stesso tipo di percorso per confermare che la correzione regge.
| Errore trovato | Correzione tipica | Dove approfondire |
|---|---|---|
| “Voglio parlare con un operatore” ignorato | Una regola rigida: una richiesta esplicita, o una seconda risposta fallita, porta al passaggio con un riepilogo | Guardrail per agenti AI |
| Loop tra canali | Eliminare le risposte “ci chiami” o “usi la chat” per i problemi che neanche l’altro canale può risolvere; offrire invece una richiamata o un ticket | Perché le conversazioni con l’AI falliscono |
| Contesto perso nel passaggio | Un contenuto fisso del passaggio: ID cliente, problema, tentativi fatti, che cosa vuole il cliente | Valutare il passaggio tra AI e operatore |
| Risposte incoerenti | Un’unica fonte delle policy, con versioni, da cui rispondono sia le persone sia gli agenti AI | Policy per agenti AI |
| Risoluzione sbagliata, ricontatto | Restringere ciò che l’agente AI può risolvere da solo; verificare le sue risoluzioni | Livelli di autonomia degli agenti AI |
| Abbandono silenzioso | Rivedere ogni settimana i percorsi abbandonati; aggiungere un follow-up per i problemi ad alto rischio irrisolti | Monitoraggio degli agenti AI |
Testi ogni modifica prima che arrivi ai clienti, poi la misuri in produzione. La nostra guida alla valutazione degli agenti AI copre entrambe le fasi: set di test prima del lancio e valutazione delle conversazioni reali dopo.
Quando il QA della customer journey non fa per lei?
Il QA della customer journey non vale l’impegno iniziale quando la maggior parte dei problemi si risolve in un solo contatto e non ha bot o agenti AI in prima linea. Se i contatti per percorso stanno intorno a 1,1, i clienti cambiano canale di rado e ha qualche centinaio di contatti a settimana, il QA delle conversazioni più un semplice dato di risoluzione al primo contatto le mostra già ciò che le serve.
È prematuro quando non riesce a collegare i contatti a un cliente: se la maggior parte delle chat è anonima e le chiamate non portano un identificativo del cliente, risolva prima questo. Nel frattempo legga ogni trascrizione con una richiesta esplicita di un operatore, che non richiede alcun collegamento. E il QA della customer journey non sostituisce mai il QA delle conversazioni: uno mostra dove si è rotto il percorso, l’altro che cosa è andato storto dentro un contatto.
Come iniziare questa settimana
Può iniziare il QA della customer journey questa settimana con un foglio di calcolo e un solo tipo di problema. L’obiettivo della prima settimana non è una dashboard. È trovare il punto di passaggio che rompe più percorsi, così che la prima correzione ripaghi lo sforzo.
- Scelga un tipo di problema ad alto volume in cui un bot o un agente AI gestisce il primo contatto, come lo stato dell’ordine o i rimborsi.
- Scriva le tre regole: quale identificativo, quale tag di problema o numero di pratica, quale finestra.
- Estragga 30 percorsi: 20 che fanno scattare un segnale di rischio e 10 a caso.
- Li riveda con la scheda di valutazione e il modello di revisione del percorso, con un segmento di causa radice per ogni errore.
- Nomini il responsabile del punto di passaggio peggiore e concordi una correzione con una data.
- Ripeta la settimana successiva sullo stesso tipo di problema per vedere se la correzione ha retto.
Quando la revisione manuale conferma lo schema, automatizzi ciò che può crescere. Il controllo qualità degli agenti AI di Kaizo valuta le conversazioni degli agenti AI e degli operatori con la stessa scheda di valutazione, compreso se l’agente ha fatto escalation sul segnale giusto e ha trasmesso il contesto, e AutoPilot valuta ogni conversazione nel momento in cui si risolve in Zendesk o Salesforce. Il collegamento di quelle conversazioni in percorsi viene dai dati del suo helpdesk: ticket collegati, ID cliente e tag di problema. Per il quadro generale, veda la nostra guida all’assistenza clienti agentica.
Domande frequenti
Qual è un buon numero di contatti per percorso?
Non esiste un benchmark universale, perché dipende dal tipo di problema. Usi la sua base di riferimento per tipo di problema e approfondisca qualsiasi valore in crescita. Come regola di partenza, le domande semplici dovrebbero stare vicino a 1,0 e tutto ciò che supera 1,5 merita uno sguardo ai percorsi che ci stanno dietro.
Il QA della customer journey è la stessa cosa della customer journey map?
No. La customer journey map progetta il percorso che vorrebbe far fare ai clienti, spesso per il marketing o il service design. Il QA della customer journey verifica i percorsi che i clienti hanno fatto davvero, contatto per contatto, e giudica se ciascuno ha risolto il problema senza loop, contesto perso o richieste di un operatore ignorate.
Si possono rivedere insieme percorsi telefonici e in chat?
Sì, se ogni chiamata ha una trascrizione o un riepilogo scritto nello stesso posto dei contatti in chat e via email. La revisione del percorso mette allora la chiamata sulla stessa linea del tempo dei contatti con il bot e in chat e applica gli stessi criteri di percorso. Senza trascrizione o riepilogo, un revisore può giudicare la chiamata solo dal suo esito.
Il QA della customer journey è la stessa cosa del monitoraggio degli agenti AI?
No. Il monitoraggio osserva segnali in tempo reale di un agente AI, come il tasso di escalation, gli errori e le derive, e manda un avviso quando cambiano. Il QA della customer journey rivede percorsi conclusi attraverso ogni bot, agente, canale e persona, e giudica se il problema del cliente è stato risolto. Il monitoraggio le dice che qualcosa è cambiato; il QA della customer journey le dice quanto è costato al cliente.
Come si individua l’abbandono silenzioso?
Cerchi i percorsi che si sono chiusi senza risoluzione e senza altri contatti: una conversazione con il bot interrotta a metà, un’escalation a cui il cliente non ha mai risposto, una richiamata mai andata a buon fine. Alcuni di questi clienti hanno risolto altrove; altri hanno disdetto. Riveda un campione ogni settimana e, dove può, controlli disdette o abbandoni nelle settimane successive.
