Vom Revenue-Chaos zur skalierbaren GTM-Engine

Warum mehr Tools selten die Lösung sind und in welcher Reihenfolge Operations, Analytics und Enablement aufgebaut werden sollten

Wachsende Unternehmen kaufen neue Tools, automatisieren einzelne Aufgaben und bauen Dashboards. Trotzdem bleiben Forecasts unzuverlässig, Übergaben brechen und Teams arbeiten nach unterschiedlichen Regeln.

Das Problem ist selten ein fehlendes Tool. Meist fehlt ein gemeinsames Revenue-System.

Die kurze Antwort

Eine skalierbare Revenue Engine entsteht in drei Schritten:

1. Operations: Klare Prozesse, Rollen, Datenstandards und Verantwortlichkeiten schaffen.
2. Analytics: Messen, wo Pipeline verloren geht, Zeit verschwendet wird oder Forecasts unzuverlässig werden.
3. Enablement: Teams gezielt befähigen, die definierten Prozesse wirksam anzuwenden.

Die Reihenfolge ist entscheidend. Wer Enablement oder Automatisierung auf unsauberen Prozessen aufsetzt, skaliert vor allem das bestehende Chaos.

Woran Revenue-Chaos erkennbar wird

Alexander Müller beschreibt drei typische Situationen:

1. Founder-led Sales lässt sich nicht übertragen

Founder verkaufen oft intuitiv, Sie kennen Produkt, Markt und Kunden so gut, dass sie ohne klar dokumentierten Prozess arbeiten können. Sobald weitere Seller dazukommen, reicht dieses implizite Wissen nicht mehr.

Typische Symptome:

• Jeder qualifiziert Opportunities anders.
• CRM-Daten sind lückenhaft oder widersprüchlich.
• Der Forecast hängt von Einzelmeinungen ab.
• Neue Mitarbeitende brauchen zu lange, um produktiv zu werden.

Der Fehler ist nicht, dass der Founder ohne Playbook erfolgreich war. Der Fehler ist anzunehmen, dieses Vorgehen ließe sich ohne Übersetzung auf ein Team übertragen.

2. Der Tool-Stack wächst schneller als das System

Für fast jedes GTM-Problem gibt es inzwischen Software. Dadurch entsteht leicht der Eindruck, jedes Problem ließe sich durch ein weiteres Tool lösen.

In der Praxis führt das häufig zu:

• überlappenden Funktionen,
• mehrfach gepflegten Daten,
• niedriger Adoption,
• zusätzlichen Übergaben,
• unklaren Systemzuständigkeiten.

Ein Tool ist erst dann sinnvoll, wenn das zugrunde liegende Problem, der gewünschte Outcome und der verantwortliche Prozess klar sind.

3. Größere Unternehmen verlieren den Kontakt zur Frontline

Mit wachsender Organisation werden Prozesse stabiler, aber häufig auch starrer. Operations-Teams optimieren dann Reports und Systeme, ohne ausreichend zu verstehen, wie Sales, Customer Success oder Partnerships tatsächlich arbeiten.

Alexanders Gegenmittel ist bewusst einfach: RevOps-Verantwortliche sollen regelmäßig Zeit mit den Teams verbringen, für die sie Prozesse bauen, Nicht nur im Meeting, sondern in Calls, Übergaben und echten Arbeitsabläufen.

Das Revenue-Engine-Modell

Alexander erklärt RevOps mit einem Rennwagen:

• Operations baut das Auto.
• Analytics zeigt, in welcher Kurve Zeit verloren geht.
• Enablement hilft dem Fahrer, an der richtigen Stelle zu beschleunigen.

Die Metapher ist nützlich, weil sie einen verbreiteten Fehler sichtbar macht: Ein Training repariert keinen schlechten Prozess. Ein Dashboard löst kein unklar definiertes Datenmodell, Und Automation beschleunigt auch falsche Abläufe.

Stufe 1: Operations

Ziel ist eine belastbare, möglichst einfache Grundlage.

Dazu gehören:

• ein gemeinsamer Funnel,
• klare Stage-Kriterien,
• definierte Verantwortlichkeiten,
• saubere Übergaben zwischen Marketing, Sales, CS und Finance,
• ein CRM als verlässliche Datenbasis,
• nur die Tools, die einen klaren Prozess unterstützen.

Wichtig: Ein kleines Unternehmen braucht keine Enterprise-Bürokratie. Der Prozess muss Orientierung geben, nicht Geschwindigkeit verhindern.

Stufe 2: Analytics

Erst wenn der Prozess definiert ist, können Zahlen sinnvoll interpretiert werden.

Relevante Fragen sind:

• Wo sinkt die Conversion Rate?
• Wie lange bleiben Deals in einzelnen Stages?
• Welche Leads oder Accounts konvertieren wirklich?
• Wie zuverlässig ist der Forecast?
• Wie schnell wird aus Pipeline tatsächlich Umsatz?
• Wo entstehen manuelle Arbeit und Datenlücken?

Der entscheidende Punkt: Ein Dashboard ist kein Selbstzweck. Jede Kennzahl sollte eine Entscheidung ermöglichen.

Stufe 3: Enablement

Enablement übersetzt Prozess und Daten in besseres Verhalten.

Das kann bedeuten:

• Manager auf konkrete Coaching-Signale vorzubereiten,
• Seller in Discovery oder Qualification zu trainieren,
• Handover-Standards zu verankern,
• neue Tools in reale Workflows zu integrieren,
• erfolgreiche Verhaltensweisen reproduzierbar zu machen.

Enablement beginnt deshalb nicht mit einem Trainingskalender, sondern mit einem nachgewiesenen Engpass.

Das praktische Playbook

Schritt 1: Den Business-Engpass benennen

Nicht mit dem Tool starten. Formuliere zuerst das Problem:

Wir verlieren zu viele qualifizierte Opportunities zwischen Discovery und Proposal, weil Entscheidungskriterien und nächste Schritte nicht verbindlich dokumentiert werden.

Ein gutes Problemstatement beschreibt Ausgangslage, Auswirkung und betroffenen Prozess.

Schritt 2: Den Ist-Zustand auditieren

Prüfe fünf Bereiche:

Schritt 3: Die kleinste wirksame Veränderung wählen

Nicht jeder Engpass verlangt ein großes Transformationsprojekt. Mögliche Maßnahmen sind:

• Stage-Kriterien präzisieren,
• Pflichtfelder reduzieren,
• eine Übergabe standardisieren,
• ein bestehendes Tool besser konfigurieren,
• einen manuellen Schritt automatisieren,
• eine konkrete Fähigkeit coachen.

Schritt 4: Erfolg vorab definieren

RevOps sollte nicht nur an erledigten Projekten gemessen werden. Sinnvoller ist eine Kombination aus Business- und Prozessmetriken:

• Conversion Rate,
• Sales Cycle beziehungsweise Conversion Speed,
• Forecast Accuracy,
• ACV oder realisierter Umsatz,
• Zeitersparnis bei manuellen Aufgaben,
• Datenvollständigkeit,
• Adoption des neuen Workflows.

Nicht jede Wirkung lässt sich exakt isolieren. Trotzdem sollte vor Projektstart klar sein, welche Veränderung erwartet wird.

Schritt 5: Mit der Frontline bauen

Hole Input von den Personen ein, die täglich im Prozess arbeiten. Beobachte tatsächliche Abläufe und verlasse dich nicht nur auf Prozessdiagramme.

Das schützt vor zwei Fehlern:

1. RevOps baut etwas, das im Alltag nicht funktioniert.
2. Teams betrachten den neuen Prozess als Kontrolle statt als Unterstützung.

Schritt 6: Quartalsweise priorisieren

Eine jährliche Richtung schafft Orientierung. Eine quartalsweise Roadmap zwingt zur Auswahl.

Jede Initiative sollte mindestens eine dieser Fragen beantworten:

• Steigert sie Conversion?
• Verkürzt sie die Zeit bis zum Umsatz?
• Verbessert sie Steuerbarkeit oder Forecast?
• Reduziert sie relevante manuelle Arbeit?
• Verbessert sie die Customer Journey über Teamgrenzen hinweg?

Wo die Argumentation Nuance braucht

Nicht jedes kleine Unternehmen braucht sofort ein RevOps-Team

Der Bedarf entsteht nicht bei einer bestimmten Mitarbeiterzahl. Entscheidend sind Komplexität, Anzahl der GTM-Rollen, Marktsegmente, Regionen, Systeme und Übergaben.

Ein kleines Unternehmen kann RevOps-Kompetenz brauchen, ohne direkt mehrere Vollzeitstellen aufzubauen. Zu Beginn können klare Ownership, ein interner Operator oder gezielte externe Unterstützung genügen.

Tool-Reduktion ist kein Selbstzweck

Zu viele Tools sind problematisch. Zu wenige können es ebenfalls sein. Die bessere Frage lautet nicht: „Wie viele Tools haben wir?“, sondern: „Hat jedes Tool einen klaren Job, Owner und messbaren Nutzen?“

Revenue endet nicht am Closed Won

Die Episode erweitert Revenue-Verantwortung bis zum Zahlungseingang. Das ist sinnvoll, darf aber nicht zu unklarer Governance führen. RevOps sollte funktionsübergreifend koordinieren. Finance bleibt für Billing, Cash Collection und finanzielle Kontrolle verantwortlich.

AI ersetzt keine Prozessentscheidung

AI kann Daten erfassen, Workflows erstellen und Systeme verbinden, Sie entscheidet aber nicht automatisch, welcher Prozess strategisch richtig ist. Besonders die letzten Prozent eines Workflows benötigen weiterhin Kontext, Kontrolle und klare Verantwortlichkeit.

Dominics Einordnung

Der wichtigste Gedanke aus dem Gespräch ist für mich nicht, dass jedes Unternehmen RevOps braucht. Es ist die Reihenfolge.

Viele Teams kaufen ein Tool, bauen eine Automation und hoffen, dass dadurch ein besserer Prozess entsteht. In der Realität passiert meistens das Gegenteil: Der alte Prozess läuft nur schneller und wird schwerer zu verändern.

Ich würde deshalb bei jeder neuen GTM-Lösung drei Fragen stellen:

1. Welches konkrete Problem lösen wir?
2. Welche Zahl oder welches Verhalten soll sich verändern?
3. Würden wir den Prozess auch ohne dieses Tool genauso bauen?

Wenn die dritte Antwort Nein lautet, ist wahrscheinlich nicht das Tool die Lösung, sondern der Prozess noch nicht klar genug.

Ausgewählte Aussagen aus der Folge

„Du musst eher deine Probleme verstehen und überlegen: Was brauchst du eigentlich?“
ca. 08:30

„Für mich gehören zu RevOps drei Bereiche: Operations, Analytics und Enablement.“
ca. 14:00

„Revenue hört nicht da auf, wo der Sale gemacht ist, sondern eigentlich erst, wenn das Geld reinkommt.“
ca. 20:00

„Wo mache ich jetzt eigentlich gerade den größten Unterschied?“
ca. 27:00

„AI ist nicht immer die Lösung. Wir müssen vor allem das Ergebnis prüfen.“
ca. 34:30

Fazit

Eine Revenue Engine wird nicht skalierbar, weil mehr Software eingesetzt wird, Sie wird skalierbar, wenn Teams nach klaren Regeln arbeiten, Engpässe sichtbar werden und Verbesserungen gezielt im Alltag verankert werden.

Die sinnvollste Reihenfolge bleibt:

Operations → Analytics → Enablement

Erst das System bauen. Dann messen. Dann optimieren.