Integrazione CTI con SAP Sales Cloud V2: una guida tecnica

Un cliente chiama. Prima ancora che un collega risponda, nome, azienda e questioni aperte del chiamante dovrebbero essere già sullo schermo, e a fine chiamata la conversazione dovrebbe risultare registrata nel CRM senza che nessuno debba digitare nulla. Questo è il CTI (computer telephony integration). Il concetto è semplice; l’implementazione ha più parti in movimento di quanto la maggior parte delle persone si aspetti.

SAP Sales Cloud V2 e Service Cloud V2 condividono un Agent Desktop che può ospitare un widget CTI di un fornitore terzo. SAP descrive questo framework nella guida SAP Service Cloud Version 2 integration with Third-Party CTI Providers. Ciò che SAP non fornisce è il collegamento al vostro sistema telefonico: quello strato va costruito o acquistato. Noi abbiamo fatto entrambe le cose, e il nostro prodotto Engage CTI ne è il risultato. Questa guida descrive l’architettura e i punti in cui i progetti tendono a incepparsi.

In sintesi: un’integrazione CTI con SAP Sales Cloud V2 ha quattro parti: il sistema telefonico, un middleware (nel nostro caso su SAP BTP), le API di V2 per il riconoscimento del chiamante e la registrazione delle chiamate, e un widget nell’Agent Desktop che comunica con la shell tramite payload XML. Le decisioni più importanti: inviare gli eventi via WebSocket invece del polling, normalizzare i numeri di telefono nel formato E.164 su entrambi i lati, mantenere una cache di ricerca perché lo screen pop arrivi entro circa due secondi e gestire il consenso alla registrazione secondo il diritto svizzero.

Che cos’è il CTI e perché conta per Sales Cloud V2?

Senza CTI ogni chiamata inizia con una ricerca: chi è, quale account, c’è un caso aperto? Dopo la chiamata qualcuno deve creare a mano l’attività telefonica, e spesso nessuno lo fa. Il CTI elimina entrambi i passaggi. Il chiamante viene riconosciuto prima della risposta e l’attività viene registrata automaticamente.

Un’integrazione CTI con SAP Sales Cloud V2 ha quattro componenti.

Sistema telefonico. Il vostro centralino o la telefonia cloud, per esempio Microsoft Teams Phone, un softphone nel browser come Twilio Voice o un centralino basato su SIP. È qui che avvengono le chiamate.

Middleware CTI. Un componente lato server che collega telefonia e CRM. Traduce gli eventi telefonici (chiamata in arrivo, connessa, terminata) in azioni CRM (screen pop, creazione dell’attività). Nella nostra architettura gira su SAP BTP.

API di Sales Cloud V2. Le API REST con cui si trovano contatti, clienti privati e account tramite il numero di telefono, si legge il contesto dell’account e si creano le attività telefoniche.

Widget nell’Agent Desktop. Un componente di interfaccia nell’Agent Desktop con i comandi di chiamata (rispondere, mettere in attesa, trasferire, chiudere) e le informazioni sul chiamante. Gira in un frame e comunica con la shell tramite l’API del browser postMessage.

Come attraversa il sistema una chiamata in arrivo?

L’obiettivo per l’intero flusso, dallo squillo al contesto del chiamante sullo schermo, è sotto i due secondi. Se ci vuole di più, gli utenti smettono di fidarsi.

1. La chiamata arriva al sistema telefonico, che invia un evento al middleware via webhook o WebSocket.
2. Il middleware cerca il numero del chiamante in Sales Cloud V2. Engage CTI cerca su tre livelli e vince la prima corrispondenza: contatti, poi clienti privati, poi account.
3. Il middleware invia il contesto del chiamante (nome, account, casi aperti, interazioni recenti) al widget tramite WebSocket.
4. Il widget avvisa la shell dell’Agent Desktop, che mostra lo screen pop e apre il record corrispondente.
5. Quando la chiamata termina, il middleware crea in V2 un’attività telefonica con direzione, durata, partecipanti e note.

I due secondi non sono arbitrari. Corrispondono all’incirca al momento in cui il collega chiederebbe altrimenti chi sta chiamando. Uno screen pop che arriva dopo viene ignorato.

Il lato Agent Desktop del passaggio 4 ha regole che la guida pubblica non rende evidenti: la shell interpreta solo XML, riconosce solo le azioni NOTIFY ed END e identifica una sessione unicamente tramite il suo ID di riferimento. Le abbiamo documentate in screen pop nativo nell’Agent Desktop di SSCV2.

Quali sono le decisioni tecniche più importanti?

WebSocket o polling?

Il widget ha bisogno degli eventi di chiamata in tempo reale. Interrogare il middleware ogni secondo genera carico e aggiunge comunque ritardo. Una connessione WebSocket consegna gli eventi nel momento in cui si verificano.

Su BTP gestiamo un server WebSocket (Node.js) che mantiene una connessione con ogni sessione attiva dell’Agent Desktop. Quando arriva un evento dal sistema telefonico, viene inviato subito alla connessione della persona giusta.

Perché non Server-Sent Events? Funzionano per lo streaming in una direzione, ma il CTI è bidirezionale: il widget invia comandi (attesa, trasferimento, fine chiamata). WebSocket gestisce entrambe le direzioni su una sola connessione.

Come si gestisce il confronto dei numeri di telefono?

Sembra semplice e non lo è. Lo stesso numero arriva come +41 44 123 45 67, 044 123 45 67 o 0041441234567. Il middleware deve normalizzare prima di cercare.

Normalizziamo nel formato internazionale E.164 (+41441234567). Sales Cloud V2 memorizza i numeri così come gli utenti li hanno inseriti, quindi i formati nel CRM sono disomogenei. Normalizzate entrambi i lati: il numero in arrivo e i numeri memorizzati con cui lo confrontate. Chi salta il lato memorizzato ottiene corrispondenze che falliscono senza motivo apparente, e il supporto passa molto tempo a cercarle.

Mantenete un indice di ricerca. Interrogare l’API di V2 con ricerche jolly sui numeri a ogni chiamata è troppo lento per un budget di due secondi. Il nostro middleware mantiene una tabella di ricerca che associa i numeri normalizzati ai record di V2 e la aggiorna quando i record cambiano.

Come funziona l’autenticazione?

Il widget gira nella sessione dell’Agent Desktop dell’utente; il middleware chiama le API di Sales Cloud V2 per suo conto. Usiamo i servizi di identità di SAP su BTP (l’AppRouter con XSUAA) e l’identity provider del cliente, così nessuno deve accedere una seconda volta.

L’autenticazione tra telefonia e middleware dipende dal fornitore: chiavi API per alcuni, OAuth per servizi cloud come Microsoft Teams. Il middleware incapsula tutto dietro un’unica interfaccia di adattatore: collegare un altro sistema telefonico significa scrivere un adattatore. Il lato V2 resta invariato.

Cosa viene registrato a fine chiamata?

Ogni chiamata crea un’attività telefonica in Sales Cloud V2. Registriamo:

• Direzione: in entrata, in uscita, persa
• Durata: inizio, fine, tempo di conversazione
• Partecipanti: chiamante, chiamato, eventuali persone a cui la chiamata è stata trasferita
• Contesto dell’account: quale account o contatto è stato riconosciuto
• Note: inserite dall’utente nel widget durante o dopo la chiamata
• Link alla registrazione: se il sistema telefonico registra le chiamate, salviamo il link, non il file

L’attività porta lo stesso ID di riferimento che il widget ha usato per la sessione nell’Agent Desktop. Quell’unico ID deve essere identico in ogni messaggio relativo alla chiamata; se due componenti ne generano uno proprio, la parte visibile funziona e la pulizia no.

Quali sistemi telefonici si possono collegare?

Engage CTI supporta oggi queste configurazioni:

Telefonia	Collegamento	Note
Microsoft Teams Phone	Integrazione Teams	La configurazione più diffusa: gli utenti mantengono numero e client Teams; attesa, trasferimento e risposta per conto altrui passano dal widget
Chiamate nel browser (Twilio Voice)	Twilio Voice SDK	Chiamate nel browser all’interno dell’Agent Desktop, cuffia al posto del telefono fisso
Centralino basato su SIP	Adattatore del fornitore	Il centralino esistente si collega tramite un adattatore; il lato SSCV2 resta invariato

Altri sistemi, per esempio piattaforme di contact center con proprie API di eventi, si collegano con lo stesso modello ad adattatore. L’impegno dipende soprattutto da quanto è documentato il modello di eventi del fornitore; per questo esaminiamo la sua API prima di fare una stima.

Quali sono le insidie più comuni del CTI?

Latenza. Se lo screen pop compare dopo che l’utente ha già chiesto chi sta chiamando, nessuno lo userà. Puntate a meno di due secondi e testate con volumi di chiamate reali, non con chiamate dimostrative.

Qualità dei numeri di telefono. Se il CRM contiene numeri in quindici formati diversi, il confronto fallisce. Pulite e normalizzate i numeri di tutti gli account e contatti prima del go-live. Lavoro noioso, e non facoltativo.

Connessioni WebSocket instabili. Proxy aziendali, VPN e cambi di rete le interrompono. Riconnettete automaticamente con backoff esponenziale e mostrate chiaramente nel widget quando la connessione è interrotta, così gli utenti sanno quando il CTI non è attivo.

Più schede del browser. Gli utenti aprono più schede, ma solo una deve gestire la chiamata. Usiamo una leader election tramite l’API BroadcastChannel perché lo screen pop compaia in una sola scheda. Senza, si hanno pop-up doppi o nessuno.

Contesto nei trasferimenti. Quando una chiamata viene trasferita, il contesto deve seguirla e la seconda persona deve vedere lo stesso screen pop. Per questo vanno tracciate le sessioni di chiamata, non i singoli tratti.

Registrazione e conformità. In Svizzera registrare una conversazione non pubblica senza il consenso dei partecipanti è un reato (art. 179ter Codice penale svizzero), con eccezioni limitate per alcune chiamate commerciali. La vostra soluzione CTI ha bisogno di impostazioni di registrazione configurabili, e il vostro ufficio legale dovrebbe approvare la configurazione.

Come si esercita il CTI su SAP BTP?

Il middleware va accanto al CRM, non dentro. Su SAP BTP, ambiente Cloud Foundry, la nostra architettura comprende:

• un’applicazione Node.js con API REST e server WebSocket
• un database per la tabella di ricerca dei numeri e lo stato delle sessioni
• l’AppRouter con XSUAA per autenticazione e separazione dei tenant

Il widget è una piccola applicazione web che si carica nel frame dell’Agent Desktop.

Nell’esercizio multi-tenant (più clienti su un’istanza del middleware), gli eventi telefonici di ogni cliente vengono instradati esclusivamente al suo tenant. La separazione dei dati qui non è negoziabile. Come realizziamo in generale estensioni di questo tipo su BTP è descritto in estendere SAP Sales Cloud V2 con app Cloud Foundry su BTP.

Dove funziona nella pratica

Da Nussbaum Matzingen, produttore svizzero di imballaggi, Spadoom Engage è stata una delle tre app BTP dedicate del progetto Sales Cloud V2: le chiamate in arrivo vengono riconosciute e la scheda del cliente si apre subito. Il progetto, da nessun CRM al go-live in cinque mesi, è descritto in come Nussbaum ha ottenuto piena visibilità sulla pipeline con SAP Sales Cloud V2. Usiamo lo stesso widget anche nel nostro CRM.

---

Volete collegare il vostro sistema telefonico a SAP Sales Cloud V2 o Service Cloud V2? Contattateci. Engage CTI è disponibile anche come prodotto pronto all’uso, con prezzi e una prova gratuita di 10 giorni su spadoom.cloud.

Domande frequenti

Quanto dura un’integrazione CTI?

Dipende dal sistema telefonico. Engage CTI gira come SaaS multi-tenant su SAP BTP, quindi con Microsoft Teams Phone o con le chiamate nel browser tramite Twilio non c’è nulla da installare: configuriamo il vostro ambiente e gli utenti telefonano dall’Agent Desktop. Uno sviluppo su misura o un nuovo adattatore per un centralino richiedono più tempo; l’impegno dipende soprattutto dall’API di eventi del fornitore, che esaminiamo prima di ogni stima.

Il CTI funziona con Sales Cloud V2 da mobile?

Il widget CTI è pensato per l’Agent Desktop nel browser, dove gli utenti telefonano dalla postazione di lavoro. Gli utenti mobili vedono le attività telefoniche registrate dal CTI, perché sono attività standard di V2. Se una forza vendita ha bisogno della telefonia direttamente sullo smartphone, questa si può integrare in un’app mobile su BTP, come abbiamo fatto con la telefonia integrata nelle app per le vendite sul territorio di intelligentfood.

Cosa succede se il middleware CTI si ferma?

Le chiamate continuano a funzionare, perché il sistema telefonico non dipende dal middleware. Gli utenti semplicemente non ricevono screen pop né registrazione automatica finché non torna attivo. Su BTP Cloud Foundry il middleware gira con riavvii automatici e health check, e la tabella di ricerca è salvata in un database, quindi un riavvio non richiede di ricostruire l’indice.

Il CTI regge volumi di chiamate elevati?

Sì, se il design è corretto. Il middleware di Engage CTI su SAP BTP gestisce oltre 500 connessioni WebSocket simultanee ed elabora un evento di chiamata in meno di 50 ms (Engage CTI). Per contact center più grandi scala orizzontalmente su Cloud Foundry, con affinità di sessione perché ogni connessione WebSocket resti sulla sua istanza.

Le registrazioni delle chiamate vengono salvate in Sales Cloud V2?

No, e non dovrebbero. Le registrazioni restano nello storage del sistema telefonico; salviamo solo il link sull’attività telefonica in V2. Questo evita costi di archiviazione, mantiene l’audio sensibile nell’ambiente conforme del sistema telefonico e rispetta i requisiti di residenza dei dati. Gli utenti aprono la registrazione con il player del sistema telefonico.