A forecast nobody opens is not a forecast

Almost every business that has rolled out prediction has a report somewhere that nobody opens. It is usually a good one. It usually has decent accuracy. And it has usually never changed a single decision.

That is not the model failing. That is the place it was put failing. A forecast affects a business only when it reaches somebody who is making that decision anyway, and tells them something they would not otherwise have known.

Accuracy is necessary and not sufficient

Picture a model that predicts which clients will leave next quarter, and does it very well. The report lands in the sales director’s inbox on the first Monday of the month. What happens next?

Usually nothing. Not because the director is lazy, but because a list of company names without context is nobody’s task. It is not clear who should call, about what, or whether somebody already called last week. To turn that list into action, somebody has to do all the work the model was supposed to save.

The same model, wired into the moment an account manager opens a client record and showing one sentence together with the reason, changes a conversation the account manager was going to have anyway. The model is identical. The difference is where it sits.

Three questions before building anything

Before anyone touches the data, it is worth having answers to three questions. Missing even one of them almost always ends in the report described above.

• Which decision is meant to change? Not "we want to predict churn", but "the account manager should call five different clients this week from the ones they would have called otherwise".
• Who makes it, and at what moment? A specific role and a specific screen. If the answer is "the board, at the monthly review", then a forecast with a one-week horizon is useless.
• What will that person do differently? There has to be an action within their reach. A demand forecast is priceless to somebody who places orders and meaningless to somebody who does not.

If any of those questions has no answer, the problem is not the model and a better model will not solve it.

The horizon has to match the response time

A common design mistake: a forecast with a horizon shorter than the time needed to react. The model says stock runs out in three days, and delivery takes two weeks. The forecast is true and there is nothing to be done with it except get annoyed.

The rule is simple: the horizon must be longer than the longest response time in that process, with room for the decision itself. If reacting takes two weeks, a one-month forecast is useful and a one-week forecast is trivia. This is set at the start and it decides which data makes any sense at all.

Uncertainty has to be shown, not hidden

A forecast given as a single number looks more certain than it is, and teaches people distrust the first time it is wrong. A forecast given with a range teaches the opposite: that this is a tool with a known accuracy, not an oracle.

In practice the difference looks like this. A statement that looks solid but cannot carry a decision:

Forecast sales next month: 412 units.

And the same result put so that you can act on it:

Forecast sales next month: 380 to 450 units, assuming no promotion. The biggest single influence is one wholesale client whose orders have been irregular over the last three months.

The second lets you plan stock for 450 and know where to look when something goes differently. The first only lets you complain when it comes out at 430.

A model that does not learn from corrections ages in silence

A business changes faster than the historical data a model was built on. A new client segment, a price change, a season that turned out differently. The model does not know any of it until somebody tells it.

The cheapest learning mechanism is recording corrections. Somebody saw the forecast and did something else? That is information. A correction that keeps going the same way means the model is systematically wrong in one specific place, and points at exactly where. It works better than a periodic accuracy review, because it happens in the course of normal work.

There is one condition: correcting has to be easier than going around the system. If fixing the forecast takes three clicks and ignoring it takes none, people will ignore it and nobody will find out.

When prediction is too early

There are situations where the honest answer is "not yet". They are worth knowing, because a failed prediction rollout puts an organisation off for years.

• The event data is created after the fact, by hand. If the loss of a client appears in the system only when somebody types it in three weeks later, the model is learning from a delayed reality.
• The decision is rare and high-stakes. With a dozen or so decisions a year there is nothing to learn from and nothing to measure improvement on. Well-prepared context works better there than a forecast.
• There is nobody who makes that decision. It sounds absurd and happens often: the process is smeared across four departments and the forecast has no addressee.

Where this sits in Omnira

This layer is handled by Predict. The principle is the same as above: the forecast has no screen of its own, it appears where the decision is being made anyway, together with its range and its reason. Corrections go back into the model, so tuning happens in the course of the work.

If you want to check whether your decision is a fit for prediction, start with a conversation. The first question will be what should change, not what data you have.

Frequently asked questions

How much historical data do you need? Less than people say, but it has to cover the cycle you are forecasting. For annual seasonality two full years is the minimum; for a weekly forecast a few months can be enough. More important than the amount is whether the data describes reality, or the moment somebody typed it into the system.

Does it have to be machine learning? No. Plenty of decisions are improved by a plain threshold rule worked out from the data. A model is worth adding when the rule stops keeping up with the number of exceptions, not at the start.

How do you win over a team that already got a report and stopped opening it? Not with another report. What works fastest is showing the forecast where that team already works, and for two weeks only as a suggestion, with nothing required of them. If nobody uses it after two weeks, that is an answer about the value of the forecast, not about the team.

What about sensitive data? Prediction does not require taking data outside the business, if it is computed where the data sits. That is an architectural decision made at the start, and it is worth making deliberately rather than discovering it during an audit.