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

Ein Kunde ruft an. Bevor Ihre Kollegin «Grüezi» sagt, sollten Name, Firma und offene Themen des Anrufers schon auf dem Bildschirm stehen, und wenn das Gespräch endet, sollte es im CRM protokolliert sein, ohne dass jemand etwas abtippt. Das ist CTI (Computer Telephony Integration). Das Konzept ist einfach; die Umsetzung hat mehr bewegliche Teile, als die meisten erwarten.

SAP Sales Cloud V2 und Service Cloud V2 teilen sich einen Agent Desktop, der ein CTI-Widget eines Drittanbieters aufnehmen kann. SAP beschreibt dieses Framework im Leitfaden SAP Service Cloud Version 2 integration with Third-Party CTI Providers. Was SAP nicht liefert, ist die Verbindung zu Ihrer Telefonanlage: Diese Schicht bauen oder kaufen Sie. Wir haben beides getan, und unser Produkt Engage CTI ist das Ergebnis. Dieser Leitfaden beschreibt die Architektur und die Stellen, an denen Projekte typischerweise haken.

Kurzfassung: Eine CTI-Integration mit SAP Sales Cloud V2 hat vier Teile: die Telefonanlage, eine Middleware (bei uns auf SAP BTP), die V2-APIs für Anruferkennung und Anrufprotokollierung und ein Widget im Agent Desktop, das über XML-Nutzlasten mit der Shell spricht. Die wichtigsten Entscheidungen: Ereignisse per WebSocket pushen statt pollen, Telefonnummern auf beiden Seiten ins E.164-Format normalisieren, einen Lookup-Cache führen, damit der Screen Pop nach etwa zwei Sekunden erscheint, und die Einwilligung zur Aufzeichnung nach Schweizer Recht regeln.

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

Ohne CTI beginnt jeder Anruf mit einer Suche: Wer ist das, welcher Account, gibt es einen offenen Fall? Nach dem Gespräch muss jemand die Telefonaktivität von Hand anlegen, und oft macht es niemand. CTI streicht beide Schritte. Der Anrufer ist erkannt, bevor abgenommen wird, und die Aktivität wird automatisch protokolliert.

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

Telefonanlage. Ihre PBX oder Cloud-Telefonie, zum Beispiel Microsoft Teams Phone, ein Softphone im Browser wie Twilio Voice oder eine SIP-basierte Telefonanlage. Hier finden die Anrufe tatsächlich statt.

CTI-Middleware. Eine serverseitige Komponente, die Telefonie und CRM verbindet. Sie übersetzt Telefonie-Ereignisse (eingehender Anruf, verbunden, beendet) in CRM-Aktionen (Screen Pop, Aktivität anlegen). In unserer Architektur läuft sie auf SAP BTP.

Sales-Cloud-V2-APIs. Die REST-APIs, mit denen Kontakte, Privatkunden und Accounts über die Telefonnummer gefunden, Account-Kontext gelesen und Telefonaktivitäten angelegt werden.

Widget im Agent Desktop. Eine UI-Komponente im Agent Desktop mit Anrufsteuerung (annehmen, halten, weiterleiten, beenden) und Anruferinformationen. Sie läuft in einem Frame und kommuniziert über die Browser-API postMessage mit der Shell.

Wie läuft ein eingehender Anruf durch das System?

Das Ziel für den gesamten Ablauf, vom Klingeln bis zum Anruferkontext auf dem Bildschirm, liegt unter zwei Sekunden. Dauert es länger, verlieren die Nutzer das Vertrauen.

1. Der Anruf trifft in der Telefonanlage ein. Sie schickt ein Anrufereignis per Webhook oder WebSocket an die Middleware.
2. Die Middleware sucht die Nummer des Anrufers in Sales Cloud V2. Engage CTI sucht in drei Stufen, der erste Treffer gewinnt: Kontakte, dann Privatkunden, dann Accounts.
3. Die Middleware pusht den Anruferkontext (Name, Account, offene Fälle, letzte Interaktionen) per WebSocket an das Widget.
4. Das Widget benachrichtigt die Shell des Agent Desktop, die den Screen Pop anzeigt und den passenden Datensatz öffnet.
5. Wenn das Gespräch endet, legt die Middleware in V2 eine Telefonaktivität mit Richtung, Dauer, Teilnehmenden und Notizen an.

Die zwei Sekunden sind nicht willkürlich. Sie entsprechen ungefähr dem Moment, in dem die Kollegin sonst fragen würde, wer am Apparat ist. Ein Screen Pop, der danach kommt, wird ignoriert.

Die Seite des Agent Desktop in Schritt 4 hat Regeln, die aus dem öffentlichen Leitfaden nicht hervorgehen: Die Shell parst nur XML, kennt nur die Aktionen NOTIFY und END und erkennt eine Sitzung ausschliesslich an ihrer Referenz-ID. Wir haben sie in Nativer Screen Pop im SSCV2 Agent Desktop dokumentiert.

Welches sind die wichtigsten technischen Entscheidungen?

WebSocket oder Polling?

Das Widget braucht Anrufereignisse in Echtzeit. Die Middleware jede Sekunde abzufragen erzeugt Last und bringt trotzdem Verzögerung. Eine WebSocket-Verbindung liefert Ereignisse, sobald sie entstehen.

Wir betreiben auf der BTP einen WebSocket-Server (Node.js), der mit jeder aktiven Agent-Desktop-Sitzung eine Verbindung hält. Kommt ein Anrufereignis aus der Telefonanlage, wird es sofort an die Verbindung der richtigen Person gepusht.

Warum nicht Server-Sent Events? Sie funktionieren für Streaming in eine Richtung, CTI braucht aber beide: Das Widget schickt Befehle zurück (halten, weiterleiten, beenden). WebSocket deckt beide Richtungen über eine Verbindung ab.

Wie gehen Sie mit dem Abgleich von Telefonnummern um?

Das klingt einfach und ist es nicht. Dieselbe Nummer kommt als +41 44 123 45 67, 044 123 45 67 oder 0041441234567 an. Die Middleware muss normalisieren, bevor sie sucht.

Wir normalisieren ins internationale Format E.164 (+41441234567). Sales Cloud V2 speichert Telefonnummern so, wie Nutzer sie eingegeben haben, die Formate im CRM sind also uneinheitlich. Normalisieren Sie beide Seiten: die eingehende Nummer und die gespeicherten Nummern, mit denen Sie vergleichen. Wer die gespeicherte Seite auslässt, bekommt Treffer, die ohne erkennbaren Grund ausbleiben, und der Support sucht lange danach.

Führen Sie einen Lookup-Index. Die V2-API bei jedem Anruf mit Wildcard-Suchen nach Telefonnummern abzufragen ist für ein Budget von zwei Sekunden zu langsam. Unsere Middleware führt eine Lookup-Tabelle, die normalisierte Nummern auf V2-Datensätze abbildet, und aktualisiert sie, wenn sich Datensätze ändern.

Wie funktioniert die Authentifizierung?

Das Widget läuft in der Agent-Desktop-Sitzung der Nutzerin; die Middleware ruft die Sales-Cloud-V2-APIs in ihrem Namen auf. Wir nutzen die Identitätsdienste von SAP auf der BTP (den AppRouter mit XSUAA) und den Identity Provider des Kunden, sodass sich niemand ein zweites Mal anmelden muss.

Die Authentifizierung zwischen Telefonie und Middleware hängt vom Anbieter ab: API-Schlüssel bei den einen, OAuth bei Cloud-Diensten wie Microsoft Teams. Die Middleware kapselt das hinter einer Adapter-Schnittstelle. Eine weitere Telefonanlage anzubinden heisst also, einen Adapter zu schreiben. Die V2-Seite bleibt gleich.

Was wird protokolliert, wenn ein Anruf endet?

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

• Richtung: eingehend, ausgehend, verpasst
• Dauer: Beginn, Ende, Gesprächszeit
• Teilnehmende: Anrufer, Angerufene, allfällige weitergeleitete Parteien
• Account-Kontext: welcher Account oder Kontakt erkannt wurde
• Notizen: von der Nutzerin während oder nach dem Gespräch im Widget erfasst
• Link zur Aufzeichnung: Zeichnet die Telefonanlage Gespräche auf, speichern wir den Link, nicht die Datei

Die Aktivität trägt dieselbe Referenz-ID, die das Widget für die Sitzung im Agent Desktop verwendet hat. Diese eine ID muss in jeder Nachricht zum Anruf identisch sein; erzeugen zwei Komponenten je ihre eigene, funktioniert der sichtbare Teil und das Aufräumen nicht.

Welche Telefonanlagen lassen sich anbinden?

Engage CTI unterstützt heute diese Varianten:

Telefonie	Anbindung	Hinweise
Microsoft Teams Phone	Teams-Integration	Häufigste Variante: Nutzer behalten Teams-Nummer und Client; Halten, Weiterleiten und Heranholen laufen über das Widget
Telefonie im Browser (Twilio Voice)	Twilio Voice SDK	Anrufe im Browser innerhalb des Agent Desktop, Headset statt Tischtelefon
SIP-basierte Telefonanlage	Anbieter-Adapter	Bestehende Anlage wird über einen Adapter angebunden; die SSCV2-Seite bleibt gleich

Andere Systeme, etwa Contact-Center-Plattformen mit eigenen Ereignis-APIs, werden nach demselben Adapter-Muster angebunden. Der Aufwand hängt vor allem davon ab, wie gut das Ereignismodell des Anbieters dokumentiert ist. Deshalb sehen wir uns dessen API an, bevor wir schätzen.

Welches sind die häufigsten Stolpersteine bei CTI?

Latenz. Erscheint der Screen Pop erst, nachdem die Nutzerin schon gefragt hat, wer anruft, nutzt ihn niemand. Zielen Sie auf unter zwei Sekunden und testen Sie mit realen Anrufvolumen, nicht mit Demo-Anrufen.

Datenqualität der Telefonnummern. Stehen im CRM Telefonnummern in fünfzehn Formaten, scheitert der Abgleich. Bereinigen und normalisieren Sie die Nummern aller Accounts und Kontakte vor dem Go-live. Langweilige Arbeit, und nicht optional.

Instabile WebSocket-Verbindungen. Firmen-Proxys, VPNs und Netzwechsel unterbrechen sie. Verbinden Sie automatisch neu, mit exponentiellem Backoff, und zeigen Sie im Widget klar an, wenn die Verbindung getrennt ist, damit Nutzer wissen, wann CTI nicht aktiv ist.

Mehrere Browser-Tabs. Nutzer öffnen mehrere Tabs, aber nur einer soll den Anruf behandeln. Wir nutzen eine Leader Election über die BroadcastChannel-API, damit der Screen Pop in genau einem Tab erscheint. Ohne sie gibt es doppelte Pop-ups oder gar keine.

Kontext bei Weiterleitungen. Wird ein Anruf weitergeleitet, muss der Kontext mitkommen, und die zweite Person sollte denselben Screen Pop sehen. Dafür müssen Anrufsitzungen verfolgt werden, nicht einzelne Gesprächsabschnitte.

Aufzeichnung und Compliance. In der Schweiz ist es strafbar, ein nicht öffentliches Gespräch ohne Einwilligung der Beteiligten aufzunehmen (Art. 179ter StGB); für bestimmte Geschäftsgespräche gibt es enge Ausnahmen. Ihre CTI-Lösung braucht konfigurierbare Aufzeichnungseinstellungen, und Ihre Rechtsabteilung sollte das Setup freigeben.

Wie betreiben Sie CTI auf SAP BTP?

Die Middleware gehört neben das CRM, nicht hinein. Auf SAP BTP in der Cloud-Foundry-Umgebung besteht unsere Architektur aus:

• einer Node.js-Anwendung mit REST-API und WebSocket-Server
• einer Datenbank für die Lookup-Tabelle der Telefonnummern und den Sitzungszustand
• dem AppRouter mit XSUAA für Authentifizierung und Mandantentrennung

Das Widget ist eine kleine Webanwendung, die im Frame des Agent Desktop geladen wird.

Im mandantenfähigen Betrieb (mehrere Kunden auf einer Middleware-Instanz) werden die Telefonie-Ereignisse jedes Kunden ausschliesslich an seinen eigenen Mandanten geleitet. Datentrennung ist hier nicht verhandelbar. Wie wir solche Erweiterungen auf der BTP generell bauen, beschreibt SAP Sales Cloud V2 mit eigenen Cloud-Foundry-Apps auf der BTP erweitern.

Wo das in der Praxis läuft

Bei Nussbaum Matzingen, einem Schweizer Verpackungshersteller, war Spadoom Engage eine von drei eigenen BTP-Apps im Sales-Cloud-V2-Projekt: Eingehende Anrufe werden erkannt, der passende Kundendatensatz öffnet sich sofort. Das Projekt, von null CRM zum Go-live in fünf Monaten, beschreibt Wie Nussbaum mit SAP Sales Cloud V2 volle Pipeline-Transparenz erreicht hat. Dasselbe Widget nutzen wir auch in unserem eigenen CRM.

---

Sie möchten Ihre Telefonanlage an SAP Sales Cloud V2 oder Service Cloud V2 anbinden? Kontakt aufnehmen. Engage CTI gibt es auch als fertiges Produkt, mit Preisen und einer 10-tägigen Testphase auf spadoom.cloud.

Häufige Fragen

Wie lange dauert eine CTI-Integration?

Das hängt von der Telefonanlage ab. Engage CTI läuft als mandantenfähiges SaaS auf SAP BTP. Mit Microsoft Teams Phone oder Telefonie im Browser über Twilio gibt es also nichts zu installieren: Wir richten Ihre Umgebung ein, und die Nutzer telefonieren im Agent Desktop. Eine Eigenentwicklung oder ein neuer Adapter für eine Telefonanlage dauert länger; der Aufwand hängt vor allem von der Ereignis-API des Anbieters ab, die wir vor jeder Schätzung prüfen.

Funktioniert CTI mit Sales Cloud V2 auch mobil?

Das CTI-Widget ist für den Agent Desktop im Browser gedacht, wo Nutzer am Arbeitsplatz telefonieren. Mobile Nutzer sehen die von CTI protokollierten Telefonaktivitäten, weil das Standard-Aktivitäten in V2 sind. Braucht ein Aussendienst Telefonie direkt auf dem Smartphone, lässt sie sich in eine mobile BTP-App einbauen, wie wir es mit der integrierten Telefonie in den Aussendienst-Apps von intelligentfood getan haben.

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

Telefonieren funktioniert weiter, weil die Telefonanlage nicht von der Middleware abhängt. Die Nutzer erhalten nur keinen Screen Pop und keine automatische Protokollierung, bis sie wieder läuft. Auf BTP Cloud Foundry läuft die Middleware mit automatischen Neustarts und Health Checks, und die Lookup-Tabelle liegt in einer Datenbank, sodass ein Neustart den Index nicht neu aufbauen muss.

Verkraftet CTI hohe Anrufvolumen?

Ja, wenn das Design stimmt. Die Engage-CTI-Middleware auf SAP BTP bewältigt über 500 gleichzeitige WebSocket-Verbindungen und verarbeitet ein Anrufereignis in unter 50 ms (Engage CTI). Für grössere Contact Center skaliert sie horizontal auf Cloud Foundry, mit Sitzungsaffinität, damit jede WebSocket-Verbindung auf ihrer Instanz bleibt.

Werden Gesprächsaufzeichnungen in Sales Cloud V2 gespeichert?

Nein, und das sollten sie auch nicht. Aufzeichnungen bleiben im Speicher der Telefonanlage; wir speichern nur den Link an der Telefonaktivität in V2. Das vermeidet Speicherkosten, hält sensible Audiodaten in der compliance-geprüften Umgebung der Telefonanlage und respektiert Vorgaben zum Datenstandort. Nutzer öffnen die Aufzeichnung über den Player der Telefonanlage.