← All articles

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.

63% to 81%
Forecast accuracy, manual vs AI-assisted (HatHawk Q1 2026)
$300K
Net move the delta walk attributes in the example below
45 min
Handshake meeting length when prep is done the day before

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.

Build it bottom to topThe monthly forecast handshake
  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

The handshake Bookings clock and cash clock meet once a month
RevOpsbookings, sales clockFinancecash, recognition clockHandshakefirst Tuesday, deltas on the tableSignedversion-stamped
RevOps commits bookings; Finance applies recognition timing. The meeting is where the bridge between the two clocks gets built and signed, not where two totals fight.

Here is the meeting structure I run once the definitions are locked.

StepOwnerOutput
Pull committed pipelineRevOpsBookings forecast by rep, by stage
Apply recognition timingFinanceRevenue forecast by period
Diff against last monthBothWhat moved, which deals, why
Lock the numberBothSigned 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
Same monthly number. One leaves you a memory contest at quarter close; one leaves you an audit trail.

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
The month-over-month delta walk
$4.8M to $5.1M breaks into four attributed moves, not one number that grew. Finance can apply recognition timing to each and tell you which change this quarter's cash and which are next-period problems.
View as table
ItemValue
Last month4,800K
New to Commit520K
Slipped out410K
Grew190K
This month5,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 rateWhat it meansHandshake action
Over 90%Sandbagging: only committing sure thingsPush the rep to call the real number
70-80%Healthy: honest read on the quarterPlan cash and capacity against it
60-70%Loose: some optimism baked inDiscount the commit, watch the slip
Under 60%A wish, not a forecastDo 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 versionSaidActualErrorRead
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.9M0%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.

Run the handshake this month
  1. 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. 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. 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. 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. 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.

forecasting finance operating-cadence

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