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 er «Hallo» sagt. Das ist CTI: Computer Telephony Integration. Einfaches Konzept, erstaunlich komplexe Umsetzung.

SAP Sales Cloud V2 liefert keinen eingebauten CTI-Adapter. Es stellt die APIs und die UI-Shell bereit. Die Integrationsschicht bauen (oder kaufen) Sie selbst. Wir haben beides gemacht. Unser Engage-CTI-Produkt übernimmt das bereits für mehrere Kunden. Hier zeigen wir, wie die Architektur aussieht und wo es typischerweise hakt.

TL;DR: Vertriebsmitarbeitende verbringen nur 28 % ihrer Zeit mit tatsächlichem Verkaufen (Salesforce, 2024). Eine CTI-Integration mit SAP Sales Cloud V2 eliminiert die manuelle Anrufersuche: Der Screen Pop liefert Anruferkontext in unter 2 Sekunden. Die Architektur: Telefonieanbieter → CTI-Middleware auf BTP (Node.js + WebSocket) → Sales Cloud V2 APIs → Client-seitiges Widget. Zentrale Entscheidungen: WebSocket statt Polling, E.164-Telefonnummern-Normalisierung, Redis-Lookup-Cache. Wir haben das für Cisco, Genesys, RingCentral und Teams deployed.

Was ist CTI und warum ist es für Sales Cloud V2 wichtig?

Vertriebsmitarbeitende verbringen nur 28 % ihrer Zeit mit tatsächlichem Verkaufen. Der Rest geht für Admin-Aufgaben, Datenerfassung und Informationssuche drauf (Salesforce, 2024). CTI beseitigt einen der grössten Zeitfresser: manuell nachzuschauen, wer anruft.

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

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

CTI-Middleware. Eine serverseitige Komponente, die 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. Das API-first-Design von V2 macht das sauber und übersichtlich. 82 % der Entwickler priorisieren inzwischen API-first-Ansätze (Postman, 2024), und V2 wurde mit genau diesem Denken gebaut.

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

Wie fliesst ein eingehender Anruf durch das System?

Der gesamte Ablauf vom Klingeln bis zum Screen Pop dauert unter 2 Sekunden. Alles Langsamere untergräbt das Vertrauen der Nutzer in das System. So läuft es im Detail ab:

1. Der Anruf erreicht das Telefoniesystem. Die Anlage sendet ein Call-Event via WebSocket oder Webhook an die CTI-Middleware.
2. Die 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 und 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.

Das 2-Sekunden-Ziel ist nicht willkürlich. Es ist die Schwelle, ab der Mitarbeitende nicht mehr «Wer spricht?» fragen, sondern Anrufer mit Namen begrüssen. Verfehlen Sie es, sinkt die Akzeptanz rapide. Ich habe es erlebt: Ein Screen Pop nach 4 Sekunden ist praktisch dasselbe wie gar kein Screen Pop. Die Leute ignorieren ihn einfach.

Was sind die wichtigsten technischen Entscheidungen?

Der Markt für Contact-Center-Software erreichte 2024 ein Volumen von 38,2 Milliarden Dollar bei 21,4 % CAGR (Grand View Research, 2024). Mit diesem Wachstum kommen mehr Telefonieoptionen und mehr Integrationsentscheidungen. Drei Entscheidungen zählen am meisten.

WebSocket oder Polling?

Das Client-Widget braucht Echtzeit-Anruf-Events. Die Middleware jede Sekunde abzufragen, erzeugt unnötige Last und zusätzliche Latenz. WebSocket-Verbindungen 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 WebSocket-Verbindung des richtigen Nutzers gepusht.

Warum keine Server-Sent Events (SSE)? Sie funktionieren für einseitiges Streaming, aber CTI braucht bidirektionale Kommunikation: Das Widget sendet Befehle zurück (Halten, Weiterleiten, Anruf beenden). WebSocket bedient beide Richtungen über eine einzige Verbindung. Sauberer.

Wie handhaben Sie das Telefonnummern-Matching?

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

Wir normalisieren auf das E.164-Format (+41441234567) und suchen gegen ein normalisiertes Feld in V2. Sales Cloud V2 speichert Telefonnummern so, wie Nutzer sie eingeben, also in wild inkonsistenten Formaten. Unsere Middleware normalisiert auf beiden Seiten: die eingehende Anrufernummer UND die in V2 gespeicherten Nummern beim Vergleich. Merke: Wer die Normalisierung auf der gespeicherten Seite auslässt, produziert Phantom-Fehltreffer, die das Support-Team in den Wahnsinn treiben.

Bauen Sie einen Telefonnummern-Index. Die V2-API bei jedem Anruf mit Wildcard-Telefonsuchen 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 sowie bei Entity-Update-Events. Ohne diesen Cache springt die Lookup-Latenz von 200 ms auf über 1,5 Sekunden. Damit ist Ihr 2-Sekunden-Budget komplett gesprengt.

Wie funktioniert die 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.

Bei der Authentifizierung zwischen Telefonie und Middleware hängt es vom Anbieter ab. Cisco und Genesys nutzen API-Keys. Cloud-Anbieter wie RingCentral und Teams nutzen OAuth. Die Middleware abstrahiert das weg: Einen neuen Telefonieanbieter hinzuzufügen bedeutet, ein Adapter-Interface zu implementieren. Die V2-Integration bleibt dieselbe.

Was wird protokolliert, wenn ein Anruf endet?

CRM liefert 3,10 Dollar Rendite pro investiertem Dollar, wobei Zeitersparnis 51 % dieses Ertrags ausmacht (Nucleus Research, 2024). Die automatische Anrufprotokollierung ist der Ort, an dem CTI diesen Ertrag einfährt: keine manuelle Aktivitätserfassung mehr nach jedem Anruf.

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, alle weitergeleiteten 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. Die V2-API akzeptiert all diese Felder nativ. Keine Custom Objects nötig. Sauber.

Welche Telefonieanbieter werden unterstützt?

Unser Engage-CTI-Produkt unterstützt derzeit fünf Anbieterkategorien:

Einen neuen Anbieter hinzuzufügen dauert typischerweise 2-4 Wochen Entwicklung. Dank Adapter-Pattern besteht die meiste Arbeit darin, das Event-Modell des Anbieters auf unser internes Format zu mappen. Die V2-Integration bleibt identisch, egal welchen Telefonieanbieter Sie betreiben.

Was sind die häufigsten CTI-Stolpersteine?

67 % der Vertriebsmitarbeitenden rechnen nicht damit, ihre Quote zu erreichen (Salesforce, 2024). Ein kaputtes CTI-System, das Reibung erzeugt statt beseitigt, macht das noch schlimmer. Hier die sechs Stolpersteine, die wir am häufigsten sehen.

Latenz killt die Akzeptanz. Wenn der Screen Pop erscheint, nachdem der Mitarbeitende bereits «Wer spricht?» gefragt hat, nutzt ihn niemand. Ziel: unter 2 Sekunden. Testen Sie mit realen Anrufvolumen, nicht mit 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. Langweilige Arbeit. Nicht verhandelbar.

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, wann CTI nicht aktiv ist.

Multi-Tab-Handling. Vertriebsmitarbeitende öffnen mehrere Browser-Tabs. Das CTI-Widget sollte nur in einem aktiv sein. Wir nutzen ein Leader-Election-Pattern (BroadcastChannel API), damit der Screen Pop in genau einem Tab erscheint. Ohne das bekommen Mitarbeitende doppelte Popups oder gar keine. Beides ist ein Ärgernis.

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 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. Das ist nicht optional, das ist Gesetz.

Wie deployen Sie CTI auf SAP BTP?

Mit 55 % der ASUG-Mitglieder, die inzwischen SAP BTP nutzen (ASUG, 2025), ist BTP das natürliche Zuhause für CTI-Middleware. Unsere Architektur nutzt vier BTP-Services:

• Node.js-Anwendung mit Express für die REST-API und den WebSocket-Server
• Redis für den Telefonnummern-Lookup-Cache und das 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. Die Telefonie-Events jedes Kunden werden ausschliesslich an dessen Mandanten geroutet. Datenisolation ist hier nicht verhandelbar. Wer das falsch macht, hat einen handfesten Vorfall am Hals.

Sie wollen Ihre Telefonanlage mit SAP Sales Cloud V2 verbinden? Unser Engage-CTI-Produkt ist produktionsreif. Unterstützt Cisco, Genesys, RingCentral und Teams. Kontakt aufnehmen.

Engage CTI gibt es auch als paketiertes Produkt: Preise und eine 10-Tage-Testversion finden Sie auf spadoom.cloud.

Häufig gestellte Fragen

Wie lange dauert eine CTI-Integration?

Eine Standardintegration mit einem Telefonieanbieter dauert 6-8 Wochen: 2 Wochen für Middleware-Setup und Telefonie-Adapter-Entwicklung, 2 Wochen für V2-Widget-Konfiguration und API-Integration sowie 2-4 Wochen für Tests mit realen Anrufabläufen. Der Zeitplan hängt stark vom Telefonieanbieter ab. Genesys Cloud geht am schnellsten (cloud-native WebSocket API). On-Premise Cisco CUCM erfordert zusätzliches Netzwerk-Setup für die BTP-Anbindung und kann Sie näher an die 8 Wochen bringen.

Funktioniert CTI mit Sales Cloud V2 auf Mobilgeräten?

Das Client-seitige CTI-Widget ist für den Desktop-Webclient konzipiert, wo Mitarbeitende Anrufe am Arbeitsplatz abwickeln. Mobile V2-Nutzer können die von CTI protokollierten Anrufaktivitäten einsehen (das sind Standard-V2-Aktivitäten), aber Echtzeit-Screen-Pop und Anrufsteuerung erfordern das Desktop-Shell-Plug-in-Framework. Für Aussendienstmitarbeitende, die primär mobil arbeiten, liefern die CTI-Anrufprotokolle soliden Kontext für Follow-ups, ganz ohne das Echtzeit-Widget.

Was passiert, wenn die CTI-Middleware ausfällt?

Anrufe funktionieren weiterhin. Das Telefoniesystem ist unabhängig von der Middleware. Die Mitarbeitenden bekommen lediglich keine Screen Pops. Unsere Middleware läuft mit automatischen Restart-Policies auf BTP Cloud Foundry, und Health Checks alarmieren die Ops-Teams innert 60 Sekunden nach einem Ausfall. Der Redis-Cache persistiert unabhängig, ein Middleware-Neustart erfordert also keinen Neuaufbau des Telefonnummern-Index.

Kann CTI hohe Anrufvolumen bewältigen?

Unsere Engage-CTI-Middleware bewältigt über 500 gleichzeitige WebSocket-Verbindungen und verarbeitet Call-Events in unter 50 ms pro Event. Für Contact Center mit höheren Volumen skalieren wir horizontal auf BTP Cloud Foundry mit Sticky Sessions, um die WebSocket-Affinität zu erhalten. Der Redis-Lookup-Cache verarbeitet Tausende Abfragen pro Sekunde, das Telefonnummern-Matching wird also auch bei Spitzenvolumen nicht zum Engpass.

Werden Anrufaufzeichnungen in Sales Cloud V2 gespeichert?

Nein. Und das sollten sie auch nicht. Anrufaufzeichnungen bleiben im Speicher des Telefoniesystems. Wir speichern nur die Aufnahme-URL als Link an der Telefonaktivität in V2. Das vermeidet Speicherkosten, hält sensible Audiodaten in der compliance-verwalteten Umgebung des Telefoniesystems und respektiert jurisdiktionsspezifische Anforderungen an die Datenresidenz. Mitarbeitende klicken auf den Link und greifen über den Player des Telefoniesystems auf die Aufzeichnung zu.