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 una parola. Questo è il CTI — Computer Telephony Integration. Concetto semplice, implementazione complessa.

SAP Sales Cloud V2 non include un adattatore CTI integrato. Fornisce le API e la shell UI. L’integrazione la costruite (o comprate) voi. Noi abbiamo fatto entrambe le cose — il nostro prodotto Engage CTI gestisce questo per diversi clienti. Ecco com’è l’architettura e dove si nascondono le insidie.

Panoramica dell’architettura

Un’integrazione CTI con Sales Cloud V2 comprende 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 collega 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.

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.

Flusso dati per una chiamata in entrata

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.

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

Decisioni tecniche chiave

WebSocket vs. polling

Il widget lato client ha bisogno di eventi chiamata in tempo reale. Interrogare il middleware ogni secondo per “c’è una chiamata?” crea carico inutile e aggiunge latenza. Le connessioni WebSocket tra widget e middleware 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.

Matching 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 inconsistenti. 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.

Suggerimento: costruite un indice dei numeri telefonici. Interrogare l’API V2 con ricerche wildcard sui numeri a ogni chiamata è lento. Manteniamo una cache di lookup leggera (Redis su BTP) che mappa numeri normalizzati agli ID entità V2. La cache si aggiorna ogni 15 minuti e sugli eventi di aggiornamento entità.

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 — aggiungere un nuovo provider telefonico significa implementare un’interfaccia adapter.

Registrazione chiamate

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

• Direzione: in entrata, in uscita, persa
• Durata: ora inizio, ora fine, tempo 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 V2 accetta nativamente tutti questi campi — nessun oggetto custom necessario.

Provider telefonici supportati

Il nostro prodotto Engage CTI attualmente supporta:

Aggiungere un nuovo provider richiede tipicamente 2-4 settimane di sviluppo.

Insidie comuni

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 solo in demo.

Qualità dati 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 contatti.

Stabilità WebSocket. Le connessioni WebSocket cadono. Proxy aziendali, VPN e switch di rete le interrompono. Implementate 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 dovrebbe essere attivo in una sola scheda. Usiamo un pattern di leader election (BroadcastChannel API) per assicurare che lo screen pop avvenga in una sola scheda.

Contesto nel trasferimento chiamata. Quando una chiamata viene trasferita, il contesto deve seguire. Il secondo agente dovrebbe vedere lo stesso screen pop. Questo richiede il tracking delle sessioni chiamata, non solo 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 necessita di controlli di registrazione configurabili.

Deployment su BTP

Il nostro middleware CTI gira su SAP BTP Cloud Foundry:

• Applicazione Node.js con Express per l’API REST e il server WebSocket
• Redis per la cache di lookup numeri telefonici e gestione 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 Sales Cloud V2 — una piccola applicazione JavaScript che si carica all’interno del frame della shell V2.

Per deployment multi-tenant (più clienti su un’istanza middleware), usiamo l’isolamento tenant XSUAA. Gli eventi telefonici di ogni cliente vengono instradati solo al proprio tenant.

Per iniziare

L’integrazione CTI è un progetto ad alto impatto. Quando funziona, cambia il modo in cui il vostro team gestisce ogni interazione telefonica. L’implementazione tecnica è gestibile se pianificate i dettagli: qualità numeri telefonici, obiettivi di latenza e affidabilità WebSocket.

Pronti a collegare il vostro sistema telefonico a SAP Sales Cloud V2? Il nostro prodotto Engage CTI è pronto per la produzione. Contattateci.