SAP Service Cloud V2: Was anders ist und warum es zählt

SAP Service Cloud V1 — also die Service-Seite von C4C — hat funktioniert. Tickets rein, Agenten ran, Cases zu. Das war branchenüblich, und eine Weile reichte das. Aber prima vista war schon länger klar: begrenztes Routing, starre Kategorisierung und ein Erweiterungsmodell, bei dem jede Anpassung zum Drahtseilakt wurde.

V2 ist kein Update. V2 ist ein Neubau. Gleicher Name, komplett anderes Produkt. Ob Sie es für eine frische Implementierung prüfen oder von V1 migrieren: Hier die konkreten Unterschiede.

Neues Case Management

V2 definiert Case Management grundlegend neu. In V1 war ein Ticket ein flacher Datensatz mit Statusfeldern. In V2 ist ein Case eine strukturierte Entität mit eigener Lifecycle-Engine.

Das Case-Lifecycle-Management arbeitet mit konfigurierbaren Zuständen und definierten Übergängen. Sie bestimmen, welche Zustände welche Aktionen erlauben, wer Übergänge auslösen kann und was bei jedem Schritt automatisch geschieht. Statt eines simplen Statusfelds: eine vollwertige Workflow-Engine.

V2 unterstützt nativ Eltern-Kind-Case-Beziehungen. Ein komplexes Kundenanliegen erzeugt Sub-Cases für Abrechnung, Technik, Logistik — der übergeordnete Case verfolgt die Gesamtlösung. In V1 brauchte man Workarounds dafür.

Beim SLA-Tracking gilt: Service Level Agreements sind direkt in die Case-Entität eingebaut. Antwort- und Lösungszeit-SLAs werden automatisch basierend auf Priorität und Kundenstufe ausgelöst. Agenten sehen Countdown-Timer, Manager SLA-Compliance-Dashboards. V1 hatte rudimentäre SLA-Unterstützung; V2 macht das Ganze operativ nutzbar.

Omnichannel-Routing

V1 routete Cases per manueller Zuweisung oder über simple Regeln. V2 bringt echtes Routing mit.

Beim Skills-basierten Routing definieren Sie Agenten-Skills — Sprache, Produktexpertise, Zertifizierungsstufe — und leiten Cases an jene Agenten, die sie tatsächlich lösen können. Schluss mit «dem Team zuweisen und hoffen».

Im Queue-Management betreten Cases Queues mit Prioritätsordnung. Agenten arbeiten aus Queues oder erhalten automatische Zuweisungen basierend auf Kapazität und Skills-Matching.

Kanalunabhängigkeit: E-Mail, Telefon, Chat, Social Media, Webformulare — V2 behandelt alle als Case-Quellen mit einheitlichem Routing. Agenten sehen einen Posteingang, egal wie der Kunde Kontakt aufgenommen hat.

Und dann die Lastverteilung. V2 verteilt Cases basierend auf der Agenten-Arbeitslast. Hat ein Agent 15 offene Cases und ein anderer 5, gehen neue Cases dorthin, wo Kapazität ist. V1 hat die Arbeitslast schlicht ignoriert.

KI-gestützte Klassifikation

Hier macht V2 den grössten Sprung.

Automatische Kategorisierung: Wenn ein Case eingeht, liest V2s KI die Beschreibung und schlägt Kategorie, Unterkategorie und Priorität vor. Bei Standardanliegen — Passwort-Rücksetzungen, Abrechnungsfragen, typische Produktfragen — klassifiziert die KI zuverlässig genug ohne Agenten-Eingriff.

Sentiment-Analyse: V2 analysiert die Sprache des Kunden und markiert negative Stimmung. Frustrierte Kunden werden automatisch priorisiert. Agenten sehen einen Stimmungsindikator, bevor sie den Case überhaupt öffnen.

Lösungsvorschläge: Basierend auf dem Case-Inhalt schlägt V2 Knowledge-Base-Artikel und Lösungsschritte aus ähnlichen früheren Cases vor. Agenten starten mit relevantem Kontext statt bei null.

Kontinuierliches Lernen: Das KI-Modell verbessert sich, wenn Agenten seine Vorschläge korrigieren. Nach einigen Monaten mit echten Daten erreicht die Klassifikationsgenauigkeit typischerweise 80-90 % für die häufigsten Case-Kategorien.

API-first-Architektur

Wie Sales Cloud V2 ist Service Cloud V2 API-first gebaut. Jede Operation der Oberfläche ist über REST-APIs erreichbar.

Warum das im Service-Kontext besonders zählt: Service-Umgebungen haben de facto mehr Integrationen als Sales. Telefoniesysteme, Chatbots, Wissensdatenbanken, Field-Service-Tools, ERP — alles muss mit dem Case-Management-System kommunizieren. V2s umfassende API-Abdeckung macht diese Integrationen sauberer und zuverlässiger.

Eigene Erweiterungen laufen auf BTP. Das alte V1-Erweiterungsmodell (PDI) ist weg. Erweiterungen laufen auf SAP BTP — Node.js, Java, CAP, Cloud Foundry. Konkret heisst das für Service-Szenarien: Sie können individuelle Eskalationslogik, Konnektoren zu externen Systemen oder spezialisierte Agenten-Tools bauen, ohne den Service Cloud Kern anzufassen.

Und dann Event-driven Integration: V2 publiziert Events (Case erstellt, Case aktualisiert, SLA verletzt) an SAP Event Mesh. Ihre Erweiterungen reagieren in Echtzeit, statt nach Änderungen zu pollen. Das ist die Grundlage einer sauberen, wartbaren Architektur.

Was das für die Migration bedeutet

Wenn Sie V1 nutzen und V2 erwägen, hier das ehrliche Bild.

Es ist kein Upgrade. Genau wie bei Sales Cloud ist Service Cloud V2 eine Reimplementierung. Ihre V1-Konfiguration, Custom Objects und Integrationen lassen sich nicht direkt übertragen.

Routing-Regeln müssen neu konzipiert werden. V2s Routing-Engine ist leistungsfähiger, aber komplett anders. Ihre V1-Zuweisungsregeln müssen für V2s Skills-basiertes Modell neu gedacht werden.

Knowledge-Base-Migration: Wenn Sie eine Wissensdatenbank in V1 pflegen, braucht sie Migrationsplanung. V2s Wissensmanagement ist mit den KI-Features integriert — ein guter Zeitpunkt, Ihre Inhalte zu restrukturieren.

Agenten-Schulung darf nicht zu kurz kommen. Die Oberfläche ist anders. Workflows sind anders. SLA-Transparenz ist anders. Agenten brauchen strukturierte Schulung, nicht bloss eine «Hier ist das neue System»-E-Mail.

Jede V1-Integration muss überprüft werden. API-Endpunkte und Datenmodelle haben sich geändert. Planen Sie Integrationsaufwand adäquat ein.

Für eine mittelgrosse Service-Organisation (20-50 Agenten) rechnen Sie mit 4-6 Monaten fokussierter V2-Implementierung. Komplexe Umgebungen mit starker Anpassung brauchen länger. Das ist kein Pessimismus, das ist Projekterfahrung.

Was Spadoom gelernt hat

Wir haben Service Cloud V2 zusammen mit Sales Cloud V2 bei mehreren Kunden implementiert. Drei Beobachtungen stechen hervor.

Starten Sie mit dem Routing. Die Routing-Engine ist die grösste Verbesserung und zugleich am anspruchsvollsten zu konfigurieren. Machen Sie es früh richtig — es beeinflusst alles, was danach kommt.

KI braucht Daten. Die Klassifikations-KI braucht echte Case-Daten zum Trainieren. Importieren Sie historische Cases, falls vorhanden. Und setzen Sie Erwartungen realistisch: Die KI-Genauigkeit verbessert sich in den ersten 2-3 Monaten spürbar.

Omnichannel ist eine Prozessänderung, keine reine Technikfrage. Wenn Ihre Agenten heute in separaten E-Mail- und Telefon-Queues arbeiten, ändert der Wechsel zu einem einheitlichen Posteingang ihren kompletten Workflow. Planen Sie dafür.

Nota bene: BTP-Erweiterungen zahlen sich schnell aus. Die wirkungsvollsten V2-Projekte, die wir umgesetzt haben, beinhalten mindestens eine BTP-Erweiterung — ein individuelles Eskalationstool, einen externen Wissens-Konnektor oder ein spezialisiertes Reporting-Dashboard.

Sie evaluieren SAP Service Cloud V2 für Ihre Service-Organisation? Wir zeigen Ihnen, was für Ihr Setup realistisch ist. Kontakt aufnehmen.