Dalla demo alla produzione con l'IA vocale: cosa serve a chi acquista nei primi 30 giorni

Portare un agente vocale con IA dalla demo alla produzione in 30 giorni significa definire l'ambito di un solo tipo di chiamata, svilupparlo e collegarlo nella seconda settimana, testarlo con chiamate simulate e reali nella terza e avviare un lancio graduale (soft launch) su una parte del traffico reale nella quarta, con un responsabile designato per ogni attività. La demo dimostra che la piattaforma sa sostenere una conversazione. I 30 giorni dimostrano che il tuo team sa gestirla, e alla fine una scorecard dal pilota alla produzione ti dice quando l'agente è pronto per più traffico.

Perché una buona demo non basta per arrivare in produzione?

Una demo risponde alla domanda «sa parlare?». La produzione pone quattro domande diverse: quali chiamate gestisce, in quali sistemi scrive, chi interviene quando una chiamata va storta e come viene testata una modifica prima che la sentano i chiamanti. La maggior parte dei team che si bloccano dopo una demo non è ferma per colpa del software. La dashboard la capiscono. Quello che manca è un piano, un responsabile designato e qualcuno a cui chiedere quando lo sviluppo incontra una domanda a cui la documentazione non risponde per il loro flusso di lavoro specifico.

Se stai ancora scegliendo una piattaforma, parti da come valutare una piattaforma di agenti vocali prima del go-live. Se hai una preferenza ma non ti sei ancora impegnato, mettila alla prova prima sui tuoi casi limite, come descritto nella prossima sezione. Dopo di che, questa guida presuppone che tu abbia scelto e che ora debba andare in produzione.

Come si esegue un proof of concept di IA vocale sui propri casi limite?

Esegui un proof of concept (POC) di IA vocale sulle chiamate che la demo ha saltato: il tuo personale interpreta i chiamanti più difficili, su record strutturati come quelli reali, rispetto a criteri di successo firmati prima da entrambe le parti, con il costo dei test concordato in anticipo. Una demo segue il percorso ideale. Un POC mostra se l'agente regge sulle regole che rendono difficili le tue chiamate.

Testa con il tuo personale su record reali

Chiedi a chi gestisce oggi queste chiamate quali casi mettono in difficoltà i nuovi assunti, poi fagli chiamare l'agente nei panni di quei chiamanti. Esegui ogni caso su un record strutturato come quello reale, perché un record di test pulito nasconde ciò che uno disordinato fa emergere.

Definisci la gestione dei dati prima che record reali arrivino in un test. La documentazione sulla compliance di Retell richiede un BAA firmato prima che informazioni sanitarie protette passino attraverso Retell. Se le tue regole non consentono ancora l'uso di record reali, riproducine la struttura: in un test di simulazione di Retell, ogni caso imposta i propri valori delle variabili dinamiche e i risultati simulati (mock) delle funzioni. Verifica cosa consentono le tue regole con un legale o con il tuo team compliance.

Concorda i criteri di successo prima che inizi il pilota

Entrambe le parti firmano i criteri prima della prima chiamata di test, perché i criteri scritti dopo tendono ad adattarsi a qualunque cosa l'agente abbia fatto. Indica i casi inclusi, la soglia di superamento e il numero di esecuzioni per ciascuno, cosa conta come errore critico, chi valuta e a cosa porta il superamento, in modo che si concluda con una decisione e non con altri test. Per le metriche, usa la guida alla valutazione della piattaforma; la scorecard più avanti in questa guida riguarda una decisione diversa.

Calcola il costo dei test per entrambe le parti

Dalla tua parte servono ore del personale per effettuare e valutare le chiamate, più il tempo di IT e compliance. Il fornitore impiega tempo di sviluppo per adattare un agente alle tue regole. Poi c'è l'utilizzo della piattaforma: secondo i prezzi dei test di Retell, i test vengono fatturati a tariffe di produzione, senza sandbox gratuita, con la voce a partire da $0,07 al minuto e il testo a messaggio, quindi esegui la maggior parte dei casi in modalità testo. Metti per iscritto chi copre ciascun costo, quanto dura il POC e se conta ai fini di un contratto. Un elenco di casi e una finestra temporale fissi lo mantengono economico per entrambe le parti.

Come dovrebbero essere i primi 30 giorni, settimana per settimana?

Quattro settimane, ciascuna con un obiettivo e un chiaro criterio di completamento. Non iniziare la settimana successiva finché quella in corso non è conclusa.

Definisci l'ambito di un tipo di chiamata (giorni da 1 a 7)

Scegli un tipo di chiamata con un volume costante e un esito verificabile in un sistema di riferimento (system of record): un appuntamento fissato, un lead instradato, un ticket creato. Recupera registrazioni o trascrizioni reali di quel tipo di chiamata, non lo script che il tuo team pensa che i chiamanti seguano.

Il documento di ambito dovrebbe rispondere a cinque punti:

• L'unico tipo di chiamata incluso e ogni tipo di chiamata esplicitamente escluso.
• La metrica di successo, definita in modo che una macchina possa segnarla come vera o falsa.
• L'unico sistema di riferimento da cui l'agente legge o in cui scrive.
• Dove vanno le chiamate quando l'agente non può aiutare, e in quali orari.
• Chi approva i testi dell'agente e chi dà il via libera al lancio.

Sviluppa e collega (giorni da 8 a 14)

Sviluppa su una versione bozza. In Retell, una nuova versione nasce come bozza che puoi modificare e testare, e la pubblicazione la rende di sola lettura, così hai sempre una configurazione fissa a cui tornare. Collega solo l'unico sistema previsto dall'ambito. Se quel collegamento è nuovo per il tuo team, il flusso di lavoro dal CRM all'IA vocale spiega quali dati si spostano in ogni momento della chiamata.

Configura subito la metrica di successo, non dopo il lancio. La Post Call Extraction di Retell viene eseguita al termine di ogni chiamata e include un campo integrato call_successful più campi personalizzati che definisci come booleano, testo, numero o selettore. Un campo come «appointment_booked» è ciò che rappresenterai nei grafici e su cui imposterai gli alert nella quarta settimana.

Testa con chiamate simulate e reali (giorni da 15 a 21)

Testa prima in testo, poi in voce, poi al telefono. I test di simulazione di Retell eseguono un caso di test senza effettuare una chiamata: un'IA interpreta il chiamante sulla base di una persona che scrivi tu, e l'esecuzione viene valutata come superata o non superata rispetto ai tuoi criteri di successo, con una spiegazione scritta. I casi salvati vengono eseguiti insieme in batch, che restituisce un tasso di superamento, così la suite diventa il tuo controllo di regressione dopo ogni modifica. Conductor, il copilot integrato nella dashboard di Retell, può creare bozze di casi di test da zero o a partire da chiamate reali.

Tre cose da fare bene questa settimana:

• Simula (mock) tutto ciò che scrive in un sistema live. La documentazione di Retell avverte che una funzione personalizzata non simulata chiama il suo endpoint reale durante un test, quindi un test può creare una prenotazione o un record reali.
• Usa le web call per la voce e le chiamate telefoniche per la telefonia. Una chiamata dal browser ti permette di sentire interruzioni e alternanza dei turni, ma lì i trasferimenti verso un numero di telefono non funzionano. Usa una vera chiamata telefonica per verificare trasferimenti, input da tastiera e audio dell'operatore.
• Mettilo a budget. In Retell i test vengono fatturati a tariffe di produzione: i test testuali a messaggio, quelli vocali al minuto.

Chiudi la settimana con il personale che chiama come farebbero i chiamanti reali, compresi quelli più difficili.

Lancio graduale e monitoraggio (giorni da 22 a 30)

Invia una piccola quota di traffico reale all'agente, controllalo ogni giorno e tieni pronto un rollback in un solo passaggio. Per la prima parte di traffico, il responsabile della telefonia instrada una porzione di chiamate al numero dell'agente dal tuo IVR o dalla tua coda esistenti. Dopo di che, Retell ti offre tre strumenti:

• L'A/B testing suddivide in percentuale il traffico di un numero di telefono tra più agenti, così una correzione può ricevere una piccola quota mentre il resto rimane sull'agente di cui ti fidi.
• I tag di ambiente associano un numero di telefono a una versione. Spostare il tag prod su una nuova versione vi indirizza le chiamate live; riportarlo indietro esegue il rollback.
• Le regole di alert inviano un'email o un webhook quando il tasso di successo delle chiamate, il volume di chiamate, la concorrenza utilizzata, il sentiment negativo o il costo superano una soglia che imposti tu.

Rivedi le chiamate ogni giorno. Call History filtra per esito, motivo di disconnessione e versione dell'agente. Live Monitoring permette a un supervisore di seguire una trascrizione in tempo reale, ascoltare in silenzio o subentrare in una chiamata. La dashboard di analytics può rappresentare il tuo campo di estrazione personalizzato accanto al volume di chiamate, suddiviso per versione dell'agente, così vedi se una correzione ha spostato il dato. Se ti serve una valutazione strutturata su grandi volumi, l'AI QA di Retell valuta un campione di chiamate rispetto a criteri che definisci tu.

Chi è responsabile di cosa durante il rollout?

Un responsabile per riga. Le righe condivise sono quelle in cui i rollout si bloccano.

La riga più importante è la seconda. Se nessuno nel tuo team può modificare l'agente senza aprire un ticket, l'agente migliora alla velocità della coda di qualcun altro. In un numero crescente di team quella riga spetta a un CX automation engineer: un responsabile interno che gestisce l'agente giorno per giorno, dopo che i forward deployed engineer del fornitore hanno aiutato a sviluppare la prima versione e formato il team.

Cosa chiedere a un fornitore sull'enablement prima di firmare?

Chiedi per iscritto quale supporto è incluso nel tuo piano e chi chiamare quando lo sviluppo si blocca. Il self-service funziona quando hai uno sviluppatore interno con tempo a disposizione. Quando non ce l'hai, acquista il supporto in anticipo invece di scoprire la lacuna nella seconda settimana.

Su Retell, la pagina dei prezzi indica supporto della community e via email con il pagamento a consumo. Il piano Enterprise prevede supporto 24/7 con un portale dedicato, un account manager dedicato e il Dedicated Implementation Support come componente aggiuntivo. Se vuoi un aiuto pratico nello sviluppo da parte di terzi, la directory dei solution partner di Retell elenca partner certificati che puoi filtrare per località, lingua, integrazioni, gratuità della prima consulenza e fascia di prezzo.

Domande da porre a qualsiasi fornitore:

1. Quali canali e orari di supporto include il nostro piano, e cosa viene considerato urgente?
2. Il supporto all'implementazione è incluso, è un componente aggiuntivo o viene erogato tramite un partner? Quanto costa, ed è a prezzo fisso o definito per progetto?
3. Qualcuno esaminerà il nostro ambito, il design dell'agente e la suite di test prima del lancio graduale?
4. Chi contattiamo durante la settimana del lancio graduale se qualcosa si rompe, e con quale rapidità risponde?
5. Il nostro team può gestire in autonomia l'intero ciclo di modifica (trovare una chiamata fallita, correggerla, testarla, pubblicarla, fare il rollback) senza ticket al fornitore?
6. Come vengono comunicati gli incidenti della piattaforma?

Se stai sviluppando con un partner, come fornitori e partner di IA vocale definiscono l'ambito del primo accordo illustra la ripartizione dal loro punto di vista.

Come si valuta un pilota di IA prima di portarlo in produzione?

Valuta il pilota con una scorecard fissa dopo almeno una settimana completa di traffico reale e portalo in produzione solo quando tutte le righe vincolanti sono superate e il totale supera la soglia che hai fissato nella prima settimana. La scorecard trasforma «sembra che stia andando bene» in una di tre decisioni: espandere, fermarsi e correggere, oppure ridefinire l'ambito.

Scrivi la soglia nel documento di ambito prima del lancio graduale, così nessuno potrà abbassarla dopo aver visto i numeri. Assegna a ogni riga 0 (non soddisfatta), 1 (parzialmente soddisfatta) o 2 (soddisfatta). Le righe vincolanti devono ottenere 2 indipendentemente dal totale. Nove righe danno un massimo di 18, e 16 è una soglia predefinita ragionevole.

Valuta di nuovo a ogni aumento del traffico, perché una quota che funzionava su una piccola parte può non reggere su una più ampia. La riga del ciclo di modifica è quella che i team sono più tentati di saltare, ed è quella che decide quanto velocemente l'agente migliora in produzione. Tratta ogni modifica al prompt come una nuova versione testabile, la pratica nota come prompt versioning, così una correzione che non funziona può essere annullata in un solo passaggio.

Questa scorecard serve a portare un lancio graduale in produzione su una piattaforma che hai già scelto. Per confrontare fornitori in un pilota, usa la checklist go/no-go nella guida alla valutazione della piattaforma.

Cosa espandere per prima cosa?

Cambia una cosa alla volta. Aumenta prima la quota di traffico, poi aggiungi un secondo tipo di chiamata, poi un secondo sistema. Ogni espansione riutilizza lo stesso ciclo: ambito, sviluppo su una bozza, esecuzione della suite, lancio graduale, revisione. Trasforma ogni chiamata di produzione fallita in un nuovo caso di test, così la suite cresce in base a ciò che i chiamanti fanno davvero. Prima di aumentare bruscamente il traffico, esegui un test di carico che segua il percorso reale della chiamata.

Parti con il giusto livello di supporto

I primi 30 giorni procedono più velocemente quando decidi in anticipo quanto supporto ti serve. Confronta cosa include ogni piano di Retell nella pagina dei prezzi oppure, se nessuno nel tuo team può farsi carico dello sviluppo, trova un partner certificato nella directory dei solution partner di Retell.

Domande frequenti

Cosa significa portare un pilota di IA in produzione?

Portare un pilota di IA in produzione significa passare da una prova su una parte del traffico reale a un agente con IA che rappresenta il percorso predefinito per un tipo di chiamata, con responsabili designati, monitoraggio e un modo testato per fare il rollback. Il pilota dimostra che l'agente sa completare la chiamata. La produzione dimostra che il tuo team sa mantenerlo funzionante.

Cosa dovrebbe includere un proof of concept di IA vocale?

I tuoi casi reali più difficili, simulati al telefono dal tuo personale su record strutturati come quelli reali; criteri di successo che entrambe le parti firmano prima della prima chiamata di test; e una ripartizione scritta di chi paga l'utilizzo della piattaforma, il tempo di sviluppo e il tempo del personale. Limitalo a un elenco di casi e a una finestra temporale fissi, così si conclude con una decisione.

Si può testare un agente vocale senza inviare dati reali dei clienti al fornitore?

Sì. Riproduci invece la struttura dei record reali nei casi di test. Nei test di simulazione di Retell, ogni caso imposta i propri valori delle variabili dinamiche e i risultati simulati delle funzioni. Simula ogni funzione che raggiunge un sistema live e assegna a ogni mock un risultato, perché un mock vuoto esegue la funzione reale, e gli strumenti MCP ignorano i mock. Se devono passare dati reali, firma prima gli accordi: Retell richiede un BAA firmato prima che informazioni sanitarie protette transitino attraverso la piattaforma. Verifica le tue regole con un legale o con il tuo team compliance.

Quanto dura un pilota di IA vocale prima della produzione?

Per un tipo di chiamata, prevedi circa 30 giorni: una settimana ciascuno per ambito, sviluppo e test, poi un lancio graduale su una parte del traffico reale. Valuta il pilota dopo almeno una settimana completa di chiamate reali, e di nuovo a ogni aumento del traffico.

Come capire se un agente vocale è pronto per la produzione?

Quando ogni riga vincolante della scorecard ottiene 2 nell'arco di una settimana completa di traffico reale: la metrica di successo regge, le chiamate riviste non presentano errori critici, il tuo team ha corretto una versione e ne ha fatto il rollback senza l'aiuto del fornitore, ogni area di lavoro ha un responsabile designato e il via libera della compliance è agli atti.

Cosa fare se il pilota non rende come previsto?

Mantieni invariata la quota di traffico, oppure riporta il tag di produzione all'ultima versione funzionante. Correggi su una versione bozza, riesegui la suite di test e valuta di nuovo dopo un'altra settimana. Se la riga dell'esito o degli errori critici ottiene ancora 0 dopo due cicli di correzione, restringi il tipo di chiamata o ridefinisci il successo.