Wenn ein Revenue-Leader uns bittet, den Forecast zu fixen, ist der Forecast in der Regel nicht das Problem. Die Pipeline-Stages darunter haben aufgehört, für die Reps, die Deals durch sie bewegen, dasselbe zu bedeuten. Discovery ist beim einen Rep der erste Call und beim anderen ein unterzeichneter Mutual Action Plan. Closed Won ist im einen Team Vertrag-unterschrieben und im anderen Kickoff-geplant. Die Conversion-Mathematik ist korrekt und operativ nutzlos, die Zahlen passen gegen Definitionen, die niemand teilt.
Warum das jetzt wichtig ist
Der Druck auf Stage-Definitionen ist gestiegen, nicht gefallen, seit AI im Funnel auftaucht. Der Beitrag von Sinha, Shastri, Lorimer und Mantrala in der Harvard Business Review vom September zu Sales-Teams, die neben AI wachsen, machte den Punkt: Die Teams, die vorne ziehen, behandeln AI als Coaching- und Orchestrierungs-Layer auf einem bereits sauberen Sales-Prozess, nicht als Ersatz dafür. Das ist die Asymmetrie. Wenn Ihre Stage-Definitionen straff sind, beschleunigt agentisches Tooling ein System, das bereits funktioniert. Wenn sie locker sind, automatisiert das AI fröhlich den Drift, Deals werden auf einem Stage-Signal geroutet, das bereits drei verschiedene Dinge bedeutet.
Die Diagnose, „Closed Won" bedeutet für drei Reps drei verschiedene Dinge
Machen Sie einen kleinen Test in Ihrer eigenen Instanz. Ziehen Sie die letzten paar Dutzend Deals, die von einer Stage wie Proposal-sent zu einer Stage wie Negotiation gewechselt haben, und fragen Sie jeden Rep, was der Stage-Übergang bedeutete. Sie bekommen Antworten wie, Pricing wurde gesendet; Pricing wurde gesendet und bestätigt; Pricing wurde gesendet, bestätigt und Procurement ist eingebunden; Pricing wurde gesendet und der Champion hat verbal Ja gesagt. Vier operative Realitäten, ein Stage-Wert, ein Forecast-Modell, das sie als gleichwertig behandelt.
Das ist kein Rep-Disziplin-Problem. Es ist ein Definitions-Problem. Reps tun, was Menschen immer tun, wenn ein System ihnen mehrdeutige Inputs gibt, sie füllen die Mehrdeutigkeit mit ihrer eigenen Arbeitsdefinition, und dann optimiert das Team rund um die Lücke. Deshalb fühlen sich Pipeline-Reviews wie Vernehmungen an. Der Manager reviewt nicht den Deal; er rekonstruiert, was der Rep mit der Stage gemeint hat.
Das einseitige Entry/Exit-Kriterien-Template
Die Lösung ist klein und unglamourös. Jede Stage in der Pipeline bekommt vier Zeilen auf einer einzigen geteilten Seite:
- Ein-Satz-Definition. Was diese Stage ist, in Sprache, die ein neuer Rep am dritten Tag lesen und sofort anwenden kann. Wenn Sie sie nicht in einen Satz schreiben können, macht die Stage zwei Jobs und muss aufgeteilt werden.
- Entry-Kriterien. Das spezifische, verifizierbare Ding, das auf dem Deal-Record wahr sein muss, damit die Stage betreten wird. „Champion hat Budget für dieses Geschäftsjahr bestätigt, erfasst in der Property Budget Confirmed."
- Exit-Kriterien. Das spezifische, verifizierbare Ding, das wahr sein muss, damit der Deal die Stage in Vorwärtsrichtung verlässt. Anders als Entry, das ist der Punkt.
- Owner. Die Rolle, die für den Übergang verantwortlich ist. Mal der AE; mal der SE; mal der Deal Desk. Den Owner zu benennen macht aus der Stage einen Prozessschritt statt eines Labels.
Das ist das ganze Template. Es passt auf eine Seite. Die Kosten liegen nicht im Schreiben. Die Kosten liegen in der Uneinigkeit, die beim Schreiben sichtbar wird, deshalb funktioniert das Template nur als Workshop, nicht als Doc, das man einer Person zum Entwerfen gibt.
An einem Deal entlanggehen, was an jeder Stage-Kante passiert
Ein Beispiel: Ein B2B-SaaS-Team, mit dem ich kürzlich gearbeitet habe, hatte eine sechsstufige Pipeline. Die mittlere Stage: nennen wir sie die Evaluation-Stage: hatte keine Entry-Kriterien und Exit-Kriterien, die fast wortgleich mit den Entry-Kriterien der nächsten Stage waren. Funktional war die Stage ein Parkplatz. Deals lebten dort im Median etwa drei Wochen länger als in jeder anderen Stage, und das Team hatte das stillschweigend als „so funktioniert die Mitte der Pipeline" akzeptiert. Als wir den Rewrite-Workshop liefen, passierten zwei Dinge in den ersten 20 Minuten. Den AEs wurde klar, dass sie diese Stage nutzten, um zu sagen, der Deal stockt, und sie nicht aus dem Forecast verlieren wollten. Dem CRO wurde klar, dass die Stage existierte, weil vor fünf Jahren jemand einen Platz für POCs wollte und seitdem niemand sie überprüft hatte. Die Entscheidung war einfach, sobald beides auf derselben Seite stand, Aufteilen. POCs bekamen ihre eigene Stage mit eigenen Entry- und Exit-Kriterien; die Parkplatz-Version der mittleren Stage wurde gelöscht.
Deshalb zählt der Workshop. Das Artefakt am Ende ist der One-Pager. Die Arbeit ist das Sichtbarmachen.
Stages, die Sie nicht definieren können
Manche Stages überleben das Rewrite sauber. Manche nicht. Das Muster, nach genug HubSpot-Instanzen, dass ich aufgehört habe zu zählen, Etwa ein Drittel der Stages braucht eine Definitions-Verschärfung, bleibt aber; etwa ein Drittel muss in zwei Stages aufgeteilt werden, weil sie zwei verschiedene operative Jobs machen; der Rest wird zusammengeführt oder gelöscht. Wenn Sie im Raum keine Ein-Satz-Definition schreiben können, ist die Stage keine Stage. Sie ist ein Flag und sollte als Property auf dem Deal-Record leben, nicht als Pipeline-Position.
Operative vs. Reporting-Stages
Auf der einen Seite brauchen Ihre Reps Stages, die zu dem passen, was sie tatsächlich täglich tun: die Action-Form, der nächste Call, das Artefakt, das benötigt wird, um voranzukommen. Auf der anderen Seite braucht Ihr CFO Stages, die sauber zu einem Forecast-Modell aggregieren, das auf Board-Level hält. Diese beiden Anforderungen haben nicht immer dieselbe Form. Wie ich es üblicherweise löse: Pipeline-Stages bleiben operativ (Rep-facing, action-shaped, vier bis sechs davon) und nutzen eine separate Forecast-Category-Property: Commit, Most-Likely, Best-Case, Pipeline, , die der Manager besitzt. Der Rep bewegt die Deal-Stage; der Manager weist die Forecast-Category zu. Verschiedene Felder, verschiedene Owner, kein Streit darüber, was eine einzelne Spalte bedeuten muss.
Muster aus der Praxis
Ein DACH-B2B-SaaS-Team in Series B kam mit der Bitte um Forecasting-Hilfe zu uns. Das vom CRO genannte Problem war, dass der gewichtete Forecast jedes Quartal deutlich danebenlag. Das tatsächliche Problem, das in der ersten Working Session sichtbar wurde, war, dass die achtstufige Pipeline drei Stages mit überlappenden Exit-Kriterien hatte und eine Stage, die das SDR-Team als Auffangbecken für unqualifizierte Leads nutzte. Wir liefen das Rewrite als zweistündigen Workshop mit den AE-Leads, dem SDR-Lead, dem CRO und dem RevOps-Lead im Raum. Output: Pipeline von acht auf fünf Stages reduziert; eine Stage zur Property befördert; eine Stage aufgeteilt, weil POCs und bezahlte Pilots verschiedene Motions waren. Das Forecast-Modell, das gegen die neue Architektur gebaut wurde, lag im nächsten Quartal innerhalb von zehn Prozent der Realität, nicht weil die Mathematik schlauer wurde, sondern weil die Inputs endlich etwas bedeuteten.
Auflösung, ein Playbook für das Rewrite
Wenn Sie das in Ihrer Instanz durchführen, kommt es auf die Reihenfolge an:
- Blockieren Sie zwei Stunden und holen Sie die richtigen Leute in den Raum. AE-Leads, SDR- oder BDR-Lead, falls Top of Funnel geteilt wird, CRO und wer immer RevOps besitzt. Keine Zuschauer. Die Uneinigkeit ist die Arbeit.
- Gehen Sie die aktuelle Pipeline Stage für Stage durch und lesen Sie die bestehenden Definitionen laut. Wenn keine schriftliche Definition existiert, lassen Sie jeden Rep im Raum eine in 60 Sekunden schreiben und vergleichen. Die Deltas sind die Diagnose.
- Füllen Sie für jede Stage die vier Zeilen aus. Definition, Entry, Exit, Owner. Wenn der Raum sich in drei Minuten nicht auf eine Ein-Satz-Definition einigen kann, macht die Stage zwei Jobs. Aufteilen.
- Markieren Sie jede Stage, deren Entry- und Exit-Kriterien identisch sind. Das ist keine Stage; es ist eine Deal-Property, die sich als eine ausgibt. Befördern Sie sie zur Property und entfernen Sie sie aus der Pipeline.
- Entscheiden Sie operativ vs. Reporting jetzt, nicht später. Pipeline-Stages bleiben Rep-facing und action-shaped. Forecast-Category wird ein separates, manager-eigenes Feld.
- Konfigurieren Sie die Änderungen in HubSpot, bevor jemand den Raum verlässt. Stage-Namen, Entry/Exit-Kriterien als Required-Properties oder Workflow-Gates erfasst, Owner-Zuweisungen. Wenn Sie die Konfiguration verschieben, zerfällt die Einigung in einer Woche.
- Re-baselinen Sie den Forecast gegen die neue Architektur. Alte Conversion-Raten übertragen sich nicht. Lassen Sie die nächsten zwei Pipeline-Reviews gegen die neuen Stages laufen, bevor Sie dem Modell wieder vertrauen.
Wo Checkpoint ins Spiel kommt
Pipeline-Stage-Rewrites sind eine der häufigsten Working Sessions, die wir innerhalb von RevOps-Engagements bei Checkpoint durchführen, meist im ersten Monat, fast immer vor jeder Forecasting- oder Reporting-Arbeit. Wenn Ihr Forecast danebenliegt, Ihre Conversion-Mathematik nicht vertrauenswürdig wirkt oder Ihre Reps im Pipeline-Review darüber streiten, was eine Stage bedeutet, ist das der Workshop, den Sie durchführen sollten, bevor Sie ein weiteres Quartal auf Definitionen modellieren, die niemand teilt.
Noah Charak