Deal-Level Forecasting: What a Stage-Free Sales Process Looks Like (and How to Build One)

It wasn’t my finest moment, but I once cost my whole team a bonus, because of one deal.

It was with one of the biggest HR tech companies you can think of, and it’d swing our team’s attainment for the first half of the year, if it landed in June. Taking us from 43% to 52% of our annual target. Which mattered more than usual because of how comp worked: everyone had a team-based bonus on top of their individual commission, paid twice a year, but only if the team was on target at the half. So my deal was everybody's deal, in a way.

I kept 2 - 3 named accounts to work at a time, even though I was building and leading the team. To help me figure out firsthand where to build out more process, adjust our positioning, etc. And it sat in my late stage looking great: commercials agreed, champion engaged, redlines moving forward, etc. Which is why I got… comfortable.

What I didn't have was the specifics on how their CFO signed off on commercials, meaning, who brought it to her, what she needed to see, and when she'd actually look at it. So when I found all that out in the last week of June, the deal actually closed in July.

The stage probably said it had an 80% chance of closing, but, the deal “evidence” said I'd never spoken to the person who signs. And the gap between those two facts cost every person on my team legit dollars.

Here’s me begging the keeper of commissions to just… ignore the reality of close dates, just this once. (I kept this screenshot as a reminder.)

That’s basically the big idea, and downside, of stage-based forecasting in one deal.

And this is a post about what’s going to replace it over time, after working alongside it for a while first: forecasting each deal, by itself, apart from sales stages, based on the buying behaviors that actually predict a decision.

We've spent the last year building exactly this inside Loop, so I'm going to show you the architecture, and what to consider to go build it yourself if you want to.

Four parts:

1. Why we forecast by stage in the first place (and why it was the right call, for a while)
2. The thought experiment: a stage-free sales process
3. What has to be true in your data layer and the model to build it
4. What changes “on Monday:” deal reviews, forecast calls, reporting, and pulling deals back into the quarter.

Part 1: Why did we ever forecast by stage?

Because we had to.

Follow me here: Say you're a VP of Sales in 2014 with 400 open opportunities across 30 reps, and you need a number for the board. You have a CRM with a stage field, a close date, and an amount, and that's about it. Meeting notes live in the rep's head, emails live in Outlook, and a “commit” and “best case” are captured during weekly meetings where you ask questions about late-stage deals.

You couldn’t score 400 deals individually, so you abstract the process with some operating rules:

1. Define stages with exit criteria (pain confirmed, champion identified, proposal delivered, etc.)
2. Look at historical conversion from each stage to closed-won
3. Apply that % as a discount to every deal sitting in the stage
4. Sum it up = your weighted pipeline forecast

This is a good abstraction, because stages functioned like a compression algorithm for the CRM era: they take the thing you can't observe (the buyer's internal decision process) and approximate it with the thing you can (which qualification boxes the rep checked).

But the assumption underneath it is where things break down: weighted pipeline forecasting assumes every deal in a stage is equally likely to close, and they aren't.

Not even close.

Two deals, same stage, same number?

Say you have two deals in Stage 4, both $120K, both closing this quarter:

• Deal A: four stakeholders in meetings, CFO attended the last one, a mutual action plan with dates the buyer edited themselves, and a champion emailing you on weekends.
• Deal B: one contact, no meeting in 19 days, a proposal sent mostly to get a reply, and a close date that's already been pushed once.

Your CRM says 70% and 70%. Your gut says 85% and 15%.

And the forecast call spends 20 minutes arguing about which stage Deal B "really" belongs in, because stage is the only lever anyone in the room has.

The industry knows this: Clari's benchmarking puts stage-weighted forecasting at 60 to 75% accuracy, with deal-level ML forecasting reaching 75 to 90%, and every forecasting vendor has published some version of "stage-based forecasting is flawed."

What almost nobody has published is the design for what replaces it. So that's parts 2 and 3.

(Side note: I wrote about the other half of this back in 2024, on why the 3X coverage rule should die. Coverage ratios = stage discounts wearing a different hat.)

Part 2: What if there were no stages?

Here's the thought experiment together:

If you deleted your stages and just left the deals, how would you forecast?

Well, you can't fall back on "it's in Stage 4," so you have to answer a different question for each deal: what has this specific buyer actually done, and what have buyers who did those things in the past, go on to do after?

The idea is that the reframe starts to get us toward a stage-free sales process, and it has four pieces:

1. Buying behaviors. Observable things the buyer did. The CFO attended a meeting, the champion edited the business case, three unique titles showed up on the last call, the timeline got confirmed in writing. (Buyer behaviors, not rep activities. Hold onto that distinction, it matters in part 3.)
2. Predictors. A behavior becomes a predictor when the data says it moves an outcome. "CFO_attended" is a predictor if deals where it happened close at a materially higher rate than deals where it didn't, and keep doing so as new deals close. Predictors get tested against the data continuously and re-ranked as it evolves.
3. Plays. The seller's move that produces the buyer behavior. You can't make a CFO attend, but you can send a one-page exec brief the week of the demo, which is the thing that reliably gets the CFO in the room.
4. Outcomes. Win rate, cycle time, and ACV. Three of them, because a predictor can matter a lot for one and not at all for another.

Chain them together and you get a map: plays → predictors → outcomes.

So the forecast for a single deal works like this:

• Look at which predictors are present and which are missing, then compare that to the target threshold that converts for deals like this one.
• The gap between "current" and "target" is the deal's risk, and the recommended next play is whichever one closes the biggest gap.
• The seller runs the play, the buyer behavior happens (or doesn't), the predictor updates, and the deal's probability moves with it.

Each deal gets forecasted based on itself: the number on Deal A is Deal A's number, and Deal B doesn't get to borrow it just because they share a stage.

"Isn't this just a lead score with extra steps?"

No, and the difference is worth a minute. A lead score is a static weighting someone configured once, where this is a model trained on your closed deals that re-ranks predictors every time it retrains, and it's tied to an action. Here's what that looks like for one play:

Three things to notice in that screen:

• One play moves two predictors, which is normal. The exec brief gets the CFO in the room and establishes economic buyer access, so plays are not one-to-one with predictors.
• The lift is estimated from closed deals, vs. raw correlation. Deals where the play ran vs. comparable deals where it didn't, and what happened after. (Correlation would just tell you "deals with CFOs attending win more," and every VP already knows that.)
• There's an example of the play done well, from a named rep, attached to the recommendation. So the rep isn't just told what to do, they're handed how someone on their team already did it.

That last one is the part I care about most, because back in my HR tech deal the missing predictor was economic buyer access and the play was an exec brief to the CFO. I knew that play. I've taught that play. But I didn't run it, because nothing in my process forced the question, and the stage said I was fine.

Which brings us to what to build.

Part 3: What has to be true to build this?

If you want to build a deal-level forecasting process yourself, to live alongside your stages (and plenty of RevOps and GTM engineering teams can), here's the sequence, where each step depends on the one before it.

1. Stages are a snapshot, and you need a time series

A stage field tells you where a deal is right now, and it has no memory. You can't ask "how many days after the demo did the CFO show up on winning deals vs. losing ones?" because the answer isn't stored anywhere.

So the first requirement is an ETL to provision a time-series data store:

Every meeting, every attendee, every email thread, every field change, with a timestamp and a deal ID. Deal-day granularity is enough. You're building what Datadog builds for infrastructure, just for revenue.

This is the foundation to a context layer that goes beyond a simple relational graph, and we've written it up twice, once on how we built ours and once on how to build one for GTM that actually predicts wins.

2. Raw events aren't predictors, predictors are derived

A calendar invite is data. "Any meeting with a CFO-titled attendee" is a feature. The translation step is where most of the work lives, and you'll want two sets:

• Defaults everyone needs: economic buyer access (attendees + role mapping), champion (call topics + email + contact roles), timeline confirmed (Gong + close-date stability), next steps (email follow-up + calendar bookings), pain validated, decision criteria, and competitive position.
• Custom predictors specific to your motion. If you sell into regulated industries, "regulated AND audit event in 90 days" might be one. If your buyer is finance, "CFO attended" might outrank everything else on the list.

The thing to notice here is that predictors are scored, and the scores change depending on what you score against. "Score against: win rate" gives you one ranking, switch it to cycle time and the list reorders.

Which brings us to...

3. Three labels, not one

Most deal scoring predicts win/loss and stops there.

But the questions a revenue leader actually asks are:

• Will it close? (win rate)
• When? (cycle time)
• For how much? (ACV)

A predictor like "multi-threaded ≥ 3 unique titles" might be a strong win-rate predictor and irrelevant to cycle time, and "timeline confirmed" is the reverse. You need all three labels, and the pull-in question in part 4 depends entirely on the second one.

One customer data point that surprised us: champions who make 3+ edits or comments on a business case draft win at 3X the rate of those who don't. We call it the Rule of 3, and it's a predictor nobody would have configured by hand. The data surfaced it.

4. The model (keep it boring)

I’ve previously written about models, and the relative strengths of each, so here I’ll just pull out the Top 3 to know and use for this use case:

• Regression to find which predictors move which outcomes and by how much. Start here, because it's interpretable, and interpretable = something a CRO will actually trust.
• Gradient-boosted trees (XGBoost is fine) for the per-deal probability, because the interactions matter. "CFO attended" means something different when there's also a confirmed timeline than when there isn't.
• Nearest-neighbor grouping to answer "what happened in deals like this one." This is what powers a predictor like similar_match in the screenshot above, and it's how you get a forecast for a deal with only three weeks of history.

Jon, my co-founder and our CTO, put it this way when I asked him what he'd tell a RevOps team building this from scratch:

"The model is the easy part. XGBoost on a clean feature table gets you 80% of the way in an afternoon. The hard part is the feature table: getting every buyer behavior onto one timeline per deal, with the outcome labels attached, and keeping it current when the CRM changes underneath you. Teams that skip the data work and jump to the model end up with a very confident score built on whatever happened to be in Salesforce that week."

If you want the deeper walk-through on model types, the crash course goes there.

"We don't have 18 months of clean CRM data."

Yes, because CRM compliance is.. not good. And if your feature table were built on CRM fields, that would be a problem.

But go back to point #1 above:

The predictors come from the event log, and calendar and email data already holds the source data, because nobody forgets to have a meeting.

So you don't need reps to have filled in "economic buyer identified" field for two years to have good CRM data: you just need to know who was on the invite. And most teams have that sitting in Google Workspace or M365 going back further than their CRM does.

So the cold-start problem is smaller than the vendors make it sound, and nearest-neighbor grouping covers the rest for young deals.

5. Plays are interventions, not correlations

Here's where most homegrown builds typically stop short:

They get a score, but they never get a recommended action, because they never modeled what a seller action does to a buyer behavior.

To estimate a play's lift, you log when the play was run (a Play record with a deal ID and a date), then compare predictor movement on deals where it ran vs. comparable deals where it didn't, over the following weeks. That's how you get to "+0.16 on cfo_attended." It's not causal in the academic sense, and it's a whole lot better than a correlation.

6. Your predictors will drift

A competitor enters, your ICP shifts, your pricing changes, and "competitive position" goes from a 0.62 to a 0.40. If your model doesn't retrain, your forecast is describing a market that no longer exists.

So set a retraining cadence (nightly is fine at most volumes) and watch for predictors whose scores are decaying. The way I think about it: your playbook = what you think you know, your model = what's actually true right now. When they diverge, the playbook is the one that's wrong.

Part 4: What changes “on Monday?”

So now you have a per-deal probability, a set of predictors with targets, and a recommended play for each deal. What do you actually do differently?

Everything below is written from the leader's seat, because that's where the time goes.

Can you skip the first 10 minutes of the deal review?

Right now, the first 10 minutes of every deal review is the rep catching the manager up. Who's involved, what happened last call, why the close date moved. It's story time, and it's where the HR tech deal hid from me for six weeks when I reviewed myself.

Replace it with a one-screen pre-read brief per deal, sent before the meeting, that shows nothing but evidence:

• Which predictors are present, with the event that triggered them ("CFO attended 9/3 pricing review")
• Which are missing vs. target ("Econ. buyer access: 0.58, target 0.68")
• What changed since last review, so predictor deltas up or down
• The recommended next play, and the example of it done well

No narrative field, and the rep doesn't write it. The system generates it from the event log.

Now the meeting starts at minute zero with "the CFO hasn't been in a meeting and we're 30 days from close," instead of arriving there at minute twelve after the rep explains how great the champion is.

Can you hand the rep a head start?

A deal review that ends with "great, go send the exec brief" is a status meeting. A deal review where the leader spends the last five minutes starting the play with the rep is coaching, and the difference is whether the play actually gets run.

So, concretely: the recommended play is "send an exec brief," and the pre-read already has the example done well from another rep on the team. You pull it up together and draft the first version for this specific CFO, using what's already in the event log (the pain from the discovery call, the ROI numbers from the demo, the one next step). The rep leaves the meeting with 70% of the play done, not a to-do.

One deal, one play, one head start per review.

What does the forecast call argue about?

Deltas, not stages. The forecast is now a rollup of individual probabilities, so the call changes to:

• Open with the number and the confidence band, not a stage-by-stage walk.
• Spend the time on deals where the model and the rep disagree by more than ~20 points, and that's the whole agenda. If the rep is at 90% and the model is at 55%, one of them knows something, so find out which.
• Sandbagging and happy ears lose their surface area, because stage placement is no longer the thing anyone can argue about. The argument becomes "what evidence would move this predictor," and evidence has a date on it.

What replaces the funnel chart?

Three reports:

1. Calibration. Did the deals we scored at 70% close 70% of the time? If your 70s are closing at 50, the model needs work, and if they're closing at 90, your reps are under-forecasting and you have more pipeline than you think.
2. Predictor coverage by segment. What % of enterprise deals have economic buyer access by day 30, and how does that compare to mid-market? That's your enablement roadmap.
3. Play execution rate. How often does the recommended play actually get run within a week? A low execution rate on a high-lift play = a coaching problem, not a pipeline problem. (Our Team View is built around exactly this.)

How do you pull a deal back into the quarter?

Every quarter-end has the same conversation: "which July deals can we pull into June?" Under stage-based forecasting that's a vibes exercise, where you look at late-stage deals and lean on the reps.

Under deal-level forecasting it's a specific question with a specific answer. Cycle-time predictors tell you which out-of-quarter deals have real compression available (timeline confirmed, economic buyer engaged, procurement already in motion), and those deals have a play that moves the date, like a mutual action plan with the buyer's dates on it or an exec brief that gets the signer's calendar. The others don't, and no amount of pressure changes that.

So "timeline confirmed" becomes a predictor you move with a play, instead of a close date you edit in the CRM on the 28th.

Do you have to delete your stages?

No. I opened part 2 with "delete the stage field," and that was the thought experiment. Here's the operating reality: finance needs forecast categories, your board deck has a funnel on slide nine, and Salesforce has a stage picklist that's not optional.

So don't fight it, reframe it:

• Stages become the reporting view. Finance and the board keep seeing what they see today.
• Predictors become the forecasting unit. That's what you and your managers run the business on.

The practical bridge, in order:

1. Keep your stages exactly as they are. Don't touch the picklist.
2. Add five to seven predictors as fields on the opportunity, derived from your event data. Start with economic buyer access, champion, multi-threaded, timeline confirmed, and next step booked. Even a manual version beats nothing.
3. Score them against closed-won for the last four quarters. Regression is enough, and you'll immediately see that two of your seven don't matter and one matters way more than you thought.
4. Run one deal review a week off the pre-read brief instead of the CRM view. Just one.
5. Attach one play to your weakest high-impact predictor, and measure whether running it moves the predictor.

Six weeks in, your stage-weighted forecast and your predictor-weighted forecast will disagree on specific deals, and those disagreements are the deals to look at. You can start this Monday without changing a single field your CFO looks at.

And if you'd rather not build the data layer yourself, that's what Loop does. Either way the architecture is the same, because the stage was never the thing predicting the outcome. The buyer's behavior was, and we just didn't have a way to see it.

I do now. I wish I'd had it that June.