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

SAP Service Cloud V1 (die Serviceseite von C4C) tat seinen Dienst. Tickets kamen rein, Agenten bearbeiteten sie, Cases wurden geschlossen. Aber das System zeigte sein Alter: begrenzte Routing-Optionen, einfache Kategorisierung und ein Erweiterungsmodell, das jede Anpassung zum Risiko machte.

Service Cloud V2 ist ein Komplettneubau. Gleicher Name, neues Produkt. Ob Sie es für eine Neuimplementierung evaluieren oder eine Migration von V1 planen — hier ist, was sich tatsächlich geändert hat.

Neues Case Management

V2s Case Management ist grundlegend anders. In V1 war ein Ticket ein flacher Datensatz mit Statusfeldern. In V2 ist ein Case eine strukturierte Entität mit eigenem Lifecycle-Engine.

Case-Lifecycle-Management. Cases durchlaufen konfigurierbare Zustände mit definierten Übergängen. Sie legen fest, welche Zustände welche Aktionen erlauben, wer Übergänge auslösen kann und was bei jedem Schritt automatisch passiert. Das ersetzt das einfache Statusfeld durch eine vollwertige Workflow-Engine.

Case-Hierarchie. V2 unterstützt Eltern-Kind-Case-Beziehungen nativ. Ein komplexes Kundenanliegen kann Sub-Cases für verschiedene Teams erzeugen — Abrechnung, Technik, Logistik — während der übergeordnete Case die Gesamtlösung verfolgt. V1 erforderte Workarounds dafür.

SLA-Tracking. Service Level Agreements sind in die Case-Entität eingebaut. Antwortzeit- und Lösungszeit-SLAs werden automatisch basierend auf Case-Priorität und Kundenstufe ausgelöst. Agenten sehen Countdown-Timer. Manager sehen SLA-Compliance-Dashboards. V1 hatte einfache SLA-Unterstützung; V2 macht es operativ nutzbar.

Omnichannel-Routing

V1 routete Cases per manueller Zuweisung oder einfacher Regeln. V2 führt echtes Routing ein:

Skills-basiertes Routing. Definieren Sie Agenten-Skills (Sprache, Produktexpertise, Zertifizierungsstufe) und leiten Sie Cases an Agenten, die sie tatsächlich bearbeiten können. Kein “dem Team zuweisen und hoffen, dass die richtige Person es aufnimmt” mehr.

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

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

Lastverteilung. V2 verteilt Cases basierend auf der Agenten-Arbeitslast. Hat ein Agent 15 offene Cases und ein anderer 5, gehen neue Cases an den mit Kapazität. V1 berücksichtigte die Arbeitslast gar nicht.

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 häufigen Anliegen (Passwort-Rücksetzungen, Abrechnungsfragen, Standard-Produktfragen) ist die KI genau genug, um ohne Agenten-Eingriff zu klassifizieren.

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 ö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 nicht bei null — sie starten mit relevantem Kontext.

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, die in der Oberfläche verfügbar ist, ist über REST-APIs erreichbar.

Warum das für Service wichtig ist: Service-Umgebungen haben mehr Integrationen als Sales. Telefoniesysteme, Chatbots, Wissensdatenbanken, Field-Service-Tools, ERP — alle müssen mit dem Case-Management-System kommunizieren. V2s umfassende API-Abdeckung macht diese Integrationen sauberer und zuverlässiger.

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

Event-driven Integration. V2 publiziert Events (Case erstellt, Case aktualisiert, SLA verletzt) an SAP Event Mesh. Ihre Erweiterungen reagieren in Echtzeit auf Events, 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 konzipiert werden.

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

Agenten-Schulung. Die Oberfläche ist anders. Workflows sind anders. SLA-Transparenz ist anders. Agenten brauchen strukturierte Schulung, nicht nur eine “Hier ist das neue System”-E-Mail.

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

Rechnen Sie mit 4-6 Monaten. Für eine mittelgrosse Service-Organisation (20-50 Agenten) dauert eine fokussierte V2-Implementierung 4-6 Monate. Komplexe Umgebungen mit starker Anpassung brauchen länger.

Was Spadoom gelernt hat

Wir haben Service Cloud V2 zusammen mit Sales Cloud V2 bei mehreren Kunden implementiert. Wichtige Beobachtungen:

Starten Sie mit dem Routing. Die Routing-Engine ist die grösste Verbesserung und am komplexesten zu konfigurieren. Machen Sie es früh richtig — es beeinflusst alles Nachgelagerte.

KI braucht Daten. Die Klassifikations-KI braucht echte Case-Daten zum Trainieren. Importieren Sie historische Cases, falls vorhanden. Setzen Sie Erwartungen, dass die KI-Genauigkeit sich in den ersten 2-3 Monaten verbessert.

Omnichannel ist eine Prozessänderung, nicht nur eine Technologieänderung. Wenn Ihre Agenten derzeit in separaten E-Mail- und Telefon-Queues arbeiten, ändert der Wechsel zu einem einheitlichen Posteingang ihren Workflow. Planen Sie dafür.

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.