Integrare un voicebot AI col centralino esistente: trunk SIP, Microsoft Teams e cosa deve reggere la rete

Il voicebot si aggancia, non sostituisce (quasi sempre)

La domanda che arriva per prima è quasi sempre la stessa: “devo cambiare centralino?”. Nella maggior parte dei casi no. La risposta seria però è un’altra: dipende dal centralino che hai, e si decide con una verifica tecnica prima del preventivo.

Come si collega

Un voicebot AI si collega al centralino esistente come farebbe un altro apparato telefonico. Nella maggior parte dei casi basta un trunk SIP diretto, cioè un collegamento telefonico dedicato fra il centralino e la piattaforma. Quando il centralino non lo consente, perché è di una generazione precedente o non espone un collegamento utilizzabile, si interpone un voice gateway o un sistema telefonico VoIP intermedio, per esempio Asterisk, che fa da ponte. Il centralino passa al voicebot le chiamate che decidi tu, per numero chiamato, per orario o per coda. Tutto il resto, interni, gruppi, casella vocale, tabulati e telefoni sulle scrivanie, resta dove sta.

Dove si inserisce nel flusso delle chiamate

Il punto vero non è quindi “se” si integra ma “come” e “dove” si inserisce nel flusso delle chiamate. I posti possibili sono tre. Dentro il centralino, come una destinazione fra le altre, richiamata dal menu esistente, da una coda o da un orario: è il caso più frequente e quello con cui conviene partire. Dentro Microsoft Teams, quando il centralino è Teams stesso con Direct Routing. Oppure davanti al centralino, con il voicebot che risponde per primo su un numero e passa al centralino solo ciò che non risolve: succede soprattutto quando il voicebot è una funzione della piattaforma telefonica stessa, e allora è la piattaforma a fare da centralino per quel numero.

Ognuna delle tre ha conseguenze precise su chi controlla il numero, su cosa succede se il voicebot non risponde e su come si trasferisce la chiamata a una persona senza far ripetere il cliente. Il resto della guida serve a scegliere.

Il perimetro di chi integra

Netframe integra la piattaforma voicebot sul centralino del cliente e sui suoi flussi, non sviluppa il motore vocale. Il motore, il modello linguistico e la sintesi sono componenti della piattaforma. La verifica tecnica, l’integrazione, la rete, la sicurezza del perimetro telefonico e il collaudo sono il lavoro dell’integratore, ed è di questo che parliamo.

Le tre architetture a confronto

Architettura	Come funziona	Quando conviene	Cosa cambia se il voicebot non risponde
Voicebot dentro il centralino, come destinazione (il caso più frequente)	Il numero resta sul centralino, che manda al voicebot solo la coda, il menu o la fascia oraria scelta, tramite trunk SIP diretto o, se il centralino non lo consente, tramite voice gateway o sistema VoIP intermedio	Chi vuole introdurlo per fasi, partendo da un servizio o da un orario, senza toccare il numero principale	Il centralino applica il timeout e ripiega sul menu tradizionale o sulla coda: la chiamata sopravvive
Voicebot dentro Microsoft Teams, tramite SBC	Il voicebot dialoga con l’SBC del Direct Routing, che instrada le chiamate verso Teams e dal voicebot verso gli utenti Teams	Aziende con Teams come centralino, dove code e centralinista automatico stanno in cloud	La sopravvivenza dipende dalle regole dell’SBC: va configurato l’instradamento alternativo verso le code Teams
Voicebot davanti al centralino (tipico quando il voicebot è integrato nella piattaforma telefonica)	L’operatore consegna il numero alla piattaforma voicebot, che risponde per prima e inoltra al centralino ciò che non risolve	Piattaforme telefoniche che includono il voicebot, e numeri unici ad alto volume di chiamate ripetitive da presidiare 24 ore su 24	Il numero è attestato sulla piattaforma: serve un instradamento di riserva verso il centralino sull’operatore o sull’SBC, altrimenti la chiamata cade

Da quale partire

La prima architettura è quella con cui conviene partire in una PMI: si può accendere su una sola coda, misurare quante chiamate il voicebot chiude da solo e allargare dopo, con la possibilità di tornare indietro cambiando una destinazione nel centralino. Con la seconda non cambia la sostanza: è la prima applicata a Teams, con l’SBC al posto del centralino come punto di innesto e con le regole della sopravvivenza locale che valgono per tutto il Direct Routing. Nella terza, naturale quando la piattaforma telefonica include il voicebot, la piattaforma risponde per prima sul numero e passa alle code o agli interni ciò che non risolve; la sopravvivenza va progettata dentro la stessa piattaforma.

Centralino per centralino

Con 3CX, FreePBX e PBXact, Asterisk e Alcatel-Lucent Enterprise il collegamento è di norma un trunk SIP configurato da entrambe le parti. I centralini che non lo consentono passano da un voice gateway o da un sistema VoIP intermedio. Per Microsoft Teams si usano gli SBC qualificati AudioCodes o Patton già in uso per il Direct Routing.

Cosa succede in una chiamata, dal primo squillo al trasferimento

Seguire una chiamata dall’inizio alla fine è il modo più rapido per capire cosa può andare storto. Il centralino passa la chiamata al voicebot come la passerebbe a un interno. Dentro la piattaforma la voce del chiamante passa dal riconoscimento vocale al modello linguistico e torna come voce sintetizzata: tre motori in cascata, e la somma dei loro tempi è la pausa che il chiamante sente prima della risposta. Se il chiamante parla sopra alla risposta, il sistema deve interrompersi e ascoltare: è il barge-in, e un voicebot senza barge-in in una chiamata di lavoro non regge.

Il trasferimento a una persona

Il momento delicato è il trasferimento a una persona. La chiamata passa a un interno o a una coda come una normale chiamata interna e il voicebot esce di scena. L’alternativa, con il voicebot che resta in linea come ponte fra chiamante e operatore, tiene occupati due canali per una sola chiamata e si usa solo quando serve davvero. Il punto è come passa il contesto: la trascrizione, la richiesta riconosciuta, il numero pratica già raccolto. Il contesto non viaggia dentro la telefonata. Viaggia in parallelo, con una scheda che si apre sul desktop dell’operatore o nel CRM al momento del trasferimento, tramite le API della piattaforma. Chi promette “il contesto passa con la chiamata” senza spiegare dove atterra sta descrivendo il tono di attesa.

I tasti servono ancora

Ultimo dettaglio che decide molte richieste di assistenza: i tasti. Anche con un voicebot in linguaggio naturale servono i toni del tastierino, per chi non vuole o non può parlare e come uscita di sicurezza verso l’operatore. Non tutte le tratte li trasportano allo stesso modo, quindi vanno provati in collaudo su ogni percorso della chiamata.

Cosa deve reggere la rete

Un voicebot è, per la rete, un insieme di chiamate VoIP contemporanee: valgono le stesse regole del centralino, con due aggiunte. Le regole di sempre: canali dimensionati sulle chiamate contemporanee e non sugli interni, con la formula di Erlang B sul traffico dell’ora di punta e la stima di orientamento di un canale ogni quattro-sei interni; circa 100 kbps per chiamata con il codec più diffuso; priorità alla voce sulla rete e sull’uplink; soglie della raccomandazione ITU-T G.114 sulla latenza (150 ms in una direzione) e jitter sotto i 30 ms. I sintomi di una rete che non regge sono quelli di sempre, dall’audio unidirezionale alla voce a scatti, e sono descritti nella guida ai problemi audio VoIP.

La prima aggiunta: la qualità dell’audio che arriva al voicebot

Il riconoscimento vocale lavora meglio con audio a banda larga, cioè in alta definizione. Dove piattaforma e centralino lo consentono conviene far arrivare al voicebot l’audio HD e lasciare la conversione verso il formato dell’operatore telefonico solo sull’ultimo tratto. Si decide in fase di verifica tecnica, perché dipende dal centralino e dalla piattaforma.

La seconda aggiunta: il firewall

Se la piattaforma è in cloud, il collegamento attraversa internet e va cifrato, e il firewall deve esporre alla piattaforma solo ciò che serve, mai un collegamento aperto a tutti. Un controllo da fare sempre in fase di progetto è quello sui filtri del protocollo SIP del firewall: in molti apparati sono attivi per impostazione predefinita e interferiscono con le chiamate, ed è una delle cause più frequenti di audio da una sola parte e chiamate che cadono. Vale la regola già scritta per la configurazione sicura di un SBC: chi telefona dall’esterno passa dal perimetro, non lo salta. Se la piattaforma è installata in sede su macchina virtuale, il collegamento resta interno e i vincoli si spostano su banda, priorità e VLAN della voce, come per qualsiasi altro server telefonico.

Continuità: se il voicebot non risponde, chi risponde?

È la domanda da fare prima di firmare, e la risposta dipende dall’architettura scelta. Con il voicebot dentro il centralino la sopravvivenza è gratis: timeout sulla destinazione e ripiego sulla coda o sul menu di prima, chiamata salva. Lo stesso vale per Teams, sulle regole dell’SBC. Se invece il voicebot è davanti al centralino, o integrato nella piattaforma telefonica, la sopravvivenza va costruita: un instradamento alternativo sull’operatore o sull’SBC entra in gioco quando la piattaforma non risponde entro pochi secondi, e va provato staccando davvero il voicebot durante il collaudo.

Servono anche gli orari e le eccezioni: fuori orario il voicebot può rispondere ma non trasferire, e deve dirlo; nei giorni di chiusura deve saperlo prima del chiamante. E serve un punto di osservazione. Le chiamate ricevute, quelle chiuse in autonomia, quelle trasferite e quelle abbandonate, con i tempi, sono i numeri su cui si decide se allargare il perimetro. Senza quei numeri il progetto resta un’opinione.

Dati, log e conformità

Tre obblighi entrano nel progetto e vanno chiusi prima dell’accensione, non dopo. Il primo è la trasparenza dell’articolo 50 del Regolamento (UE) 2024/1689, applicabile dal 2 agosto 2026: chi interagisce con un sistema di intelligenza artificiale deve esserne informato, salvo che sia evidente dal contesto, e le linee guida della Commissione del 20 luglio 2026 chiedono di leggere l’eccezione in modo restrittivo. L’obbligo di progettare il sistema in modo trasparente è del fornitore della piattaforma; l’azienda che lo utilizza deve poter dimostrare che l’avviso c’è, arrivi prima di qualsiasi raccolta di informazioni e sia comprensibile. In pratica: la dichiarazione va nel messaggio di apertura, il barge-in non deve permettere di saltarla, e la configurazione va documentata.

Il secondo è la protezione dei dati: registrazioni e trascrizioni contengono dati personali, quindi informativa, base giuridica, tempi di conservazione e controllo degli accessi vanno decisi prima, insieme a dove i dati vengono elaborati. Se sono coinvolti gli operatori, valgono anche le tutele dell’articolo 4 dello Statuto dei lavoratori. Il terzo, per chi rientra nel perimetro NIS2, è la tracciabilità: il voicebot diventa un sistema che tocca dati e processi, e i suoi log entrano nelle misure di gestione del rischio dell’articolo 24 del D.Lgs. 138/2024, come per ogni altro sistema in rete.

Il collaudo in cinque prove

Prova	Cosa si verifica	Cosa deve succedere
Chiamata base	Risposta, audio nelle due direzioni, chiusura	Nessun audio da una sola parte, nessuna caduta dopo pochi secondi
Interruzione	Il chiamante parla sopra la risposta	Il voicebot si ferma e ascolta entro una frazione di secondo
Trasferimento con contesto	Passaggio a un operatore reale	La chiamata arriva, la scheda si apre, il cliente non ripete
Tasti	Pressione dei tasti durante la conversazione	I toni arrivano e attivano l’uscita verso l’operatore
Caduta del voicebot	Piattaforma spenta durante il collaudo	La chiamata ripiega sul menu o sulla coda entro il timeout previsto

Le cinque prove vanno fatte da fuori, da un cellulare e da un fisso, e ripetute dopo ogni modifica al centralino, perché è lì che i progetti si rompono mesi dopo.

Gli errori che si vedono più spesso

• Il collegamento verso il voicebot lasciato senza cifratura “perché tanto è provvisorio”.
• I filtri SIP del firewall lasciati attivi, con l’audio che sparisce da una parte sola.
• Il timeout di risposta troppo lungo, con dieci secondi di silenzio prima del ripiego.
• Il contesto promesso e non consegnato, con l’operatore che chiede “mi ridice il nome?”.
• La dichiarazione di trasparenza dopo la prima domanda invece che prima.
• La misura mai impostata, con il progetto che a tre mesi non sa dire quante chiamate ha chiuso.

Da dove si parte

Dalla verifica tecnica del centralino: quale sistema, quale versione, se espone un trunk SIP utilizzabile o serve un voice gateway, come è attestato il numero, quante chiamate contemporanee ha davvero nell’ora di punta, e quali code o orari valgono la prima fase. Nelle aziende che lavorano su appuntamento la prima fase è quasi sempre la prenotazione, e lì conta anche l’aggancio all’agenda: il caso è trattato nella guida al voicebot per prenotazioni e appuntamenti. Poi la scelta dell’architettura, il collegamento, il collaudo con le cinque prove e un mese di misura prima di allargare. Netframe è un system integrator IT dell’Emilia-Romagna con sede a Modena: integriamo voicebot AI e centralino intelligente sul centralino esistente, VoIP aziendale o Microsoft Teams Direct Routing, e seguiamo progetti in tutta Italia. Il confronto fra le piattaforme, con 3CX, Yeastar, Kalliope, Mercury Welcome Center e Microsoft Teams, è nella guida al centralino con intelligenza artificiale; le architetture della telefonia aziendale nella guida all’integrazione della telefonia aziendale; i costi a consumo dei moduli AI nella guida su quanto costa un centralino cloud.

Domande frequenti

Devo cambiare centralino per avere un voicebot AI?

Nella maggior parte dei casi no. Il voicebot si collega al centralino esistente, di solito con un trunk SIP diretto; se il centralino non lo consente si interpone un voice gateway o un sistema telefonico VoIP intermedio, e con Microsoft Teams si passa dall’SBC del Direct Routing. Serve però una verifica tecnica del centralino prima del preventivo: è lì che si decide come collegarlo e dove inserirlo nel flusso delle chiamate.

Funziona anche se il mio centralino è Microsoft Teams?

Sì, se Teams usa il Direct Routing: il voicebot dialoga con l’SBC, che instrada le chiamate verso Teams e dal voicebot verso gli utenti. Con Calling Plan e Operator Connect non c’è un SBC in azienda, quindi l’aggancio va fatto a monte, sull’operatore, o con una piattaforma che si integra direttamente con Teams.

Come passa la chiamata all’operatore senza far ripetere il cliente?

La chiamata si trasferisce come una normale chiamata interna; il contesto viaggia in parallelo, con una scheda che si apre sul desktop dell’operatore o nel CRM al momento del trasferimento, tramite le API della piattaforma. Il contesto non è dentro la telefonata: chiedi sempre dove atterra.

Quanti canali servono per il voicebot?

Si contano sulle chiamate contemporanee dell’ora di punta, come per il centralino: la formula di Erlang B dà il numero preciso, la stima di orientamento è un canale ogni quattro-sei interni. Un voicebot che risponde a un numero molto chiamato può assorbire picchi che il centralino non vedeva, quindi il traffico va misurato prima, non stimato.

Il voice bot deve dire che è un’intelligenza artificiale?

Sì. Dal 2 agosto 2026 si applica l’articolo 50 dell’AI Act: chi chiama deve esserne informato prima di qualsiasi raccolta di informazioni. Il fornitore della piattaforma deve progettare il sistema in modo trasparente; l’azienda che lo utilizza deve poter dimostrare che l’avviso c’è, e nei progetti che seguiamo lo configuriamo nel messaggio di apertura, lo verifichiamo in collaudo e lo documentiamo.

Fonti

• ITU-T, Raccomandazione G.114, One-way transmission time
• Regolamento (UE) 2024/1689 (AI Act), articolo 50, e linee guida della Commissione europea del 20 luglio 2026
• Normattiva, Decreto legislativo 4 settembre 2024, n. 138 (testo vigente), articolo 24
• Microsoft Learn, Plan Direct Routing
• Documentazione dei produttori dei centralini citati (3CX, FreePBX e PBXact, Asterisk, Alcatel-Lucent Enterprise) e della piattaforma voicebot integrata sui trunk SIP, sui gateway e sull’autenticazione, citata in forma descrittiva

Fonti verificate il 18 agosto 2026.

Nota di indipendenza: Netframe è un system integrator indipendente e multi-vendor. È certificata 3CX, AudioCodes e Patton; Microsoft e Alcatel-Lucent Enterprise sono technology partner; la piattaforma voicebot Mercury è integrata, installata e personalizzata da Netframe senza rapporti di rivendita esclusiva. Gli altri produttori citati sono nominati a titolo di confronto e non hanno rapporti commerciali con Netframe.