Die CRM-Adoption-Lücke: Wenn Automation versucht, smart zu sein – und es nicht ist

Es gibt einen Moment in jeder CRM-Migration, in dem das System aufhört, sich wie ein Projekt anzufühlen, und anfängt, sich wie ein Produkt anzufühlen, mit dem das Team leben muss. Er tritt normalerweise etwa eine Woche vor dem Go-live ein. Die Pipeline ist konfiguriert, die Properties sind gemappt, die Workflows triggern auf Kommando in der Sandbox. Der Implementierungspartner führt den Champion durch eine Demo. Alles funktioniert.

Und dann sagt der Champion etwas, das jedes RevOps-Team beunruhigen sollte: Ich habe nicht das Vertrauen, das unseren Nutzern zu präsentieren.

Nicht weil der Build fehlerhaft war. Sondern weil sich einige Felder mit Werten füllten, die sie nicht auf einen Trigger zurückführen konnten. Und wenn die Person, die für das Rollout verantwortlich ist, nicht erklären kann, was das System tut, werden es die Nutzer erst recht nicht können.

Warum das immer wieder passiert

Die Lücke zwischen „das System funktioniert“ und „das Team vertraut dem System“ ist der Punkt, an dem die meisten CRM-Migrationen still scheitern. Nicht die dramatische Art des Scheiterns, bei der der Launch verschoben und die Rechnung angefochten wird. Die stille Art, bei der die Adoption bei 40 % stagniert und der VP Sales innerhalb von zwei Wochen nach Go-live ein Schatten-Spreadsheet anlegt.

Die Harvard Business Review hat das kürzlich als das „Last Mile“-Problem bezeichnet: Die technische Fähigkeit ist vorhanden, aber das organisatorische Design hat nicht nachgezogen (Lakhani, Spataro und Stave, HBR, März 2026). Die CRM-Version davon ist spezifisch und vorhersagbar. Die Implementierung liefert das Datenmodell, die Automationen und die Integrationen, die 80 %, die sich scopen, schätzen und vorführen lassen. Was sie oft nicht liefert, ist die Antwort auf „Warum hat sich dieses Feld geändert?“, wenn ein Nutzer unerwartete Daten auf seinem Bildschirm sieht.

Forresters Enterprise-Software-Predictions für 2026 bestätigen das Muster: Business-Process-Standardisierung bleibt das hartnäckige Hindernis, selbst wenn das Tooling besser wird (Naik Lopez et al., Forrester, November 2025). CRM ist da keine Ausnahme. Das Adoption-Risiko liegt nicht darin, ob das System etwas kann. Es liegt darin, ob der Nutzer vorhersagen kann, dass das System es tun wird.

Clevere Automation vs. transparente Automation

Generell gibt es, wenn wir in einem CRM-Build eingebettet sind, zwei Designphilosophien, die bei jeder Automation-Entscheidung konkurrieren: smart machen oder transparent machen. Das klingt nach demselben Ziel. Ist es aber nicht.

Clevere Automation minimiert den Aufwand für den Nutzer. Sie füllt Felder automatisch, leitet Werte von anderen Objekten ab, führt bedingte Logik über Deal Stages hinweg aus und aktualisiert still die Record Ownership. Auf dem Papier sieht das elegant aus. In der Demo beeindruckend. Das Problem ist, dass clevere Automation Ergebnisse produziert, die der Nutzer nicht angefordert hat und oft nicht erklären kann.

Transparente Automation tut weniger, aber der Nutzer kann immer „warum“ beantworten. Ein Close Date aktualisiert sich, weil ich den Deal auf Closed Won verschoben habe: das habe ich gemacht, das verstehe ich. Ein Next-Meeting-Feld füllt sich, weil das System meinen Kalender gelesen hat, das kann ich verifizieren. Ein Design optimiert für Aufwandsreduzierung. Das andere für Vorhersagbarkeit.

Deshalb kommen wir immer wieder zu diesem Framing zurück: Eine Automation, die der Nutzer nicht erklären kann, ist eine Automation, die der Nutzer umgehen wird.

Wo die Adoption-Lücke tatsächlich steckt

Die Adoption-Lücke taucht nicht im Projektplan auf. Sie zeigt sich in drei spezifischen Momenten, nachdem der Build technisch abgeschlossen ist.

1. Der Champion-Walkthrough

Die Person, die das Rollout verantwortet, setzt sich zum ersten Mal mit dem System hin, ohne den Implementierungspartner im Call. Wenn sie auf ein Feld stößt, das sie nicht erklären kann: ein Datum, das als Zahl erscheint, ein Owner, der sich ohne sichtbaren Trigger geändert hat, verliert das System seine Glaubwürdigkeit, bevor sich ein einziger Endnutzer einloggt.

Wir haben kürzlich mit einem wachstumsstarken B2B-Unternehmen gearbeitet, das von Salesforce zu HubSpot migrierte. Der interne Champion war technisch versiert, durchgehend engagiert im Projekt und stellte in jeder Sprint Review die richtigen Fragen. Aber als es an der Zeit war, die neuen Layouts seinem Team zu präsentieren, fühlte er sich nicht sicher. Nicht weil der Build fehlerhaft war: weil mehrere automatisierte Felder Werte anzeigten, die er nicht auf einen Workflow zurückführen konnte.

2. Der Grenzfall, der nicht getestet wurde

Automationen funktionieren auf dem Happy Path perfekt, weil dort gebaut wird. Der Grenzfall: der, der Vertrauen zerstört, ist der, den die Demo nie abdeckt.

In einer eingebetteten Implementierung zum Beispiel wurde eine Account-Ownership-Automation entworfen, die den Owner basierend auf dem Deal-Stage-Fortschritt rotiert. Lead Owner übergibt an Account Executive, Account Executive an Customer Success, Customer Success an Account Manager, jeder Übergang ausgelöst durch die Vorwärtsbewegung des Deals. Bei jedem neuen Deal, der durch die Pipeline floss, funktionierte es einwandfrei. Aber als das Team einen Stapel verlorener Opportunities umverteilte: den Lead Owner neu zuwies, um einen zweiten Anlauf zu starten, versagte die Automation still. Das Lead-Owner-Feld aktualisierte sich; das Account-Owner-Feld folgte nicht. Niemand testete umverteilte Lost Deals, weil der Happy Path sauber aussah.

Diese Art von stillem Versagen kostet mehr als ein Bug. Sie kostet den Glauben des Teams daran, dass das System tut, was es vorgibt zu tun.

3. Das System, das versucht, smart zu sein

Ein Client-Champion hat das besser formuliert als jeder Consultant es könnte: Das System versucht, smart zu sein, aber dann ist es das nicht. Und das ist schlimmer, als gar nicht smart zu sein.

Wenn ein Nutzer einen manuellen Prozess erwartet und einen bekommt, weiß er, was zu tun ist. Wenn ein Nutzer Automation erwartet und einen falschen Wert bekommt, weiß er nicht, ob er ihn korrigieren, ignorieren oder eskalieren soll. Also hört er auf, dem System zu vertrauen. Das ist die Adoption-Lücke: nicht zwischen funktionierend und kaputt, sondern zwischen vorhersagbar und undurchsichtig.

Die Checkliste für transparente Automation

Vor dem Go-live führen wir fünf Prüfungen an der Automation durch. Nicht ob sie funktioniert, ob der Nutzer sie erklären kann.

1. Jedes automatisierte Feld auf eine Nutzeraktion oder ein dokumentiertes System-Event zurückführen. Wenn der Nutzer nicht sagen kann „das hat sich geändert, weil ich X getan habe“ oder „das aktualisiert sich nächtlich über den Data-Warehouse-Sync“, ist die Automation undurchsichtig. Den Trigger sichtbar machen oder die Automation entfernen.
2. Die Unhappy Paths testen. Umverteilte Deals, wiedergeöffnete Tickets, manuell überschriebene Stages, Kontakte ohne zugeordnetes Unternehmen. Das sind die Pfade, die die Demo nie abdeckt und die der Nutzer am dritten Tag trifft.
3. Dem Champion einen Solo-Walkthrough geben. Kein Implementierungspartner im Raum. Wenn er jedes nicht offensichtliche Feld nicht einem Kollegen erklären kann, ist die Automation zu clever für die aktuelle Reife dieses Teams. Das muss man mit etwas Vorsicht genießen, nicht jedes Feld braucht eine Erklärung. Aber die, die in der primären Deal- oder Kontaktansicht erscheinen, schon.
4. Die Automation in der Feldbeschreibung benennen. Sowohl HubSpot als auch Salesforce unterstützen Feldbeschreibungen. „Aktualisiert durch [Workflow: Deal Stage Progression]“ kostet nichts und beantwortet die Frage, bevor sie gestellt wird.
5. Eine einseitige Automation-Übersicht für das Training erstellen. Nicht das vollständige Workflow-Diagramm: eine Klartext-Tabelle: dieses Feld, dieser Trigger, dieses erwartete Verhalten. Wenn die Tabelle mehr als 15 Zeilen hat, ist die Automation wahrscheinlich zu clever für die Reife des Teams.

Die Reifefrage

Das hängt ein Stück weit davon ab, wo das Team steht. Ein Unternehmen, das seit drei Jahren in einem CRM lebt und eine dedizierte RevOps-Funktion hat, kann mehr clevere Automation absorbieren: es hat den Kontext, um unerwartetes Verhalten zu debuggen. Ein Team, das zum ersten Mal migriert, oder dessen RevOps-Reife selbstbeschrieben „funktional, aber nicht voll ausgebaut“ ist, braucht standardmäßig transparente Automation.

Das ist kein Urteil. Es ist eine Staging-Entscheidung. Man kann später immer clevere Automation hinzufügen, wenn das Vertrauen in das Fundament etabliert ist. Man kann Vertrauen nicht zurückgewinnen, das man verbrannt hat, indem man Automation ausgeliefert hat, der das Team von Tag eins nicht folgen konnte.

Und es gibt einen praktischen Test dafür: Wenn die Person, die für das User-Training verantwortlich ist, nicht erklären kann, was das System tut, ohne das Workflow-Diagramm zu lesen, ist die Automation dem Reifegrad des Teams voraus. Zurückdrehen. Erst transparent. Dann clever.

Quellen

• Lakhani, K. R., Spataro, J., & Stave, J. „The 'Last Mile' Problem Slowing AI Transformation.“ Harvard Business Review, März 2026. hbr.org
• Naik Lopez, A., Medhora, F., Cicman, J., Leggett, K., & Martorelli, B. „Predictions 2026: AI Agents, Changing Business Models, and Workplace Culture Impact Enterprise Software.“ Forrester, November 2025. forrester.com