Le chiamate outbound AI permettono di automatizzare parti del processo di contatto, qualificazione e follow-up. Non sostituiscono però il disegno del processo: prima del volume servono una lista utilizzabile, regole di contatto verificabili, un obiettivo misurabile e una gestione affidabile degli esiti.
In una campagna ben progettata, il voice agent non si limita ad avviare conversazioni. Sa quali informazioni può usare, quali domande può porre, quando deve fermarsi, quando deve trasferire la chiamata a una persona e quale esito deve scrivere nel CRM.
Nota di perimetro: questa guida distingue l’architettura tecnica dalla valutazione di privacy e telemarketing. La seconda richiede verifica caso per caso da parte del titolare del trattamento e dei referenti legali/compliance prima del go-live.
Casi d’uso compatibili con un workflow controllato
Un progetto può riguardare, ad esempio:
- richiamo di lead che hanno richiesto un contatto;
- qualificazione di richieste ricevute da form, eventi o campagne;
- follow-up su appuntamenti, preventivi o pratiche aperte;
- promemoria e conferme operative verso clienti esistenti;
- fissazione di appuntamenti, con disponibilità verificata sul calendario;
- trasferimento a un operatore quando emergono interesse, complessità o richiesta esplicita.
Il caso d’uso non rende automaticamente lecito il contatto. Stabilisce soltanto il workflow tecnico da sottoporre a verifica.
L’architettura di una campagna outbound concorrente
Quando il volume aumenta, la difficoltà non è soltanto far partire molte chiamate. Occorre coordinare l’avvio, evitare duplicazioni, mantenere coerente lo stato del contatto e non saturare agenti umani, webhook, CRM o infrastruttura SIP.
Un’architettura concettuale può essere composta da questi blocchi:
- Registro di eleggibilità: contiene i contatti candidati, la campagna, le finestre di contatto, le esclusioni e le evidenze operative necessarie.
- Motore di pacing: decide quante nuove chiamate possono essere avviate in base a CPS, concorrenza, capacità del voice agent, code e disponibilità degli operatori.
- Coda di lavoro: conserva le chiamate pronte ma non ancora originate, senza trattare la coda come prova che il contatto sia stato effettivamente chiamato.
- Macchina a stati del contatto: mantiene uno stato persistente per contatto e campagna, separato dagli eventi temporanei del provider.
- Orchestratore conversazionale: applica script, regole di escalation, limiti alle azioni e raccolta dell’outcome.
- Gateway eventi e webhook: riceve callback, valida il mittente, deduplica i retry e aggiorna i sistemi a valle.
- CRM e sistemi di blocco: ricevono outcome, appuntamenti, richieste di richiamo e richieste di non ricontatto.
- Osservabilità e controllo qualità: unisce dati di capacità, telefonia, conversazione, integrazione e compliance operativa.
La regola utile è semplice: un evento telefonico non è ancora un outcome di business, e un outcome di business non deve dipendere da un singolo webhook non verificato.
CPS, concorrenza e coda: tre limiti diversi
Per pianificare una campagna vanno distinti almeno tre parametri:
- CPS (Calls Per Second): il tasso al quale è possibile avviare nuove chiamate;
- concorrenza: il numero totale di chiamate attive nello stesso momento, comprese quelle in squillo, connesse, trasferite o in chiusura;
- profondità della coda: quante chiamate attendono l’avvio o un passaggio del workflow.
Nella documentazione Twilio per Programmable Voice, le chiamate create tramite API sono soggette a un limite CPS a livello account; quelle oltre soglia vengono accodate. Il valore predefinito indicato è 1 CPS e gli account con Business Profile approvato possono modificare autonomamente il CPS fino a 5 dalla Console. Il parametro queue_time rappresenta una stima dell’attesa prima dell’esecuzione della chiamata. Questi valori sono specifici della piattaforma e vanno confermati sul singolo account prima della produzione.
La concorrenza non coincide con il CPS. Se una campagna avvia poche chiamate al secondo ma le conversazioni, gli squilli o i trasferimenti durano a lungo, il numero di chiamate simultanee può crescere rapidamente. Anche la rilevazione della segreteria telefonica, i timeout e le code verso operatori incidono sulla capacità richiesta.
Pacing: una politica, non un numero fisso
Un motore di pacing dovrebbe calcolare nuove chiamate solo quando sono rispettati contemporaneamente:
- il CPS disponibile sul provider;
- il tetto di chiamate concorrenti definito per la campagna;
- la capacità dell’applicazione di gestire nuove sessioni vocali;
- la disponibilità di operatori o code di trasferimento, se previste;
- le finestre temporali e le regole di frequenza di contatto;
- l’assenza di stop tecnici o di compliance.
È prudente prevedere una modalità di rallentamento automatico. Per esempio, il pacing può ridursi o fermarsi se crescono la coda del provider, gli errori webhook, i trasferimenti senza risposta, le richieste di opposizione o gli errori di sincronizzazione CRM.
Stato persistente del contatto: impedire doppie chiamate e retry impropri
Ogni contatto deve avere uno stato persistente, cioè registrato in un archivio affidabile e non ricostruito soltanto dai log della telefonia. Lo stato va modellato per campagna o finalità, non soltanto per numero di telefono.
Una macchina a stati essenziale può includere:
| Stato | Significato operativo |
|---|---|
eligible | Il contatto è candidato, dopo le verifiche previste dal processo. |
reserved | Un worker ha riservato il contatto per impedire che altri worker lo chiamino. |
queued | La richiesta di chiamata è stata accettata o è in attesa sul provider. |
dialing | La chiamata è stata avviata o sta squillando. |
connected | La chiamata è connessa; non implica necessariamente che abbia risposto una persona. |
in_conversation | Il voice agent o l’operatore sta gestendo l’interazione. |
handoff_pending | È in corso il trasferimento a un operatore, endpoint SIP o coda. |
completed | Il tentativo è terminato e l’esito tecnico è acquisito. |
business_outcome_recorded | L’outcome strutturato è stato validato e scritto nel CRM. |
suppressed | Il contatto non deve ricevere ulteriori tentativi per la specifica regola di blocco. |
Lo stato reserved è particolarmente utile nelle campagne concorrenti. Prima di chiamare, un solo worker deve ottenere una prenotazione atomica con scadenza. Se il worker fallisce, la prenotazione scade e il contatto torna valutabile senza creare un blocco permanente.
Chiavi di deduplicazione consigliate
Per non associare due tentativi allo stesso evento, è utile conservare almeno:
- ID interno del contatto;
- ID della campagna e della specifica ondata di contatto;
- ID del tentativo;
- ID della chiamata assegnato dal provider, quando disponibile;
- chiave di idempotenza dell’operazione applicativa;
- versione dello script o del workflow eseguito;
- timestamp di creazione, aggiornamento e ultima transizione di stato.
La blacklist o la richiesta di non ricontatto deve prevalere sul resto della macchina a stati. Non deve attendere la fine di batch, retry o sincronizzazioni differite.
Webhook e retry: progettare per consegne ripetute
I webhook sono eventi HTTP inviati dal provider alla vostra applicazione. Per una chiamata outbound possono aggiornare lo stato di avanzamento, ad esempio avvio, squillo, risposta e completamento.
Nella documentazione Twilio, gli status callback delle chiamate Programmable Voice possono essere configurati per gli eventi initiated, ringing, answered e completed. Lo stato finale può includere esiti quali completata, occupato, nessuna risposta, fallita o annullata. Una chiamata tecnicamente completata indica che è stata stabilita una connessione e trasmesso audio, ma può essere stata risposta anche da un IVR o da una segreteria: non è una prova sufficiente di conversazione utile.
Regole per webhook idempotenti
Il receiver deve essere progettato assumendo che un evento possa arrivare più di una volta, fuori ordine o dopo un temporaneo errore di rete.
- Verificare autenticità e integrità prima di elaborare l’evento. Per Twilio, la documentazione raccomanda HTTPS e la validazione della firma
X-Twilio-Signaturecon le librerie ufficiali. - Registrare l’evento ricevuto con payload minimizzato, ID del provider, timestamp e hash del contenuto, nel rispetto delle policy di retention.
- Deduplicare su una chiave coerente, ad esempio provider + ID chiamata + tipo evento + identificatore di consegna, se disponibile.
- Applicare transizioni di stato ammesse, senza far retrocedere impropriamente uno stato terminale per un callback tardivo.
- Separare ricezione e lavori lenti: il receiver valida, salva e risponde; elaborazioni non real-time passano a una coda interna.
- Rispondere in tempi compatibili con il flusso vocale. Twilio segnala un limite massimo di 15 secondi per le richieste HTTP legate all’elaborazione della chiamata.
- Riconciliare periodicamente gli stati interni con i dati del provider, per intercettare webhook persi o anomalie.
Twilio documenta opzioni di retry per callback HTTP e indica l’header I-Twilio-Idempotency-Token per distinguere tentativi ripetuti. Questa funzionalità non elimina la necessità di una deduplicazione applicativa: il sistema deve restare corretto anche se una richiesta viene ricevuta più volte.
Trasferimento a operatore: definire prima il punto di passaggio
Il trasferimento non dovrebbe essere una risposta generica dell’agente a qualsiasi incertezza. Va modellato come una transizione controllata, con criteri, disponibilità e fallback.
Esempi di trigger:
- richiesta esplicita di parlare con una persona;
- domanda che richiede valutazione contrattuale, tecnica o commerciale non prevista;
- segnale di vulnerabilità, reclamo o contestazione;
- impossibilità di confermare un’informazione con una fonte o un sistema autorizzato;
- esito qualificato che richiede intervento umano;
- errore del voice agent o degrado della qualità conversazionale.
Con Twilio, il verbo TwiML `` consente di connettere una chiamata attiva a un’altra parte, inclusi numero telefonico ed endpoint SIP. Per un endpoint SIP, è possibile usare il trasporto TLS; la progettazione deve comunque verificare compatibilità di PBX/SBC, routing, codec, timeout e gestione degli errori.
Fallback del trasferimento
Ogni handoff deve specificare:
- gruppo o destinazione di trasferimento;
- timeout massimo di attesa;
- messaggio da usare durante l’attesa;
- comportamento se nessun operatore risponde;
- se e quando proporre un richiamo;
- outcome da registrare nel CRM;
- regola che impedisce all’agente AI di riprendere una conversazione non autorizzata dopo un handoff fallito.
È utile tracciare separatamente handoff_requested, handoff_answered, handoff_failed e handoff_abandoned. Altrimenti un tasso di completamento apparentemente buono può nascondere trasferimenti inefficaci.
SIP e sicurezza del percorso vocale
Quando l’architettura integra PBX, contact center, SBC o endpoint SIP, la chiamata va considerata come un percorso composto da segnalazione e media, non come una semplice API.
Per le integrazioni SIP con Twilio, la documentazione descrive l’uso di TLS per la segnalazione e di SRTP per i pacchetti media nella modalità Secure Media. Se abilitata, la modalità richiede negoziazione cifrata e rifiuta le chiamate che non soddisfano il requisito. Per SIP in uscita, la documentazione indica l’uso di transport=tls e del parametro secure=true per proteggere rispettivamente segnalazione e media nel contesto supportato.
Controlli tecnici minimi:
- separare endpoint, credenziali e numerazioni tra test e produzione;
- documentare il percorso della chiamata e il punto di trasferimento a operatore;
- usare un SBC o controlli equivalenti quando richiesto dal contesto;
- limitare l’accesso con ACL, allowlist, credenziali e rotazione dei segreti;
- testare NAT, media unidirezionale, codec, DTMF, timeout e failover;
- non esporre dati personali non necessari in URI, header SIP, log o strumenti di debug;
- verificare certificati, catena di fiducia e compatibilità TLS dell’infrastruttura coinvolta.
Controllo qualità: misurare il processo, non solo le chiamate concluse
La qualità va osservata su quattro livelli distinti.
| Livello | Domande da monitorare |
|---|---|
| Telefonia | Le chiamate entrano in coda? Squillano? Cadono? Arriva audio bidirezionale? |
| Conversazione | L’agente si identifica correttamente, segue i limiti dello script e riconosce stop/escalation? |
| Operazioni | CRM, calendario e sistemi di blocco ricevono dati completi, una sola volta e nel tempo previsto? |
| Compliance operativa | Le opposizioni e le esclusioni bloccano davvero i nuovi tentativi? Il caller ID è quello approvato? |
Un set iniziale di indicatori può includere:
- CPS effettivo e
queue_time; - chiamate concorrenti per stato;
- tasso di esiti
busy,no-answer,failedecanceled; - durata di squillo e durata di conversazione;
- rilevazioni di segreteria, se utilizzate, tenendo conto dei possibili falsi positivi e negativi;
- tasso e tempo di completamento dei trasferimenti;
- percentuale di outcome CRM mancanti, duplicati o non classificati;
- richieste di non ricontatto e tempo di propagazione al sistema di blocco;
- errori di firma, validazione, retry e processamento webhook;
- campioni di conversazione valutati secondo una griglia approvata.
Non esiste un benchmark universale affidabile per questi indicatori: dipendono da settore, lista, Paese, orari, script, canale di trasferimento e finalità della campagna. Conviene definire una baseline in ambiente controllato e rilasciare il volume per incrementi.
Test pre-rilascio: cosa verificare prima di aumentare il volume
Il go-live non dovrebbe coincidere con il primo test reale. Prima del rilascio, un piano di collaudo dovrebbe includere:
- Test di eleggibilità: contatti esclusi, opposizioni e limiti di frequenza non devono arrivare alla coda di chiamata.
- Test di concorrenza: verificare riserve atomiche, scadenze e assenza di doppie origination con più worker attivi.
- Test di saturazione controllata: simulare CPS insufficiente, code e indisponibilità degli operatori senza perdere stato.
- Test webhook: eventi duplicati, ritardati, fuori ordine, firma non valida e indisponibilità temporanea del receiver.
- Test di handoff: trasferimento riuscito, timeout, operatore non disponibile, caduta della chiamata e logging dell’esito.
- Test conversazionale: identificazione, domande consentite, richieste di stop, richiesta di operatore, silenzio, segreteria, accenti e pronunce rilevanti.
- Test CRM: una chiamata deve produrre un solo outcome coerente, senza sovrascrivere informazioni più recenti.
- Test di rollback: sospensione della campagna, stop immediato dei nuovi tentativi e riconciliazione delle chiamate già in corso.
Il rilascio progressivo è preferibile a un aumento immediato di CPS o concorrenza. Ogni incremento dovrebbe avere soglie di stop, un proprietario operativo e una procedura esplicita per rientrare a un volume sicuro.
Checklist legale e privacy da validare prima del go-live
Questa sezione non determina la liceità di una campagna concreta. Le chiamate per marketing, teleselling o finalità promozionali possono coinvolgere disciplina privacy, Registro pubblico delle opposizioni, regole di identificazione della linea chiamante, ruoli nella filiera e ulteriori obblighi settoriali.
Il Garante indica che il Registro pubblico delle opposizioni è esteso ai numeri nazionali fissi e mobili, inclusi quelli riservati, e che l’iscrizione annulla i consensi al telemarketing e alla cessione a terzi precedentemente rilasciati per finalità promozionali. In un provvedimento del 14 maggio 2026, il Garante ha richiamato la necessità di un idoneo consenso per il telemarketing, salvo il caso previsto per numerazioni in elenco non iscritte al RPO, e ha ribadito l’obbligo di controllo del titolare anche quando i contatti provengono da fornitori terzi.
AGCOM ha aggiornato nel 2026 la disciplina del Piano nazionale di numerazione con misure rivolte alla trasparenza dell’identificativo chiamante e al contrasto del CLI spoofing. La numerazione e il caller ID della campagna devono quindi essere verificati sul flusso e sul Paese effettivi, non dedotti dal solo setup tecnico del provider.
Prima dell’avvio, il titolare e i referenti legal/compliance dovrebbero approvare almeno:
- Finalità e classificazione del contatto: assistenza, richiamo richiesto, marketing, ricerca, teleselling o altra attività.
- Qualificazione del canale: operatore umano, processo automatizzato, messaggio preregistrato, voce sintetica o combinazione di queste modalità.
- Origine e qualità della lista: provenienza, informativa, consensi, opposizioni, trasferimenti e verifiche sul fornitore di contatti.
- RPO e liste interne di blocco: procedura applicabile, data e risultato delle verifiche, perimetro delle numerazioni e conservazione della relativa evidenza.
- Gestione dell’opposizione: frase di uscita, canale per esercitare i diritti, responsabilità, tempi e propagazione tecnica del blocco a tutti i sistemi.
- Identificativo chiamante: titolarità, richiamabilità, coerenza con gli obblighi applicabili e assenza di configurazioni che possano produrre spoofing o identificativi fuorvianti.
- Trasparenza della chiamata: identità del soggetto nel cui interesse avviene il contatto, finalità, rinvio all’informativa completa ed eventuale informazione sull’uso di AI, registrazione o trascrizione quando pertinente.
- Registrazioni e trascrizioni: necessità, base e modalità di trattamento da verificare, accessi, retention, sicurezza, fornitori e trasferimenti.
- Ruoli contrattuali: titolare, responsabili, sub-responsabili, istruzioni documentate, audit, gestione degli incidenti e disponibilità delle evidenze.
- Approvazione del go-live: script, flussi di stop, test, numerazioni, dashboard, piano di escalation e proprietari del processo.
Se uno di questi punti non è chiuso, la scelta prudente è non aumentare il volume e mantenere la pagina di campagna in revisione operativa e legale.
In sintesi
Una campagna outbound AI sostenibile non dipende soltanto dalla capacità di generare molte chiamate. Dipende dalla coerenza tra eleggibilità del contatto, pacing, stato persistente, eventi idempotenti, trasferimento a operatore, controllo qualità e blocchi efficaci.
La parte tecnica può rendere il processo più tracciabile e controllabile. Non sostituisce però la verifica delle condizioni che consentono il contatto, né trasferisce al provider tecnologico le responsabilità del titolare o degli altri soggetti coinvolti nella filiera.
Fonti
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.garanteprivacy.it
- www.garanteprivacy.it
- www.garanteprivacy.it
- www.garanteprivacy.it
- www.garanteprivacy.it
- www.garanteprivacy.it
- garanteprivacy.it
- www.twilio.com
- www.twilio.com
- www.garanteprivacy.it
- www.twilio.com
- www.twilio.com
- www.garanteprivacy.it
- www.agcom.it
- garanteprivacy.it
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.agcom.it
- www.garanteprivacy.it
- www.agcom.it
- www.twilio.com
- help.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com
- eur-lex.europa.eu
- docs-resources.prod.twilio.com
- docs-resources.prod.twilio.com
- www.twilio.com
- www.twilio.com
- www.twilio.com