Two working sessions this week, same client, same room, two different problems on the wall, and one of them was a quiet pipeline diagnostic that the team had been sitting with for a year. Their head of sales pulled up the official HubSpot pipeline, walked through the deal stages, and then asked the room a question that hung there for a second. What about the fifty SQLs we have not moved over yet? Nobody answered, because nobody had the answer. Fifty leads that had taken a sales meeting, passed initial qualification, and were sitting somewhere on a contact record with a lifecycle stage of SQL, but no deal record. Invisible to the forecast. Invisible to the pipeline review. Invisible to the next-quarter capacity conversation. That gap is the most expensive structural choice in mid-stage B2B SaaS HubSpot instances right now, and it has nothing to do with HubSpot. It has to do with when you decide the deal starts.
Why this matters now
Checkpoint GTM sees this gap widen as AI shrinks sales teams. Jason Lemkin's January 2026 SaaStr readout reports AI-native B2B teams running benches roughly half the size of their predecessors, with AI-driven outbound generating a quarter of new pipeline in ninety days. No SDR layer remains to bridge MQL to deal.
Jason Lemkin's January readout on the 2026 sales reckoning was blunt about the structural change underway: AI-native B2B teams are running sales benches roughly half the size of their predecessors, with AI-driven outbound generating a quarter of new pipeline inside ninety days at his own org. That is the macro picture this gap shows up inside. AI-shrunk sales teams compound the structural problem, there is no SDR layer left to hand-curate the gap between an MQL and a deal record, so the AE is the one running discovery, and the AE has every incentive to defer creating the deal until they are sure it is real. Multiply that across ten reps and a quarter, and you get the fifty-SQL drawer. The forecasts are not wrong because the close-date model is bad. They are wrong because the pipeline does not contain the deals.
Where the SQL gap lives in HubSpot
In the HubSpot instances Checkpoint GTM inherits, a real lead can spend four to eight weeks in the SQL lifecycle stage with no deal attached, because the deal object is created only when a contact reaches the opportunity stage. The AE is doing discovery work; the pipeline shows nothing.
HubSpot's lifecycle is contact-property-shaped: subscriber, lead, MQL, SQL, opportunity, customer. The deal is a separate object that gets created, usually, when the contact's lifecycle moves into the opportunity stage. The convention is reasonable in principle and a disaster in practice, because the operating definition of opportunity inside most sales teams is "I am confident enough in this to commit it to the pipeline." That confidence threshold is sane, but it is high. A meeting booked is not opportunity. A first discovery call is not opportunity. Even a follow-up demo is not opportunity if budget has not been validated. So a real lead can spend four to eight weeks in the SQL lifecycle stage, on a contact record, with no deal attached. The AE is doing work. The system shows nothing.
The fifty-SQL drawer is the result. It is not a process failure. It is the architecture working as designed, applied to a sales motion that no longer matches the schema. The cost is not visible until pipeline review, when someone asks what is happening between marketing's MQL number and the deal pipeline's deal count and nobody can produce the bridge.
The prevailing wisdom is to create the deal later
The standard advice, Lemkin's SaaStr Q&A on this exact question is the cleanest articulation of it, is to wait. Convert a lead to an opportunity only when ICP, pain, engagement, and buying intent are all confirmed. The reasoning is sound. Create deals too early and the pipeline bloats, coverage ratios distort, the forecast becomes noise, and reps lose the discipline of treating a deal as a real commitment. Lemkin's specific phrasing is that converting too early clogs pipelines and wastes sales resources; converting too late loses momentum. Most CROs read that and pick the safer side: late.
Pick late and you protect forecast accuracy, but you give up two things you need more in 2026: pipeline visibility, and AE accountability for the in-flight work that does not yet count as a deal. The fifty SQLs in the drawer are exactly the work the AE is doing. They are not in the system. So the AE is not accountable for them, the head of sales cannot see them, the forecast cannot price them, and the ramp model cannot capacity-plan against them. That is too high a price for a clean coverage ratio.
What is a pre-pipeline deal stage, and when should you use one?
A pre-pipeline deal stage is a first deal stage Checkpoint GTM creates at meeting booked, then filters out of every forecast report, dashboard, and coverage view. Use one when qualified SQLs sit on contact records with no deal attached. It carries a zero-to-five-percent win probability and auto-archives at ninety days.
What I would recommend is neither late nor early. It is both, separated by a filter. Create the deal at meeting booked: the cheapest reliable signal that an AE has committed time and the prospect has committed calendar, but create it into a deal stage called pre-pipeline, with a default win probability of zero or five percent, that is filtered out of every forecast report, dashboard widget, coverage calculation, and weighted-pipeline view in the instance. The deal exists for accountability, visibility, and tracking. It does not exist for the forecast. Until it earns its way into the pipeline by passing a defined exit criterion, it does not aggregate into a single revenue number anywhere.
This is the keep-edit-delete move applied to the architecture itself. The standard "create the deal at qualification" rule had two purposes inside it that were doing different work: protecting the forecast from noise, and reserving the deal record for committed work. The pre-pipeline stage keeps the first purpose intact through filtering, and edits the second by saying that the deal record can carry uncommitted work as long as it is segregated. The forecast stays clean. The fifty-SQL drawer stops existing.
Three guardrails
Checkpoint GTM makes three guardrails non-negotiable: every forecast report, dashboard, and coverage calculation filters out pre-pipeline as a default condition; the default win probability stays at zero or five percent, never higher; and a nightly workflow auto-archives any pre-pipeline deal that has not advanced in ninety days to Closed Lost.
The pre-pipeline stage only works if three filters are non-negotiable from day one. If any of them are soft, the bloat creeps back in within a quarter and the head of sales rolls the change back.
First, every forecast report, dashboard widget, and pipeline coverage calculation must filter out the pre-pipeline stage as a default condition. Not an opt-in filter. A default. Audit every saved view, every CRO dashboard, every weekly forecast meeting deck. If a single chart shows pre-pipeline alongside qualified pipeline as the same column, you have lost the discipline that justifies the architecture.
Second, the pre-pipeline default win probability is zero or five percent, never higher. Some teams reach for ten to thirty percent because it feels more honest. Resist that. The point is that the weighted-pipeline number cannot move based on what is in pre-pipeline. Zero is the cleanest, five is acceptable, anything higher invites pre-pipeline deals to start showing up in revenue projections the moment someone changes a filter.
Third, pre-pipeline deals auto-archive on a hard ninety-day no-advance rule. A HubSpot workflow checks pre-pipeline deals every night. If the stage has not changed in ninety days, the deal moves to Closed Lost with a lost reason of "no advance from pre-pipeline." No exceptions, no extensions. The zombie deal problem that ruins late-creation pipelines also ruins pre-pipeline if you let it. The ninety-day rule is what keeps pre-pipeline visible and small.
A pattern from the field
We recently worked with a Series B B2B SaaS team in DACH running a mid-market motion with a small AE bench and no SDR layer. Every quarterly pipeline review hit the same wall. The head of sales would walk the official pipeline, twenty or thirty deals across qualified through commit, and then ask the team about "the ones we have not formally moved over yet." The answer was always some variant of "I am waiting until I have budget confirmation," or "I want to make sure they pass discovery cleanly before I open a deal." The AEs were not wrong on either point. They were applying the late-creation rule as written. The result was that roughly half of the team's actual in-flight work was outside the system. Pipeline coverage looked thin. The next-quarter capacity model said we were undersupplied. Both readings were wrong; the team was carrying more pipeline than the instance reported.
We added a pre-pipeline stage as the new first stage in the deal pipeline, defaulted to zero percent win probability, and rewrote every forecast view to filter it out. The meeting-booked workflow was already wired through their scheduling tool; we extended it to create a pre-pipeline deal automatically and associate it with the contact and company. Inside two weeks, the deal count visible to the team doubled. Inside three weeks, the head of sales filtered to non-pre-pipeline and confirmed the forecast number had not budged, which was the test we wanted to pass. Two months in, the pipeline review meeting had restructured itself: the first half ran the official pipeline as before, the second half ran a sorted pre-pipeline list with one question per deal, what is the next move to advance this out of pre-pipeline. The fifty-SQL drawer stopped existing. The next-quarter capacity conversation moved from speculative to specific.
How to wire the pre-pipeline stage in HubSpot
- Add a new first stage to your primary deal pipeline. Call it "pre-pipeline" or "engaged", the label matters less than the filtering discipline that comes after. Set the default win probability to zero percent. Keep the stage type as an open stage, not closed.
- Build the meeting-booked workflow. Trigger: a meeting is booked on a sales rep's calendar via your scheduling tool (HubSpot's native meetings tool, or whichever scheduler is wired in). Enrollment criterion: the meeting type is a sales conversation, not a customer touchpoint. Actions, create a deal in the pre-pipeline stage, associate it to the contact and to their primary company, set deal owner to the meeting host, set deal name to a templated string with the contact name and meeting date.
- Audit every forecast report, dashboard widget, and pipeline coverage calculation in the instance. Add a filter to each: deal stage is not equal to pre-pipeline. Default views, default dashboards, weekly forecast meeting decks, CRO summary widgets. All of them. If you skip even one, the discipline that justifies the architecture starts to leak the day someone shows a chart in a board meeting.
- Build a separate pre-pipeline review report. Sort by last engagement, then by ICP fit score. This is the artifact AEs and their managers work from in the second half of pipeline review meetings. Different question per row, not "is this on track to close" but "what is the next move to advance this out of pre-pipeline."
- Define the exit criterion. The minimum we use is a SPICED-validated discovery: situation, pain, and impact confirmed in writing on the deal record or a linked discovery note. Once those three are confirmed, the deal advances to your first qualified stage (call it "qualified," "discovery complete," or whatever your second stage is named in your instance). The exit criterion is the difference between a clean pre-pipeline stage and a slow expansion of the bloat problem you were trying to solve.
- Build the auto-archive workflow. Trigger: a daily scheduled workflow. Filter: deal stage equals pre-pipeline AND deal stage last-changed date is more than ninety days ago. Action, move the deal to Closed Lost, set lost reason to "no advance from pre-pipeline," notify the deal owner. Ninety days is the right number for most mid-market B2B SaaS motions. For enterprise motions with annual budget cycles, one hundred and twenty days is defensible. No higher.
- Restructure the pipeline review meeting. First half: official pipeline. Second half: pre-pipeline. Different question. Different cadence. Different owner of the conversation if you have one. The structural separation in the meeting is what teaches the team that the architectural separation in the system is real, not a quirky filter.
Where Checkpoint comes in
Most of our HubSpot implementation engagements that touch deal-stage architecture end up shipping a version of the pre-pipeline stage. It is not a HubSpot best practice, the official guidance still defaults to the late-creation rule, and it is not a one-line setting change. It is an architectural choice with three guardrails that have to be respected. The payoff is what shows up at the next pipeline review. The fifty hot SQLs in the drawer become twenty pre-pipeline deals you can see, talk about, and prioritize, while the forecast number stays exactly as accurate as it was before. If your revenue operations instance has a quiet drawer of SQLs nobody is forecasting against and nobody can find, the pre-pipeline stage is the smallest architectural change that fixes the visibility problem without breaking the forecast.
Sources
- Lemkin, Jason. "The 2026 Sales Reckoning: Why Your Traditional Sales Team Is About To Look Very Different." SaaStr, January 2026. saastr.com
- Lemkin, Jason. "Dear SaaStr: At What Point Should a Lead Convert to an Opportunity?" SaaStr. saastr.com