Ein Gründer hat mir letzte Woche eine völlig berechtigte Frage gestellt: Wo steht dieses Projekt eigentlich gerade? Niemand im Raum konnte sie beantworten. Nicht weil die Daten fehlten, sondern weil sie in zwei Systemen lagen und keines davon für die Antwort zuständig war.
Diese Frage ist die teuerste in einer wachsenden Revenue-Organisation, und die Lösung, zu der Teams greifen, ist fast immer die falsche. Sie hören eine Anfrage nach Transparenz und fangen an, eine Integration zu scopen. Sechs Wochen später läuft ein Sync in beide Richtungen und der Gründer kann die Frage immer noch nicht beantworten.
Warum das schlimmer wird statt besser
Der Grund, warum Ihnen das immer wieder begegnet: Der Markt hat nicht geklärt, wo die Wahrheit liegt, also entscheidet das jedes Unternehmen still für sich. In seiner Analyse zu Salesforces Übernahme von Momentum im Februar hat Anthony McPartlin von Forrester die Wahl beschrieben, vor der Käufer jetzt stehen: entweder ein CRM-as-a-Platform-Ansatz, der Ihnen „simplicity, centralized governance, and a single point of accountability“ bringt, oder eine Best-of-Breed-Truth-Plattform, die Ihnen „faster innovation and advanced specialization“ bringt. Seine Prognose: Die Suites werden diese Orchestrierungsebenen weiter aufsaugen, statt Spezialisten zwischen CRM und Workflow sitzen zu lassen.
Das ist ein Kampf zwischen Anbietern. Ihre Version davon ist kleiner und dringender. Sie haben ein CRM, Sie haben ein zweites System, in dem die eigentliche Arbeit passiert, und Sie haben eine Führungskraft, die einen einzigen Satz darüber will, wo die Dinge stehen. Niemand hat entschieden, welches System diese Antwort geben darf.
Die Fehldiagnose
Das ist der Punkt. Wenn jemand nach Transparenz fragt, ist der Reflex, die Systeme zu verbinden: Zwei-Wege-Sync, Field Mapping, gespiegelte Datensätze auf beiden Seiten. Das ist sehr viel Bauaufwand, im Betrieb ehrlich gesagt teuer, und an dem Tag, an dem die Spiegelung auseinanderläuft, haben Sie ein neues Problem: Zwei Teams zeigen auf die Daten des jeweils anderen statt auf die Arbeit.
Es löst außerdem das Falsche. Die Führungskraft, die nach Transparenz fragt, will nicht die Datensätze des anderen Systems. Sie will drei Fakten: in welcher Phase das steckt, wer es gerade verantwortet und ob es blockiert ist. Das ist ein Reporting-Problem mit sehr kleiner Oberfläche, und Sie können es beantworten, ohne ein einziges Feld zu verschieben.
Ich würde hier das Keep / Edit / Delete-Raster anlegen, bevor jemand ein Integrationskonzept schreibt. Keep: die Daten, die die Frage der Führungskraft beantworten. Edit: die Journey, damit Verantwortung explizit wird. Delete: die Annahme, dass beide Systeme alles wissen müssen, was das andere weiß. Integration ist ein Weg, Transparenz zu kaufen, und es ist der teuerste auf der Karte.
Bauen Sie eine Status-Ebene über der Journey
Was Transparenz tatsächlich liefert, ist eine schlanke Ebene, die über Ihrer Customer Journey liegt und sie zusammenfasst. Keine weitere Pipeline. Ein kleiner Satz von Properties auf dem Objekt, das bei Ihnen die echte Arbeitseinheit ist: Account, Projekt oder Portfolio.
Das ist der Teil, den die meisten überspringen, weil eine Status-Ebene zu simpel aussieht für ein Problem, das sich architektonisch angefühlt hat.
Vier Felder tragen den größten Teil der Last:
- Aktueller Meilenstein. Ein Wert aus einer kurzen Liste, sechs bis zehn Optionen, nicht jeder einzelne Arbeitsschritt.
- Aktueller Owner. Der namentlich benannte Mensch, der für das Vorankommen verantwortlich ist, und der mit dem Meilenstein wechselt.
- Blockiert. Ein Ja/Nein-Feld plus eine Zeile Begründung.
- Datum der nächsten Aktion. Der Termin, an dem als Nächstes etwas passieren soll.
Diese Ebene berührt die zentralen Meilensteine und ignoriert die Details darunter bewusst. Wenn das operative System eine Checkliste mit fünfzig Schritten abarbeitet, interessiert die Status-Ebene die Schritte elf bis neunzehn nicht. Sie interessiert, dass Sie im Build sind, dass eine benannte Person verantwortlich ist und dass es nicht feststeckt. Granularität lebt dort, wo die Arbeit stattfindet. Die Zusammenfassung lebt dort, wo die Führungskraft hinschaut.
Jede Phase benennt ihr System
Die zweite Hälfte der Lösung ist Dokumentation, und sie ist um eine Größenordnung günstiger als die Integration. Gehen Sie die Journey Phase für Phase durch und schreiben Sie explizit auf, in welchem System die Leute in dieser Phase arbeiten und was sie dort tun.
Die meiste systemübergreifende Verwirrung ist überhaupt kein Datenproblem. Es hat nur niemand aufgeschrieben, wo die Arbeit passiert, also hat jedes der beiden Teams angenommen, das andere schaue hin. Sobald eine Phase sagt „ab hier arbeiten Sie im operativen Tool, und das Einzige, was das CRM von Ihnen braucht, ist der Meilenstein-Wert“, ist die Mehrdeutigkeit weg und der Sync, den Sie bauen wollten, schrumpft auf ein Feld.
Arbeiten Sie danach mit den Stärken der jeweiligen Plattform, statt sie einzuebnen. Case Routing, Ticketing und eingehende E-Mails gehören ins CRM, wo diese Mechanik ohnehin existiert. Die Ausführung gehört in das System, das für Ausführung gebaut wurde. Akzeptieren Sie, dass eine Person, meist ein Routing-Gatekeeper, über beide Systeme hinweg arbeitet. Das ist eine Rolle, kein Defekt.
Sichern Sie die Übergabe ab, statt sie zu synchronisieren
Die Übergabe ist der Punkt, an dem Transparenz tatsächlich stirbt, und die Belege dafür sind ungewöhnlich deutlich. Ein SaaStr-Panel dazu, wie die schnellsten KI-Unternehmen Customer Success neu gebaut haben, nennt die Übergabe „the place most failure and data loss happens“. Ein Unternehmen in diesem Panel hat Closed Won aus dem Vertrieb heraus und als Schwelle in die Implementierung verlegt, sodass ein unterschriebener Deal, der nie gestartet ist, auch nie gezählt wurde. Die Churn ging von 4 % pro Monat auf rund ein halbes Prozent zurück, während das Unternehmen von 8 Mio. USD auf 200 Mio. USD ARR skalierte.
Das ist keine Integrationsgeschichte. Das ist eine Definitionsgeschichte. Sie haben verändert, was eine Phase bedeutet und wer sie ausrufen darf.
Machen Sie dasselbe mit Ihren Gates. Eine Phase braucht Eintrittskriterien, und Sie betreten sie erst, wenn diese erfüllt sind. Sie übergeben einen Kunden nie an ein neues Team, solange das vorherige Team noch offene Punkte hat, denn genau in diesem Moment wird Verantwortung mehrdeutig und Transparenz verschwindet für alle oberhalb der Arbeit. Wenn Sie binäre Go/No-Go-Punkte in einer Phase vergraben haben, und die meisten technischen Prüfprozesse haben zwei oder drei davon, machen Sie aus jedem eine eigene benannte Phase mit eigenem Owner. Ein Checkpoint, den niemand sieht, ist ein Checkpoint, für den niemand verantwortlich ist.
Parallele Pipelines, parallele Verantwortung
Bei Teams, in denen kommerzielle und operative Arbeit wirklich gleichzeitig laufen, trägt eine Pipeline das nicht. Führen Sie zwei: eine kommerzielle Pipeline und eine operative Pipeline, die parallel dazu geöffnet wird, jede mit eigenen Phasen, beide laufen in dieselbe Status-Ebene.
Die Verantwortung teilt sich genauso auf. Führen Sie auf dem Account getrennte Owner-Felder für die kommerzielle und die operative Beziehung, dazu wer das Onboarding verantwortet und wer den Account nach dem Abschluss betreut. Es sieht nach mehr Feldern aus. Es sind weniger Diskussionen, weil es zu jedem Zeitpunkt genau einen Namen pro Fragetyp gibt.
Wie das in der Praxis aussah
Wir arbeiten mit einem kleinen DACH-Team, unter zwanzig Personen, das zwei schwierige Dinge gleichzeitig macht: die Migration weg von einem Alt-CRM und den Aufbau eines eigenen internen operativen Tools. Das erklärte Erfolgskriterium des Gründers für das gesamte Programm war eine einzige Ansicht, die zeigt, wo jedes Projekt steht, vom ersten eingehenden Lead bis zum laufenden Betrieb.
Auf dem Tisch lag der Vorschlag, die beiden Systeme zu verbinden. Der Gründer hat entgegnet, dass ihm das nicht reicht, und er hatte recht, wenn auch nicht aus dem Grund, den er vermutete. Das Problem war nie, dass die Daten an zwei Orten lagen. Es war, dass eine mehrstufige technische Prüfphase für alle außerhalb des ausführenden Teams unsichtbar war und niemand aufgeschrieben hatte, welches System zu welchem Zeitpunkt den Status eines Projekts besitzt.
Was wir stattdessen gescopt haben: acht Meilensteine auf dem Projektdatensatz, ein Owner-Feld pro Meilenstein, ein Read-only-Link vom CRM-Datensatz in das operative Tool für alle, die die Details brauchen, und drei Prüfpunkte, die aus versteckten Teilschritten zu benannten Phasen befördert wurden. Der Zwei-Wege-Sync ist komplett von der Roadmap geflogen. Gesamtaufwand: ein Bruchteil der Integration, und die Transparenz, nach der der Gründer gefragt hat, kommt in Wochen statt in einem Quartal.
Das Playbook
- Schreiben Sie zuerst die Frage auf. Holen Sie sich den exakten Satz, den die Führungskraft sagen können will, in ihren Worten. Jede Designentscheidung unten wird daran gemessen.
- Bestimmen Sie das Reporting-Zuhause. Ein System beantwortet „wo steht das“. Meist ist das das CRM, weil dort Funnel-Ansicht und Forecast bereits liegen. Entscheiden Sie es laut und verbindlich.
- Definieren Sie sechs bis zehn Meilensteine. Nur zentrale Übergänge. Wenn Sie mehr als zehn brauchen, beschreiben Sie Aufgaben, keine Meilensteine.
- Setzen Sie auf jeden Meilenstein einen Owner. Eine benannte Person, und sie wechselt, wenn der Meilenstein weiterrückt.
- Benennen Sie pro Phase das Arbeitssystem. Eine Zeile pro Phase im Journey-Dokument: hier arbeiten Sie in diesem System, und zwar so.
- Schreiben Sie Eintrittskriterien und setzen Sie sie durch. Kein Phasenwechsel, solange die vorherige Phase offene Punkte hat. Befördern Sie jedes versteckte Go/No-Go in eine sichtbare Phase.
- Verlinken statt spiegeln. Ein Read-only-Verweis von einem Datensatz auf den anderen deckt den Detailfall ab. Synchronisieren Sie nur den Meilenstein-Wert, und nur in eine Richtung.
- Prüfen Sie wöchentlich gegen Schritt eins. Wenn die Führungskraft den Satz immer noch nicht sagen kann, ist die Ebene falsch, und Sie reparieren die Ebene, nicht die Integration.
Die meisten Teams schaffen alle acht Punkte in ein paar Wochen. Die Integration, die sie gerade beauftragen wollten, hätte ein Quartal gedauert und die Frage trotzdem nicht beantwortet.
Wenn Ihr Führungsteam fragt, wo die Dinge stehen, und je nach befragter Person eine andere Antwort bekommt, dann haben Sie eine Transparenzlücke im Design, kein Tooling-Problem. Wir können die Status-Ebene über Ihre bestehende Journey legen, oder, falls das zweite System ein CRM ist, von dem Sie ohnehin weg wollen, mit der Migration anfangen. So oder so: Sagen Sie uns, was Ihre Führungskraft sehen will, und wir sagen Ihnen, ob Sie überhaupt eine Integration brauchen.
Quellen
- Forrester. „What Salesforce’s Acquisition Of Momentum Means.“ Anthony McPartlin, Februar 2026. forrester.com
- SaaStr. „Lovable, Harvey and Assembly AI: How the Fastest AI Companies Rebuilt Customer Success.“ Jason Lemkin, Juni 2026. saastr.com