SAP Service Cloud V2 implementieren: Schritt für Schritt für B2B-Teams

Die meisten SAP Service Cloud V2 Projekte, die ins Stocken geraten, scheitern am Vorgehen, nicht an der Software. Ein Team wählt das richtige Produkt, unterschreibt den Vertrag und steigt direkt in die Konfiguration ein, ohne vorher das eigene Servicemodell zu verstehen. Drei Monate später folgen Nacharbeit, Budgetüberschreitung und frustrierte Servicemitarbeitende.

Dieser Leitfaden deckt die ganze Implementierung ab, vom ersten Scoping-Gespräch bis zum Ende der Hypercare. Er folgt der SAP Activate Methodik, die wir in jedem Projekt einsetzen, angepasst an Service Cloud V2 im B2B-Umfeld.

Wenn Sie von C4C (Service Cloud V1) migrieren, beginnen Sie besser mit unserem Migrationsleitfaden. Dieser Beitrag richtet sich an Teams, die Service Cloud V2 als neues System einführen, ob es nun ein Altsystem, Tabellen oder geteilte Postfächer ablöst. Zu den Budgets lesen Sie den Preis- und Kostenleitfaden für Service Cloud V2.

Kurzfassung: Eine Service Cloud V2 Implementierung für ein mittelgrosses B2B-Team (50 bis 150 Servicemitarbeitende) dauert nach SAP Activate 10 bis 16 Wochen bis zum Go-Live, dazu kommen rund vier Wochen Hypercare. Fünf Phasen: Discovery und Vorbereitung, Konfiguration, ERP-Integration, Tests und Migration, Go-Live und Hypercare. Die grössten Risiken sind unsaubere Daten, Überkonfiguration, ein vernachlässigtes Arbeitserlebnis der Servicemitarbeitenden und gekürzte Schulungen. Einfache Einführungen gehen nach rund 8 Wochen live, Enterprise-Projekte mit mehreren Integrationen brauchen 4 bis 6 Monate.

Lieber ein Partner als ein Leitfaden zum Selbermachen? Spadoom ist Schweizer SAP Gold Partner für Cloud ERP und Customer Experience: Wir implementieren SAP Service Cloud V2 und die S/4HANA-Seite der Integration mit einem Team, in der Schweiz, in Deutschland, Österreich und Italien. Scoping-Gespräch anfragen oder lesen Sie, wie intelligentfood mit Sales und Service Cloud V2 in drei Monaten live ging.

Warum das Vorgehen wichtiger ist als die Software

SAP Service Cloud V2 bringt einen konfigurierbaren Case Designer, Routing nach Team, Falltyp oder Kategorie, Standard-SLAs, KI-Empfehlungen für die Fallkategorie und ähnliche Fälle sowie einen Agent Desktop für Telefon, E-Mail und Chat. Den verbindlichen Umfang listet SAP in der Feature Scope Description auf.

Nichts davon hilft, wenn die Konfiguration nicht dazu passt, wie Ihr Serviceteam arbeitet.

Wir haben Organisationen gesehen, die 47 Status im Fall-Lebenszyklus konfiguriert haben, weil man sie «vielleicht brauchen könnte», SLA-Setups mit über 200 Regeln, die niemand mehr pflegen kann, und Wissensdatenbanken mit 3’000 Artikeln aus einem Altsystem, die meisten davon veraltet. Wie diese Projekte ausgingen, können Sie sich denken.

Das Muster ist immer gleich: Teams, die ihr Servicemodell verstehen, bevor sie konfigurieren, sind schneller fertig, geben weniger aus und erreichen eine höhere Akzeptanz bei den Servicemitarbeitenden. Teams, die mit dem Werkzeug beginnen, landen in einer Schleife aus Nacharbeit. Deshalb beginnt dieser Leitfaden vor dem eigentlichen Projekt.

Vor dem Projekt: Scoping und Readiness-Prüfung

Bevor Sie ein Angebot unterschreiben, beantworten Sie vier Fragen. Jede, die Sie überspringen, holt Sie später wieder ein, meistens im Abnahmetest.

1. Wie sieht Ihr Servicemodell aus?

Bilden Sie ab, wie Service heute wirklich funktioniert: den echten Ablauf, nicht das Prozessdiagramm an der Wand. Setzen Sie sich zu den Servicemitarbeitenden und schauen Sie zu, wie sie Fälle bearbeiten. Dokumentieren Sie:

• Falltypen: Welche Arten von Anfragen kommen herein? Technische Probleme, Abrechnungsfragen, Retouren, Garantieansprüche, allgemeine Anfragen? Sortieren Sie nach Volumen.
• Lösungswege: Welche Fälle gehen direkt zur Lösung? Welche springen zwischen Teams hin und her? Wo liegen die Übergaben?
• Eskalationsauslöser: Was macht einen Fall dringend? SLA-Verletzung, Kundensegment, Produkttyp, wiederholte Kontaktaufnahme?
• Teamstruktur: Wie sind die Servicemitarbeitenden gruppiert? Nach Kompetenz, Region, Produktlinie oder Kundensegment?

Das ist die wertvollste Übung der ganzen Implementierung. Jede Konfigurationsentscheidung (Routing-Regeln, SLA-Definitionen, Status im Fall-Lebenszyklus) leitet sich aus diesem Modell ab.

2. Welche Kanäle nutzen Ihre Kunden?

Erfassen Sie jeden eingehenden Kanal:

• E-Mail: Wie viele geteilte Postfächer? Welches Volumen pro Tag?
• Telefon: Welche Contact-Center-Plattform setzen Sie ein (Cisco, Genesys, Microsoft Teams)? Brauchen Sie CTI?
• Chat: Live-Chat auf der Website? Chat in der App? WhatsApp Business?
• Webformulare: Ein Kundenportal mit Ticketformular?
• Social Media: Melden Kunden Serviceanliegen über LinkedIn, X oder Facebook?

Notieren Sie für jeden Kanal das heutige Volumen und das erwartete Volumen nach dem Go-Live. Das bestimmt die Kanalkonfiguration und die Kapazitätsplanung. Beachten Sie: Telefon, Chat und SMS erreichen den Agent Desktop von V2 über Kommunikationsanbieter von Drittherstellern und ein UI-Widget, E-Mail wird nativ verarbeitet.

3. Welche SLAs gelten?

Dokumentieren Sie jede Service-Level-Vereinbarung, intern und extern:

• Reaktionszeiten nach Priorität (zum Beispiel P1: 1 Stunde, P2: 4 Stunden, P3: 8 Stunden, P4: 24 Stunden)
• Lösungszeiten nach Falltyp und Priorität
• Eskalationsregeln: Was passiert, wenn ein SLA zu reissen droht?
• Kundensegmente: Erhalten Premiumkunden schnellere Antworten?
• Geschäftszeiten: Unterschiedliche Kalender für unterschiedliche Regionen?

Service Cloud V2 liefert Standard-SLAs für Erstreaktion, Bearbeitungszeit und Zeit bis zum Abschluss und lässt eigene Parameter zu. Das funktioniert gut, wenn die Vorgaben sauber sind. Unklare SLAs führen zu unklarer Automatisierung.

4. Welche Systeme müssen angebunden werden?

Zeichnen Sie die Integrationslandschaft:

• ERP: S/4HANA oder ECC? Welche Daten brauchen die Servicemitarbeitenden: Auftragshistorie, Garantiestatus, installierte Basis, Abrechnung?
• Aussendienst: Werden Fälle an Technikerinnen und Techniker vor Ort eskaliert? Dann planen Sie die Integration von SAP Field Service Management ein.
• Telefonie: CTI für Screen Pop und Anrufprotokollierung?
• Wissensdatenbank: In welchem Wissenssystem sollen die Servicemitarbeitenden suchen? V2 bindet eine externe Wissensdatenbank an, statt eine eigene mitzubringen.
• Identity Provider: SSO über Microsoft Entra ID, SAP Cloud Identity Services oder einen anderen IdP?
• Data Warehouse und BI: Reporting-Anforderungen über die eingebettete SAP Analytics Cloud hinaus?

Jede Integration erweitert den Umfang, und Integrationen dauern regelmässig länger als geschätzt. Planen Sie den Puffer jetzt ein, statt zu hoffen, dass Sie ihn nicht brauchen.

Phase 1: Discovery und Vorbereitung (Wochen 1 bis 3)

Diese Phase entspricht den Phasen Discover und Prepare von SAP Activate. Ziel ist, aus dem Scoping einen konkreten Projektplan ohne offene Unklarheiten zu machen.

Workshops

Führen Sie strukturierte Workshops mit drei Gruppen durch.

Serviceleitung (1 Tag): strategische Ziele, KPIs, SLA-Vorgaben, Reporting-Bedarf. Woran erkennen Sie sechs Monate nach dem Go-Live den Erfolg? Nicht an «besserem Service», sondern an konkreten Zahlen wie «Reaktionszeit P1 unter 30 Minuten, Erstlösungsquote über 65 %».

Teamleitungen und erfahrene Servicemitarbeitende (2 Tage): detaillierte Durchgänge pro Falltyp, Ausnahmefälle und die Umgehungslösungen, die sich rund um das heutige System gebildet haben. Diese Umgehungslösungen zeigen Anforderungen, die in keinem Prozessdokument stehen, und es gibt immer mehr davon, als man erwartet.

IT- und Integrationsteam (1 Tag): Systemlandschaft, verfügbare APIs, Datenzugriff, Sicherheits- und Compliance-Anforderungen, Tenant- und Landschaftsaufbau (Test- und Produktivtenant, Transport der Konfiguration).

Anforderungen zuordnen

Erstellen Sie ein Anforderungsdokument, das jedes fachliche Bedürfnis einer Funktion von Service Cloud V2 zuordnet:

Anforderung	Funktion in V2	Nötige Konfiguration	Eigenentwicklung
Abrechnungsfälle an das Finanzteam leiten	Routing nach Kategorie und Team	Kategorien, Teams, Routing-Regeln	Nein
Auftragshistorie des Kunden im Fall anzeigen	S/4HANA-Integration	Standard-Integrationsinhalt, Mashup oder replizierte Daten	Nur für Daten ausserhalb des Standards
Kategorie für eingehende E-Mail-Fälle vorschlagen	KI-Empfehlungen für die Fallkategorie	Bereinigte historische Kategorien, Aktivierung	Nein
P1-Fälle nach 30 Minuten an die Leitung eskalieren	SLAs plus Autoflow	SLA-Definition, Autoflow-Regel mit Benachrichtigung	Nein
CTI-Screen-Pop bei eingehenden Anrufen	Agent Desktop mit Widget des Drittanbieters	Widget des Anbieters, Kundensuche	Abhängig vom Anbieter

Diese Tabelle ist Ihr Implementierungs-Backlog. Jede Zeile wird geschätzt, priorisiert und einem Sprint zugeordnet.

Datenprüfung

Prüfen Sie die Daten, die Sie nach V2 übernehmen wollen:

• Konto- und Kontaktdaten: Wie sauber sind sie? Dubletten? Fehlende Felder? Verwaiste Kontakte?
• Historische Fälle: Brauchen Sie diese in V2? Wie viele, in welchem Format?
• Wissensartikel: Wie viele? Wann wurden sie zuletzt geprüft? Wie viele stimmen noch?
• Daten zu Servicemitarbeitenden und Teams: Rollen, Kompetenzen, Verfügbarkeiten

Unsaubere Daten sind die häufigste Ursache für Verzögerungen, die wir sehen. Wenn Ihre Kontodaten zu 30 % aus Dubletten bestehen, bereinigen Sie das vor der Konfiguration von V2, nicht erst im Abnahmetest, wenn keine Zeit mehr bleibt, es richtig zu machen.

Ergebnis

Ein Scoping-Dokument mit Servicemodell, Falltypenkatalog, Kanalübersicht mit SLA-Vorgaben, Integrationslandschaft mit Einstufung für den Go-Live, Strategie für die Datenmigration und Personalplanung. Dieses Dokument wird zur Arbeitsgrundlage zwischen Fachbereich und Implementierungsteam.

Phase 2: Konfiguration und Entwicklung (Wochen 4 bis 9)

Hier nimmt das System Gestalt an. Arbeiten Sie in Sprints von zwei Wochen und zeigen Sie den Stakeholdern am Ende jedes Sprints den Stand, damit Kurskorrekturen früh passieren.

Fallmanagement konfigurieren

Beginnen Sie mit dem Fall-Lebenszyklus und halten Sie ihn einfach.

1. Falltypen definieren: Leiten Sie sie aus den Kategorien Ihres Servicemodells ab. Widerstehen Sie der Versuchung, für jeden Sonderfall einen eigenen Typ anzulegen: Beginnen Sie mit 5 bis 8 Falltypen und ergänzen Sie nach dem Go-Live.
2. Lebenszyklus gestalten: Ein typischer B2B-Ablauf ist Neu, Zugewiesen, In Bearbeitung, Warten auf Kunde, Warten auf intern, Gelöst, Abgeschlossen. Sieben Status, nicht 47.
3. Phasen und Schritte modellieren: Im Case Designer legen Sie Phasen und Schritte fest (Aufgaben, Formulare, Genehmigungen, Workflows, Mashups). Entscheiden Sie, wer einen Fall weiterschieben darf und welche automatischen Aktionen ausgelöst werden, zum Beispiel eine Benachrichtigung bei «Warten auf Kunde».
4. Fallformulare konfigurieren: Welche Felder erscheinen bei welchem Falltyp? Halten Sie die Formulare schlank. Jedes überflüssige Feld bleibt leer oder wird mit Unsinn gefüllt.

Kanäle einrichten

Konfigurieren Sie jeden Kanal aus dem Scoping:

• E-Mail: Verbinden Sie die geteilten Postfächer. V2 erstellt, kategorisiert, priorisiert und routet Fälle aus eingehenden E-Mails. Legen Sie Eingangsbestätigungen pro Sprache und Falltyp an.
• Telefon: Wenn CTI im Umfang ist, behandeln Sie es als parallelen Arbeitsstrang. Ihr Telefonieanbieter wird über ein Widget an den Agent Desktop angebunden, die Kundensuche identifiziert den Anrufer. Rechnen Sie allein für CTI mit 2 bis 4 Wochen. Unser Beitrag zum nativen Screen Pop im Agent Desktop von V2 beschreibt die Stolperfallen.
• Chat: Konfigurieren Sie den Chat-Anbieter und die Kapazität pro Person (wie viele Chats gleichzeitig), dazu Überlaufregeln, falls alle im Chat belegt sind.
• Webformular: Bauen Sie das Formular Ihres Portals oder binden Sie es an die API zur Fallerstellung an.

SLAs

Konfigurieren Sie die SLAs anhand Ihrer dokumentierten Vorgaben:

• SLA-Regeln: Ordnen Sie Bedingungen (Falltyp, Priorität, Kundensegment) den Reaktions- und Lösungszeiten zu. Beginnen Sie mit höchstens 10 bis 15 Regeln. Jede weitere Regel muss jemand verstehen und pflegen.
• Geschäftskalender: Definieren Sie die Arbeitszeiten pro Region, inklusive Feiertagen. Fehlen sie, zählen die SLA-Uhren nachts und am Wochenende weiter. Das haben wir mehr als einmal erlebt.
• Eskalationen: Was passiert bei 75 % der SLA-Zeit? Bei 90 %? Bei Verletzung? Benachrichtigungen, Umleitung, höhere Priorität, Hinweis an die Leitung, alles über Autoflow.
• SLA-Dashboards: Richten Sie Compliance-Ansichten für Teamleitungen und Management ein. Sie werden zur täglichen Arbeitsansicht.

Routing-Regeln

Richten Sie das Routing ein:

1. Routing-Kriterien festlegen: Sprache, Produktwissen, technisches Niveau, Kundensegment, Kanal.
2. Teams bilden: Gruppieren Sie die Servicemitarbeitenden so, dass sich die Kriterien auf Teams abbilden lassen. Bleiben Sie realistisch und weisen Sie niemandem Kompetenzen zu, die er nicht hat.
3. Routing-Regeln bauen: Ordnen Sie Fallattribute Teams oder Bearbeitenden zu. Definieren Sie Ausweichregeln, falls niemand Passendes verfügbar ist (Warteschlange, Teamleitung, Eskalation).
4. Kapazitätsgrenzen setzen pro Kanal: Telefonfälle brauchen volle Aufmerksamkeit, E-Mail-Fälle lassen sich parallel bearbeiten.

Wissensdatenbank

V2 bindet eine externe Wissensdatenbank an: Die Servicemitarbeitenden durchsuchen sie aus dem Agent Desktop und hängen Artikel an ihre Antworten an. Die Arbeit liegt deshalb weniger in der Konfiguration als im Inhalt:

• Wissenssystem früh auswählen und anbinden, denn es ist eine Integration wie jede andere.
• Taxonomie festlegen: Produkt, Thema, Artikel. Halten Sie sie so flach, dass Inhalte in zwei Klicks gefunden werden, nicht in fünf.
• Erste Artikel schreiben: Konzentrieren Sie sich auf die 20 Falltypen mit dem höchsten Volumen. Sie decken die meisten Alltagsfragen ab.
• Prüfzyklen festlegen: Artikel veralten. Führen Sie vom ersten Tag an eine vierteljährliche Prüfung mit benannten Verantwortlichen ein und verfolgen Sie, welche Artikel genutzt und welche übergangen werden.

KI-Empfehlungen

Service Cloud V2 schlägt eine Fallkategorie vor und zeigt ähnliche Fälle an. Wie nützlich diese Vorschläge sind, hängt von Ihren historischen Daten ab:

1. Historie bereinigen: Kategorien, die im Altsystem uneinheitlich verwendet wurden, bringen der KI genau diese Uneinheitlichkeit bei. Konsolidieren Sie sie vor der Migration.
2. Umgang mit dem Vorschlag festlegen: übernehmen, korrigieren oder ignorieren. Korrekturen helfen nur, wenn die Kategorien dahinter klar sind.
3. Nach dem Go-Live messen: Verfolgen Sie pro Kategorie, wie oft der Vorschlag übersteuert wird. Eine Kategorie, die ständig korrigiert wird, deutet meist auf ein Problem in der Taxonomie hin, nicht auf ein KI-Problem.

Beginnen Sie früh. Warten Sie nicht bis zum Go-Live, um festzustellen, dass «Rechnungsreklamation» immer wieder unter «Allgemeine Anfrage» landet. Generative Funktionen wie Joule und der Digital Service Agent sind eine eigene Entscheidung mit eigener Lizenzierung; planen Sie sie als spätere Stufe ein.

Phase 3: ERP-Integration (Wochen 6 bis 10, parallel zu Phase 2)

Für B2B-Serviceteams ist die ERP-Integration oft der wertvollste Teil der ganzen Implementierung. Die Servicemitarbeitenden brauchen Kundenkontext (Auftragshistorie, Garantiestatus, installierte Basis, Abrechnung), ohne das System zu wechseln.

SAPs Standard-Integrationsinhalte

SAP liefert die Integration zwischen Service Cloud V2 und den eigenen ERP-Systemen als vorkonfigurierte Inhalte auf der SAP Integration Suite (Cloud Integration). Abgedeckt sind unter anderem:

• Geschäftspartner: Konten und Kontakte, bidirektional zwischen V2 und dem ERP
• Produkte: der Produktstamm aus S/4HANA zur Verwendung in Serviceprozessen
• Equipments und registrierte Produkte: Equipments aus dem ERP als registrierte Produkte in V2, die Grundlage für Garantien und installierte Basis
• Codelisten und Organisationsdaten wie Verkaufsorganisationen
• Folgebelege, zum Beispiel Serviceaufträge oder Kundenaufträge, die aus dem Serviceprozess im ERP angelegt werden

Auftragshistorie und Faktura werden im Fall meist über Mashups oder gezielte Abfragen angezeigt, statt vollständig repliziert zu werden. SAP dokumentiert die Einrichtung in der Learning Journey zur Integration von Sales und Service Cloud V2 mit S/4HANA und für ECC im Integrationsleitfaden für SAP ERP.

Die Standardinhalte decken die üblichen B2B-Szenarien ab. Was übrig bleibt, sind meist eigene Felder, branchenspezifische Daten oder alte Datenmodelle, die Erweiterungen brauchen. Wenn Sie auch SAP Sales Cloud V2 einsetzen, zeigt unser Beitrag zu S/4HANA Public Cloud und Sales Cloud V2 als integriertem Stack, wie ein gemeinsames ERP-Rückgrat die doppelte Integration vermeidet. Unser Leitfaden zur Integration von Service Cloud V2 und S/4HANA Public Cloud geht tiefer auf den Ablauf vom Fall bis zur Lösung ein.

Architekturentscheidungen zur Integration

Drei Fragen, die Sie früh klären sollten.

Replizieren oder nachschlagen? Stammdaten (Geschäftspartner, Produkte, registrierte Produkte) werden repliziert. Bei Bewegungsdaten entscheidet das Volumen: Einige tausend Aufträge pro Kunde lassen sich live über ein Mashup anzeigen, Hunderttausende historische Belege gehören nicht ins Servicesystem kopiert.

S/4HANA oder ECC? Mit SAP S/4HANA Public Cloud arbeiten Sie mit freigegebenen APIs und den Standardpaketen von SAP auf der Integration Suite. Mit ECC brauchen Sie zusätzlich das Integrations-Add-on von SAP im ERP, und die bidirektionale Replikation von Geschäftspartnern setzt ECC 6.0 EhP8 voraus; ältere Releases replizieren Kunden und Kontakte nur in eine Richtung. In beiden Fällen gehören Mapping, Fehlerbehandlung und Monitoring ins Budget: Vorkonfigurierte Inhalte verringern den Aufwand, sie ersetzen ihn nicht.

Eskalation an Field Service Management. Wenn Fälle an Technikerinnen und Techniker eskaliert werden, legt die FSM-Integration aus dem Fall in V2 einen Serviceabruf in FSM an. FSM übernimmt Planung und Disposition, Statusänderungen fliessen in den Fall zurück, sodass Servicemitarbeitende und Kunde den Fortschritt sehen. Behandeln Sie das als eigenen Arbeitsstrang und rechnen Sie mit 2 bis 4 Wochen, je nachdem, wie komplex Ihre FSM-Konfiguration ist.

Integrationstests (paralleler Strang)

Testen Sie jede Integration zuerst einzeln, dann durchgängig:

1. Schnittstellentests: Jeder Aufruf liefert für gültige und ungültige Eingaben die erwarteten Daten.
2. Integrationstests: Die Daten fliessen unter normalen Bedingungen korrekt zwischen den Systemen.
3. Fehlerbehandlung: Was passiert, wenn S/4HANA nicht erreichbar ist? Timeouts, Wiederholungen und was die Servicemitarbeitenden in der Zwischenzeit sehen.
4. Volumentests: Testen Sie mit Daten in Produktionsgrösse. Eine Schnittstelle, die mit 10 Datensätzen läuft, kann bei 10’000 scheitern.

Phase 4: Tests und Migration (Wochen 9 bis 13)

Datenbereinigung

Bereinigen Sie die Daten vor der Migration, nicht danach. Prioritäten:

• Dubletten bei Konten und Kontakten im Quellsystem zusammenführen. Wer Dubletten migriert, verdoppelt den Bereinigungsaufwand.
• Feldwerte vereinheitlichen: Ländercodes, Telefonnummernformate, Statuswerte, Kategorienamen. Uneinheitliche Daten brechen Routing-Regeln und Berichte.
• Veraltete Datensätze archivieren: Brauchen Sie wirklich 50’000 abgeschlossene Fälle aus 2019 in V2? Migrieren Sie, was die Servicemitarbeitenden tatsächlich nachschlagen, und archivieren Sie den Rest. Ein Zeitfenster von 12 bis 18 Monaten reicht meist.
• Pflichtfelder prüfen: V2 hat Pflichtfelder, die Ihr Quellsystem womöglich nicht erzwingt. Finden Sie die Lücken vor der Migration, nicht währenddessen.

Abnahmetest (UAT)

Der UAT ist nicht «einmal durch die Masken klicken und sagen, es sieht gut aus». Strukturieren Sie ihn.

Testskripte nach Rolle:

• Servicemitarbeitende: Fall über jeden Kanal anlegen. Kategorisieren, routen, eskalieren, lösen, abschliessen. Prüfen, ob die SLA-Uhren korrekt starten und stoppen. Wissenssuche und KI-Kategorievorschlag testen.
• Teamleitung: Warteschlangen, manuelle Zuweisung, SLA-Dashboard, Teamberichte, Eskalationen.
• Serviceleitung: teamübergreifende Sicht, KPI-Dashboards, Ausnahmebehandlung, Konfigurationsänderungen.
• Kunde (simuliert): Anfrage über Portal, E-Mail und Chat einreichen, Statusmeldungen erhalten, Lösungsbenachrichtigung bestätigen.

Jede Integration durchgängig testen:

• Fall anlegen und prüfen, ob die Auftragsdaten aus S/4HANA im Fall erscheinen.
• An FSM eskalieren und prüfen, ob der Serviceabruf mit den richtigen Angaben angelegt wird und der Status zurückfliesst.
• Eingehenden Anruf annehmen und prüfen, ob der Screen Pop den Anrufer zeigt und den Fall anlegt (falls CTI im Umfang ist).
• Fall über das Portal einreichen und prüfen, ob er mit dem richtigen Kundenkontext in V2 ankommt.

Sonderfälle testen:

• SLA-Verletzung: Greift die Eskalation?
• Niemand verfügbar: Funktioniert das Ausweich-Routing?
• Doppelte Einreichung: Wie geht das System damit um?
• Grosse Anhänge: Werden die Grössenlimits eingehalten?
• Fall ausserhalb der Geschäftszeiten: Verhält sich die SLA-Uhr korrekt?

Beziehen Sie echte Servicemitarbeitende in den UAT ein, nicht nur das Projektteam. Sie finden Fehler, die Prozessexperten übersehen, weil sie die Arbeit anders betrachten.

Performancetests

Führen Sie Performancetests mit realistischen Volumen durch:

• Durchsatz bei der Fallerstellung: Wenn am Montagmorgen 500 Fälle pro Stunde eingehen, testen Sie mit 500 Fällen pro Stunde.
• Antwortzeit der Suche: Wissenssuche und Fallsuche mit Daten in Produktionsgrösse.
• Ladezeit der Dashboards: SLA-Dashboards mit Tausenden offenen Fällen.
• Latenz der Integration: Abruf von S/4HANA-Daten unter gleichzeitiger Last, vor allem die Latenz des Screen Pop. Alles über zwei Sekunden fällt den Servicemitarbeitenden auf.

Cutover planen

Schreiben Sie ein Cutover-Drehbuch, eine Checkliste Schritt für Schritt für das Go-Live-Wochenende:

1. Finale Datenmigration (Delta seit der letzten Probemigration)
2. Umschalten der Integrationen (auf den Produktivtenant zeigen lassen)
3. Anpassungen an DNS und E-Mail-Routing (eingehende E-Mails nach V2)
4. Smoke-Tests: ein Fall pro Kanal, eine Prüfung pro angebundenem System
5. Benutzerbereitstellung und Prüfung des SSO
6. Kriterien und Ablauf für den Rollback (festlegen, bevor Sie sie brauchen)

Proben Sie den Cutover mindestens einmal und messen Sie die Zeit. Ein Cutover, der «4 Stunden dauern sollte», aber 12 braucht, bedeutet: Am Montagmorgen kann niemand arbeiten.

Phase 5: Go-Live und Hypercare (Go-Live um Woche 13, danach vier Wochen)

Checkliste für den Go-Live

Vor dem Umschalten:

• Alle Fehler aus dem UAT behoben oder als bekannte Einschränkung mit dokumentierter Umgehung akzeptiert
• Performancetests mit Volumen in Produktionsgrösse bestanden
• Cutover-Probe im geplanten Zeitfenster abgeschlossen
• Schulung der Servicemitarbeitenden durchgeführt und überprüft, nicht nur eingeplant
• Supportteam informiert und für die Hypercare bereit
• Rollback-Ablauf dokumentiert und getestet
• Monitoring eingerichtet: Fallvolumen, SLA-Einhaltung, Systemfehler, Zustand der Integrationen
• Kommunikation an die Servicemitarbeitenden verschickt: Go-Live-Datum, Anmeldung, Supportkontakte, bekannte Einschränkungen

Schulung der Servicemitarbeitenden

Schulung ist kein einstündiges Webinar am Freitag vor dem Go-Live. Sie entscheidet über die Akzeptanz.

Woche −2: Präsenzschulung (4 bis 6 Stunden pro Gruppe)

• Navigation und Fallbearbeitung für jeden Falltyp
• Abläufe pro Kanal: E-Mail, Telefon (mit CTI, falls vorhanden), gleichzeitige Chats
• SLA-Sichtbarkeit: was die Uhren bedeuten, was zu tun ist, wenn sie laufen, wie «Warten auf Kunde» sie anhält
• Wissenssuche und Anhängen von Artikeln
• KI-Kategorievorschläge: was sie tun und wann man sie übersteuert
• Praktische Übungen im Schulungstenant

Woche −1: begleitetes Üben (2 bis 3 Tage)

• Servicemitarbeitende bearbeiten simulierte Fälle im Schulungstenant
• Eine Trainerin oder ein Trainer beantwortet Fragen direkt
• Typische Fehler werden erkannt, bevor sie in die Produktion gelangen

Woche 1: Buddy-System

• Jede Person erhält einen Champion aus der UAT-Gruppe, der das System kennt, zur Seite gestellt
• Die Champions beantworten Fragen direkt vor Ort
• So fallen die meisten Routinefragen gar nicht erst beim Projektteam an

Die ersten 30 Tage

Der Go-Live ist der Beginn der Bewährungszeit, nicht die Ziellinie.

Tägliche Prüfungen (Woche 1):

• Fallvolumen gegenüber der erwarteten Basis: Läuft wirklich alles über V2?
• SLA-Einhaltung gegenüber dem vereinbarten Ziel
• Übernahmequote der KI-Kategorievorschläge
• Fehlerquote der Integrationen: Ziel unter 1 %
• Fragen der Servicemitarbeitenden: jede erfassen, schnell beantworten, Schulungsunterlagen nachführen

Wöchentliche Prüfungen (Wochen 2 bis 4):

• Routing: Landen die Fälle bei der ersten Zuweisung bei der richtigen Person?
• Wissenslücken: Für welche Falltypen fehlen noch Artikel?
• Rückmeldungen der Servicemitarbeitenden: strukturierte Runden von 30 Minuten, keine Gespräche im Flur
• SLA-Trend: besser, stabil oder schlechter?
• Kategoriekorrekturen: Werden bestimmte Kategorien regelmässig übersteuert?

Ende Woche 4: Abschluss der Hypercare

• Alle kritischen und schwerwiegenden Fehler behoben
• SLA-Einhaltung stabil über dem vereinbarten Ziel
• Akzeptanz bestätigt: Die Servicemitarbeitenden melden sich täglich an, kein Fall wird ausserhalb von V2 bearbeitet
• Die Wissensdatenbank deckt die Falltypen mit dem höchsten Volumen ab
• Formelle Übergabe an das Supportteam mit dokumentierten Betriebsanleitungen

Für Schweizer Serviceorganisationen erklärt unsere Seite zur SAP CX Beratung Schweiz, wie wir Service-Cloud-V2-Projekte in vier Sprachen besetzen und führen.

Häufige Fehler und wie Sie sie vermeiden

Diese Muster tauchen immer wieder auf, und jedes davon lässt sich vermeiden.

Unsaubere Daten

Was passiert: Teams migrieren Kontodaten mit 30 % Dubletten, Kontakte ohne E-Mail-Adresse und Fallhistorien mit uneinheitlichen Kategorien. Routing-Regeln brechen, Berichte stimmen nicht, und die Servicemitarbeitenden misstrauen dem System vom ersten Tag an.

So vermeiden Sie es: Bereinigen Sie die Daten vor der Migration im Quellsystem: Dubletten zusammenführen, vereinheitlichen, Pflichtfelder prüfen. Das ist unspektakuläre Arbeit und der am besten investierte Aufwand im ganzen Projekt. Planen Sie dafür 2 bis 3 Wochen ein, getrennt von der eigentlichen Migration.

Überkonfiguration

Was passiert: Das Team konfiguriert 30 Falltypen, 47 Status, 200 Routing-Regeln und 15 SLA-Stufen. Niemand kann erklären, wie das zusammenspielt, niemand weiss, welche Regel einen Fehler verursacht hat, und jede Änderung wird riskant.

So vermeiden Sie es: Beginnen Sie minimal: 5 bis 8 Falltypen, 7 Status, Routing-Regeln, die sich in je einem Satz erklären lassen. Komplexität lässt sich nach dem Go-Live ergänzen, wenn echte Nutzungsdaten sie rechtfertigen. Sie wieder zu entfernen, wenn sich alle daran gewöhnt haben, ist viel schwieriger.

Das Arbeitserlebnis der Servicemitarbeitenden vernachlässigen

Was passiert: Das Projekt optimiert auf Management-Reporting und Prozesstreue. Das Fallformular hat 40 Pflichtfelder, die Servicemitarbeitenden verbringen mehr Zeit mit Metadaten als mit Kunden, die Bearbeitungszeit steigt und die Stimmung sinkt.

So vermeiden Sie es: Holen Sie die Servicemitarbeitenden ins Design und testen Sie jedes Formular vor dem Go-Live mit ihnen. Braucht ein Standardfall mehr als etwa drei Minuten Arbeit im System, vereinfachen Sie das Formular. Das Reporting kann Fallkontext und KI-Daten nutzen; es braucht keine 40 Felder pro Fall.

Bei der Schulung sparen

Was passiert: Das Budget ist aufgebraucht oder der Zeitplan rutscht, und die Schulung schrumpft auf zwei Stunden am Tag vor dem Go-Live. Die Servicemitarbeitenden starten verunsichert, bauen Umgehungslösungen und arbeiten nebenher weiter per E-Mail. Sechs Monate später fragt die Geschäftsleitung, ob das System «funktioniert».

So vermeiden Sie es: Schützen Sie das Schulungsbudget von Anfang an. Vier bis sechs Stunden Präsenzschulung plus zwei bis drei Tage begleitetes Üben sind das Minimum. Eine schwache Schulung kostet Monate schwacher Akzeptanz.

Alles auf einmal starten

Was passiert: Das Team will am selben Tag mit KI, Wissensdatenbank, CTI, FSM-Integration, Kundenportal und erweiterter Analytik live gehen. Das Projekt wächst auf sechs Monate, und jede Abhängigkeit erhöht das Risiko.

So vermeiden Sie es: Definieren Sie einen minimalen Go-Live. Stufe 1: Kern-Fallmanagement, E-Mail, SLAs, einfaches Routing, Kontodaten aus S/4HANA. Stufe 2 (Go-Live plus 4 Wochen): weitere Kanäle, KI-Vorschläge, Wissensdatenbank. Stufe 3 (Go-Live plus 8 Wochen): FSM-Integration, CTI, erweiterte Analytik. Jede Stufe bringt Nutzen und baut auf einer stabilen Grundlage auf.

Richtwerte für den Zeitplan

Der Zeitplan hängt von drei Grössen ab: der Zahl der Servicemitarbeitenden, der Zahl der Integrationen und dem Umfang der Eigenentwicklung. Die Angaben unten gelten bis zum Go-Live; die Hypercare kommt dazu.

Einfach (rund 8 Wochen)

• 10 bis 30 Servicemitarbeitende
• 1 bis 2 Kanäle (E-Mail und Webformular)
• Keine ERP-Integration oder nur die Standardintegration der Geschäftspartner
• Kein CTI
• Standard-Lebenszyklus mit einfachem Routing
• Minimale Datenmigration (nur Konten und Kontakte)

Standard (10 bis 16 Wochen)

• 50 bis 150 Servicemitarbeitende
• 3 bis 4 Kanäle (E-Mail, Telefon, Chat, Webformular)
• S/4HANA-Integration: Kontoabgleich, Produkte, registrierte Produkte, Auftragskontext
• SLAs mit Regeln nach Kundensegment und Eskalationen
• KI-Kategorievorschläge auf Basis bereinigter Fallhistorie
• Wissensdatenbank mit 50 bis 100 ersten Artikeln
• Mittlere Datenmigration: Konten, Kontakte, offene Fälle, Wissensartikel

Enterprise (4 bis 6 Monate)

• Über 200 Servicemitarbeitende in mehreren Regionen und Zeitzonen
• Alle Kanäle, inklusive Social Media über einen Drittanbieter
• Mehrere ERP-Integrationen (S/4HANA plus ECC oder ein ERP eines anderen Herstellers)
• CTI mit einer Contact-Center-Plattform (Cisco, Genesys oder ähnlich)
• FSM-Integration für Eskalationen an den Aussendienst
• Self-Service-Portal mit Fallverfolgung
• Eigene Erweiterungen für branchenspezifische Abläufe
• Komplexe Datenmigration aus mehreren Quellsystemen
• Mehrsprachige SLAs über mehrere Zeitzonen mit regionalen Geschäftskalendern

Das sind Bandbreiten, keine Zusagen. Die Scoping-Phase ist dazu da, daraus einen realistischen Plan für Ihre Situation zu machen.

Häufige Fragen

Wie lange dauert eine Implementierung von SAP Service Cloud V2?

Das hängt vom Umfang ab. Eine einfache Einführung (10 bis 30 Servicemitarbeitende, E-Mail und Webformular, keine ERP-Integration) geht nach rund 8 Wochen live. Eine typische B2B-Implementierung (50 bis 150 Servicemitarbeitende, 3 bis 4 Kanäle, S/4HANA-Integration, KI-Vorschläge) braucht 10 bis 16 Wochen bis zum Go-Live, danach folgen rund vier Wochen Hypercare. Enterprise-Projekte mit mehreren Integrationen, CTI, FSM und eigenen Erweiterungen dauern 4 bis 6 Monate. In welche Kategorie Sie fallen, klärt die Scoping-Phase.

Brauchen wir S/4HANA für Service Cloud V2?

Nein, aber es hilft B2B-Teams erheblich. Service Cloud V2 ist ein eigenständiges SaaS-Produkt und funktioniert auch ohne SAP-ERP. B2B-Serviceteams brauchen bei der Fallbearbeitung aber meist Auftragshistorie, Garantie- und Produktdaten. SAP liefert dafür vorkonfigurierte Integrationsinhalte auf der SAP Integration Suite, für S/4HANA wie für SAP ERP (ECC). ECC braucht zusätzlich das Integrations-Add-on von SAP, und die bidirektionale Replikation von Geschäftspartnern setzt ECC 6.0 EhP8 voraus.

Können wir Service Cloud V2 ohne SAP Activate einführen?

Das geht, wir würden es aber nicht tun. SAP Activate gibt dem Projekt eine feste Struktur, die die üblichen Ursachen für Probleme früh sichtbar macht: unklarer Umfang, übersehene Anforderungen und zu wenig Tests. Die Methodik ist kein bürokratischer Überbau, sondern eine Checkliste, die das Projekt auf Kurs hält. Wir skalieren sie auf Grösse und Komplexität jedes Projekts, siehe wie wir arbeiten.

Was unterscheidet diesen Leitfaden vom Migrationsleitfaden?

Unser Migrationsleitfaden behandelt den Wechsel von SAP Cloud for Customer (Service Cloud V1) auf V2: Datenmigration aus einem bestehenden SAP-Servicesystem, Umbau der Integrationen und Parallelbetrieb. Dieser Leitfaden beschreibt die Einführung von V2 als neues System, unabhängig davon, was es ablöst. Die Phasen von SAP Activate sind dieselben, Ausgangslage und Risiken unterscheiden sich.

Nächste Schritte

Wenn Sie eine Einführung von Service Cloud V2 planen, beginnen Sie mit den vier Scoping-Fragen oben: Servicemodell abbilden, Kanäle erfassen, SLAs dokumentieren und die Integrationslandschaft zeichnen. Diese Grundlage macht alles Weitere schneller und günstiger.

Eine veröffentlichte Referenz: intelligentfood ging mit einer Sales- und Service-Plattform auf V2 in drei Monaten live, angebunden an das eigene ERP. Wenn Sie eine realistische Zeitschätzung oder eine zweite Meinung zu Ihrem Scoping möchten, melden Sie sich. Keine Verkaufspräsentation, sondern ein Gespräch über Ihre Situation.

Wenn Sie noch einen Implementierungspartner suchen, zeigen unsere Übersicht der besten SAP-CX-Beratungen in der Schweiz und unser Leitfaden zu einem Partner für Cloud ERP und CRM, worauf es ankommt, wenn das Serviceprojekt vom ERP abhängt. Was wir von Anfang bis Ende liefern, beschreibt die Lösungsseite zu SAP Service Cloud V2, inklusive Team, Referenzen und Datenhaltung.