Pipeline-Stage-Design: Die drei Dinge, die jede Stage braucht

Die meisten GTM-Systeme, die ich diagnostiziere, haben dasselbe strukturelle Problem: Pipeline-Stages, die benannt, aber nie definiert wurden. Marketing Qualified Leads fließen an Sales. Deals bewegen sich von Discovery zu Proposal. Opportunities werden als Closed Won markiert. Aber wer fragt, was genau wahr sein muss, damit ein Deal zwischen diesen Stages vorwärtsgeht, erhält eine Beschreibung — kein Kriterium.

Eine Beschreibung ist keine Definition. Und ein undefiniertes Gate ist kein Gate. Es ist eine Lücke.

Revenue Operations (RevOps) — die Funktion, die Marketing, Sales und Customer Success unter einem gemeinsamen operativen Framework ausrichtet — hängt vollständig von der Qualität der Definitionen auf jeder Stage ab. Eine Prozessebene, die auf vagen Kriterien aufgebaut ist, produziert verunreinigte Daten. Verunreinigte Daten produzieren ungenaue Forecasts. Ungenaue Forecasts produzieren verfehlte Zahlen. Immer. In jedem Maßstab.

Was braucht jede Pipeline-Stage?

Jede Stage in einem B2B-Verkaufsprozess — ob PLG-Motion, Enterprise-Direktvertrieb oder ein Hybridmodell — benötigt genau drei definierte Komponenten. Ohne alle drei ist die Stage ein Label, kein System.

Komponente 1: Expected Behaviour

Expected Behaviour definiert, was der Sales-Mitarbeitende oder SDR tun muss, während sich ein Deal in dieser Stage befindet. Dazu gehören der Time-in-Stage-Benchmark (wie lange sollte ein Deal normalerweise hier verweilen), das Conversion-Rate-Ziel für diese Stage und die Mindest-Aktivitätsfrequenz je Segment.

Im Enterprise-Segment muss die Kontaktfrequenz präzise festgelegt sein: ein sinnvoller Touchpoint alle vier Wochen ist eine Strukturregel, keine Präferenz. Wenn die Kontaktfrequenz nicht segmentspezifisch definiert ist, trifft jeder Mitarbeitende seine eigene Entscheidung — und das Ergebnis ist kein Prozess, sondern 20 parallele Interpretationen desselben.

Aktivitätsfrequenz-Standards gehören ins CRM. Sie sollen automatisch als Flags ausgelöst werden, nicht als Erinnerungen an Manager, die dann manuell nachfassen müssen. Sobald ein Manager persönlich prüfen muss, ob Mitarbeitende einem Prozess folgen, ist dieser Prozess bereits gescheitert.

Komponente 2: Qualifikationskriterien

Qualifikationskriterien definieren, was als wahr bestätigt sein muss, damit ein Deal in dieser Stage bleibt. Das operative Schlüsselwort ist: bestätigt. Nicht vermutet. Nicht angenommen. Bestätigt mit harten Daten.

Binäre Qualifikation ist nicht verhandelbar. Wenn ein Kriterium einen Sales-Mitarbeitenden auffordert, Ermessen walten zu lassen — „der Interessent wirkt engagiert“, „der Senior-Entscheider scheint interessiert“ — ist es kein Kriterium. Es ist eine Meinung. Meinungen auf der Qualifikationsebene bedeuten, dass Ihre SQL-Anzahl keine Anzahl qualifizierter Leads ist — es ist eine Anzahl optimistischer Einschätzungen.

Die Regel, die wir in unseren Cremanski-Projekten anwenden, ist eindeutig: Wenn ein SDR eine Ermessensentscheidung treffen muss, um dieses Kriterium anzuwenden, ist das Kriterium noch nicht fertig. Es muss in eine binäre, datenprüfbare Bedingung umgearbeitet werden.

Komponente 3: Exit-Kriterien

Exit-Kriterien definieren die genauen Bedingungen, die erfüllt sein müssen, bevor ein Deal zur nächsten Stage voranschreitet. Nicht Bedingungen, die erfüllt sein sollten. Nicht Bedingungen, die üblicherweise erfüllt sind. Bedingungen, die verifiziert sein müssen, bevor ein Voranschreiten erlaubt wird.

Exit-Kriterien sind der Punkt, an dem Qualität in die Pipeline einfliesst. Sie sind auch der Punkt, an dem Sales-Teams am stärksten Widerstand leisten — weil durchgesetzte Exit-Kriterien den Unterschied zwischen einer gesunden und einer optimistischen Pipeline sichtbar machen. Diese Transparenz ist unangenehm. Sie ist auch unabdingbar.

Kein Senior-Override. Keine Manager-Ausnahme. Wenn Exit-Kriterien verhandelbar sind, sind es keine Exit-Kriterien. Sobald eine Ausnahme gemacht wird, ist die Botschaft an das Team: die Kriterien sind aspirativ. Und ein aspiratives Kriterium entspricht funktional keinem Kriterium.

Was sind die drei Hard Gates?

Innerhalb der Pipeline haben drei Momente überproportionales Gewicht: MQL, SQL und Closed Won. Jeder repräsentiert eine Übergabe zwischen Funktionen. Jede Übergabe ist entweder ein Qualitäts-Checkpoint oder eine Qualitätslücke.

MQL: Das Ende der Marketing-Verantwortung

Die MQL-Definition markiert die Grenze der Output-Verantwortung von Marketing. Sie muss vollständig je Segment definiert sein. Nur harte Kriterien — Engagement-Scores kombiniert mit firmografischen Schwellenwerten, nicht eines davon isoliert.

Soft-Scoring-Modelle, die auf „Lead-Score über X“ ohne Verankerung an explizite Aktivitäts- und firmografische Daten setzen, produzieren MQLs, die statistisch wahrscheinlich, aber individuell unzuverlässig sind. Der SDR-Überblick sieht im Durchschnitt gut aus. Die Varianz unterhalb dieses Durchschnitts ist der Ort, an dem sich das Pipeline-Qualitätsproblem verbirgt.

SQL: Das Ende der Qualifikationsphase

Das SQL-Gate ist der Punkt, an dem die kostspieligsten Qualitätsfehler entstehen. Ein SQL, der die binären Qualifikationskriterien tatsächlich nicht erfüllt, kostet einen Account Executive Zeit, stört das Forecasting und verunreinigt den Conversion-Nenner, von dem Ihre Pipeline-Coverage-Ratio abhängt.

In dem früher erwähnten Fall — 38% Pipeline ohne Kaufbelege — war jeder dieser Deals als SQL markiert. Das Gate existierte. Es wurde nicht gehalten. Der Forecast war strukturell unmöglich zu erreichen ab dem Moment, in dem diese Deals die Pipeline betraten.

Closed Won: Qualität entsteht durch das, was davor kommt

Closed Won ist das Ergebnis von allem Vorgelagerten. Wenn die MQL-Definition unklar war, wenn das SQL-Gate nicht gehalten wurde, wenn die Exit-Kriterien beim Deal-Review überstimmt wurden — summiert sich die Kontamination. Eine Pipeline mit kompromittierter Qualifikation am Eingang kann keinen zuverlässigen Forecast am Ausgang produzieren.

Wie auditieren Sie Ihr aktuelles Stage-Design?

Ein Stage-Design-Audit erfordert keine externen Berater. Es erfordert ehrliche Antworten auf vier Fragen, angewandt auf jede Pipeline-Stage.

‍

Ein ehrlicher Durchlauf dieses Audits über eine zehnstägige Pipeline deckt in der Regel drei bis sechs strukturell undefinierte Stages auf. Das ist kein Versagen des Teams. Es spiegelt wider, wie die meisten Pipeline-Prozesse aufgebaut wurden: iterativ, unter Druck, ohne die Zeit, präzise zu definieren, was jede Stage eigentlich bedeutet.

Die Lösung ist kein Schulungsprogramm. Es ist eine Design-Session, gefolgt von CRM-Implementierung, gefolgt von Durchsetzung.

FAQ: Pipeline-Stages, Gate-Design und Qualifikation

Was ist der Unterschied zwischen Qualifikationskriterien und Exit-Kriterien?

Qualifikationskriterien definieren, was wahr sein muss, damit ein Deal in einer bestimmten Stage ist. Exit-Kriterien definieren, was wahr sein muss, damit ein Deal zur nächsten Stage voranschreitet. Beide müssen binär sein. Ein Deal kann Eintrittskriterien erfüllen, aber noch nicht die Bedingungen für das Voranschreiten — z. B. bestätigtes Budget (Qualifikation), aber keine bestätigte Entscheidungskompetenz (Exit-Kriterium für das Voranschreiten zur Proposal-Stage).

Wie viele Pipeline-Stages sollte ein B2B-SaaS-Unternehmen haben?

Fünf bis acht Stages decken die meisten B2B-SaaS-Motions effektiv ab. Weniger als fünf bedeutet in der Regel, dass Exit-Kriterien in vagen Definitionen zusammengefasst werden. Mehr als acht bedeutet meist, dass Stages interne Aktivitäten statt Käufermeilensteine verfolgen. Die richtige Anzahl ist diejenige, bei der jede Stage eine eigenständige, verifizierbare Änderung des Käuferstatus repräsentiert.

Sollten Enterprise- und SMB-Deals denselben Pipeline-Stages folgen?

Die Stage-Namen können geteilt werden, aber die Definitionen müssen segmentspezifisch sein. Time-in-Stage-Benchmarks, Kontaktfrequenzstandards und Conversion-Ziele unterscheiden sich zwischen Enterprise und SMB erheblich. Eine einzige Pipeline mit einheitlichen Benchmarks produziert Durchschnittswerte, die für kein Segment aussagekräftig sind.

Was passiert mit der Forecast-Genauigkeit, wenn SQL-Kriterien nicht durchgesetzt werden?

Die Forecast-Genauigkeit verschlechtert sich proportional zum Anteil nicht qualifizierter Deals in der Pipeline. In einem Cremanski-Projekt hatten 38% der Pipeline keine Kaufbelege — alle als SQL markiert. Der darauf aufbauende Forecast war strukturell unerreichbar. Nach Durchsetzung binärer SQL-Kriterien stieg die Forecast-Genauigkeit innerhalb eines Quartals von 61% auf 94%.

Wie geht man mit erfahrenen Sales-Mitarbeitenden um, die Exit-Kriterien ablehnen?

Die Reaktion ist strukturell, nicht interpersonell. Exit-Kriterien gelten für Deals, nicht für Personen. Wenn das CRM kein Voranschreiten ohne erfüllte Kriterien erlaubt, wird die Durchsetzung zu einer Eigenschaft des Tools, nicht zu einem Führungsverhalten. Der Widerstand nimmt erheblich ab, wenn er nicht mehr auf eine Person gerichtet ist.