Consider an illustrative equipment supplier building next year’s plan. Website sessions have risen steadily for several periods, and the trend looks clean enough to extend forward. Project the sessions, apply the previous enquiry rate, apply the previous close rate, multiply by average order value, and a revenue number appears at the far end looking as solid as the traffic line behind it.<\/p>\n
Now suppose traffic arrives close to that projection while revenue does not. When leadership asks which assumption moved, the problem becomes obvious: traffic was the only variable the model allowed to move.<\/p>\n
Traffic has its own observed history and can be projected from that history. Revenue has a history too, but a revenue forecast built from traffic depends on more than the traffic series. It also depends on what share of visitors enquire, what share progress through the commercial chain, what orders are worth, and when those orders become revenue.<\/p>\n
Each of those drivers can move independently. A pricing change may alter close rate. A form change may alter enquiry rate. A longer customer approval cycle may alter timing even when demand is unchanged.<\/p>\n
The arithmetic may be perfectly correct while the label is too confident. The model has forecast one variable and held several others as assumptions. Present the result without exposing those assumptions and it becomes a traffic forecast wearing revenue’s clothes.<\/p>\n
Everything below describes an invented business, written for this article. No figure in it is measured, and every number exists to show the shape of the reasoning.<\/p>\n
The supplier sells equipment to contractors. Last year the site drew 40,000 sessions. Two percent of visitors sent an enquiry, giving 800. A quarter of those enquiries became orders, giving 200. The average order was worth $3,000, so the year came to $600,000. The base case for next year assumes 48,000 sessions with every other link held where it is: 960 enquiries, 240 orders, $720,000.<\/p>\n
Three things can go differently, and each is a different kind of uncertainty.<\/p>\n
The chain holds exactly as it did. Traffic is the assumption in doubt: a channel that supplied a third of last year’s sessions is showing signs of decay, and this year the growth may flatten.<\/p>\n
At 40,000 sessions with an unchanged chain, revenue is $600,000. At 34,000 it is $510,000. This is the control case: it shows the kind of downside a traffic-led forecast can already see. The next two scenarios matter because they expose what that same line cannot see.<\/p>\n
Traffic arrives as planned and the chain moves underneath it. Suppose two of the four links shift: the enquiry rate falls to 1.6% because a competitor’s landing page is absorbing comparison traffic, and the close rate falls to a fifth because more of the enquiries that remain are early-stage.<\/p>\n
That is 48,000 sessions, 768 enquiries, 154 orders, $462,000 \u2014 below the pessimistic traffic case, on traffic that hit its number. In a single line the chain is a constant, so this outcome is invisible to it.<\/p>\n
Both traffic and the chain behave. What moves is time. Contractors’ approval cycles stretch from six weeks to eleven, and orders that would have been invoiced in the fourth quarter are invoiced in the first quarter of the year after.<\/p>\n
Timing is the assumption most easily left out of a forecast built by multiplication, which handles quantities and has no way to hold a date. The eventual order value may be unchanged while the period in which it is invoiced shifts, so the forecast can look directionally right about demand and still be wrong about when the reported revenue appears.<\/p>\n
They do not buy accuracy. Three wrong numbers are worth no more than one wrong number. Scenarios do not earn value by multiplying forecasts; they earn it by exposing the assumptions that differ between them.<\/p>\n
What they buy is legibility. When the outcome misses, a single line supports one conclusion \u2014 the forecast was wrong. Three scenarios turn that into a locatable question. Traffic behaved, the close rate moved, and the argument now has an address.<\/p>\n
Three is a working count. It is enough to show that one traffic figure supports several outcomes, and few enough that each can be argued through in a meeting without a spreadsheet tutorial. A fourth earns its place when a genuinely independent assumption sits outside all three \u2014 a currency move, a regulatory change, the loss of a single account large enough to carry the year on its own.<\/p>\n
Under the scenarios, write the assumptions out. One line each: what is assumed, who owns it, and the event that would revise it. The roles below are placeholders. In a live receipt, replace each one with the name of the person responsible for revisiting that assumption.<\/p>\n
Ownership needs to resolve to a person because a trigger requires someone who can notice it and reopen the assumption.<\/p>\n
The word receipt is doing the work here. A plan states what will happen; a receipt records what was believed, by whom, at the moment the number was handed over. Six months later it converts an argument about judgement into an argument about a line: the close-rate assumption moved, it had an owner, and here is the event that should have prompted its revision.<\/p>\n
A revision trigger is an observable event \u2014 a price change, a channel loss, a form redesign, a lead time crossing a threshold named in advance. Writing it into the receipt settles beforehand what will count as new information, while everyone involved is still ahead of the result.<\/p>\n
Without a revision trigger, two failure modes become easy: changing the forecast whenever a result disappoints, or leaving it untouched long after an assumption has moved. Both end in the same place, where the number stops carrying information about what the business currently believes.<\/p>\n
The trigger also closes what a scenario leaves open. Scenarios show that several futures are available; the trigger tells you when one of the assumptions supporting the forecast needs to be reopened.<\/p>\n
Take the forecast you are about to hand over. Underneath it, write the four or five assumptions it rests on, and against each one write a name and an event. Then produce the two neighbouring versions \u2014 one in which traffic is the thing that moved, one in which the chain is.<\/p>\n
The number may still miss. This method does not eliminate forecast error. What it changes is your ability to explain what moved, who owned that assumption, and what event should have triggered a revision. That is a materially different conversation from the one that begins and ends with the observation that the forecast missed.<\/p>\n
Before you bolt on another tool, it is worth knowing whether your business runs on systems or on you. I put together a free 2-minute assessment that gives you a straight read on exactly that, and the first thing to fix. Take the free assessment<\/a>.<\/p>\n