Il design dell’IA conversazionale consiste nel decidere che cosa dice un agente IA, quando lo dice e che cosa succede quando la conversazione va storta. La maggior parte delle guide sull’argomento è scritta per i chatbot. Questa è per gli agenti vocali, dove chi chiama non può tornare indietro, ogni pausa si sente e il riconoscimento vocale a volte capirà «quindici» quando qualcuno ha detto «cinquanta».
Sviluppiamo i modelli vocali e la piattaforma su cui girano gli agenti vocali, quindi questa guida indica l’impostazione di Cartesia che risolve ciascun problema. Le idee valgono per qualsiasi stack. In breve: progetta per il compito, scrivi per l’orecchio e dedica la maggior parte dello sforzo ai momenti in cui le cose vanno storte. A nessuno è mai piaciuto sentirsi dire «Scusi, non ho capito» tre volte di fila.
Voce e chat sono problemi di design diversi
Molti consigli di design conversazionale valgono sia per la chat sia per la voce. Molti altri no.
| Chat | Voce | |
|---|---|---|
| Lettura | L’utente può rileggere, scorrere e tornare indietro | Chi chiama sente ogni parola una volta, in ordine |
| Lunghezza | Un paragrafo con un elenco va bene | Due frasi sono già un turno lungo |
| Scelte | Pulsanti e link | Chi chiama deve ricordare le opzioni |
| Silenzio | Nessuno nota un’attesa di due secondi | Una pausa di un secondo sembra una linea caduta |
| Errori di input | L’utente vede i propri refusi | Gli errori di riconoscimento restano invisibili finché l’agente non li ripete |
| Interruzioni | Rare | Continue, e l’agente deve smettere di parlare |
La ricerca sull’usabilità lo dice da tempo. Quando Nielsen Norman Group ha testato gli assistenti vocali nel 2018, ha rilevato che funzionavano bene solo per domande semplici con risposte brevi. Gli LLM hanno reso gli agenti molto più bravi a capire la domanda. Non hanno cambiato quanto una persona riesce a ricordare mentre ascolta.
Parti dal compito, non dal personaggio
Prima di scrivere un saluto o scegliere una voce, annota i due o tre compiti che l’agente deve portare a termine e che cosa significa «fatto» per ciascuno. «Spostare un appuntamento» è fatto quando il nuovo orario è nel calendario e la persona l’ha sentito ripetere. «Rispondere alle domande sulla fatturazione» non è un compito. «Spiegare un addebito dell’ultima fattura e offrire un rimborso se è un duplicato» lo è.
Per ogni compito, elenca le informazioni che servono all’agente, da dove arrivano (chi chiama, il tuo CRM, uno strumento) e che cosa l’agente non può fare. Quell’elenco diventa le istruzioni dell’agente e le descrizioni dei suoi strumenti. Il personaggio può venire dopo. Un agente simpatico che non trova l’ordine resta l’agente sbagliato.
Scrivi per l’orecchio
Le risposte parlate richiedono abitudini diverse da quelle scritte:
- Una domanda per turno. «Qual è la sua data di nascita e il CAP dell’account?» ottiene mezza risposta. Chiedi una cosa, poi l’altra.
- Prima la risposta. «Il suo ordine è partito martedì e arriva venerdì» è meglio di una frase che parte dai dati di tracciamento e arriva alla data solo alla fine.
- Poche opzioni. Come regola pratica, tre al massimo: alla quarta, chi chiama ha dimenticato la prima. Se sono di più, fai una domanda aperta e lascia che il modello linguistico interpreti la risposta.
- Niente formattazione. Markdown, elenchi puntati ed emoji vengono letti ad alta voce o spariscono. Di’ al modello che sta scrivendo per la voce.
Numeri, codici e nomi richiedono la cura maggiore. Sonic legge correttamente da solo le forme scritte convenzionali: prezzi come $19.99, date come 04/20/2025, numeri di telefono come (415) 555-1212. Per un codice di conferma da leggere carattere per carattere, racchiudilo in un tag <spell>. Se il modello pronuncia male il nome di un prodotto o di un luogo, aggiungilo una volta a un dizionario di pronuncia invece di combatterlo in ogni prompt. I nostri consigli di prompting includono un prompt di sistema di partenza per il parlato scritto da un LLM che copre queste regole; è una buona prima bozza del tuo.
Prova le stringhe che chi chiama sente davvero. Un agente che suona benissimo leggendo un saluto può comunque storpiare «il suo saldo è di $1,204.50, in scadenza il 11/03».
Progetta i tempi
Nella conversazione le persone si passano la parola in circa 200 millisecondi (Stivers et al., 2009). Un agente che aspetta un secondo intero per essere sicuro che la persona abbia finito sembra lento. Uno che interviene a ogni pausa interrompe chi sta ancora pensando.
Questa decisione spetta al rilevamento dei turni, non a un timer di silenzio fisso. Ink, il nostro modello di riconoscimento vocale, rileva i turni in base al significato di ciò che è stato detto oltre che all’audio. Può emettere un segnale anticipato quando la persona ha probabilmente finito, così il tuo agente può iniziare a preparare la risposta, e ritirarlo se la persona continua. La nostra guida al rilevamento dell’attività vocale e dei turni approfondisce.
Altre due decisioni sui tempi sono di design, non di ingegneria:
- Di’ qualcosa prima di un’operazione lenta. Se una chiamata a uno strumento richiede tre secondi, tre secondi di silenzio sembrano un guasto. Una frase breve, «Cerco subito quell’ordine», fa sapere alla persona che l’agente l’ha sentita. In Managed Agents gli strumenti hanno un’impostazione
pre_tool_speechper questo. - Decidi che cosa si può interrompere. Chi chiama interrompe di continuo, e di solito l’agente dovrebbe fermarsi e ascoltare. Un’informativa legale o la ripetizione di un importo di pagamento sono l’eccezione: finiscila, poi rispondi alla domanda.
Conferma ciò che conta, e solo quello
Confermare tutto è noioso. Non confermare niente è il modo in cui un agente prenota il dentista per il martedì sbagliato. Ordina ogni informazione in base a quanto costerebbe un errore:
- Costo basso: il nome della persona nel saluto, il motivo della chiamata. Conferma in modo implicito usandolo: «Certo, la aiuto con il suo ordine».
- Costo alto: date, importi, indirizzi, numeri di conto, tutto ciò che avvia un’azione irreversibile. Ripetilo e aspetta un sì: «Giovedì 8 ottobre alle 14:30. Lo prenoto?».
Gli errori di riconoscimento si concentrano sulle stesse parole: nomi di prodotti, nomi di vie, codici cliente. Se li conosci in anticipo, passali al riconoscitore come keyterms così li sente correttamente fin dall’inizio. Correggere una trascrizione sbagliata dopo è più difficile che prevenirla.
Dai a ogni errore un passo successivo
La maggior parte del lavoro di design sta nei percorsi che vanno storti. Pianifica questi prima del lancio:
| Situazione | Che cosa deve fare l’agente |
|---|---|
| Non ha capito | Riformulare la domanda, in modo più mirato. Non ripeterla parola per parola. |
| Non ha capito due volte | Offrire una persona o un altro canale. Al terzo «scusi?» la gente comincia a premere lo zero a ripetizione. |
| Silenzio | Sollecitare una volta, poi offrire di richiamare o chiudere con cortesia. |
| Fuori ambito | Dire in che cosa l’agente può aiutare e offrire un trasferimento. |
| Uno strumento ha dato errore | Dire che il sistema non è disponibile e indicare il passo successivo. Non inventare mai una risposta. |
| Chi chiama chiede all’agente di ignorare le istruzioni | Rifiutare e proseguire con il compito. Testalo prima del lancio. |
Scrivi esplicitamente la regola dei due tentativi nelle istruzioni dell’agente. Gli LLM hanno una pazienza infinita, e una pazienza infinita al telefono sembra una trappola.
Rendi il trasferimento facile da raggiungere
Ogni agente ha bisogno di un modo per arrivare a una persona, e chi chiama deve poterlo chiedere in qualsiasi momento. In Managed Agents, lo strumento di sistema transfer_to_number inoltra la chiamata a un numero di telefono o a un indirizzo SIP, con una condizione in linguaggio naturale per ogni destinazione, per esempio «The caller has a billing or payment question».
Sappi che tipo di trasferimento hai. In un trasferimento a freddo la chiamata va direttamente alla destinazione e l’agente si sgancia. In un trasferimento a caldo qualcuno aggiorna la persona che risponde prima che si unisca chi chiama. I trasferimenti che Cartesia documenta oggi sono a freddo; la documentazione sul SIP trunking li descrive come trasferimenti SIP REFER. Progetta di conseguenza: fai dire all’agente con chi sta per mettere in contatto la persona e perché e, se chi risponde ha bisogno di contesto, scrivi un breve riepilogo nel tuo CRM con uno strumento webhook prima del trasferimento, così nessuno deve chiedere «e di che cosa si tratta?».
Fai i test con chiamate reali
Un copione letto ad alta voce dal team che l’ha scritto passa sempre. Chi chiama davvero non leggerà il copione. Prima di indirizzare traffico reale:
- Raccogli da 20 a 50 registrazioni o trascrizioni reali della coda che stai automatizzando e falle passare dall’agente.
- Includi quelle difficili: rumore di fondo, accenti, persone che cambiano idea a metà frase, persone che chiedono un operatore nei primi cinque secondi.
- Valuta i risultati, non le impressioni. Managed Agents può valutare le chiamate concluse con metriche personalizzate, cioè giudici LLM che definisci tu («Il problema di chi ha chiamato è stato risolto?»). Registra anche il tempo fino al primo byte di audio nel primo turno dell’agente di ogni chiamata.
- Ascolta tu stesso un campione ogni settimana dopo il lancio. Le trascrizioni nascondono il tono, le pause lunghe e le sovrapposizioni con chi chiama.
La guida per avviare un pilota di call center con l’IA trasforma tutto questo in una scheda di valutazione per una coda. Per creare un agente da testare in questo modo, inizia con Managed Agents e un account gratuito nel playground di Cartesia.