CRM-Implementierung: was im Angebot fehlt

Das Projekt ist abgenommen. Die Daten sind drin, die Felder stimmen, das Team hat seine Schulung bekommen. In der ersten Woche nach dem Go-Live fällt jemandem auf, dass die Anfragen aus dem Kontaktformular niemandem mehr zugewiesen werden. Da liegen sie. Niemand hat diese Regel entfernt. Es hat nur nie jemand aufgeschrieben, dass es sie gab.

Das ist der häufigste Bruch in einer CRM-Implementierung, und er hat fast nie mit Daten zu tun. Daten ziehen um. Was nicht von allein umzieht, sind die Prozesse, die im Altsystem still gelaufen sind: Automatisierungen, Zuweisungsregeln, die Übergabe zwischen Marketing und Sales. In keinem Projektumfang stehen sie, weil niemand sie je als eigenen Punkt gedacht hat.

Warum die Abnahme das nicht fängt

Eine Abnahme prüft, was im Umfang steht. Genau das ist ihr Zweck, und genau darin liegt die Lücke: Die Prozesse, über die niemand geschrieben hat, sind kein Prüfpunkt. In keiner Checkliste tauchen sie auf, weil eine Checkliste aus dem Umfang entsteht.

Der Weg dorthin ist immer derselbe, und jeder einzelne Schritt wirkt vernünftig. Im Workshop nennt der Kunde eine Regel, die ihm wichtig ist. Der Anbieter sagt zu, das abzubilden. Zwei Wochen später wird die Regel im Detail anders besprochen, weil sich eine Abhängigkeit gezeigt hat. Beide Seiten wissen, was gemeint ist, und keiner hält es fest. Der Umfang stammt aus Woche eins und wird nicht nachgezogen. Am Go-Live existieren dann drei Versionen: die im Dokument, die im Kopf des Kunden und die im System.

Deshalb ist der Moment des Bruchs auch nicht der Moment des Fehlers. Der Fehler liegt Wochen früher, in einem Gespräch, in dem jemand sagte: „Das machen wir dann natürlich mit.“ Nur notierte niemand, was „das“ war. Die interne Aufarbeitung auf Anbieterseite kommt in solchen Fällen fast immer zum selben Befund, und er ist unspektakulär: keine böse Absicht, sondern zu schwache Projekt-Governance. Umfangsänderungen wurden mündlich besprochen und nie schriftlich festgehalten. Risiken wurden nicht formal an die Entscheidungsträger auf beiden Seiten eskaliert.

Daten ziehen um, Prozesse nicht

An dieser Unterscheidung hängt der ganze Artikel. Ein Datenimport ist eine abgrenzbare technische Aufgabe: Objekte und Felder, Zuordnungen und die Logik für Dubletten. Er lässt sich in Tagen beschreiben und in Tagen prüfen. Eine Prozessintegration ist etwas anderes. Hier geht es um die Frage, welche Abläufe das neue System nach dem Go-Live tragen muss, und das ist der Teil, der Wochen braucht.

Bei MAIA by Prodlane ist beides belegt und auseinandergehalten. Das Unternehmen hatte vorher vier Wochen in Pipedrive investiert und war dabei an die Grenzen der Anpassbarkeit gestossen. SalesPlaybook half dann, HubSpot innerhalb von 6-8 Wochen vollständig aufzusetzen und in die bestehenden Prozesse zu integrieren. Das Ergebnis waren klar strukturierte Abläufe, die planbar wurden.

Die Wochenzahl ist die interessante Grösse. Denn sie beschreibt nicht, wie lange ein Import dauert, sondern wie lange es dauert, bis ein System die Arbeit eines Teams wirklich abbildet. Liest du in einem Angebot eine Migrationsdauer, stell deshalb genau diese Frage: Bezieht sich die Zahl auf die Daten oder auf die Prozesse?

Die vier Bereiche, die regelmässig fehlen

In Implementierungs- und Migrationsprojekten wiederholt sich dasselbe Muster. Vier Bereiche laufen im Altsystem so unauffällig, dass niemand sie als Leistung wahrnimmt. Deshalb tauchen sie im Umfang nicht auf.

Die vierte Zeile ist die unangenehmste, weil sie oft ausserhalb der CRM-Zuständigkeit gesehen wird. Ein Webhook, der Aufträge ins Abrechnungssystem schiebt, gilt intern als IT-Thema. Bis er nach der Umstellung nicht mehr feuert. Dann ist er ein CRM-Thema.

Die Liste dieser vier Bereiche zu erstellen, dauert weniger lang als die Diskussion darüber, wer sie erstellen müsste. Im Altsystem kannst du Automatisierungen und Zuweisungsregeln aufzählen: sie stehen in einer Übersicht, haben Namen und lassen sich exportieren. Die Übergabe an den Vertrieb ist schwieriger, weil sie teilweise nicht im System steht, sondern in einer Gewohnheit. Dann lautet die richtige Frage nicht „Welche Regel gilt?“, sondern „Woran erkennt Sales, dass ein Lead für ihn ist?“. Bei den Schnittstellen hilft nur eins: die Systeme durchgehen, die Daten aus dem CRM beziehen oder hineinschreiben, und pro System eine Person benennen.

Hast du diese Liste vor der Unterschrift, verhandelst du anschliessend über etwas Konkretes. Der Anbieter kann jede Zeile einschätzen, herausnehmen oder als Aufwand ausweisen. Was er nicht mehr kann: sie unausgesprochen mitnehmen. Genau das ist der Zweck der Übung.

Der Gegenfall: wenn der Umfang vorher steht

Es geht auch anders, und der Unterschied ist kein Glück. Workist hat den Wechsel von Salesforce zu HubSpot als Umstellung der gesamten Revenue-Journey aufgesetzt, nicht als Datenumzug. Marketing, Sales und Service laufen in einem System, das Backend hängt per Webhooks daran, und alle Teams konnten ab dem ersten Tag damit arbeiten.

Dazu kommen zwei Posten, die dieselbe Case Study ausweist: über 100.000 € jährliche Toolkosten eingespart, weil Einzeltools ersetzt wurden. Und die Notwendigkeit einer Vollzeit-RevOps-Rolle entfiel, weil das Setup wartbar genug ist, um ohne Spezialistin zu laufen. Beide Angaben stehen in der Case Study Workist.

Der Punkt dieser Zahlen ist nicht ihre Höhe, sondern ihre Herkunft: „Vollständige End-to-End-Abbildung der Revenue-Journey“ war bei Workist ein Umfangspunkt und kein Nebenprodukt. Machst du die Prozesse zum Gegenstand des Projekts, bekommst du sie. Und am Ende sparst du an einer Stelle, an der vorher niemand gerechnet hatte.

Wie eine Umfangszeile aussieht, die hält

Ob ein Umfang trägt oder später ausgelegt werden muss, hängt an einer einzigen Eigenschaft: Die Zeile nennt ein Ergebnis, das du am Go-Live prüfen kannst. Drei Beispiele aus demselben Projektteil.

Trägt nicht: „Übernahme der bestehenden Automatisierungen.“ Die Zeile klingt vollständig und ist es nicht. Offen bleibt, welche und wie viele gemeint sind und ob „Übernahme“ nachbauen oder ersetzen heisst. Am Go-Live lässt sich nichts daran prüfen.

Trägt: „Die 14 im Export vom 12.03. gelisteten Pipedrive-Automatisierungen werden in HubSpot nachgebaut. Sieben davon eins zu eins, sieben werden vorher fachlich geprüft und gegebenenfalls zusammengefasst; die Entscheidung wird je Regel dokumentiert.“ Diese Zeile hat eine Zahl, eine Quelle, eine Abgrenzung und einen Prüfpunkt.

Trägt auch: „Automatisierungen sind nicht Bestandteil dieses Projekts. Der Kunde setzt sie nach dem Go-Live selbst auf; SalesPlaybook stellt eine Übersicht der Altregeln bereit.“ Ein ausdrückliches Nein ist ein guter Umfang. Einen Go-Live gefährdet nicht die enge Abgrenzung, sondern die fehlende.

Dieselbe Prüfung kannst du auf jede Zeile anwenden: Steht dort etwas, dessen Fehlen am Tag nach dem Go-Live auffallen würde? Wenn ja, ist die Zeile brauchbar. Lautet die Antwort „Das kommt darauf an, wie man es liest“, ist sie der nächste Streitpunkt.

Deep Dive Guide · 14 Seiten · kostenlos

HubSpot-Partner beauftragen: die Fragen vor der Unterschrift

Zwölf Fragen, drei Klauseln und die Warnsignale in den Antworten. Für die Phase zwischen zwei und fünf Anbietergesprächen, bevor der Preis entscheidet.

Guide ansehen →

Wenn es doch bricht: Problem vor Zuständigkeit

Kein Projektumfang ist vollständig. Irgendwann bricht etwas, das niemand vorhergesehen hat. Dann entscheidet die Reihenfolge der ersten Reaktion über die Zusammenarbeit, nicht der Vertragstext.

Was in diesem Moment fast automatisch passiert: Sobald das Problem sichtbar ist, verschiebt sich das Gespräch auf die Frage, was vereinbart war und was nicht. Für den Anbieter fühlt sich das nach nötiger Klärung an. Für den Kunden fühlt es sich nach einem Themenwechsel an, weg vom Ausfall und hin zu einer Detailfrage, die er nicht gestellt hat. Und sein Prozess steht weiter still.

Das ist keine Frage der Freundlichkeit, sondern der Wirkung. Wer zuerst über Zuständigkeit spricht, hat den Vertrauensschaden meist schon angerichtet, egal wie berechtigt der vertragliche Punkt ist.

Das Schriftliche ist dabei kein Formalismus. Es ist das einzige Werkzeug, das in einem Projekt mit zwei Parteien und mehreren Monaten Laufzeit zuverlässig funktioniert. Eine Notiz nach jedem Workshop, in der steht, was sich am Umfang geändert hat und wer zugestimmt hat, kostet zehn Minuten. Dafür erspart sie dir später eine Diskussion, in der beide Seiten aufrichtig etwas Verschiedenes erinnern.

Die Liste für das Angebot, das vor dir liegt

Prüfst du gerade ein Angebot für eine CRM-Implementierung, sind das die Fragen, auf die es ankommt. Gestellt sind sie absichtlich so, dass eine ausweichende Antwort auffällt.

1. Nennt der Umfang Prozesse oder nur Objekte? Steht dort „Kontakte, Unternehmen, Deals“, ist das ein Datenumfang. Prozesse haben Namen.
2. Wer erstellt die Liste der bestehenden Automatisierungen? Bleibt die Antwort offen, erstellt sie niemand.
3. Bezieht sich die genannte Dauer auf Import oder auf Integration? Beides ist eine legitime Antwort. Aber nur eine davon beschreibt den Go-Live.
4. Wie werden Umfangsänderungen festgehalten? „Wir sprechen das laufend ab“ ist die Antwort, die später zum Streitpunkt wird.
5. Was passiert in Woche eins nach dem Go-Live? Ein Projekt, das mit der Abnahme endet, endet zu früh.

Für den Weg aus einem bestimmten Altsystem gehen wir an anderer Stelle ins Detail: Salesforce, Marketo und Excel haben je eigene Fallstricke. Was intern an Aufwand anfällt, rechnet der Artikel zu den internen Kosten einer CRM-Einführung durch. Und sind mehrere Gesellschaften betroffen, kommt die Governance-Frage dazu, die wir für konzernweite CRM-Projekte beschreiben.

Für dich heisst das: Behandle den Projektumfang nicht als juristisches Dokument, sondern als Liste der Prozesse, die nach dem Go-Live laufen müssen. Schreibst du sie vorher auf, hast du am Ende kein Vertragsproblem, sondern einen Projektplan.