Luis García, GTM engineer and founder of Drivant. About four years building GTM systems for B2B SaaS, fintech, HR-tech and staffing companies, from early-stage startups to established teams. How I work
Where forecast accuracy is won or lost
- Open deal
- then → Stage evidence
- then → Close-date history
- then → Revenue type
- Stage evidencebuyer did, not said
- then → System baseline
- Close-date historypushes, days slipped
- then → System baseline
- Revenue typenew, expansion, usage
- then → Rep call
- System baselineyour history
- then → Forecast
- Rep calljudgment
- then → Forecast
- Forecast
Takeaway. The call is the last step. Accuracy is decided by the three gates before it.
5 ways it breaks.
Stages that measure activity, not commitment
Entry to a stage is triggered by a seller action, like sending a proposal, instead of buyer evidence, like a named signer or a confirmed procurement step.
Close dates that only move right
Pushing a close date costs the rep nothing and leaves no trace, so slippage is invisible until the quarter is already lost.
One amount for different revenue
New business, expansion, usage and multi-year terms all share one amount field, so a single number blends deals with very different timing and certainty.
Rep calls with no baseline
There's no system forecast built from history to compare against, so nobody can tell whether a call is optimistic or informed.
Coverage ratios from another company
The coverage target was borrowed, not derived from your own stage conversion and cycle length by segment.
The slippage ledger.
| Deal | Category | Pushes | Days slipped | Rule applied |
|---|---|---|---|---|
| Deal A | Commit | 0 | 0 | Holds |
| Deal B | Commit | 1 | 14 | Watch |
| Deal C | Commit | 2 | 41 | Move to best case |
| Deal D | Best case | 3 | 63 | Remove from call |
| Deal E | Commit | 0 | 0 | Holds |
Illustrative data, not a real client. Rule: a second push moves a deal out of commit automatically.
What does a buyer have to have done, not said, for a deal to enter your proposal stage? The Pipeline Leak Teardown answers questions like this one for your company, in one page, without a call.
Get the teardownWhat changes when it is designed on purpose.
Typical today
- Proposal entered when the rep sends one
- Commit is the rep's judgment
- Close dates move freely
- One amount for new, expansion and usage
After the build
- Proposal entered when the buyer names a signer
- Commit allows at most one push
- Slippage logged per deal
- Revenue type split so timing is forecast separately
What I check in the first 48 hours.
How many of this quarter's commit deals have already had their close date moved at least once? That question usually opens the audit. Then, in order:
- Close-date push count and days slipped for every open deal in the current and next quarter
- Stage entry criteria as written, versus what a sample of deals actually had when they entered
- How amount is defined per deal type, and whether new, expansion and usage can be separated in reporting
- Historical stage-to-close conversion and cycle time by segment and deal size
- Last four quarters: rep call versus system baseline versus actual
- Deals in late stages with no activity from the buyer side in the last 21 days
Three decisions we make together.
Gating stages on buyer evidence makes late-stage numbers reliable, but reps will feel slowed down. We gate the stages the forecast depends on and leave early stages flexible.
Weighting by stage probability is mechanical and stable; categories like commit and best case capture judgment. Most teams need both, compared every week, not one replacing the other.
Separate amount fields keep one deal per buyer decision; separate deals per revenue type keep reporting simple. The choice depends on how finance recognizes revenue.
How we know it worked.
Three numbers, measured before the build and again after one full quarter.
Call versus actual, by week of quarter. The goal is a smaller error earlier, not only at the end.
Share of commit deals whose close date moved after the quarter started.
Distance between the rep call and the system baseline built from your own history.
Questions.
Is this the same as pipeline reporting?
No. Pipeline reporting is about what the numbers mean and keeping history stable. Forecast accuracy is about predicting which deals will close and when, which needs that foundation but asks a different question.
Do we need a forecasting product?
Not to start. Accuracy comes from stage evidence, slippage tracking and a baseline from your own history. Those have to exist before any forecasting software can help.
How do you measure improvement?
Forecast error by week of quarter, before and after, for both the rep call and the system baseline. The goal is a smaller error earlier in the quarter, not just at the end.
Will reps accept stricter stages?
Usually, if the criteria are few, observable and agreed with them. We keep the gates to the stages the forecast actually depends on.