A forecast people actually believe

You cannot coach a force you cannot see. Here is what each leaves behind once a model is reading the same pipeline your reps are calling:

• Sandbagging - commit consistently below the model, a best case that rarely converts, and a suspicious cluster of deals landing just over target.
• Happy ears - high rep confidence with single-threading, no finance or legal contact, and long gaps between meaningful replies from the buyer.
• Stage inflation - rising stage age at the late stages, deals sitting in negotiation with no pricing document, and a quarter-end cliff of slips.

All three fingerprints are things a machine is genuinely good at counting. All three causes are things only a person can address. That split is the whole session.

You do not need a product for this. A shared tab started this week will beat any tool bought next quarter, because the value sits in the accumulated reasons rather than the interface.

After one quarter you can answer questions no dashboard will answer for you: which reps override well and can be trusted, which override on hope, which reasons predict reliably across the whole team (procurement freeze almost always right, "they told me they love it" almost always wrong), and where the model is systematically blind so you can tell the vendor something specific instead of "it feels off".

The log only works if reps write in it honestly, which means it can never be used to ambush them. Review the reasons in aggregate before you look at individuals, and praise a good override that lost - a sound call with a bad outcome is still a sound call, and rewarding only outcomes gets you outcome-chasing.

Below is our forecast override log for Q3: deal, model number, rep-called
number, the rep's written reason, and the actual outcome.

Group the reasons into themes. For each theme give me:
- how many times it was used
- how often the override landed closer to actual than the model did
- one example entry, quoted

Then list the themes where reps were reliably right and the themes where
they were reliably wrong. Do not rank or score individual reps.

Analyse our override log and rank the reps by forecast accuracy.
Tell me which reps I should not trust with their own commit number.

The second produces a leaderboard, the leaderboard produces careful reps, and careful reps write "rep judgment" in the reason field forever. You will have destroyed the asset in one meeting.

The countermeasure is not a cleverer accuracy metric. It is scoring three things together, so that gaming one visibly damages another:

• Forecast accuracy - how close the commit landed to actual.
• Pipeline coverage - are you carrying enough to make the number at all? Sandbagging shrinks this.
• Slipped-deal rate - how many deals moved out rather than closed. Stage inflation inflates this.

Any one can be gamed. All three at once is close to just doing the job properly. And the rail underneath it all: never compensate on forecast accuracy alone. The moment accuracy touches pay you have converted your forecast from an estimate into a negotiation with money attached, and you will never see an honest number again.

Stage inflation is a definition problem before it is a behaviour problem. A stage defined by what you did can always be claimed. A stage defined by what they did cannot.

Write yours as exit criteria, not entry feelings, and make every criterion an observable act by the buyer. Then let the model score conversion by stage and it will finally be measuring something stable.

Zombie deals are the tax nobody budgets for: they consume rep attention, inflate coverage, and make every pipeline review longer and less honest. Humans are bad at killing them because each one carries a sunk cost and a small hope. A model has neither.

• No inbound activity in 21 days at a late stage. Not "we emailed them" - no reply from them. One-way activity is not a deal, it is a hobby.
• Single-threaded past evaluation. One contact at proposal stage means the deal ends the day that person's priorities change, and you will hear about it afterwards.
• Stage age well beyond the segment median. A deal sitting at three times the usual stage age is not slow, it is stuck, and the honest move is to name it.
• Slipped twice. Once is a timing problem. Twice is a qualification problem you have been carrying since discovery.

Killing is not deleting. Move it to a nurture state with a dated reason and a re-engagement trigger. The point is to get it out of the commit and out of the rep's head, not to pretend it never existed. A good share of them come back next year with a real budget.

This moment decides whether your team believes in the system, and it will arrive in your first month. Your best rep calls a deal at full value, the model calls it at a quarter, and everyone is watching what you do.

Do this five times and your reps stop treating the model as a threat and start treating it as a colleague with a very narrow but very consistent point of view.

Most forecast calls are a recitation of numbers everyone already read. These six questions turn the same 30 minutes into something that changes an outcome. Ask them per deal, in this order, and stop when you have your answer.

• 1 · What did the buyer do most recently? Not what you did. An act by them, with a date. If nobody can name one, the deal is not where the stage says it is.
• 2 · Who else has been in the room? Names and functions. If the answer is one name past evaluation, that is the risk, not the price.
• 3 · What has to be true for this to close this quarter? List the conditions, then ask which of them are already true today.
• 4 · What would make you drop this to zero? Reps find it far easier to name the kill condition than to admit a deal is weak. It is the same information.
• 5 · The model says X and you say Y. What do you know that it does not? A fact goes in the log. A feeling gets coached.
• 6 · What is the next step and who owns it? If the next step is "follow up", there is no next step. Get a date and a named person on their side.

Six questions, three or four minutes per deal, no slide deck. The point of the call is not to collect the forecast - the system already has it. The point is to test it.