SAP Service Cloud V2 vs. V1: Was sich geändert hat und warum es zählt
CEO Spadoom AG & Sprecher DSAG AG CX Schweiz
Service Cloud V1 (die Service-Seite von SAP Cloud for Customer, C4C) beherrscht das klassische Ticketing: Fälle kommen herein, Agenten bearbeiten sie, Tickets werden geschlossen. Ihr Alter zeigt sich beim Routing, bei der Kategorisierung und bei einem Erweiterungsmodell, das jede Anpassung teuer macht. SAP hat diese Codebasis nicht weiterentwickelt, sondern Service Cloud V2 als neues Produkt gebaut, und dorthin fliesst heute die Service-Innovation.
Dieser Beitrag vergleicht die beiden Versionen Bereich für Bereich, damit Sie einschätzen können, was V2 für Ihren Service-Desk ändert und was ein Wechsel bedeutet.
Kurzfassung: Service Cloud V2 ersetzt die flachen Tickets von V1 durch eine Fall-Lebenszyklus-Engine, regelbasierte Zuweisung durch kompetenzbasiertes Routing mit Lastverteilung und die PDI/SDK-Erweiterungen von C4C durch Services nebenan auf SAP BTP, und sie bettet KI direkt in die Arbeit der Agenten ein. Der Wechsel ist eine Neueinführung und kein Upgrade: Planen Sie 4 bis 6 Monate für 20 bis 50 Agenten und 6 bis 10 Monate für 50 bis 200. Bringen Sie Datenqualität und Routing-Design in Ordnung, bevor Sie die KI-Funktionen einschalten.
Wie unterscheidet sich das Fallmanagement?
Das ist die grundlegende Änderung. In V1 ist ein Ticket ein flacher Datensatz mit Statusfeldern: Status ändern, Notiz ergänzen, schliessen. V2 ersetzt das durch einen strukturierten Fall, der als Workflow-Engine arbeitet. SAP beschreibt das Modell im Hilfeportal zu SAP Service Cloud Version 2.
Fall-Lebenszyklus. Fälle durchlaufen konfigurierbare Status mit definierten Übergängen. Sie legen fest, welche Status welche Aktionen erlauben, wer einen Übergang auslösen darf und was bei jedem Schritt automatisch passiert. Aus einem einfachen Statusfeld wird eine Prozess-Engine, die zur Arbeitsweise von Service-Teams passt.
Fallhierarchie. V2 unterstützt übergeordnete und untergeordnete Fälle standardmässig. Ein komplexes Kundenanliegen erzeugt Teilfälle für Fakturierung, Technik und Logistik, während der übergeordnete Fall die Gesamtlösung verfolgt. In V1 ging das nur mit Workarounds.
SLA-Überwachung. Reaktions- und Lösungsziele starten automatisch nach Fallpriorität und Kundenstufe. Agenten sehen Countdowns, Führungskräfte Compliance-Dashboards. V1 hatte eine einfache SLA-Unterstützung; in V2 wird sie Teil des Tagesgeschäfts. (Das Gegenstück im Vertrieb: SAP Sales Cloud V2 vs. C4C.)
Was ist beim Routing anders?
V1 verteilt Fälle manuell oder nach einfachen Regeln: Produkt A an Team A, Region B an Team B. Das stösst bei Sonderfällen, ungleich verteilten Warteschlangen und komplexen Anliegen bei jungen Agenten an Grenzen.
V2 bringt ein Routing, das Kompetenzen und Kapazität berücksichtigt.
Kompetenzbasiertes Routing. Sie definieren Skills der Agenten (Sprache, Produktwissen, Zertifizierungsstufe) und leiten Fälle an Agenten, die sie tatsächlich lösen können.
Warteschlangen. Fälle landen in nach Priorität geordneten Warteschlangen. Agenten arbeiten aus der Warteschlange oder erhalten Zuweisungen nach Kapazität und Skill-Übereinstimmung.
Lastverteilung. V2 verteilt Fälle nach der Auslastung der Agenten. Wer 15 offene Fälle hat, bekommt den nächsten nicht vor einer Kollegin mit fünf. Das klingt selbstverständlich und macht in der Praxis einen grossen Unterschied.
Kanalunabhängiger Posteingang. E-Mail, Telefon, Chat und Webformulare werden zu Fallquellen mit einheitlichem Routing, und die Agenten arbeiten in einem einzigen Posteingang.
Wie verändert KI den Servicebetrieb?
Hier macht V2 den grössten Schritt. C4C hat einige KI-Funktionen, doch neue KI, einschliesslich Joule und seiner Agenten, zielt auf V2 und ist direkt in den Service-Ablauf eingebettet.
Fallklassifizierung. Die KI liest die Fallbeschreibung und schlägt Kategorie, Unterkategorie und Priorität vor. Wie treffsicher die Vorschläge sind, hängt von Qualität und Menge Ihrer historischen Fälle ab, und sie werden besser, wenn Agenten Ausnahmen korrigieren. Messen Sie die Treffsicherheit während des parallelen Aufbaus an Ihren eigenen Daten, statt sich auf eine Herstellerzahl zu verlassen.
Stimmung und Zusammenfassungen. V2 kann negative Kundenstimmung markieren und lange Fallverläufe zusammenfassen, sodass Agenten und Teamleitungen sofort sehen, was zuerst Aufmerksamkeit braucht.
Antwortvorschläge. Joule entwirft Antworten auf Basis des Fallinhalts und ähnlicher gelöster Fälle. Agenten überarbeiten und senden, statt bei null anzufangen.
Wissensempfehlungen. Passende Artikel erscheinen neben dem Fall, abgestimmt auf seinen Kontext, sodass Agenten weniger suchen.
Digital Service Agents. Diese Agenten erledigen Routineanfragen durchgängig (Bestellstatus, Standardretouren, einfache Kontoänderungen) und übergeben bei Bedarf an einen Menschen. Was sie in der Praxis leisten, beschreiben wir in Digital Service Agents in SAP Service Cloud V2, die jüngsten Neuerungen in Was ist neu in SAP Service Cloud V2 im Jahr 2026.
Wie unterscheidet sich die API-Architektur?
V2 ist API-first gebaut: Was in der Oberfläche möglich ist, steht auch über APIs zur Verfügung. Im Service wiegt das schwerer als im Vertrieb, weil Service-Desks mehr Schnittstellen haben: Telefonie, Chatbots, Wissensdatenbanken, Field-Service-Tools, ERP und Commerce hängen alle am Fallmanagement.
Ereignisbasierte Integration. V2 veröffentlicht Business Events (Fall angelegt, Fall geändert und ähnliche), sodass Erweiterungen und Middleware wie die SAP Integration Suite nahezu in Echtzeit reagieren können, statt Änderungen abzufragen. Mit V1 hiess das meist Polling oder eigene Benachrichtigungslogik.
Erweiterungen nebenan auf BTP. Für das PDI/SDK von C4C gibt es in V2 kein Gegenstück. Erweiterungen laufen auf SAP BTP mit Node.js, Java oder CAP, sodass Sie eigene Eskalationslogik, externe Wissensanbindungen oder spezielle Dashboards bauen können, ohne den Kern der Service Cloud anzufassen. Gehört S/4HANA zu Ihrer Landschaft, zeigt SAP Service Cloud V2 + S/4HANA Public Cloud: vom Service-Ticket zum ERP-Auftrag, wie die ERP-Seite angebunden wird.
Was bedeutet das für die Migrationsplanung?
Wenn Sie heute V1 betreiben und V2 in Betracht ziehen, planen Sie mit diesen Punkten.
Es ist kein Upgrade. Ihre V1-Konfiguration, eigene Objekte und Schnittstellen werden nicht übernommen. Behandeln Sie den Wechsel als Neueinführung mit Datenmigration; das jetzt einzuplanen ist besser, als es mitten im Projekt zu entdecken.
Die Routing-Regeln brauchen ein neues Design. Die kompetenzbasierte Engine von V2 kann mehr und funktioniert anders als die Zuweisungsregeln von V1. Entwerfen Sie das Routing aus Ihrem Service-Modell, nicht aus den alten Regeln.
Die Wissensdatenbank muss neu strukturiert werden. Das Wissensmanagement von V2 speist die KI-Funktionen. Die Migration ist der richtige Moment, Inhalte zu bereinigen und neu zu ordnen.
Die Schulung der Agenten ist Pflicht. Oberfläche, Abläufe, SLA-Sicht und KI-Funktionen ändern sich. Agenten brauchen eine strukturierte, praktische Schulung.
Heute zwingt keine Frist zum Wechsel. Stand September 2026 hat SAP für C4C kein Wartungsende angekündigt, und V1 erhält weiterhin Releases; neue Funktionen gehen in V2. Die aktuellen Pläne zeigt der SAP Roadmap Explorer, die Dokumentation zu SAP Cloud for Customer deckt V1 ab.
Planen Sie mindestens 4 bis 6 Monate für 20 bis 50 Agenten und 6 bis 10 Monate für 50 bis 200 Agenten. Die Phasen beschreibt unser Plan für die Migration von C4C zu Service Cloud V2.
Häufig gestellte Fragen
Kann ich von V1 auf V2 upgraden?
Nein. V2 ist ein eigenständiges Produkt mit eigenem Datenmodell, eigenen APIs und eigenem Erweiterungsmodell, der Wechsel ist also eine Neueinführung. Eigene Felder, Schnittstellen und Erweiterungen müssen neu gebaut werden; Daten werden mit den Migrationswerkzeugen von SAP übernommen, die Konfiguration jedoch nicht.
Welche KI-Funktionen bietet V2?
V2 bettet KI in den Service-Ablauf ein: Vorschläge zur Fallklassifizierung, Fallzusammenfassungen, Antwortentwürfe mit Joule, Wissensempfehlungen und Digital Service Agents für Routineanfragen. Der genaue Umfang hängt von Lizenz und Release ab; prüfen Sie vor der Planung die aktuelle SAP-Dokumentation und Roadmap.
Wie lange sollten wir für die Migration planen?
Als Planungswert: 4 bis 6 Monate für 20 bis 50 Agenten mit mittlerer Komplexität, 6 bis 10 Monate für 50 bis 200 Agenten und 10 bis 14 Monate für stark angepasste Umgebungen. Am häufigsten dauert der Neubau der Schnittstellen länger als erwartet.
Wird V1 weiterhin unterstützt?
Ja. Stand September 2026 hat SAP für C4C (V1) kein Wartungsende angekündigt, und V1 erhält weiterhin Releases. Die Innovation von SAP, einschliesslich neuer Joule-AI-Funktionen, konzentriert sich auf V2.
Brauchen wir für V2 neue Kompetenzen?
Ja. V2-Erweiterungen laufen nebenan auf SAP BTP (Node.js, Java oder SAP CAP) statt im PDI/SDK von C4C, und auch Administration und Konfiguration funktionieren anders. Planen Sie Schulungen ein oder arbeiten Sie mit einem Partner, der V2-Projekte umgesetzt hat.
Fragen Sie Spadoom
Antworten auf Basis dessen, was Spadoom auf dieser Website veröffentlicht hat, mit Links zu den Quellseiten.
Versuchen Sie eine dieser Fragen
KI-generierte Antworten. Vor Entscheidungen prüfen. Fragen werden anonym und ohne IP-Adresse gespeichert, damit wir unsere Inhalte verbessern können. Bitte geben Sie keine Personendaten ein.
SAP Service Cloud V2 Implementierungspartner
Spadoom ist Ihr SAP Service Cloud V2 Implementierungspartner in der Schweiz, Deutschland, Österreich und Italien. 14 Wochen Median-Go-Live. Live-Kunden in der gesamten DACH-Region.
Verwandte Artikel
Von SAP C4C zu Service Cloud V2 migrieren: ein Plan in fünf Phasen
Der Wechsel Ihres Service-Desks von C4C zu SAP Service Cloud V2 ist eine Neueinführung, kein Upgrade. Dieser Plan beschreibt die fünf Phasen, realistische Zeitrahmen und den Integrationsaufwand, den die meisten Teams unterschätzen.
Vier Sprachen, ein CRM: SSCV2 wirklich mehrsprachig machen
Schweiz heisst vier Sprachen, und ein CRM, das die falsche erwischt, wirkt kaputt. Was wir auf Kundenprojekten gelernt haben, um SSCV2 vollständig mehrsprachig zu machen: fünf Regeln und die Prüfungen, die sie durchsetzen.
Nativer Screen Pop im SSCV2 Agent Desktop: Was das PDF verschweigt
Im August 2026 haben wir unser Telefonie-Widget an den nativen Screen Pop des SSCV2 Agent Desktop angebunden. Der öffentliche Integrationsleitfaden deckt die Hälfte des Vertrags ab. Hier die andere Hälfte, im September 2026 an echten Anrufen verifiziert.