GTM Operations
The Forecast Handshake: Make the CRM Number Equal the Board Number
RevOps forecasts $5.1M in bookings, Finance modeled $4.4M in revenue, and the board hears both. A monthly reconciliation ritual ends the argument. Here is the five-rung build that makes one number defensible.
· 13 min read
RevOps sends the board $5.1M in bookings. Finance sends the board $4.4M in revenue off the same pipeline. The board asks which one is real, and now it is a fight instead of a reconciliation. That $700K gap is not a modeling error. It is two teams forecasting different things, in different tools, on different clocks, comparing them for the first time inside a board deck where the only available move is to argue.
For years the fix was a stern email: RevOps, tighten your commit; Finance, trust the CRM. That never worked, because the two numbers were never supposed to be equal in the first place, and pretending they should be only moved the argument to a worse room. Manual forecasting lands around 63 percent accurate; AI-assisted pushes it to 81 percent (HatHawk, Q1 2026). Best-in-class RevOps teams hold sub-5 percent forecast variance (revopsmasters, 2026). None of those numbers matter if RevOps and Finance only meet the number in front of the board. The accuracy problem is real. The reconciliation problem is the one nobody schedules time for, and it is bigger.
So I stopped chasing a better model and built a ritual. Once a month, RevOps and Finance sit in a room and turn two forecasts into one signed number. It runs on five rungs, each one closing a gap the previous version left open. This is the handshake. Scroll the build bottom to top, then I will show you the math, the query, and the worked example under every rung.
- R5Sign one number both teams defend1 number
Lock the reconciled forecast, version it, and both names go on it. The bookings clock and the cash clock now describe the same quarter, and the board hears one number with two owners.
- R4Check commit rate as the honesty gate70-80%
Committed forecast divided by what closes. Over 90 percent is sandbagging, under 60 percent is a wish. Catch both tails here, before either number reaches the board.
- R3Walk the deltas, not the totals$300K net
Diff today against last month deal by deal. Every moved dollar gets a line and a reason: slipped, grew, created, pushed, closed early. Bring the attributed moves to the room, not two big numbers.
- R2Freeze a snapshot every monthversion-stamped
Stamp the committed set as an immutable, dated version. Never overwrite. This frozen set is what next month diffs against and what the post-mortem reads at quarter close.
- R1Agree the definitions firstshared defs
Write down what counts as Commit, what a booking is versus recognized revenue, and whose close date wins. If the two teams cannot state these the same way, every later number is an argument about vocabulary wearing a spreadsheet.
Locate your team on that ladder. Most live below R3, mailing raw totals back and forth and meeting the gap for the first time in the board deck. Every rung above subtracts a specific way the two numbers drift apart. By R5 the number you carry into the board is one both teams built, which is the only kind the board cannot pick apart.
R1: Two forecasts, two clocks, agreed on purpose
RevOps forecasts bookings on the sales clock: what closes, when, weighted by stage and rep commit. Finance forecasts revenue and cash on the recognition clock: what activates, what invoices, what collects. These are supposed to differ. A booking signed in March is cash in May. The handshake is not there to make the two equal. It is there to make the bridge between them explicit and owned, so the difference is a documented timing map instead of a surprise.
That only works if both teams define the terms the same way before anyone forecasts anything. If Commit means “verbal yes” to a rep and “contract received” to Finance, the two numbers cannot reconcile no matter how clean the data is. Rung one is boring and it is the whole foundation: one written definition of Commit, one rule for booking versus recognized revenue, one owner for the close date.
Here is the meeting structure I run once the definitions are locked.
| Step | Owner | Output |
|---|---|---|
| Pull committed pipeline | RevOps | Bookings forecast by rep, by stage |
| Apply recognition timing | Finance | Revenue forecast by period |
| Diff against last month | Both | What moved, which deals, why |
| Lock the number | Both | Signed forecast, version stamped |
The whole thing takes 45 minutes if the data is clean going in. It takes three hours if you are reconciling live, which is why the prep matters more than the meeting.
R2: Freeze the snapshot or the handshake means nothing
The output of every handshake is a locked, version-stamped forecast. Not a spreadsheet that gets overwritten next month with no record of what it said. Stamped, saved, immutable.
This matters for one reason. When the quarter closes and the number was wrong, you need to know what you believed and when. If the forecast lives in a spreadsheet edited in place, there is no audit trail, and every post-mortem becomes a memory contest that the loudest voice wins. The frozen snapshot is also what rung three diffs against, so R2 is not optional bookkeeping. It is the input to the rung that does the real work.
| Overwritten spreadsheet | Version-stamped forecast | |
|---|---|---|
| What last month said | Gone, overwritten in place | Frozen, dated, immutable |
| Post-mortem | "I think we called $4.8M?" | Diff actual against each committed version |
| When forecast got reliable | Unknowable | Visible: which week the number held |
| Board defense | One person's recollection | A signed number both teams own |
R3: Walk the deltas, not the totals
This is the rung that turns two numbers into one. The failure mode is walking in with two big totals and arguing about the difference. The fix is walking in with the difference already attributed to individual deals.
I diff the current committed forecast against last month’s frozen snapshot using a daily snapshot of the opportunity table. Every deal that moved gets a line: it slipped, it grew, it got created, it got pushed to next quarter, it closed early. When RevOps and Finance sit down, the conversation skips “why is your number higher” and goes straight to “these nine deals moved the number $300K net, from $4.8M to $5.1M, here is each one, here is what the rep said.”
Committed last month $4,800,000
+ 3 new deals reached Commit stage $520,000
- 2 deals slipped to next quarter ($410,000)
+ 4 deals grew in negotiation $190,000
= Committed this month $5,100,000
View as table
| Item | Value |
|---|---|
| Last month | 4,800K |
| New to Commit | 520K |
| Slipped out | 410K |
| Grew | 190K |
| This month | 5,100K |
The four moves net to a $300K increase, which is the number on the middle stat tile above, and they reconcile the exact gap that started this piece. The board saw $5.1M from RevOps and $4.4M from Finance and heard a fight. The delta walk turns that same spread into a timing map: of the $5.1M committed, Finance’s recognition rules push some of it past the quarter boundary, which is why its in-period revenue number sits lower. That is not a disagreement. It is a bridge, and once it is drawn deal by deal, nobody argues about it.
The diff comes straight out of the daily snapshot. You are comparing today’s committed opportunities against the frozen set from last month’s handshake:
-- Deals that changed since last month's committed snapshot
SELECT o.Id, o.Name, o.Amount, o.StageName, o.CloseDate,
s.Amount AS prior_amount, s.CloseDate AS prior_close, s.StageName AS prior_stage
FROM Opportunity o
LEFT JOIN forecast_snapshot s ON s.opp_id = o.Id AND s.snapshot_month = :last_handshake
WHERE o.ForecastCategory = 'Commit'
AND (o.Amount != s.Amount OR o.CloseDate != s.CloseDate OR o.StageName != s.StageName
OR s.opp_id = null);
Now Finance applies its recognition timing to each of those moves and tells RevOps which ones change the revenue picture this period and which are next-period problems. The two slipped deals might not touch this quarter’s cash at all. You only learn that by walking the deltas together. This is the same bridge discipline as the CRM-to-Finance reconciliation layer, run forward on the forecast instead of backward on the actuals.
R4: Commit rate is the honesty gate
The number I watch hardest going into the handshake is commit rate: committed forecast divided by what closes. Healthy sits at 70 to 80 percent. If a rep or a segment commits at over 90 percent, read it as sandbagging rather than confidence. They are only committing deals already in the bag and hiding the rest, which makes the forecast useless for planning even though it looks accurate on paper. This is also why raw accuracy is a trap: a sandbagged forecast can post great numbers and still tell you nothing about the quarter.
Below 60 percent the commit is a wish, and RevOps planning headcount off a wish over-hires. With win rates having fallen to 19 percent across B2B in 2025 (Ebsta and Pavilion, 2025 B2B benchmarks), the pressure to pad commit both directions is higher than it has been in years, which is exactly why the gate belongs in the ritual and not in one rep’s head.
| Commit rate | What it means | Handshake action |
|---|---|---|
| Over 90% | Sandbagging: only committing sure things | Push the rep to call the real number |
| 70-80% | Healthy: honest read on the quarter | Plan cash and capacity against it |
| 60-70% | Loose: some optimism baked in | Discount the commit, watch the slip |
| Under 60% | A wish, not a forecast | Do not plan headcount off it |
R5: Sign one number, then read the year it teaches you
The version stamp feels like bookkeeping until the fourth quarter, when you can line up every committed forecast you froze against what landed and read your own process like a chart. Diff month one’s commit against actual and you learn how blind you were at the start of the quarter. Diff month three’s against the same actual and you learn the week your forecast became trustworthy. Do this for four quarters and you have something no forecasting tool sells: a measured answer to “how early can we believe our own number,” which is the input to every capacity and cash decision you make.
| Committed version | Said | Actual | Error | Read |
|---|---|---|---|---|
| Month 1 (early) | $5.6M | $4.9M | +14% | Optimism, deals not yet real |
| Month 2 (mid) | $5.1M | $4.9M | +4% | Tightening, inside the band |
| Month 3 (late) | $4.9M | $4.9M | 0% | Reliable, but too late to act on |
The pattern that table exposes, and every team has one, is that the forecast gets accurate exactly when it stops being useful. A number you can trust in the last week of the quarter cannot change how you staffed or spent. The whole point of freezing the versions is to push the reliable read earlier, and you cannot push what you never measured. This is the same instinct behind computing board metrics at the source: a number is only worth what its history and its definition let you do with it.
- 1
Lock the definitions once (rung 1)
Write one definition of Commit, one rule for booking versus recognized revenue, one owner for close date. Both teams sign it. This does not change month to month.
- 2
Freeze last month, then diff (rungs 2 and 3, day before)
RevOps pulls the committed set, diffs it against the frozen snapshot, and gives every moved deal a line and a reason. Finance maps each committed booking to when it recognizes and collects.
- 3
Walk the deltas together (meeting, 45 min)
Skip the two totals. Walk the nine deals that moved the number $300K net, each with the rep reason and the recognition read. Argue the deals, not the difference.
- 4
Check commit rate as the gate (rung 4)
Over 90 percent is sandbagging, under 60 percent is a wish. Catch it here before either number is committed to the board.
- 5
Sign and version-stamp (rung 5)
Freeze the reconciled forecast as an immutable, dated version with both names on it. Never overwrite. This is the record you diff the actual against at quarter close.
The accuracy tools matter, and getting from 63 to 81 percent is real money. But a signed, defensible number does not come from a better model. It comes from RevOps and Finance climbing the same five rungs once a month, walking the same deltas on the same clock, and freezing what they agreed to. Put it on the first Tuesday. Walk in with deltas, not totals, and leave with a version-stamped number the board hears once, from two owners. For the sales-side inputs that feed rung three, see the forecast you can defend.
Keep reading
One email. Every week.
One email a week: an operating problem I solved or botched, with the model, the numbers, and what I would change. No roundups, no theory, unsubscribe whenever it stops being useful.
The newsletter opens soon.
Connect a provider in src/config.ts