Wir nutzen SAP Sales Cloud und Service Cloud selbst. Das haben wir gebaut.

Wir sagen Kunden oft, dass sie kein CRM-Theater bauen sollen.

Keine riesige erste Phase. Keine endlosen Workshops. Keine Zusatzfelder, nur weil sie in einem alten System einmal existierten. Beginnen Sie mit der Arbeit. Bauen Sie den Prozess. Gehen Sie live. Verbessern Sie danach.

Als wir entschieden, SAP Sales Cloud V2 und SAP Service Cloud V2 selbst zu nutzen, mussten wir genau das auch für uns tun.

Wir lizenzierten den Stack Anfang 2026. Rund einen Monat später waren wir live.

Der Scope

Wir hielten das erste Release bewusst klein.

Für den Vertrieb war der Kernprozess klar:

• Leads aus echten Gesprächen, Events und der Website erfassen.
• Accounts und Kontakte sauber führen.
• Opportunities verfolgen, ohne jeden Deal in ein Adminprojekt zu verwandeln.
• Follow-ups sichtbar halten.
• Dem Management genug Pipeline-Kontext geben, ohne ein Reporting-Monster zu bauen.

Für den Service war die Anforderung genauso praktisch:

• Supportanfragen als Cases verfolgen.
• Zuständigkeit klar halten.
• Eingehende Website-Anfragen mit dem Supportprozess verbinden.
• Status und nächste Schritte sichtbar machen.
• Kundenkontext nicht in Mail-Threads verlieren.

Das reichte für den Go-Live. Alles Weitere musste seinen Platz verdienen.

Warum Sales Cloud V2

SAP positioniert Sales Cloud als CRM für Vertriebsarbeit: Lead- und Opportunity-Management, Account-Arbeit, Guided Selling, Forecasting und Analytics. Das ist das öffentliche Versprechen.

Unsere interne Frage war einfacher: Sieht unser Team, was zählt, ohne zu suchen?

Wir konfigurierten Sales Cloud so, wie Spadoom verkauft. Unser Vertrieb ist selten transaktional. Ein erstes Gespräch enthält oft Architektur, Integration, fachliche Passung und unbequeme Fragen zum Scope. Das CRM muss diese Realität unterstützen.

Darum fokussierten wir auf saubere Account-Strukturen, sinnvolle Opportunity-Stufen, klare nächste Schritte und genug Qualifikation, damit niemand dasselbe Gespräch zweimal führen muss.

Warum Service Cloud V2

SAP positioniert Service Cloud für Serviceprozesse: Case Management, Knowledge, Automatisierung und Kundensupport.

Für uns ist der Case zentral. Eine Supportanfrage braucht ein Zuhause. Sie braucht eine zuständige Person. Sie braucht einen Status. Sie braucht Kontext.

Vor diesem Projekt passierte zu viel Supportarbeit noch an Orten, die leicht verloren gehen: Inboxen, Chats, Seitennotizen. Bei wenig Volumen funktioniert das. Bei mehr Kunden, mehr Projekten und mehr Übergaben beginnt es zu schmerzen.

Service Cloud gibt uns einen Ort für diese Arbeit.

Die Website-Anbindung

Die Website ist wichtig, weil dort oft die erste Supportanfrage oder das erste Vertriebssignal entsteht.

Wir haben Website-Formulare an den internen Prozess angebunden, damit Anfragen in SAP Service Cloud landen statt in einem Postfach. Der Punkt ist nicht technische Show. Der Punkt ist saubere Arbeit:

• Die Anfrage wird erfasst.
• Das richtige Team sieht sie.
• Der Status ist nachverfolgbar.
• Die Historie bleibt beim Kunden.

Genau diese Art Integration empfehlen wir Kunden. Also haben wir sie für uns gebaut.

Was Wir Personalisiert Haben

Wir haben keinen generischen SAP-Demotenant eingeführt.

Wir haben das System an Spadoom angepasst:

• Opportunity-Stufen für beratende SAP-CX-Deals.
• Case-Kategorien für echte Supportarbeit.
• Schlanke Felder für schnelle Erfassung statt dekorativer Vollständigkeit.
• Views für die Menschen, die damit arbeiten.
• Website-angebundenes Intake für Supportanfragen.

Hier laufen viele CRM-Projekte falsch. Sie bleiben zu generisch und niemand nutzt das System. Oder sie passen alles an und bauen ein Wartungsproblem.

Der sinnvolle Weg liegt dazwischen: dort anpassen, wo es die tägliche Arbeit verbessert, und Standard lassen, wo es reicht.

Was Wir Wieder Gelernt Haben

Dieses Projekt bestätigte, was wir in Kundenprojekten sehen.

Erstens: Geschwindigkeit kommt von Entscheidungen. Das Produkt war nicht der Engpass. Scope-Disziplin war der Schlüssel.

Zweitens: Standardkonfiguration reicht weiter, als viele erwarten. Sie müssen nicht jede Irritation im ersten Release wegkonfigurieren.

Drittens: Service Cloud wird nützlich, wenn Cases das Standard-Zuhause für Supportarbeit werden. Wenn Support weiterhin in Inboxen läuft, bleibt das System Dekoration.

Viertens: Wer das System selbst nutzt, berät anders. Wir spüren die kleinen Workflow-Details jeden Tag. Das macht unsere Empfehlungen schärfer.

Die Technische Form

Das Projekt blieb bewusst sauber:

• SAP Sales Cloud V2 für Leads, Accounts, Kontakte und Opportunities.
• SAP Service Cloud V2 für casebasierten Support.
• Website-Intake angebunden an den Supportprozess.
• Standardkonfiguration zuerst.
• Personalisierung dort, wo sie die tägliche Arbeit verbessert.
• Spätere Erweiterungen ausserhalb des ersten Go-Live-Scopes.

Keine Zeremonie. Kein Transformationstheater. Ein System, das läuft.

Warum Das Selten Ist

Viele SAP-Partner verkaufen SAP CX. Weniger führen Vertrieb und Service intern auf denselben Produkten.

Das zählt. Wenn wir über Adoption, Felder, Servicequeues, Leadqualität, Übergaben oder Website-Intake sprechen, sprechen wir nicht nur aus Kundenprojekten. Wir sprechen auch aus unserem eigenen System.

Es ist schwieriger, etwas schönzureden, wenn man das Produkt selbst nutzt.

Quellen

• SAP Sales Cloud Überblick
• SAP Service Cloud Überblick
• SAP Business Technology Platform Überblick

Die Kurzfassung

Wir gingen rund einen Monat nach der Lizenzierung live. Schnell, ja. Wichtiger ist aber, was nach dem Go-Live passiert.

Das System unterstützt jetzt täglich unseren Vertrieb und Support. Es bringt eine klarere Pipeline, eine bessere Supportqueue und mehr Kontext zu Kunden.

Nutzen Sie, was Sie empfehlen.

Tun wir. Und dann verbessern wir das Rezept.