Deterministic Commercial Forecast Automation: Three Scenarios, Zero Guesswork

Showing a placeholder number before real data loads is a common enough pattern that it rarely gets a second thought — until the placeholder looks exactly like a real revenue figure, sits where a real number belongs, and a person glances at the dashboard mid-meeting and repeats it as fact. The fix is not a subtler placeholder; it is treating "I don't have this data yet" as a state the interface has to represent honestly, even if that means a section of the dashboard is briefly, visibly, empty.

A demo number is chosen because an empty dashboard looks broken — but a number that looks exactly like a real one, sitting where a real one belongs, is a worse failure mode than an obviously empty box, because nothing about its appearance tells a viewer to doubt it. The same reasoning applies to a fabricated forecast: a plausible number with no visible method invites exactly the kind of confidence a genuinely thin dataset does not support. The honest fix in both cases is the same — degrade visibly (omit the block, or explain the limitation) rather than degrade silently (keep showing something that looks fine).

The home screen's revenue, spend, ROAS and conversion tiles used to show fixed "Demo" values ahead of the real label loading — that placeholder has been replaced with the organization's actual funnel data. When the underlying Orbit pipeline fails to load, the block does not fall back to a stale or fabricated number; it degrades by omission, disappearing rather than showing something that looks current but isn't.

On top of the real pipeline, `buildCommercialForecast()` is explicit, in its own governing comment, about what it is not: with six weeks of history, 96 recorded stage transitions and zero closed deals in the dataset the function was built against, there is no time series to train a model on and no observed conversion rate to calibrate one — "any fitted curve over this would be drawing a picture, not a forecast." What the function computes instead is deterministic arithmetic over the real pipeline, split into four quantities the interface keeps visually and semantically separate: REALIZED (deals actually won, with their last activity falling inside the chosen window — not their creation date, so a deal won months later doesn't retroactively count as this month's revenue), OPEN PIPELINE (every open deal's value, whether or not it has an expected close date), PROJECTION (open deals with both a value and an expected close date inside the window, weighted by their stage's configured probability), and three SCENARIOS built from the same projectable pool under three different, named rules: Conservative counts only deals in a stage at 75% probability or higher, at full value; Realistic weights every projectable deal by its own stage's probability; Optimistic counts every projectable deal at full value, as if none were ever lost. Each scenario carries its rule as a plain-language string traveling with the number itself, not documented separately where it could drift out of sync — anyone can redo the exact arithmetic on paper.

Open deals with no expected close date are counted in the pipeline total but explicitly excluded from every scenario and named in a separate count, because a deal with no expected date genuinely cannot be said to fall inside any specific window. And the interface carries its own standing warning, verbatim in the forecast's own output: realized, open pipeline and projection are different quantities and must never be summed — stacking them into one number is the textbook mistake this design is built to prevent.

A pipeline holds a handful of large, early-stage deals with a low configured probability and a couple of smaller, late-stage deals near closing. The Conservative scenario counts only the late-stage deals at full value, since only they clear the 75%-probability bar. The Realistic scenario adds in a small, probability-weighted slice of the large early-stage deals. The Optimistic scenario counts everything, including the large early-stage deals, at full value. The three numbers can differ by a wide margin — which is the entire point of publishing three, rather than collapsing the same pipeline into one number that hides how much the outcome depends on which deals actually close.

A revenue leader gets a range instead of a single confident-looking number, with the specific rule behind each end of that range spelled out rather than hidden behind an "AI forecast" label. Nobody on the team can mistake a stale demo tile for a live figure, because the tile that used to show one now shows the real pipeline or nothing at all. And because realized, pipeline and projection stay visually and semantically apart, a monthly report is far less likely to accidentally double-count revenue that's still just potential.

A team wanting a machine-learning-based sales forecast — one that learns conversion rates and cycle length from historical patterns — will find deliberately deterministic arithmetic here instead, by design, because the underlying dataset does not yet support that kind of model honestly. A team wanting one single forecast number for a board deck will need to pick one of the three published scenarios and cite its rule, rather than expect the tool to pick one for them.

A single forecast number labeled "AI-powered" implicitly asks for trust without showing its work — and over a pipeline too young to support a real statistical model, that confidence is not earned. Centriu Dash instead publishes deterministic arithmetic under three named, rule-stated scenarios, so a viewer sees exactly which assumption produced which number and can recompute any of them by hand — the opposite of a black box, over a dataset honest enough to admit it isn't ready for one yet.