Match a job Paths Subjects Questions Quizzes Pricing

Case Study: Demand Forecasting for Retail & Logistics

SKU×store quantile forecasts that feed inventory decisions, reconciled across a hierarchy

Overview Read

Case Study: Demand Forecasting for Retail & Logistics

"We sell 50,000 products through 500 stores and replenish every week. Design the forecasting system that drives the orders" is a staple of retail, grocery, marketplace-logistics and supply-chain interviews. The trap is to answer with a model name. The real question is a decision under uncertainty: how many units of each SKU should each store hold for the next 9 days, given that holding too much costs money and holding too little loses sales you will never see.

This subject is a model answer. It applies theory taught elsewhere instead of re-teaching it: global models, probabilistic forecasts, hierarchies and the forecast-value-added idea come from Forecasting at Scale: Global, Probabilistic & Hierarchical Models; seasonality, stationarity and the baselines from Time Series Fundamentals; coverage and calibration from Uncertainty Quantification & Conformal Prediction; input-side anomaly checks from Anomaly Detection for Tabular Data & Time Series; partial pooling for new items from Bayesian Statistics for Data Scientists; promo and price effects from Pricing Optimization & Marketplace Economics; and the point-in-time feature discipline from ML Data Pipelines & Feature Stores. Notation follows the forecasting lesson: y_t is observed sales, d_t is true demand, \hat y_{t+h\mid t} is a forecast made at origin t for h days ahead.

Every number below is from a synthetic panel (200 SKUs by 20 stores = 4,000 series, 1,100 days, fixed seed, Python with NumPy, LightGBM, statsforecast), not from a company. The simulator keeps the true demand, so it can answer questions real data cannot, such as how biased a model is against the demand that was never recorded. Treat the figures as mechanics and relative sizes, not benchmarks, and expect real data to be noisier. Each script is named at the point of use and can be re-run.


Step 1 — Requirements and the Decision Behind the Forecast

Questions to ask. What decision consumes the forecast (a weekly order for each SKU and store)? What is the review period and supplier lead time? Is stock perishable? Are forecasts used by humans (a planner can override) or only by an automatic replenishment engine? What is the cost of a lost sale versus a unit left over? Is there a trusted record of stock on hand at the start of each day, so stockouts can be identified?

Assumptions to state.

Quantity Assumption
Grid 50,000 SKUs by 500 stores = 25 million possible series; assume a store carries about 35 percent of the assortment, so about 8.75 million active series (an assumption to challenge)
Output Daily forecast for 28 days: a mean and quantiles per series-day, plus a quantile of the 9-day lead-time demand
Decision Weekly review, 2-day supplier lead time, so each order must cover a protection interval of 7 + 2 = 9 days
Freshness Nightly batch finishing before planners start at 06:00; planner UI reads a serving table in about 200 ms; overrides are logged
Hierarchy SKU by store at the bottom, rolled up to store, SKU, region and total; every roll-up must add up
Success Business: cost of lost margin plus waste or holding at a target service level. Model: bias, WAPE, pinball loss and coverage, judged against a seasonal-naive baseline

The framing sentence. "A point forecast is the wrong output. Replenishment needs the quantile of lead-time demand that balances the cost of running out against the cost of holding a unit, so I will build calibrated quantiles, check them against realised stockouts and leftovers, and treat WAPE as a diagnostic, not the goal."

Scale in one line. 25 million possible series by 28 horizons is 700 million forecast rows a night at the full grid. Step 9 turns that into compute and storage arithmetic.


Pro content

Sign up free, then start a 14-day Pro trial — no card needed.

We use cookies for product analytics to improve OmniAtlas. See our Privacy Policy.