«Il cognome è Tschanz.»
«Grazie, signor Schanz.»
«No, Tschanz. Con la T.»
«Capito, signor Schanz.»
Al terzo tentativo l’assistente non deve dimostrare pazienza. Deve capire che la strategia usata non sta funzionando.
I modelli vocali più recenti rendono la conversazione più naturale. OpenAI descrive GPT-Live come full-duplex e misura in valutazioni umane aspetti come turn-taking, interruzioni e flusso. Nella realtà restano però dialetto, rumore, Bluetooth, nomi insoliti, targhe e code-switching.
La domanda importante non è se la Voice AI sbaglierà mai. È cosa fa dopo il primo errore.
Il repair loop ha bisogno di stati, non della stessa frase
Un bot debole dice: «Mi dispiace, non ho capito. Può ripetere?» e continua a farlo.
La riparazione dovrebbe cambiare forma.
Prima incertezza: conferma dell’ipotesi. Seconda: spelling, chunking o altro identificatore. Se un campo critico resta instabile, handover.
Raccomandazione: non ripetere tre volte la stessa tattica. Dopo due fallimenti sulla stessa entità critica, cambiare metodo o passare a un umano è un buon punto di partenza per il pilot; non è una soglia scientifica universale.
Fatto confermato: qualità vocale comprende flusso, interruzioni e turn-taking; modelli migliori non eliminano ogni failure audio o linguistico.
Un errore sul nome non pesa come un errore sul filler
Ogni workflow dovrebbe definire entità critiche: nome, telefono, data, ora, indirizzo, importo, targa, servizio.
Se il cliente dice martedì e il bot capisce mercoledì, è sensato confermare: «Ho martedì 25 agosto alle 14, corretto?»
Anche la contraddizione è un segnale forte. Il cliente dice «non Berna, Thun» e più avanti l’assistente usa ancora Berna. La correzione esplicita non è stata assorbita.
Infine c’è il comportamento: ripetuti «no», «sbagliato», «l’ho già detto». Possono attivare un repair senza pretendere di inferire in modo perfetto lo stato emotivo.
Cambiare la forma del compito
- Offrite due alternative. «Meier o Meyer?»
- Dividete numeri e codici in piccoli gruppi.
- Usate un canale alternativo come SMS o tastiera.
- Cambiate identificatore se il processo lo permette.
- Azzerate il campo contestato anziché lasciare la risposta sbagliata nel contesto.
- Passate a una persona con contesto, includendo ciò che è già stato confermato.
Un handover ben fatto evita che il cliente debba raccontare tutto da capo.
Dialetto e lingue miste richiedono più di una confidence threshold
Una chiamata svizzera può unire Hochdeutsch, dialetto, nome francese e via italiana. Un solo valore di confidence può generare troppi trasferimenti.
Guardate insieme criticità del campo, correzioni esplicite, ripetizione dell’errore, cambio lingua e possibilità di input alternativo.
Anche l’orario conta. Di giorno live transfer; fuori orario callback con priorità e contesto.
La frase dovrebbe essere trasparente: «Non sto acquisendo il suo cognome in modo affidabile. Passo la richiesta al team; ho già salvato numero e orario desiderato.»
È una migliore customer experience di altre due richieste identiche.
Pilot minimo con nomi e rumori reali
Costruite un test con cognomi svizzeri, località, targhe, numeri, rumore di strada, vivavoce e cambio lingua. Fate correggere il bot apposta.
Misurate first-pass success sulle entità critiche, casi risolti dopo un repair, repair medi per chiamata, handover per incomprensione, chiamate con tre o più ripetizioni dello stesso campo e handover con contesto sufficiente per l’operatore.
La metrica non dovrebbe essere «meno handover possibile». Un agente che non passa mai la chiamata può semplicemente trattenere troppo a lungo i casi che non sa risolvere.
l’incomprensione è una parte normale del workflow Voice. Progettatela. Un repair breve, un cambio di strategia e un handover rispettoso sono più robusti di una conversazione infinita.
Un repair loop efficace deve cambiare strategia, non solo ripetere la stessa domanda con parole diverse. Se il cognome non è stato acquisito due volte via audio, un terzo tentativo identico raramente aggiunge informazione. L’agente può chiedere spelling, confermare solo le lettere incerte, proporre l’inserimento tramite link sicuro o usare un dato già noto come riferimento senza fingere di averlo capito.
Classificate inoltre i campi per criticità. Una preferenza di orario può tollerare una conferma finale; indirizzo di intervento, targa, numero cliente o dato che autorizza un’azione richiedono una soglia più severa. Il repair loop deve quindi dipendere dalla conseguenza dell’errore, non soltanto dalla confidence del riconoscimento vocale.
Registrate ogni repair come evento QA: campo problematico, lingua, rumore, strategia usata, esito e numero di tentativi. Questo crea una base concreta per capire se il problema nasce da pronuncia, flow, modello o telephony. Un semplice conteggio dei transfer non lo mostra.
Quando il cliente corregge esplicitamente l’assistente — «no, ho detto quindici, non cinquanta» — considerate la correzione un segnale forte. Azzerate il valore precedente, confermate la nuova informazione e non lasciate entrambe le versioni nel contesto come se fossero equivalenti. Se la contraddizione resta irrisolta, passate la chiamata.
Infine, preparate un fallback asincrono per quando nessun operatore è disponibile. L’agente può creare una richiamata prioritaria con numero, motivo, dati già confermati e punto rimasto incerto. Non dovrebbe invece trasformare l’assenza di personale in una scusa per continuare a chiedere all’infinito o chiudere il caso come completato.
Per modifiche sensibili serve anche la verifica del chiamante. Il nostro assistente telefonico IA usa azioni limitate e passaggi espliciti.
Fonti
FAQ
Quante volte bisogna chiedere di ripetere?
Non esiste un numero universale. Due fallimenti su un campo critico sono un buon trigger iniziale per cambiare strategia.
Bisogna confermare tutto?
No. Concentratevi sui dati che cambiano persona, appuntamento, importo o azione.
La confidence del speech recognition basta?
No. Combinatela con correzioni dell’utente, ripetizioni e criticità business.
Cosa passa all’operatore?
Motivo, dati confermati, campo incerto, tentativi già fatti e prossimo passo richiesto.
Come funziona fuori orario?
Con callback o ticket assegnato, preservando il contesto e comunicando un’aspettativa realistica.