Most B2B HubSpot instances I inherit have one pipeline doing two jobs. The deal pipeline tracks the AE's commercial work: discovery, qualification, proposal, negotiation: and it also tracks operational work the AE does not own, offer generation, technical fit checks, KYC, contract approval, sometimes onboarding. The instinct to model all of that as deal stages feels tidy on a whiteboard. In a live revenue system it produces a slow, unforecastable pipeline where the AE is a coordinator and the data is wrong.
Why this matters now
B2B buying has not gotten simpler. Brent Adamson, Matthew Dixon, and Nick Toman argued in Harvard Business Review in 2012 that the sales rep's traditional job: discover needs, recommend a solution, was already being eaten by sophisticated procurement and a buying side that arrives with its own answers. The version of that problem I see in HubSpot in 2026 is structural. In service-heavy commercial motions, energy and utilities, regulated industrials, hardware-plus-onboarding, the buying decision is gated by work that lives outside the AE's day. Modeling that work as deal stages does not make the AE more strategic. It makes the deal pipeline a project tracker for someone else's queue.
The pattern, one workflow is sales, the other is operations
A useful diagnostic question on every pipeline I review: who has to take an action for this stage to advance? If the answer is consistently the AE, it is a sales stage. If the answer is consistently somebody else: a deal desk, an offer team, a compliance reviewer, a CS lead, an onboarding engineer, it is operational work, and the AE does not have the leverage to pull it through on a forecastable timeline.
The standard mistake is to compress the operational work into the deal pipeline as stages like "offer in progress," "compliance review," or "awaiting contract." The AE then owns a pipeline they cannot move. Forecast accuracy collapses because stage age is dominated by queue time in a function the AE has no operational control over. Conversion rates between stages stop meaning anything because the rate at which deals leave a compliance-review stage has nothing to do with sales execution.
The two-pipeline architecture
The architecture I would recommend in HubSpot for any service-gated motion is two pipelines running in parallel:
Deal pipeline, owned by the AE
Stages reflect commercial decisions the AE actually drives: discovery, qualified, offering, contracting, closed won, closed lost. Stage transitions are gated by AE-controllable evidence, a discovery summary captured, a fit confirmed, an offer requested, a signed contract received. The AE is forecastable on this pipeline because every stage advances on something they can do.
Ticket pipeline, owned by RevOps or the operations team
Underneath the deal sits a ticket on a separate pipeline, owned by the function that does the operational work, offer requested, inputs validated, offer generated, compliance cleared, contract sent. Each stage represents work that team actually performs. The ticket has its own SLAs, its own queue, its own assignees, its own reporting. RevOps or the offer team is forecastable on this pipeline because, again, every stage advances on something they can do.
The gate between them
The deal cannot reach Closed Won until the associated ticket is closed. That gate is the entire architectural point. The AE is not blocked from selling while the ticket is in flight; the deal can sit in the contracting stage indefinitely. But Closed Won, the stage that drives bookings, commissions, and revenue forecasting, only fires when operations has finished its work. The deal pipeline now reports on commercial throughput. The ticket pipeline reports on operational throughput. The gate ensures the two stay coupled.
Required-field gates and the data validation layer
Two-pipeline architecture only holds up if the hand-off between AE and operations is clean. The most common point of failure is the moment an AE creates a ticket: the operations team needs a defined input set, site address, capacity, technical specs, customer entity for KYC, contract template selection, and most of the time they do not get it. The fix is required-property gates on the deal stage that triggers ticket creation.
What I would do, define the inputs the offer team needs before they start. Make those properties required to move the deal from qualified into offering. The workflow that creates the ticket copies those properties across. The AE's job at the hand-off is to fill out the form, not to chase the offer team for status.
The hand-off triggers between AE and RevOps
The mechanical wiring in HubSpot is straightforward. A deal-based workflow triggers on stage change into the offering stage, creates a ticket on the offer pipeline, sets the ticket pipeline to its first stage, copies the required deal properties, and associates the ticket with the deal and contact. A ticket-based workflow triggers when the ticket reaches the compliance-cleared stage and updates a deal property, something like offer_status, that an AE-facing dashboard reads. When the ticket closes, a final workflow flips a deal property that allows the AE to move the deal into Closed Won.
None of this is exotic, it is the same workflow building blocks every HubSpot instance has. The architectural decision is the part that matters, the work belongs on its own pipeline, the AE's pipeline is gated rather than blocked, and the two systems coordinate through a small set of named properties.
Pattern from the field
A German energy SME with a hardware-plus-onboarding motion came to us with a single deal pipeline carrying eleven stages. About half of those stages were operational, offer in progress, technical review, KYC, contract review, signature. AE forecasts were unreliable because most of the stage age in any given quarter was queue time in operations. The fix was a deal pipeline with sales stages owned by the AE and a separate ticket pipeline with operational stages owned by the offer team. A deal-to-ticket workflow ran on stage transition with required-field validation; the Closed Won gate was a deal property updated when the ticket closed. After the change, the offer team had its own queue and SLAs, the AE forecast started behaving like a forecast, and the weekly pipeline review shifted from "where is my offer" to "what is the next commercial step."
Resolution, the two-pipeline playbook
If you are running a service-gated commercial motion in HubSpot today, here is the order I would run the change in:
- Audit your current deal pipeline. For every stage, ask whether the AE owns the action that advances it. List the stages that fail the test, those are operational work in the wrong pipeline.
- Design the parallel ticket pipeline. Stages reflect what the operations team actually does, in the language they actually use. Owners, SLAs, and queue assignment are defined per stage.
- Define the deal-to-ticket hand-off properties. The minimum input set the operations team needs before they can start. Make these required-to-advance on the deal stage that triggers ticket creation.
- Build the workflows. One workflow creates the ticket on stage transition and copies properties across. A second workflow updates the deal when the ticket reaches a meaningful checkpoint. A third closes the loop when the ticket closes.
- Gate the Closed Won stage on ticket closure. The deal cannot move to Closed Won unless the associated ticket is closed. Enforce it with a validation rule or a required-property check.
- Rebuild the dashboards on the new boundary. AE forecast and conversion reports run on the deal pipeline. Operational throughput, SLA compliance, and queue age run on the ticket pipeline. Stop reporting on both from the same chart.
- Train the AE team on the new model. The single most common pushback is that the AE "can't see what's happening with the offer." The answer is a deal-side dashboard fed by the ticket properties, not a return to one pipeline.
Do those seven things and the change takes a few weeks; the forecast starts being honest within a quarter. Skip step one and you will design a parallel pipeline with the same boundary problem as the one you are replacing.
Where Checkpoint comes in
Most HubSpot pipelines we redesign at Checkpoint have this pathology, a sales pipeline doing operational work, a forecast that does not behave like one, and a team that has stopped trusting the data. The fix is rarely a new property or a smarter dashboard. It is an architectural decision about what work belongs on which pipeline, owned by which function, gated by which evidence. That decision sits at the seam between RevOps and customer success operations. If your pipeline is carrying operational work it cannot forecast, that is the conversation to have.
Harmeet Obhrai