Come creare voice agent che durano: alcune lezioni dall’ingegneria sul campo

Per la maggior parte delle organizzazioni, le soluzioni puntuali per il supporto sono state a lungo valutate in base alla capacità di deviare le richieste. Questo significa ridurre il volume delle chiamate e limitare le interazioni con agenti in tempo reale. Ma deviare non vuol dire risolvere, e il divario tra questi due aspetti è proprio dove l’esperienza del cliente si interrompe. Per colmare questo divario servono agenti che abbiano accesso non solo ai dati, ma anche ai sistemi necessari per agire. In questo modo, gli agenti possono gestire rimborsi, guidare i clienti nel processo di acquisto e passare la conversazione a un agente umano con tutte le informazioni necessarie quando serve. Così le aziende possono gestire le interazioni con i clienti su larga scala, riducendo davvero il carico sui team di supporto umano e migliorando l’esperienza da entrambe le parti della chiamata. In unIn una recente implementazione con Revolut, una fintech che serve 70 milioni di clienti in tutto il mondo, questo si è tradotto in una riduzione di 8 volte del tempo di risoluzione e in un tasso di successo delle chiamate del 99,7%.

Le organizzazioni devono affrontare cambiamenti di questa portata in modo iterativo, sempre in linea con la missione aziendale e con il supporto della leadership. Dal punto di vista tecnico, ragionare in un ambiente non strutturato comporta rischi che vanno gestiti con attenzione. Dare a un agente la possibilità di agire su un sistema di Customer Relationship Management (CRM), modificare un ordine nel sistema di cassa o gestire un’escalation significa che il modello di governance è importante quanto il modello stesso. La domanda non è più se gli agenti possono gestire attività reali, ma quali meccanismi servono per distribuirli in modo sicuro e ripetibile.

In questo articolo condividiamo la nostra esperienza su cosa rende un agente efficace, dalla prima distribuzione fino alla scalabilità su tutta l’operazione clienti di un’organizzazione.

Distribuire agenti vs. distribuire software

Prima di entrare nel dettaglio della creazione di agenti, vale la pena confrontare la distribuzione dei voice agent con quella del software tradizionale, qualcosa che le aziende fanno da decenni. Da questa prospettiva, gli agenti si dividono in due componenti distinti: software tradizionale e core orchestrator.

Software:

Software: osservabilità e governance

Orchestratore centrale

I componenti Core Orchestrator sono per natura più difficili da prevedere, ma determinano le prestazioni dell'agente sia in termini di qualità delle risposte che di latenza percepita. A differenza del software tradizionale, questi componenti lavorano su linguaggio naturale e audio, dove lo spazio degli input è praticamente illimitato e piccoli cambiamenti nella formulazione, nel contesto, nei rumori di fondo o nel comportamento dell’utente possono produrre risultati molto diversi nel tempo. Questo rende i test convenzionali insufficienti da soli: un agente può funzionare perfettamente in centinaia di casi di test e comunque fallire in produzione in modi difficili da prevedere.versioning, A/B testing, telefonia e configurazione del primo messaggio, tra le altre. Queste componenti cambiano poco o nulla dopo la distribuzione, rendendo il loro comportamento molto prevedibile. Con buone pratiche di ingegneria, le organizzazioni possono sviluppare rapidamente su queste funzionalità e monitorarne le prestazioni in produzione grazie a metriche, trace e log accurati. I miglioramenti di latenza in questo livello seguono schemi noti: caching, connection pooling, scalabilità dell’infrastruttura e ottimizzazione dei protocolli sono leve affidabili con risultati deterministici.

Anche la latenza in questo livello è meno deterministica, influenzata dai tempi di inferenza del modello, dall’inserimento di artefatti audio, dalle catene di chiamate agli strumenti e dalla variabilità tipica dei sistemi generativi. Gestire bene questi componenti richiede una disciplina diversa, basata su framework di valutazione, monitoraggio in produzione e la volontà di iterare continuamente partendo dai dati reali delle conversazioni, non solo da ipotesi fatte prima del rilascio.

Questa distinzione influenza il modo in cui le organizzazioni dovrebbero affrontare l’adozione: partire da casi d’uso rilevanti per l’organizzazione ma a basso rischio, per poi scalare in modo graduale man mano che cresce la fiducia nel sistema.

Ciclo di rilascio

Selezionare i path-finder

Per i team che iniziano a usare agenti vocali, scegliere i giusti path-finder è una delle decisioni iniziali più importanti. E riguarda meno la tecnologia di quanto si pensi. I team che ottengono risultati concreti e non restano bloccati in POC infiniti hanno spesso una cosa in comune: sanno rispondere con chiarezza alle seguenti domande.

Per i team che iniziano a usare voice agent, scegliere i casi pilota giusti è una delle decisioni più importanti. E conta meno la tecnologia di quanto si pensi. I team che ottengono risultati concreti ed evitano di restare bloccati in POC infiniti hanno una cosa in comune: sanno rispondere con chiarezza alle seguenti domande.

• In che modo questo caso d’uso genera valore misurabile per il business? Il caso d’uso giusto da cui partire non è quello più interessante dal punto di vista tecnico, ma quello che può davvero fare la differenza su un risultato che l’azienda già considera prioritario. Questo si misura con l’impatto sui ricavi, la riduzione dei costi, la soddisfazione dei clienti e altre metriche che i responsabili già monitorano. Senza un collegamento diretto al valore per il business, diventa difficile giustificare i cicli di iterazione necessari per perfezionare l’agente, e il progetto rischia di arenarsi prima che la tecnologia possa dimostrare il suo valore.
• È subito chiaro agli utenti qual è lo scopo e il perimetro dell’agente?L’ambiguità sul perimetro è una delle cause più comuni di problemi tra sviluppo e produzione. Gli utenti che non capiscono cosa può o non può fare un agente ne testeranno i limiti in modi che i test non avevano previsto. Un agente ben definito chiarisce le aspettative fin dal primo messaggio e gestisce con eleganza le richieste fuori perimetro.
• Come si presentano le interazioni buone e quelle negative, e possono essere codificate in criteri di valutazione concreti?Una buona interazione non è solo quella in cui l’agente completa il compito, ma anche quella in cui l’utente si sente ascoltato, l’escalation avviene al momento giusto e il risultato è in linea con gli obiettivi aziendali. I criteri di valutazione si dividono in due categorie: metriche quantitative raccolte dalla piattaforma, come il tasso di completamento dei compiti e il tasso di escalation, e criteri basati sulle trascrizioni che richiedono l’analisi della conversazione stessa. Definire questi ultimi fin dall’inizio dà al team un obiettivo concreto su cui lavorare e stabilisce una soglia naturale per il go-live. Quando l’agente supera costantemente i criteri di valutazione e le metriche della piattaforma sono stabili, puoi andare in produzione con fiducia. Senza criteri definiti, il go-live diventa una scelta soggettiva.
• Quali sono i compromessi tra prestazioni e controllo, e cosa conta di più in questa fase?Più autonomia si dà a un agente, più le interazioni risultano naturali e flessibili, ma aumenta anche il rischio che operi fuori dai limiti validati. Un controllo più stretto tramite prompt vincolati e logiche di escalation rigorose riduce questo rischio, ma può rendere l’agente troppo rigido. Nessuno dei due estremi è ideale. Le organizzazioni che bloccano tutto troppo presto finiscono con un IVR glorificato. Chi si muove troppo in fretta senza aver costruito fiducia crea problemi di supporto che annullano i benefici. Capire dove posizionare questo equilibrio in ogni fase di maturità influenza la configurazione del modello, la logica di escalation e quanto della conoscenza dell’agente vive nel prompt rispetto a fonti recuperate o strutturate.

Impostare la prima versione

Quando si passa all’esecuzione, i team possono ispirarsi a metodologie quasi antiche quanto il software stesso. Il Test Driven Development (TDD) offre la struttura per mantenere gli agenti allineati alle metriche chiave durante tutto lo sviluppo.

Quando si passa all’esecuzione, i team possono ispirarsi a metodologie quasi antiche quanto il software stesso. Il Test Driven Development (TDD) offre la struttura per mantenere gli agenti allineati alle metriche chiave durante tutto lo sviluppo.

Con una prima serie di test pronta, lo sviluppo dell’agente parte dal system prompt. Qui si definiscono le regole, il tono e l’approccio dell’agente: cosa deve fare, cosa non deve fare e come comportarsi ai limiti del suo ruolo. Un system prompt ben strutturato è importante tanto per la forma quanto per il contenuto. Separare le istruzioni in sezioni chiare, tenere insieme le indicazioni correlate ed evitare frasi condizionali fa davvero la differenza nella coerenza del comportamento dell’agente. In questa fase torniamo spesso alla guida ai prompt.Test dell’agente, che verificano ripetutamente i comportamenti che l’agente deve mostrare. I primi si basano sull’analisi delle chiamate reali tra umani, una volta disponibili. I secondi si costruiscono in modo incrementale, partendo da un set iniziale di comportamenti attesi e ampliandolo man mano che emergono nuovi casi e situazioni limite.

Insieme al system prompt, si configurano i componenti principali dell’agente: l’LLM, il modello Text to Speech (TTS) e la voce. La scelta dell’LLM è soprattutto un compromesso tra latenza e prestazioni: i modelli ottimizzati per la velocità sacrificano spesso parte della capacità di ragionamento, e viceversa. Per il TTS, la scelta giusta dipende da cosa richiede il caso d’uso: delivery espressiva, bassa latenza o supporto multilingue. La voce, però, è una decisione tanto di brand quanto tecnica. Definisce come l’organizzazione si presenta a ogni chiamata, rendendola una delle poche scelte di configurazione che riguarda sia il marketing che gli ingegneri. Questo significa che la selezione della voce può avvenire in parallelo al resto dello sviluppo, senza diventare un collo di bottiglia all’inizio o alla fine. ElevenAgents offre accesso a oltre 10.000 voci, e se nessuna va bene, i team possono clonare o creare la propria.

Da qui, gli agenti possono essere estesi opzionalmente con una Knowledge Base,

Con queste basi, l’agente è pronto per essere messo alla prova.Knowledge Base, strumenti e configurazioni dei canali. Ogni aggiunta sblocca nuove capacità ma introduce anche nuove aree da testare. Che si tratti di integrazione telefonica, accesso a database esterni o possibilità di agire per conto del cliente, queste decisioni vanno sempre verificate rispetto ai criteri di valutazione prima di ampliare il perimetro. Quando si aggiungono strumenti, il system prompt e la descrizione degli strumenti forniscono indicazioni esplicite su quando e come usarli, così l’agente li utilizza in modo coerente e nel contesto giusto.

Verso la produzione

Con i test e i criteri di valutazione definiti nella fase di impostazione ora applicati all’agente costruito, lo sviluppo diventa un ciclo serrato: aggiungi nuovi test, identifica i fallimenti, aggiorna il system prompt o la configurazione e ripeti. La maggior parte dei problemi in questa fase non dipende dal modello, ma dal prompt. Un’istruzione che sembrava chiara da sola può risultare ambigua in conversazione. Emergono edge case che la suite iniziale non aveva previsto. Ognuno di questi diventa un nuovo test Next Turn, creato direttamente dalla conversazione. La domanda su quando fermarsi ha una risposta concreta: quando l’agente supera costantemente i criteri di valutazione su più run e le metriche della piattaforma come tasso di completamento e di escalation sono stabili entro i limiti accettabili. Ecco perché definire questi criteri prima di costruire è così importante. Senza di essi, la prontezza resta una valutazione soggettiva e il traguardo si sposta sempre più avanti.

In pratica, la maggior parte dei team scopre che pochi pattern di errore ricorrenti spiegano la maggior parte dei problemi. I più comuni sono: ambiguità del prompt, dove l’agente riceve istruzioni in conflitto o poco chiare e si comporta in modo imprevedibile; uso scorretto degli strumenti, dove l’agente li attiva nel contesto sbagliato o non li usa quando dovrebbe; e drift nell’escalation, dove l’agente esegue escalation troppo presto o mantiene conversazioni che dovrebbe passare ad altri. Ognuno di questi si risolve a livello di prompt: basta rafforzare l’istruzione, aggiungere un esempio esplicito o regolare la soglia di escalation. Il rischio è non intercettarli prima del go-live.

L’errore più comune è considerare una suite di test superata come una garanzia, invece che come un segnale. Una suite che copre solo i casi ideali passerà facilmente ma avrà poco valore. La copertura di rifiuti, cambi di direzione a metà conversazione, input ambigui e interazioni ricche di strumenti dà invece peso ai risultati. Allo stesso modo, chi salta i test di simulazione e si affida solo a test a livello di turno perde una classe di errori che emergono solo in conversazioni complete, come il drift di contesto (l’agente perde il filo dei turni precedenti) o errori che si accumulano e portano a un esito negativo. Una volta risolti i pattern ricorrenti e l’agente gestisce con disinvoltura la coda lunga degli edge case, il valore marginale di ulteriori iterazioni in staging diminuisce. A quel punto, il segnale più utile arriva dalle conversazioni reali.

Andare live non significa che l’iterazione sia finita. Significa che il ciclo di apprendimento si sposta dai test sintetici alle trascrizioni in produzione. I criteri di valutazione che hanno definito il go-live diventano il riferimento per misurare le prestazioni reali, e il ciclo continua da lì.

Feedback loop, valutazione e quando fermare l’iterazione

Una volta che i test sono definiti e attivi, le lacune nella pipeline emergono rapidamente. Tramite

La disciplina più importante in questa fase è validare i cambiamenti, non darli per scontati. Una correzione che risolve un errore può introdurne silenziosamente un altro. ElevenAgents supporta il versionamento, permettendo ai team di testare nuove iterazioni su una piccola percentuale di utenti prima di estenderle a tutti. Così puoi verificare che i miglioramenti portino davvero benefici, invece di spostare semplicemente il problema altrove.

Cosa può andare stortoversioning, permettendo ai team di testare nuove iterazioni su una piccola percentuale di utenti prima di estenderle a tutti. Così puoi verificare che i miglioramenti siano reali e non spostino semplicemente il problema altrove.

L’errore più grave in questa fase è saltare i rollout a rami e applicare le modifiche direttamente a tutta la base utenti. Senza rollout graduali, perdi la possibilità di isolare l’impatto di ogni cambiamento e, su larga scala, diventa quasi impossibile capire cosa sta davvero migliorando o peggiorando le metriche della piattaforma. Usare tutta la base utenti come ambiente di test non è solo rischioso: elimina la visibilità necessaria per prendere decisioni sicure in futuro.

Oltre alla strategia di rollout, ci sono altri due rischi da evitare. Il primo è reagire troppo agli ultimi errori. Quando una conversazione importante va male, è naturale voler correggere subito e in modo ampio, ma modifiche reattive al prompt senza eseguire l’intera suite di test spesso causano regressioni in comportamenti prima stabili. Ogni cambiamento, anche minimo, va trattato come una nuova iterazione e testato di conseguenza. Il secondo rischio è il drift nella valutazione: col tempo, i team possono abbassare inconsciamente la soglia di cosa considerano un test superato, soprattutto sotto pressione. I criteri di valutazione definiti all’inizio devono restare il punto di riferimento. Se sembrano troppo rigidi, la risposta giusta è aggiornarli consapevolmente, non abbassare gli standard in modo informale.

Scalare con fiducia

Aumentare il traffico è una decisione di fiducia, non di tempo. Il segnale per espandere arriva quando l’agente supera costantemente i criteri di valutazione su più run di test, le metriche della piattaforma sono stabili e i rollout a rami non mostrano regressioni significative rispetto al gruppo di controllo.

Una domanda frequente in questa fase è: quanto traffico serve per trarre conclusioni? Batch inferiori a 100 chiamate per ramo producono troppa variabilità per valutare i risultati in modo affidabile. Un tasso di successo del 60% su 25 chiamate e uno del 60% su 100 chiamate danno livelli di fiducia molto diversi. Oltre al numero, il batch deve essere abbastanza ampio da includere tutta la varietà di input realistici, compresi edge case probabili, intenti rari e modalità di errore che emergono solo con grandi volumi.

Più traffico amplifica sia ciò che funziona sia ciò che non funziona. Espandere prima di aver risolto i pattern di errore principali crea carichi di supporto difficili da gestire.

Ricomincia e ripeti

Sapere quando fermarsi è importante quanto sapere cosa correggere. L’iterazione ha rendimenti decrescenti, e il segnale giusto per mettere in pausa è quando l’agente soddisfa costantemente i criteri di valutazione definiti all’inizio. Da quel momento, ulteriori cambiamenti comportano più rischi che benefici.

Cosa significa “soddisfare costantemente i criteri” dipende dal contesto. Team con accesso limitato ai dati o integrazioni incomplete possono considerare realistico un tasso di escalation intorno al 50% finché non risolvono questi vincoli. Dove l’accesso ai dati è solido, le migliori implementazioni puntano di solito a un completamento dei task sopra l’80% e escalation sotto il 20%. Più importante di qualsiasi numero è la stabilità: prestazioni costanti su diverse settimane di traffico reale, senza regressioni significative nei test, sono il vero segnale. Quando il beneficio marginale della prossima iterazione è inferiore al rischio di regressione, è il momento di fermarsi.

Questo non significa che il lavoro sia finito. Quando emergono nuove esigenze, il processo ricomincia dall’inizio. Le domande di scoping della prima versione restano valide anche per la seconda. La differenza è che chi affronta un secondo ciclo lo fa con una suite di test, una baseline di valutazione e un’esperienza operativa che nel primo ciclo ha dovuto costruire da zero. Questo vantaggio progressivo distingue chi ottiene valore duraturo dagli agenti vocali da chi resta bloccato nei proof of concept.

Conclusione

I team che abbiamo visto colmare il divario tra deflessione e risoluzione sono quelli che definiscono cosa significa “buono” prima di iniziare a costruire, mantengono la disciplina durante l’iterazione e trattano ogni rilascio come base per il successivo. Gli agenti conversazionali non sono un deployment una tantum: le conversazioni reali fanno emergere edge case che nessuna suite di test può prevedere del tutto, e il lavoro di miglioramento non si ferma al go-live.

ElevenAgents nasce da questa realtà. Agent Testing, Conversation Analysis e rollout a rami sono le fondamenta che trasformano un proof of concept in un sistema che risolve davvero i problemi dei clienti su larga scala, non si limita a deviarli. Questo è il divario che vale la pena colmare.

ElevenAgents nasce da questa realtà. Agent Testing, Conversation Analysis e rollout a rami sono la base che trasforma un proof of concept in un sistema che risolve davvero i problemi dei clienti su larga scala, non si limita a deviarli. Questo è il divario che vale la pena colmare.