The probability column is typed from memory, multiplied, and presented as data. A stored number with its reasons can be reviewed three weeks later.
A spreadsheet rebuilt every Monday. Nine columns, one of them a probability somebody guessed, and a weighted total nobody believes. At a thirty-person software company the sheet is rebuilt because last week is already wrong.
By hand today
“Opportunity Name”, “Sales Phase”, “Probability of Sale %”, “Weighted Forecast Amount”
Four of the nine columns in the Smartsheet sales forecasting templates, read 8 September 2026
Those are four of the nine columns in the template that most small companies end up copying. Look at the third one. The probability is typed by a person, from memory, in the same few minutes as every other row. Then it is multiplied by a deal value and totalled, and the total is presented as though it came from data.
The sheet is also a copy. It was pulled out of the CRM on Monday and it starts going out of date on Monday afternoon, so next week it is exported again and last week’s version is kept in a folder nobody opens. The reasoning that produced each probability was never written anywhere at all.
That is the real loss. Not the hour of copying, but the fact that in three weeks nobody can say why this deal was called likely, or who called it, or what they knew at the time.
What it costs you each week
Forty-five per cent, the share of sales leaders and sellers with high confidence in their own forecasting accuracy, in a 2020 survey. The other half rebuild the sheet anyway, every week.
Source: Gartner survey, published 12 February 2020, read 8 September 2026
Gartner published that figure on 12 February 2020. The release does not give a sample size, so read it as a direction and not a measurement. The point stands without precision. Most of the people producing a forecast do not believe it, and produce it again next week.
The weekly cost is the rebuild. Count the minutes it takes to export the pipeline, fix the columns, set the probabilities and total it. Then count how many of last month’s numbers you could still explain today.
The build
Codex stores a number with its reasons. The forecast is written once a week onto the pipeline, with who wrote it and why. Until somebody writes one, the field reads as empty, and never as zero.
Say the state of things plainly first, because it is the material of this chapter. The ArkOne platform has no forecast field today. It counts companies by stage over crm_pipeline, at docs/crm-module.md line 18, and it has no place to put a number somebody predicted. That gap is written down rather than papered over, and closing it is exactly the build below.
The rule the build follows is the one ArkOne applies to every judgement. A derived value, a score, a summary or a forecast is stored as a field with the reasoning beside it, never regenerated by a model each time somebody opens the page, at CLAUDE.md line 290. And a field nobody has written yet renders as absent, never as a zero and never as an invented default, at line 306. Copy that shape and build your own. There is no demo to download.
Work in the folder that holds your CRM. Type:
Add a forecast to the pipeline: a value, the reasons behind it, who
wrote it and the date. Do not calculate it. Every Monday, read the
pipeline and show me the deals that could close this month, each with
its stage, the last thing that happened and the date it happened. I
write the number and the reasons. Store what I write, then show it
beside last week's number and beside what actually closed. If no
forecast has been written this week, show the field as empty and say so.
What comes back on Monday is a short brief, not a spreadsheet: the handful of deals that can move the number, each with the last real event on it. You write one number and a few lines of why. Codex stores it against the week, with your name and the date.
What comes back on Friday is the comparison. The number you wrote, the number that happened, and the gap. Nothing is recalculated behind you, so a forecast written three weeks ago still says exactly what it said then, in the words you used.
The one thing to refuse is a probability column with no sentence behind it. A number on its own cannot be reviewed later. A number with two lines of reasoning can be, and the reasoning is what improves.
What it feeds
One screen for the engine. A stored number can be shown beside last week without being recalculated or argued about, and the next chapter puts every stage on a single screen. The forecast is the only number on it a person wrote by hand, which is exactly why it must be stored with its reasons rather than computed on the way to the display.
Three numbers prove this stage. The Monday number against the Friday actual. The variance against last week, which should narrow as the reasoning gets sharper. And weeks with no forecast written, which should be zero, because a blank week is the one that hides a slide.
What stays with a person
The probability on the three real deals. A machine can count a stage. It cannot know that the buyer has gone quiet since Thursday.
Almost every forecast turns on two or three deals. The rest is noise around them. Those two or three are the ones where a person has heard a tone of voice, or noticed that the sponsor stopped replying, or been told that a board meeting sits in the way.
None of that is in the CRM, and it should not be faked from what is. The build hands you the deals and the evidence, and then gets out of the way. You write the number. Signing it is the point, because a forecast with an author is a forecast somebody can learn from.
The tools you already pay for
Nothing new to buy.
CRM holds the stages, the counts and the new field.
A text file, forecast.md, holds one entry a week.
Your calendar gives it twenty minutes on a Monday.
The pipeline from the previous chapter supplies the facts under it.
No forecasting tier and no analyst.
A number with its reasons under it. Then one screen can show it.
Ask: Who wrote your current forecast, and what did they write beside the number?
This is chapter 10 of twelve, after a pipeline true on Monday; chapter 11 puts the engine on one screen. The book, Building a real GTM engine with Claude Code and Codex, end to end, runs the whole engine in order, one chapter per stage. A free starter edition for firms under fifty people is coming through the 100k programme.