Zwei Working-Sessions diese Woche, derselbe Klient, derselbe Raum, zwei unterschiedliche Probleme an der Wand: und eines davon war eine stille Pipeline-Diagnose, mit der das Team seit einem Jahr saß. Der Head of Sales öffnete die offizielle HubSpot-Pipeline, ging die Deal-Stages durch und stellte dann eine Frage, die einen Moment im Raum hängen blieb. Was ist mit den fünfzig SQLs, die wir noch nicht herübergezogen haben? Niemand antwortete, weil niemand die Antwort hatte. Fünfzig Leads, die ein Sales-Meeting genommen, die erste Qualifizierung bestanden hatten und irgendwo auf einem Contact-Record mit dem Lifecycle-Stage SQL saßen, aber ohne Deal-Record. Unsichtbar für den Forecast. Unsichtbar für das Pipeline-Review. Unsichtbar für das Capacity-Gespräch zum nächsten Quartal. Diese Lücke ist die teuerste strukturelle Entscheidung in Mid-Stage-B2B-SaaS-HubSpot-Instanzen gerade jetzt, und sie hat nichts mit HubSpot zu tun. Sie hat damit zu tun, wann Sie entscheiden, dass der Deal beginnt.
Warum das jetzt zählt
Jason Lemkins Januar-Readout zum 2026 Sales Reckoning war deutlich über den strukturellen Wandel, der im Gang ist: AI-native B2B-Teams führen Sales-Benches, die etwa halb so groß sind wie ihre Vorgänger, und AI-getriebener Outbound generiert in seiner eigenen Organisation ein Viertel der neuen Pipeline innerhalb von neunzig Tagen. Das ist das Makro-Bild, in dem diese Lücke auftaucht. AI-verkleinerte Sales-Teams verschärfen das strukturelle Problem, es gibt keine SDR-Schicht mehr, die die Lücke zwischen einem MQL und einem Deal-Record per Hand schließt. Der AE ist derjenige, der Discovery fährt, und der AE hat jeden Anreiz, die Deal-Erstellung aufzuschieben, bis er sicher ist, dass es real ist. Multiplizieren Sie das auf zehn Reps über ein Quartal, und Sie bekommen die fünfzig-SQL-Schublade. Die Forecasts sind nicht falsch, weil das Close-Date-Modell schlecht ist. Sie sind falsch, weil die Pipeline die Deals nicht enthält.
Wo die SQL-Lücke in HubSpot lebt
HubSpots Lifecycle ist contact-property-geformt: Subscriber, Lead, MQL, SQL, Opportunity, Customer. Der Deal ist ein separates Objekt, das: in der Regel: erstellt wird, wenn der Contact-Lifecycle auf die Opportunity-Stage wechselt. Die Konvention ist im Prinzip vernünftig und in der Praxis ein Desaster, weil die operative Definition von Opportunity in den meisten Sales-Teams lautet, „Ich bin überzeugt genug, das in die Pipeline zu committen.“ Diese Confidence-Schwelle ist gesund, aber sie ist hoch. Ein gebuchtes Meeting ist nicht Opportunity. Ein erster Discovery-Call ist nicht Opportunity. Selbst ein Follow-up-Demo ist nicht Opportunity, wenn das Budget nicht validiert wurde. Ein echter Lead kann also vier bis acht Wochen im SQL-Lifecycle-Stage verbringen, auf einem Contact-Record, ohne angehefteten Deal. Der AE leistet Arbeit. Das System zeigt nichts.
Die fünfzig-SQL-Schublade ist das Ergebnis. Es ist kein Prozess-Fehler. Es ist die Architektur, die so funktioniert wie konzipiert, angewendet auf eine Sales-Motion, die nicht mehr zum Schema passt. Die Kosten sind nicht sichtbar, bis zum Pipeline-Review, wenn jemand fragt, was zwischen der MQL-Zahl von Marketing und der Deal-Anzahl der Deal-Pipeline passiert, und niemand die Brücke erzeugen kann.
Die vorherrschende Weisheit lautet, den Deal später zu erstellen
Die Standard-Empfehlung, Lemkins SaaStr Q&A zu genau dieser Frage ist die sauberste Formulierung davon, lautet: warten. Konvertieren Sie einen Lead erst in eine Opportunity, wenn ICP, Pain, Engagement und Buying-Intent alle bestätigt sind. Die Begründung ist solide. Erstellen Sie Deals zu früh, und die Pipeline blähen sich auf, Coverage-Ratios verzerren sich, der Forecast wird zu Rauschen, und die Reps verlieren die Disziplin, einen Deal als echtes Commitment zu behandeln. Lemkins konkrete Formulierung lautet, dass eine zu frühe Konvertierung Pipelines verstopft und Sales-Ressourcen verschwendet; eine zu späte verliert Momentum. Die meisten CROs lesen das und wählen die sicherere Seite, spät.
Wählen Sie spät, schützen Sie zwar die Forecast-Genauigkeit, geben aber zwei Dinge auf, die Sie 2026 dringender brauchen: Pipeline-Visibility und AE-Accountability für die laufende Arbeit, die noch nicht als Deal zählt. Die fünfzig SQLs in der Schublade sind genau die Arbeit, die der AE leistet. Sie sind nicht im System. Also ist der AE nicht für sie verantwortlich, der Head of Sales kann sie nicht sehen, der Forecast kann sie nicht bewerten, und das Ramp-Modell kann keine Capacity-Planung gegen sie fahren. Das ist ein zu hoher Preis für eine saubere Coverage-Ratio.
Die Pre-pipeline-Stage: eine dritte Option
Was ich empfehlen würde, ist weder spät noch früh. Es ist beides, durch einen Filter getrennt. Erstellen Sie den Deal beim Meeting Booked: dem günstigsten zuverlässigen Signal, dass ein AE Zeit committet und der Prospect Kalender committet hat, aber erstellen Sie ihn in eine Deal-Stage namens Pre-pipeline, mit einer Default-Win-Probability von null oder fünf Prozent, die aus jedem Forecast-Report, jedem Dashboard-Widget, jeder Coverage-Kalkulation und jeder Weighted-Pipeline-View in der Instanz herausgefiltert wird. Der Deal existiert für Accountability, Visibility und Tracking. Er existiert nicht für den Forecast. Bis er sich durch ein definiertes Exit-Kriterium den Weg in die Pipeline verdient hat, aggregiert er nirgendwo in eine einzige Revenue-Zahl.
Das ist der Keep-Edit-Delete-Move, angewendet auf die Architektur selbst. Die Standard-Regel „Deal bei Qualifizierung erstellen“ hatte zwei Zwecke in sich, die unterschiedliche Arbeit leisteten: den Forecast vor Rauschen zu schützen und den Deal-Record für committed Arbeit zu reservieren. Die Pre-pipeline-Stage erhält den ersten Zweck durch Filterung intakt und editiert den zweiten, indem sie sagt, dass der Deal-Record uncommittete Arbeit tragen kann, solange sie segregiert ist. Der Forecast bleibt sauber. Die fünfzig-SQL-Schublade hört auf zu existieren.
Drei Guardrails
Die Pre-pipeline-Stage funktioniert nur, wenn drei Filter ab Tag eins nicht verhandelbar sind. Wenn einer davon weich ist, kriecht der Bloat innerhalb eines Quartals zurück, und der Head of Sales rollt die Änderung zurück.
Erstens: Jeder Forecast-Report, jedes Dashboard-Widget und jede Pipeline-Coverage-Kalkulation muss die Pre-pipeline-Stage als Default-Bedingung herausfiltern. Kein Opt-in-Filter. Ein Default. Auditieren Sie jede gespeicherte View, jedes CRO-Dashboard, jedes Weekly-Forecast-Meeting-Deck. Wenn ein einziges Chart Pre-pipeline neben qualifizierter Pipeline als dieselbe Spalte zeigt, haben Sie die Disziplin verloren, die die Architektur rechtfertigt.
Zweitens: Die Pre-pipeline-Default-Win-Probability liegt bei null oder fünf Prozent, niemals höher. Manche Teams greifen zu zehn bis dreißig Prozent, weil es sich ehrlicher anfühlt. Widerstehen Sie dem. Der Punkt ist, dass die Weighted-Pipeline-Zahl sich nicht bewegen darf, basierend auf dem, was in Pre-pipeline steckt. Null ist am saubersten, fünf ist akzeptabel, alles darüber lädt Pre-pipeline-Deals dazu ein, in Revenue-Projektionen aufzutauchen, sobald jemand einen Filter ändert.
Drittens: Pre-pipeline-Deals werden über eine harte 90-Tage-No-Advance-Regel automatisch archiviert. Ein HubSpot-Workflow prüft Pre-pipeline-Deals jede Nacht. Wenn sich die Stage in neunzig Tagen nicht geändert hat, geht der Deal in Closed Lost mit dem Lost-Reason „no advance from pre-pipeline“. Keine Ausnahmen, keine Verlängerungen. Das Zombie-Deal-Problem, das Late-Creation-Pipelines ruiniert, ruiniert auch Pre-pipeline, wenn Sie es zulassen. Die 90-Tage-Regel ist das, was Pre-pipeline sichtbar und klein hält.
Ein Muster aus der Praxis
Wir haben kürzlich mit einem Series-B-B2B-SaaS-Team in DACH gearbeitet, das eine Mid-Market-Motion mit einer kleinen AE-Bench und ohne SDR-Schicht fuhr. Jedes Quartals-Pipeline-Review stieß an dieselbe Wand. Der Head of Sales ging die offizielle Pipeline durch: zwanzig oder dreißig Deals von Qualified bis Commit, und fragte dann das Team nach „den anderen, die wir noch nicht formal herübergezogen haben“. Die Antwort war immer eine Variante von „Ich warte, bis ich die Budget-Bestätigung habe“ oder „Ich will sicherstellen, dass sie Discovery sauber passen, bevor ich einen Deal eröffne“. Die AEs lagen bei beiden Punkten nicht falsch. Sie wendeten die Late-Creation-Regel wie geschrieben an. Das Ergebnis war, dass etwa die Hälfte der tatsächlich laufenden Arbeit des Teams außerhalb des Systems lag. Die Pipeline-Coverage sah dünn aus. Das Capacity-Modell zum nächsten Quartal sagte, wir seien unterversorgt. Beide Lesarten waren falsch; das Team trug mehr Pipeline, als die Instanz auswies.
Wir fügten eine Pre-pipeline-Stage als neue erste Stage in der Deal-Pipeline hinzu, defaulteten sie auf null Prozent Win-Probability und schrieben jede Forecast-View so um, dass sie herausgefiltert wird. Der Meeting-Booked-Workflow war bereits über ihr Scheduling-Tool verdrahtet; wir erweiterten ihn so, dass er automatisch einen Pre-pipeline-Deal erstellt und ihn mit Contact und Company assoziiert. Innerhalb von zwei Wochen verdoppelte sich der für das Team sichtbare Deal-Count. Innerhalb von drei Wochen filterte der Head of Sales auf Non-Pre-pipeline und bestätigte, dass die Forecast-Zahl sich nicht bewegt hatte: was der Test war, den wir bestehen wollten. Zwei Monate später hatte sich das Pipeline-Review-Meeting strukturell neu sortiert: Die erste Hälfte lief die offizielle Pipeline wie zuvor, die zweite Hälfte lief eine sortierte Pre-pipeline-Liste mit einer Frage pro Deal, was ist der nächste Move, um diesen aus Pre-pipeline herauszubekommen. Die fünfzig-SQL-Schublade hörte auf zu existieren. Das Capacity-Gespräch zum nächsten Quartal verschob sich von spekulativ zu spezifisch.
Wie Sie die Pre-pipeline-Stage in HubSpot verdrahten
- Fügen Sie eine neue erste Stage zu Ihrer primären Deal-Pipeline hinzu. Nennen Sie sie „pre-pipeline“ oder „engaged“: das Label zählt weniger als die Filterungs-Disziplin, die danach kommt. Setzen Sie die Default-Win-Probability auf null Prozent. Behalten Sie den Stage-Typ als offene Stage, nicht geschlossen.
- Bauen Sie den Meeting-Booked-Workflow. Trigger: Ein Meeting wird auf dem Kalender eines Sales-Reps über Ihr Scheduling-Tool gebucht (HubSpots natives Meetings-Tool oder welcher Scheduler auch verdrahtet ist). Enrollment-Kriterium: Der Meeting-Typ ist ein Sales-Gespräch, kein Customer-Touchpoint. Actions, Erstellen Sie einen Deal in der Pre-pipeline-Stage, assoziieren Sie ihn mit dem Contact und der primären Company, setzen Sie den Deal-Owner auf den Meeting-Host, setzen Sie den Deal-Namen auf einen Template-String mit Contact-Name und Meeting-Datum.
- Auditieren Sie jeden Forecast-Report, jedes Dashboard-Widget und jede Pipeline-Coverage-Kalkulation in der Instanz. Fügen Sie einen Filter zu jedem hinzu: deal stage ist nicht gleich Pre-pipeline. Default-Views, Default-Dashboards, Weekly-Forecast-Meeting-Decks, CRO-Summary-Widgets. Alle. Wenn Sie auch nur eines auslassen, beginnt die Disziplin zu lecken, die die Architektur rechtfertigt, an dem Tag, an dem jemand ein Chart in einem Board-Meeting zeigt.
- Bauen Sie einen separaten Pre-pipeline-Review-Report. Sortieren Sie nach letztem Engagement, dann nach ICP-Fit-Score. Das ist das Artefakt, mit dem AEs und ihre Manager in der zweiten Hälfte der Pipeline-Review-Meetings arbeiten. Andere Frage pro Zeile: nicht „ist das auf Kurs zu Closen“, sondern „was ist der nächste Move, um diesen aus Pre-pipeline herauszubekommen“.
- Definieren Sie das Exit-Kriterium. Das Minimum, das wir verwenden, ist eine SPICED-validierte Discovery: Situation, Pain und Impact schriftlich auf dem Deal-Record oder einer verlinkten Discovery-Note bestätigt. Sobald diese drei bestätigt sind, avanciert der Deal in Ihre erste qualifizierte Stage (nennen Sie sie „qualified“, „discovery complete“ oder wie Ihre zweite Stage in Ihrer Instanz heißt). Das Exit-Kriterium ist der Unterschied zwischen einer sauberen Pre-pipeline-Stage und einer langsamen Ausdehnung des Bloat-Problems, das Sie lösen wollten.
- Bauen Sie den Auto-Archive-Workflow. Trigger: ein täglicher geplanter Workflow. Filter: deal stage ist gleich Pre-pipeline UND deal stage last-changed-Datum liegt mehr als neunzig Tage zurück. Action, Verschieben Sie den Deal in Closed Lost, setzen Sie den Lost-Reason auf „no advance from pre-pipeline“, benachrichtigen Sie den Deal-Owner. Neunzig Tage ist die richtige Zahl für die meisten Mid-Market-B2B-SaaS-Motions. Für Enterprise-Motions mit jährlichen Budget-Zyklen sind 120 Tage vertretbar. Nicht höher.
- Restrukturieren Sie das Pipeline-Review-Meeting. Erste Hälfte: offizielle Pipeline. Zweite Hälfte: Pre-pipeline. Andere Frage. Anderer Takt. Andere Verantwortliche für das Gespräch, falls vorhanden. Die strukturelle Trennung im Meeting ist das, was dem Team lehrt, dass die architektonische Trennung im System real ist und kein eigenwilliger Filter.
Wo Checkpoint ins Spiel kommt
Die meisten unserer HubSpot-Implementierungs-Engagements, die Deal-Stage-Architektur berühren, liefern am Ende eine Version der Pre-pipeline-Stage aus. Es ist keine HubSpot-Best-Practice, die offizielle Empfehlung defaultet immer noch auf die Late-Creation-Regel, und es ist keine Einzeiler-Setting-Änderung. Es ist eine architektonische Entscheidung mit drei Guardrails, die respektiert werden müssen. Der Payoff ist das, was beim nächsten Pipeline-Review auftaucht. Die fünfzig heißen SQLs in der Schublade werden zu zwanzig Pre-pipeline-Deals, die Sie sehen, besprechen und priorisieren können, während die Forecast-Zahl genauso präzise bleibt wie zuvor. Wenn Ihre Revenue-Operations-Instanz eine stille Schublade voller SQLs hat, gegen die niemand forecastet und die niemand findet, ist die Pre-pipeline-Stage die kleinste architektonische Änderung, die das Visibility-Problem behebt, ohne den Forecast zu brechen.
Quellen
- Lemkin, Jason. „The 2026 Sales Reckoning: Why Your Traditional Sales Team Is About To Look Very Different.“ SaaStr, Januar 2026. saastr.com
- Lemkin, Jason. „Dear SaaStr: At What Point Should a Lead Convert to an Opportunity?“ SaaStr. saastr.com