Reading a forecast bridge deal by deal: from run rate to the number the CFO sees

Every forecast call has the same moment: the number is $1.4m above the run rate, someone asks why, and the answer is a list of deal names from memory. A forecast bridge is that answer computed from the pipeline history, deal by deal, before the call. This guide sets out how to build it and how to read it.

What a bridge is

Between two points in time, the forecast for a period changes because of named events:

The components sum exactly to the change. That is what makes it a bridge rather than a commentary.

The rows you need

• Pipeline history: one row per deal per change, with stage, close date, value and the date of the change. Salesforce opportunity history or the HubSpot equivalent.
• Snapshot dates: the two points to bridge, usually the prior forecast call and today.
• Owner and segment: from the deal.

Building it

1. Reconstruct each deal's state at both snapshots from the history.
2. Classify the change per deal into one component. A deal can only be in one.
3. Sum by component. Assert that the sum equals the forecast change.
4. Count slips per deal across the whole history: each move of the close date to a later period.
5. Rank the deals within each component by value.

forecast(now) − forecast(prior) = new + expansion + pulled in − pushed out − slipped − lost − won

A worked example

Q4 forecast rose $1.4m since the last call.

Three deals pulled in from Q1 explain most of the rise. All three are in the West, and the history shows each has already slipped twice. Excluding them, the forecast is $0.3m above run rate, inside the usual range. That is the sentence the CRO says on the call, and the CFO's follow-up, "what is Q4 without the three", is answered on the same page.

Reading the slip count

A deal that has slipped once is ordinary. A deal that has slipped twice is a pattern, and the third slip is more likely than the close. A forecast that depends on deals with two or more slips is a forecast built on the deals least likely to close on time, and the bridge should flag them by rep, because the pattern is usually a rep's, not a customer's.

Where it goes wrong

Snapshot only. A CRM export without history cannot bridge; it can only compare two totals. Get the history export.

Pushed and slipped merged. Without a reason on the close-date change, every move looks the same. Record the reason; it is one field.

Value changes and date changes together. A deal that grew and slipped in the same week belongs in one component. Decide the precedence, usually the date change, and apply it every time.

Won deals left in. A deal closed won during the window is revenue, not forecast. Move it to the won line so the bridge does not double count.

Before every call

Mapped once, the history export produces the bridge, the slip counts and the ranked deals before every forecast call, and answers the follow-ups with the deals shown. Covirage does this on the export as it is. The forecast analysis page describes the setup.