CTI-Integration mit SAP Sales Cloud V2: Ein technischer Leitfaden

Ihr Vertriebsteam nimmt den Hörer ab. Name, Firma und letzte Interaktion des Anrufers sollten auf dem Bildschirm erscheinen, bevor der Anrufer etwas sagt. Das ist CTI — Computer Telephony Integration. Einfaches Konzept, komplexe Umsetzung.

SAP Sales Cloud V2 liefert keinen eingebauten CTI-Adapter. Es stellt die APIs und die UI-Shell bereit. Die Integration bauen (oder kaufen) Sie. Wir haben beides gemacht — unser Engage-CTI-Produkt übernimmt das für mehrere Kunden. Hier die Architektur und wo die Stolpersteine liegen.

Architekturübersicht

Eine CTI-Integration mit Sales Cloud V2 besteht aus vier Komponenten:

Telefonieanbieter. Ihre Telefonanlage oder Cloud-Telefonie — Cisco, Genesys, RingCentral, Teams Phone oder ein SIP-basierter Anbieter. Hier finden die Anrufe tatsächlich statt.

CTI-Middleware. Eine serverseitige Komponente, die den Telefonieanbieter und Sales Cloud V2 verbindet. Sie übersetzt Telefonie-Events (eingehender Anruf, Anruf verbunden, Anruf beendet) in CRM-Aktionen (Screen Pop, Aktivität erstellen, Anruf protokollieren). In unserer Architektur läuft sie auf SAP BTP.

Sales Cloud V2 APIs. REST-APIs für die Kontaktsuche per Telefonnummer, das Erstellen von Telefonaktivitäten und das Abrufen von Kontokontext. V2s API-first-Design macht das sauber.

Client-seitiges Widget. Eine UI-Komponente, eingebettet in die Sales-Cloud-V2-Shell, die Anrufsteuerung (Annehmen, Halten, Weiterleiten, Beenden) und Anruferinformationen anzeigt. Dieses Widget läuft als Side-by-Side-Erweiterung über V2s Shell-Plug-in-Framework.

Datenfluss bei einem eingehenden Anruf

1. Anruf erreicht das Telefoniesystem. Die Anlage sendet ein Call-Event an die CTI-Middleware via WebSocket oder Webhook.
2. Middleware extrahiert die Telefonnummer des Anrufers und fragt die Sales Cloud V2 API ab: GET /sap/c4c/api/v1/phone-call-collection?$filter=phone eq '{number}'. (In der Praxis suchen wir über Konten, Kontakte und Einzelkunden.)
3. Bei einem Treffer sendet die Middleware den Anruferkontext (Name, Konto, offene Opportunities, kürzliche Interaktionen) via WebSocket an das Client-Widget.
4. Das Widget löst einen Screen Pop aus — es navigiert Sales Cloud V2 zum zugeordneten Kontakt- oder Kontodatensatz.
5. Wenn der Anruf endet, erstellt die Middleware eine Telefonaktivität in V2 mit Dauer, Richtung, Teilnehmern und Notizen.

Der gesamte Ablauf dauert unter 2 Sekunden vom Klingeln bis zum Screen Pop. Alles Langsamere untergräbt das Vertrauen der Nutzer in das System.

Wichtige technische Entscheidungen

WebSocket vs. Polling

Das Client-Widget braucht Echtzeit-Anruf-Events. Jede Sekunde die Middleware nach “Gibt es einen Anruf?” zu fragen, erzeugt unnötige Last und fügt Latenz hinzu. WebSocket-Verbindungen zwischen Widget und Middleware liefern Events in Millisekunden.

Wir nutzen einen WebSocket-Server auf BTP (Node.js), der persistente Verbindungen zu jeder aktiven Sales-Cloud-V2-Sitzung hält. Wenn ein Call-Event vom Telefoniesystem eintrifft, wird es sofort an die richtige WebSocket-Verbindung des Nutzers weitergeleitet.

Telefonnummern-Matching

Klingt einfach. Ist es nicht. Telefonnummern kommen in vielen Formaten: +41 44 123 45 67, 044 123 45 67, 0041441234567. Ihre Middleware muss Nummern normalisieren, bevor sie sucht.

Wir normalisieren auf E.164-Format (+41441234567) und suchen gegen ein normalisiertes Feld in V2. Sales Cloud V2 speichert Telefonnummern so, wie Nutzer sie eingeben — also in inkonsistenten Formaten. Unsere Middleware normalisiert auf beiden Seiten: die eingehende Anrufernummer UND die in V2 gespeicherten Nummern beim Vergleich.

Tipp: Bauen Sie einen Telefonnummern-Index. V2s API bei jedem Anruf mit Wildcard-Suchen abzufragen, ist langsam. Wir pflegen einen schlanken Lookup-Cache (Redis auf BTP), der normalisierte Telefonnummern auf V2-Entity-IDs abbildet. Der Cache aktualisiert sich alle 15 Minuten und bei Entity-Update-Events.

Authentifizierung

Die Middleware muss Sales Cloud V2 APIs im Namen von Nutzern aufrufen. Wir nutzen OAuth 2.0 mit SAP IAS (Identity Authentication Service) als Identity Provider. Das Widget übernimmt den initialen OAuth-Flow; die Middleware nutzt Refresh-Tokens für API-Aufrufe.

Für die Telefonie-zu-Middleware-Authentifizierung hängt es vom Anbieter ab. Cisco und Genesys nutzen API-Keys. Cloud-Anbieter wie RingCentral und Teams nutzen OAuth. Die Middleware abstrahiert das — einen neuen Telefonieanbieter hinzuzufügen bedeutet, ein Adapter-Interface zu implementieren.

Anrufprotokollierung

Jeder Anruf erstellt eine Telefonaktivität in Sales Cloud V2. Wir protokollieren:

• Richtung: eingehend, ausgehend, verpasst
• Dauer: Startzeit, Endzeit, Gesprächszeit
• Teilnehmer: Anrufer, angerufene Partei, weitergeleitete Parteien
• Kontokontext: welches Konto/welcher Kontakt zugeordnet wurde
• Notizen: Mitarbeitende können während oder nach dem Anruf Notizen über das Widget hinzufügen
• Aufnahme-Link: falls das Telefoniesystem Anrufe aufzeichnet, speichern wir die Aufnahme-URL (nicht die Datei)

Die Aktivität wird über POST /sap/c4c/api/v1/phone-call-collection erstellt. V2s API akzeptiert all diese Felder nativ — keine Custom Objects nötig.

Unterstützte Telefonieanbieter

Unser Engage-CTI-Produkt unterstützt derzeit:

Einen neuen Anbieter hinzuzufügen dauert typischerweise 2-4 Wochen Entwicklung.

Typische Stolpersteine

Latenz killt die Akzeptanz. Wenn der Screen Pop erscheint, nachdem der Mitarbeitende bereits “Wer spricht?” gefragt hat, nutzt es niemand. Ziel: unter 2 Sekunden. Testen Sie mit realen Anrufvolumen, nicht nur in Demos.

Datenqualität bei Telefonnummern. Wenn Ihre V2-Daten Telefonnummern in 15 verschiedenen Formaten enthalten, scheitert das Matching. Bereinigen Sie Ihre Daten vor dem Go-live. Lassen Sie ein Normalisierungsskript über alle Konten und Kontakte laufen.

WebSocket-Stabilität. WebSocket-Verbindungen brechen ab. Firmen-Proxys, VPNs und Netzwerk-Switches unterbrechen sie. Implementieren Sie automatischen Reconnect mit exponentiellem Backoff. Zeigen Sie im Widget einen klaren “Getrennt”-Indikator, damit Mitarbeitende wissen, wenn CTI nicht aktiv ist.

Multi-Tab-Handling. Vertriebsmitarbeitende öffnen mehrere Browser-Tabs. Das CTI-Widget sollte nur in einem Tab aktiv sein. Wir nutzen ein Leader-Election-Pattern (BroadcastChannel API), um sicherzustellen, dass der Screen Pop in genau einem Tab erscheint.

Kontext bei Anrufweiterleitung. Wenn ein Anruf weitergeleitet wird, sollte der Kontext mitwandern. Der zweite Agent sollte denselben Screen Pop sehen. Das erfordert Tracking von Anruf-Sessions, nicht nur einzelner Anruf-Legs.

Compliance. Anrufaufzeichnung und -protokollierung unterliegen rechtlichen Anforderungen, die je nach Jurisdiktion variieren. In der Schweiz müssen beide Parteien der Aufzeichnung zustimmen. Ihre CTI-Lösung braucht konfigurierbare Aufnahmesteuerung.

Deployment auf BTP

Unsere CTI-Middleware läuft auf SAP BTP Cloud Foundry:

• Node.js-Anwendung mit Express für die REST-API und den WebSocket-Server
• Redis für den Telefonnummern-Lookup-Cache und Session-Management
• SAP Integration Suite für zuverlässige Event-Zustellung von On-Premise-Telefoniesystemen
• XSUAA für Authentifizierung und Mandantentrennung

Das Widget wird als Sales-Cloud-V2-Shell-Plug-in deployed — eine kleine JavaScript-Anwendung, die innerhalb des V2-Shell-Frames läuft.

Für mandantenfähige Deployments (mehrere Kunden auf einer Middleware-Instanz) nutzen wir XSUAA-Mandantentrennung. Telefonie-Events jedes Kunden werden nur an dessen Mandanten geroutet.

Erste Schritte

CTI-Integration ist ein wirkungsvolles Projekt. Wenn es funktioniert, verändert es die Art, wie Ihr Vertrieb jeden Telefonkontakt handhabt. Die technische Umsetzung ist machbar, wenn Sie die Details planen: Telefonnummern-Qualität, Latenz-Ziele und WebSocket-Zuverlässigkeit.

Bereit, Ihre Telefonanlage mit SAP Sales Cloud V2 zu verbinden? Unser Engage-CTI-Produkt ist produktionsreif. Kontakt aufnehmen.