Integrazione CTI con SAP Sales Cloud V2: Una guida tecnica

Il vostro team commerciale risponde al telefono. Nome, azienda e ultima interazione del chiamante dovrebbero apparire sullo schermo prima ancora che dica pronto. Questo è il CTI: Computer Telephony Integration. Concetto semplice, implementazione sorprendentemente complessa.

SAP Sales Cloud V2 non include un adattatore CTI integrato. Fornisce le API e la shell UI. Lo strato di integrazione lo costruite (o comprate) voi. Noi abbiamo fatto entrambe le cose. Il nostro prodotto Engage CTI gestisce già questo per diversi clienti. Ecco com’è fatta l’architettura e dove le cose tendono ad andare storte.

In breve: I commerciali dedicano solo il 28% del tempo alla vendita vera e propria (Salesforce, 2024). L’integrazione CTI con SAP Sales Cloud V2 elimina la ricerca manuale del chiamante: lo screen pop porta il contesto in meno di 2 secondi. L’architettura: provider telefonico → middleware CTI su BTP (Node.js + WebSocket) → API Sales Cloud V2 → widget lato client. Decisioni chiave: WebSocket invece di polling, normalizzazione dei numeri in E.164, cache di lookup Redis. L’abbiamo deployata per Cisco, Genesys, RingCentral e Teams.

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

I commerciali dedicano solo il 28% del tempo alla vendita vera e propria. Il resto va in attività amministrative, inserimento dati e ricerca di informazioni (Salesforce, 2024). Il CTI elimina una delle perdite di tempo più grandi: cercare manualmente chi sta chiamando.

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

Provider telefonico. Il vostro PBX o sistema di telefonia cloud: Cisco, Genesys, RingCentral, Teams Phone o qualsiasi provider basato su SIP. Qui avvengono effettivamente le chiamate.

Middleware CTI. Un componente server-side che fa da ponte tra il provider telefonico e Sales Cloud V2. Traduce eventi telefonici (chiamata in arrivo, chiamata connessa, chiamata terminata) in azioni CRM (screen pop, crea attività, registra chiamata). Nella nostra architettura, gira su SAP BTP.

API di Sales Cloud V2. API REST per cercare contatti per numero di telefono, creare attività telefoniche e recuperare il contesto dell’account. Il design API-first di V2 rende tutto pulito. L’82% degli sviluppatori ormai privilegia approcci API-first (Postman, 2024), e V2 è stato costruito esattamente con quella logica.

Widget lato client. Un componente UI incorporato nella shell di Sales Cloud V2 che mostra i controlli chiamata (risposta, attesa, trasferimento, fine) e le informazioni del chiamante. Funziona come estensione side-by-side tramite il framework plug-in della shell V2.

Come attraversa il sistema una chiamata in entrata?

L’intero flusso dallo squillo allo screen pop richiede meno di 2 secondi. Qualsiasi ritardo in più e gli utenti perdono fiducia nel sistema. Ecco esattamente cosa succede:

1. La chiamata arriva al sistema telefonico. Il PBX invia un evento chiamata al middleware CTI via WebSocket o webhook.
2. Il middleware estrae il numero di telefono del chiamante e interroga l’API Sales Cloud V2: GET /sap/c4c/api/v1/phone-call-collection?$filter=phone eq '{number}'. (In pratica, cerchiamo su account, contatti e clienti individuali.)
3. Se trova una corrispondenza, il middleware invia il contesto del chiamante (nome, account, opportunità aperte, interazioni recenti) al widget lato client via WebSocket.
4. Il widget attiva uno screen pop, navigando Sales Cloud V2 al record contatto o account corrispondente.
5. Quando la chiamata termina, il middleware crea un’attività telefonica in V2 con durata, direzione, partecipanti e note.

Quell’obiettivo di 2 secondi non è arbitrario. È la soglia oltre la quale i commerciali smettono di chiedere “chi parla?” e iniziano a salutare i chiamanti per nome. Mancatela, e l’adozione crolla in fretta. L’ho visto succedere: uno screen pop di 4 secondi è de facto come non avere alcuno screen pop. La gente lo ignora e basta.

Quali sono le decisioni tecniche chiave?

Il mercato del software per contact center ha raggiunto i 38,2 miliardi di dollari nel 2024, con una crescita del 21,4% CAGR (Grand View Research, 2024). Con quella crescita arrivano più opzioni di telefonia e più decisioni di integrazione. Tre scelte contano più di tutte.

Meglio WebSocket o polling?

Il widget lato client ha bisogno di eventi chiamata in tempo reale. Interrogare il middleware ogni secondo crea carico inutile e aggiunge latenza. Le connessioni WebSocket consegnano eventi in millisecondi.

Usiamo un server WebSocket su BTP (Node.js) che mantiene connessioni persistenti con ogni sessione attiva di Sales Cloud V2. Quando arriva un evento chiamata dal sistema telefonico, viene inoltrato istantaneamente alla connessione WebSocket dell’utente giusto.

Perché non Server-Sent Events (SSE)? Funzionano per lo streaming unidirezionale, ma il CTI ha bisogno di comunicazione bidirezionale: il widget invia comandi indietro (attesa, trasferimento, fine chiamata). WebSocket gestisce entrambe le direzioni su una sola connessione. Più pulito.

Come si gestisce il matching dei numeri telefonici?

Sembra semplice. Non lo è. I numeri di telefono arrivano in molti formati: +41 44 123 45 67, 044 123 45 67, 0041441234567. Il middleware deve normalizzare i numeri prima di cercare.

Normalizziamo in formato E.164 (+41441234567) e cerchiamo contro un campo normalizzato in V2. Sales Cloud V2 salva i numeri come inseriti dagli utenti, il che significa formati selvaggiamente incoerenti. Il nostro middleware gestisce la normalizzazione su entrambi i lati: normalizza il numero del chiamante in entrata E normalizza i numeri salvati in V2 durante il confronto. Nota bene: se saltate la normalizzazione lato dati salvati, otterrete corrispondenze mancate fantasma che faranno impazzire il vostro team di supporto.

Costruite un indice dei numeri telefonici. Interrogare l’API di V2 con ricerche wildcard sui numeri a ogni chiamata è lento. Manteniamo una cache di lookup leggera (Redis su BTP) che mappa i numeri normalizzati agli ID entità V2. La cache si aggiorna ogni 15 minuti e sugli eventi di aggiornamento delle entità. Senza questa cache, la latenza di lookup salta da 200ms a oltre 1,5 secondi. E vi brucia completamente il budget dei 2 secondi.

Come funziona l’autenticazione?

Il middleware deve chiamare le API Sales Cloud V2 per conto degli utenti. Usiamo OAuth 2.0 con SAP IAS (Identity Authentication Service) come identity provider. Il widget gestisce il flusso OAuth iniziale; il middleware usa refresh token per le chiamate API.

Per l’autenticazione telefonia-middleware, dipende dal provider. Cisco e Genesys usano API key. Provider cloud come RingCentral e Teams usano OAuth. Il middleware astrae tutto questo, quindi aggiungere un nuovo provider telefonico significa implementare una sola interfaccia adapter. L’integrazione V2 resta identica.

Cosa viene registrato quando una chiamata termina?

Il CRM restituisce 3,10 dollari per ogni dollaro speso, e il risparmio di tempo genera il 51% di quel ritorno (Nucleus Research, 2024). La registrazione automatica delle chiamate è dove il CTI incassa quel ritorno: niente più creazione manuale di attività dopo ogni chiamata.

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

• Direzione: in entrata, in uscita, persa
• Durata: ora inizio, ora fine, tempo di conversazione
• Partecipanti: chiamante, destinatario, eventuali parti trasferite
• Contesto account: quale account/contatto è stato abbinato
• Note: i commerciali possono aggiungere note durante o dopo la chiamata tramite il widget
• Link registrazione: se il sistema telefonico registra le chiamate, salviamo l’URL della registrazione (non il file)

L’attività viene creata via POST /sap/c4c/api/v1/phone-call-collection. L’API di V2 accetta nativamente tutti questi campi. Nessun oggetto custom necessario. Pulito.

Quali provider telefonici sono supportati?

Il nostro prodotto Engage CTI attualmente supporta cinque categorie di provider:

Aggiungere un nuovo provider richiede tipicamente 2-4 settimane di sviluppo. Il pattern adapter fa sì che la maggior parte del lavoro sia mappare il modello eventi del provider sul nostro formato interno. L’integrazione V2 resta identica a prescindere dal provider telefonico che usate.

Quali sono le insidie CTI più comuni?

Il 67% dei commerciali non si aspetta di raggiungere la quota (Salesforce, 2024). Un sistema CTI rotto, che aggiunge attrito invece di toglierlo, peggiora le cose. Ecco le sei insidie che vediamo più spesso.

La latenza uccide l’adozione. Se lo screen pop appare dopo che il commerciale ha già chiesto “chi parla?”, nessuno lo userà. Obiettivo: meno di 2 secondi. Testate con volumi di chiamate reali, non con le demo.

Qualità dei dati dei numeri telefonici. Se i vostri dati V2 hanno numeri di telefono in 15 formati diversi, il matching fallisce. Pulite i dati prima del go-live. Eseguite uno script di normalizzazione su tutti gli account e i contatti. Lavoro noioso. Non negoziabile.

Stabilità WebSocket. Le connessioni WebSocket cadono. Proxy aziendali, VPN e switch di rete le interrompono. Implementate la riconnessione automatica con backoff esponenziale. Mostrate nel widget un indicatore chiaro “disconnesso” così i commerciali sanno quando il CTI non è attivo.

Gestione multi-tab. I commerciali aprono più schede del browser. Il widget CTI deve essere attivo in una sola. Usiamo un pattern di leader election (BroadcastChannel API) per assicurare che lo screen pop avvenga esattamente in una scheda. Senza, i commerciali ricevono popup duplicati o nessuno. Entrambi un pasticcio.

Contesto nel trasferimento di chiamata. Quando una chiamata viene trasferita, il contesto deve seguire. Il secondo agente deve vedere lo stesso screen pop. Questo richiede il tracking delle sessioni di chiamata, non delle singole tratte.

Compliance. La registrazione e il logging delle chiamate hanno requisiti legali che variano per giurisdizione. In Svizzera, entrambe le parti devono acconsentire alla registrazione. La vostra soluzione CTI ha bisogno di controlli di registrazione configurabili. Non è un’opzione, è la legge.

Come si deploya il CTI su SAP BTP?

Con il 55% dei membri ASUG che ormai usa SAP BTP (ASUG, 2025), BTP è la casa naturale del middleware CTI. La nostra architettura usa quattro servizi BTP:

• Applicazione Node.js con Express per l’API REST e il server WebSocket
• Redis per la cache di lookup dei numeri telefonici e la gestione delle sessioni
• SAP Integration Suite per la consegna affidabile di eventi da sistemi telefonici on-premise
• XSUAA per autenticazione e isolamento tenant

Il widget è distribuito come plug-in della shell di Sales Cloud V2: una piccola applicazione JavaScript che si carica all’interno del frame della shell V2.

Per i deployment multi-tenant (più clienti su un’unica istanza middleware), usiamo l’isolamento tenant di XSUAA. Gli eventi telefonici di ogni cliente vengono instradati solo al proprio tenant. L’isolamento dei dati qui non è negoziabile. Sbagliatelo e avete un incidente serio tra le mani.

Volete collegare il vostro sistema telefonico a SAP Sales Cloud V2? Il nostro prodotto Engage CTI è pronto per la produzione. Supporta Cisco, Genesys, RingCentral e Teams. Contattateci.

Engage CTI è disponibile anche come prodotto pacchettizzato: prezzi e prova di 10 giorni su spadoom.cloud.

Domande frequenti

Quanto dura un’integrazione CTI?

Un’integrazione standard con un provider telefonico richiede 6-8 settimane: 2 settimane per il setup del middleware e lo sviluppo dell’adapter telefonico, 2 settimane per la configurazione del widget V2 e l’integrazione API, e 2-4 settimane di test con flussi di chiamata reali. La tempistica dipende molto dal provider telefonico. Genesys Cloud è il più rapido (API WebSocket cloud-native). Cisco CUCM on-premise richiede setup di rete aggiuntivo per la connettività BTP e può spingervi verso le 8 settimane.

Il CTI funziona con Sales Cloud V2 su mobile?

Il widget CTI lato client è pensato per il client web desktop, dove i commerciali gestiscono le chiamate alla postazione. Gli utenti V2 mobile possono vedere le attività di chiamata registrate dal CTI (sono normali attività V2), ma lo screen pop in tempo reale e i controlli chiamata richiedono il framework plug-in della shell desktop. Per i commerciali sul campo che usano principalmente il mobile, i log delle chiamate CTI offrono comunque un contesto solido per i follow-up senza il widget in tempo reale.

Cosa succede se il middleware CTI va giù?

Le chiamate continuano a funzionare. Il sistema telefonico è indipendente dal middleware. I commerciali semplicemente non ricevono gli screen pop. Il nostro middleware gira con policy di riavvio automatico su BTP Cloud Foundry, e abbiamo health check che avvisano i team operativi entro 60 secondi da un downtime. La cache Redis persiste in modo indipendente, quindi un riavvio del middleware non richiede di ricostruire l’indice dei numeri telefonici.

Il CTI regge volumi di chiamate elevati?

Il nostro middleware Engage CTI gestisce oltre 500 connessioni WebSocket simultanee ed elabora gli eventi chiamata in meno di 50ms per evento. Per i contact center con volumi superiori, scaliamo orizzontalmente su BTP Cloud Foundry con sticky session per mantenere l’affinità WebSocket. La cache di lookup Redis gestisce migliaia di query al secondo, quindi il matching dei numeri non diventa un collo di bottiglia nemmeno nei picchi.

Le registrazioni delle chiamate vengono salvate in Sales Cloud V2?

No. E non dovrebbero. Le registrazioni restano nello storage del sistema telefonico. In V2 salviamo solo l’URL della registrazione come link sull’attività telefonica. Questo evita costi di storage, mantiene i dati audio sensibili nell’ambiente conforme del sistema telefonico e rispetta i requisiti di residenza dei dati delle diverse giurisdizioni. I commerciali cliccano il link per accedere alla registrazione attraverso il player del sistema telefonico.