Demand Forecasting for Distribution

Replenishment planners were forecasting several thousand product-location combinations in spreadsheets using a moving average and their own judgement. It worked reasonably for stable products and badly for anything seasonal or promoted, and the result was persistent overstock in some categories and stockouts in others, both expensive. Nobody could separate the two effects because there was no record of what had been forecast versus what happened. The ask was better forecasts, but the real requirement was a system where a forecast is recorded, reviewable and improvable.

I was the data scientist on the project, one of two, with a data engineer who owned the pipeline into the models and a business analyst from the client's planning team. I owned modelling, evaluation and the feedback loop. I made a point of not owning the planners' decisions — the system proposes and a planner can override, and I pushed back when the client suggested automating the override away.

I built the feature pipeline, the model training and evaluation harness, and the backtesting framework we used to argue about whether anything was actually better. I owned the model selection, the promotion-handling logic, and the confidence bands that determine which forecasts a planner is asked to review. I also built the override-capture mechanism, so when a planner disagrees we record it and their reasoning becomes training signal. I did not build the planning interface itself, which their internal team owned.

The most important decision was making a gradient boosting model the default rather than a deep sequence model, which is what the client expected because a previous vendor had pitched one. With about three years of history and strong seasonality, the boosted model backtested better and, more to the point, a planner could be shown which features drove a number. That explainability was the difference between planners using the forecasts and ignoring them. I also chose to forecast at the product-location-week level and aggregate up rather than forecasting aggregates and allocating down, which is more computationally expensive and avoids the allocation errors that made the previous approach untrustworthy at store level. Promotions are modelled as an explicit uplift on a baseline instead of a feature in one model, because the client's promotion calendar arrives late and often changes.

History was three years, and one of those was so distorted by an unusual demand period that we ended up excluding chunks of it, which we argued about for two weeks. Promotion plans arrive between two days and three weeks before they run, so anything that needed long lead time was unusable. Forecast runs had to finish inside a four-hour overnight window, which is what pushed us to a model that trains quickly rather than the largest one that fit the data. Planners also had limited patience — if a review took more than a few seconds per item, they'd skip it.

Forecast error, measured as weighted mean absolute percentage error on held-out weeks, improved from around 34 percent to about 21 percent overall, with the biggest gains on promoted lines where the old approach was worst. Stockouts on the top two hundred products fell by roughly a third over two quarters. The result I'm most pleased with is quieter: planners now review about fifteen percent of forecasts instead of touching all of them, so their attention goes where the model is uncertain. Their overrides are also recorded, and about a year in the override data revealed a supplier whose lead times were consistently worse than contracted.

The business analyst translated between my evaluation metrics and what planners cared about, and repeatedly told me a metric improvement wasn't one in practice. The data engineer built the feature pipeline and the retraining schedule, so I could iterate without owning the plumbing. Two senior planners reviewed early forecasts and their scepticism sharpened the design of the confidence bands more than any evaluation run did.