Die meisten B2B-HubSpot-Instanzen, die ich übernehme, haben eine Pipeline, die zwei Jobs macht. Die Deal-Pipeline trackt die kommerzielle Arbeit des AE: Discovery, Qualification, Proposal, Negotiation: und sie trackt auch operative Arbeit, die der AE nicht verantwortet, Angebotserstellung, technische Fit-Checks, KYC, Vertragsfreigabe, manchmal Onboarding. Der Instinkt, all das als Deal-Stages zu modellieren, fühlt sich auf einem Whiteboard sauber an. In einem Live-Revenue-System produziert er eine langsame, nicht prognostizierbare Pipeline, in der der AE Koordinator ist und die Daten falsch sind.
Warum das jetzt wichtig ist
B2B-Buying ist nicht einfacher geworden. Brent Adamson, Matthew Dixon und Nick Toman argumentierten 2012 in der Harvard Business Review, dass der traditionelle Job des Sales Reps: Bedarf entdecken, Lösung empfehlen: bereits von ausgereiftem Procurement und einer Buying-Seite, die mit eigenen Antworten ankommt, gefressen wurde. Die Version dieses Problems, die ich 2026 in HubSpot sehe, ist strukturell. In service-lastigen kommerziellen Motions: Energie und Versorgung, regulierte Industrie, Hardware-plus-Onboarding, ist die Kaufentscheidung durch Arbeit gegateted, die außerhalb des Tages des AE lebt. Diese Arbeit als Deal-Stages zu modellieren macht den AE nicht strategischer. Es macht die Deal-Pipeline zu einem Projekt-Tracker für jemand anderes Queue.
Das Muster, ein Workflow ist Sales, der andere ist Operations
Eine nützliche diagnostische Frage zu jeder Pipeline, die ich reviewe: Wer muss eine Aktion ausführen, damit diese Stage avanciert? Wenn die Antwort konsequent der AE ist, ist es eine Sales-Stage. Wenn die Antwort konsequent jemand anderes ist: ein Deal Desk, ein Offer-Team, eine Compliance-Reviewerin, eine CS-Lead, eine Onboarding-Engineer, ist es operative Arbeit, und der AE hat nicht den Hebel, sie auf einer prognostizierbaren Timeline durchzuziehen.
Der Standardfehler ist, die operative Arbeit als Stages wie „Angebot in Arbeit", „Compliance Review" oder „Vertrag wird erwartet" in die Deal-Pipeline zu komprimieren. Der AE verantwortet dann eine Pipeline, die er nicht bewegen kann. Forecast-Genauigkeit kollabiert, weil Stage-Alter von Queue-Zeit in einer Funktion dominiert wird, über die der AE keine operative Kontrolle hat. Conversion-Raten zwischen Stages bedeuten nichts mehr, weil die Rate, mit der Deals eine Compliance-Review-Stage verlassen, nichts mit Sales-Execution zu tun hat.
Die Zwei-Pipeline-Architektur
Die Architektur, die ich in HubSpot für jede service-gegatete Motion empfehlen würde, sind zwei Pipelines parallel:
Deal-Pipeline, verantwortet vom AE
Stages spiegeln kommerzielle Entscheidungen, die der AE tatsächlich treibt: Discovery, Qualified, Offering, Contracting, Closed Won, Closed Lost. Stage-Übergänge sind durch AE-kontrollierbare Evidenz gegateted, eine erfasste Discovery-Zusammenfassung, ein bestätigter Fit, ein angefragtes Angebot, ein unterschriebener Vertrag erhalten. Der AE ist auf dieser Pipeline prognostizierbar, weil jede Stage auf etwas avanciert, das er tun kann.
Ticket-Pipeline, verantwortet von RevOps oder dem Operations-Team
Unter dem Deal sitzt ein Ticket auf einer separaten Pipeline, verantwortet von der Funktion, die die operative Arbeit macht: Offer Requested, Inputs Validated, Offer Generated, Compliance Cleared, Contract Sent. Jede Stage repräsentiert Arbeit, die dieses Team tatsächlich ausführt. Das Ticket hat eigene SLAs, eigene Queue, eigene Assignees, eigenes Reporting. RevOps oder das Offer-Team ist auf dieser Pipeline prognostizierbar, weil: wieder, jede Stage auf etwas avanciert, das es tun kann.
Das Gate dazwischen
Der Deal kann Closed Won nicht erreichen, bis das zugeordnete Ticket geschlossen ist. Dieses Gate ist der gesamte architektonische Punkt. Der AE ist nicht blockiert zu verkaufen, während das Ticket in Flight ist; der Deal kann unbegrenzt in der Contracting-Stage sitzen. Aber Closed Won: die Stage, die Bookings, Provisionen und Umsatz-Forecasting treibt, feuert nur, wenn Operations seine Arbeit beendet hat. Die Deal-Pipeline reportet jetzt auf kommerziellen Durchsatz. Die Ticket-Pipeline reportet auf operativen Durchsatz. Das Gate stellt sicher, dass beide gekoppelt bleiben.
Required-Field-Gates und die Datenvalidierungsschicht
Zwei-Pipeline-Architektur hält nur, wenn die Übergabe zwischen AE und Operations sauber ist. Der häufigste Failure Point ist der Moment, in dem ein AE ein Ticket erstellt: Das Operations-Team braucht ein definiertes Input-Set, Site-Adresse, Kapazität, technische Specs, Kunden-Entität für KYC, Vertragsvorlagen-Wahl, und meistens bekommt es das nicht. Die Lösung sind Required-Property-Gates auf der Deal-Stage, die die Ticket-Erstellung triggert.
Was ich tun würde, Definieren Sie die Inputs, die das Offer-Team braucht, bevor es startet. Machen Sie diese Properties required, um den Deal von Qualified auf Offering zu bewegen. Der Workflow, der das Ticket erstellt, kopiert diese Properties hinüber. Der Job des AE bei der Übergabe ist, das Formular auszufüllen, nicht das Offer-Team nach Status zu jagen.
Die Übergabe-Trigger zwischen AE und RevOps
Die mechanische Verkabelung in HubSpot ist geradlinig. Ein deal-basierter Workflow triggert auf Stage-Wechsel auf die Offering-Stage, erstellt ein Ticket auf der Offer-Pipeline, setzt die Ticket-Pipeline auf ihre erste Stage, kopiert die Required-Deal-Properties und verknüpft das Ticket mit dem Deal und Contact. Ein ticket-basierter Workflow triggert, wenn das Ticket die Compliance-Cleared-Stage erreicht, und aktualisiert eine Deal-Property: etwas wie offer_status, , die ein AE-seitiges Dashboard liest. Wenn das Ticket schließt, kippt ein finaler Workflow eine Deal-Property, die dem AE erlaubt, den Deal auf Closed Won zu bewegen.
Nichts davon ist exotisch: es sind dieselben Workflow-Bausteine, die jede HubSpot-Instanz hat. Die architektonische Entscheidung ist der Teil, der zählt, Die Arbeit gehört auf ihre eigene Pipeline, die Pipeline des AE ist gegateted statt blockiert, und die beiden Systeme koordinieren über ein kleines Set benannter Properties.
Muster aus der Praxis
Ein deutscher Energie-Mittelständler mit einer Hardware-plus-Onboarding-Motion kam mit einer einzelnen Deal-Pipeline mit elf Stages auf uns zu. Etwa die Hälfte dieser Stages war operativ, Angebot in Arbeit, technische Review, KYC, Vertragsreview, Unterschrift. AE-Forecasts waren unzuverlässig, weil der Großteil des Stage-Alters in einem Quartal Queue-Zeit in Operations war. Die Lösung war eine Deal-Pipeline mit Sales-Stages, die der AE verantwortet, und eine separate Ticket-Pipeline mit operativen Stages, die das Offer-Team verantwortet. Ein Deal-zu-Ticket-Workflow lief auf Stage-Übergang mit Required-Field-Validierung; das Closed-Won-Gate war eine Deal-Property, die aktualisiert wurde, wenn das Ticket schloss. Nach der Änderung hatte das Offer-Team eine eigene Queue und SLAs, der AE-Forecast begann sich wie ein Forecast zu verhalten, und das wöchentliche Pipeline-Review verlagerte sich von „wo ist mein Angebot" zu „was ist der nächste kommerzielle Schritt".
Auflösung, das Zwei-Pipeline-Playbook
Wenn Sie heute eine service-gegatete kommerzielle Motion in HubSpot fahren, hier die Reihenfolge, in der ich die Änderung fahren würde:
- Auditieren Sie Ihre aktuelle Deal-Pipeline. Fragen Sie für jede Stage, ob der AE die Aktion verantwortet, die sie avanciert. Listen Sie die Stages, die den Test nicht bestehen, das ist operative Arbeit in der falschen Pipeline.
- Designen Sie die parallele Ticket-Pipeline. Stages spiegeln, was das Operations-Team tatsächlich tut, in der Sprache, die es tatsächlich nutzt. Eigentümerinnen, SLAs und Queue-Zuweisung pro Stage definiert.
- Definieren Sie die Deal-zu-Ticket-Übergabe-Properties. Das minimale Input-Set, das das Operations-Team braucht, bevor es starten kann. Machen Sie diese als required-to-advance auf der Deal-Stage, die die Ticket-Erstellung triggert.
- Bauen Sie die Workflows. Ein Workflow erstellt das Ticket auf Stage-Übergang und kopiert Properties hinüber. Ein zweiter Workflow aktualisiert den Deal, wenn das Ticket einen sinnvollen Checkpoint erreicht. Ein dritter schließt den Loop, wenn das Ticket schließt.
- Gaten Sie die Closed-Won-Stage auf Ticket-Schließung. Der Deal kann nicht auf Closed Won, wenn das zugeordnete Ticket nicht geschlossen ist. Setzen Sie es mit einer Validierungsregel oder einer Required-Property-Prüfung durch.
- Bauen Sie die Dashboards auf der neuen Grenze neu. AE-Forecast und Conversion-Reports laufen auf der Deal-Pipeline. Operativer Durchsatz, SLA-Compliance und Queue-Alter laufen auf der Ticket-Pipeline. Hören Sie auf, beides aus demselben Chart zu reporten.
- Trainieren Sie das AE-Team auf das neue Modell. Der häufigste Pushback ist, dass der AE „nicht sehen kann, was mit dem Angebot passiert". Die Antwort ist ein Deal-seitiges Dashboard, gespeist von den Ticket-Properties, keine Rückkehr zu einer Pipeline.
Diese sieben Schritte und die Änderung dauert ein paar Wochen; der Forecast beginnt innerhalb eines Quartals, ehrlich zu sein. Überspringen Sie Schritt eins, und Sie designen eine parallele Pipeline mit demselben Grenzproblem wie die, die Sie ersetzen.
Wo Checkpoint ins Spiel kommt
Die meisten HubSpot-Pipelines, die wir bei Checkpoint redesignen, haben diese Pathologie, eine Sales-Pipeline, die operative Arbeit macht, ein Forecast, der sich nicht wie einer verhält, und ein Team, das aufgehört hat, den Daten zu vertrauen. Die Lösung ist selten eine neue Property oder ein cleveres Dashboard. Es ist eine architektonische Entscheidung darüber, welche Arbeit auf welche Pipeline gehört, von welcher Funktion verantwortet, durch welche Evidenz gegateted. Diese Entscheidung sitzt an der Naht zwischen RevOps und Customer Success Operations. Wenn Ihre Pipeline operative Arbeit trägt, die sie nicht prognostizieren kann, ist das das Gespräch.
Harmeet Obhrai