Forecasting that survives contact with an ops team

Demand forecasting is the most over-promised capability in operations. Everyone agrees it’s foundational — accurate forecasting “underpins effective inventory management and delivery planning” and is a cornerstone of “minimizing stockouts and overstock.” And yet forecasts routinely die on contact with the ops team that’s supposed to use them. The model was accurate; the floor ignored it. Understanding why is more useful than chasing another decimal point of accuracy.

Three lessons from recent work, each about matching the model to the decision rather than maximizing a metric.

Lesson 1: the horizon is part of the model

A forecast isn’t accurate or inaccurate in the abstract — it’s accurate at a horizon. Get the horizon wrong and a good model produces useless numbers.

A study fighting the bullwhip effect in online food delivery makes this vivid. The team built a two-phase LSTM on two years of demand from Swiggy and Zomato, deliberately splitting the problem by clock speed. Phase 1 forecasts intra-day demand — the short, jagged variation within a single day. Phase 2 forecasts daily demand — the smoother overall total. Same data, same architecture, two horizons.

The results are the lesson: Phase 1 (intra-day) scored an R² of 0.69 for Zomato and 0.71 for Swiggy. Phase 2 (daily) jumped to 0.88 and 0.90. The longer horizon is dramatically more predictable, because intra-day demand is mostly noise and daily demand is mostly signal.

The operational takeaway isn’t “use the daily model” — it’s that the decision picks the horizon. Staffing the next two hours needs the noisy intra-day forecast and must be built to tolerate its lower accuracy. Ordering perishables for tomorrow uses the sharper daily forecast. Pretending a single model serves both is how forecasts lose the floor’s trust: they’re judged against a decision they were never shaped for.

Lesson 2: know which uncertainty you’re fighting

Not all forecasting error is the same kind, and the expensive mistakes come from misdiagnosing which kind you have.

There’s demand uncertainty — you don’t know how many orders will come. And there’s parameter uncertainty — you don’t even know the underlying statistics of demand yet, because you haven’t seen enough of it. Work on Bayesian demand learning under limited capacity shows why the distinction matters: when capacity is constrained, the optimal decision hinges on the ratio of supply to total demand, and early on you’re not just uncertain about demand — you’re uncertain about the distribution demand is drawn from. The right response is a model that updates its beliefs as evidence arrives, rather than one that commits hard to an estimate it doesn’t yet have the data to justify.

This is the difference between a forecast that’s confidently wrong and one that’s honestly uncertain. An ops team can plan around honest uncertainty — hold a little buffer, stay flexible. Confident-but-wrong is the one that burns them, because they staffed and stocked against a number the model had no business asserting.

Lesson 3: the model has to explain itself, or it doesn’t get used

Here’s the failure that no accuracy metric catches. A black-box demand model can be more accurate than the planner’s gut and still lose, because when the number is surprising the planner can’t ask “why,” can’t sanity-check it against the promotion they know is running, and so quietly overrides it. The forecast was right and irrelevant.

This is the actual mechanism behind most “the team won’t adopt it” stories. Adoption isn’t a training problem; it’s a trust problem, and trust requires the model to show its work. A forecast that says “demand is up 30% next Tuesday” gets ignored. One that says “demand is up 30%, and here are the drivers — the promotion, the weather, last week’s trend” gets acted on, because now the planner can agree or disagree with the reasoning, not just the conclusion. Explainability isn’t a nicety layered on top of accuracy. For an operational model it’s a precondition of being used at all — which makes it a precondition of being accurate in production, where accuracy is measured in decisions, not R².

Putting it together

A forecast that survives the ops team has three properties the notebook never tests for. It’s matched to the horizon of the decision it serves, so it isn’t judged against a clock speed it was never built for. It’s honest about its uncertainty, updating as evidence arrives instead of committing to numbers it hasn’t earned. And it explains itself, so the human holding the consequences can interrogate the reasoning rather than override the result.

None of those is a modeling breakthrough. They’re discipline about the decision the model exists to serve. Which is the quiet truth of operational forecasting: the hard part was never predicting demand. It was building a forecast an operator would actually act on.