Demand forecasting with machine learning: a practical guide
What should you know about demand forecasting machine learning?
Forecasting models trained on sales, seasonality and promotions feed purchasing and replenishment, monitored for drift every season. Demand forecasting machine learning works when the forecast matches the grain of the decision, is validated on time, and is judged by the stock-outs and overstock it prevents.
Demand forecasting machine learning is one of the oldest and most reliable uses of ML in business, and one of the easiest to get subtly wrong. The model is rarely the problem. The problems are forecasting at the wrong level, validating on the wrong split, ignoring the promotions calendar, and treating a forecast as a number rather than a range. This guide covers how to define the forecast so purchasing and replenishment can use it, which models are worth considering, how to validate on time, and what monitoring looks like once the forecast is feeding real orders.
Start from the decision, not the data
A forecast exists to drive a decision: how much to order, when to reorder, how much to make, how many people to roster. Each decision has a grain (product by store by week, or SKU by warehouse by day), a horizon (next week, next quarter), and a cost of being wrong in each direction. Define those three things first. A model that forecasts national weekly demand beautifully is useless for a store manager deciding tomorrow's order, and a daily SKU-level forecast for slow sellers is mostly noise. The grain and horizon of the decision set the grain and horizon of the forecast.
Which forecasting approach fits
| Approach | Best for | Strength | Limitation |
|---|---|---|---|
| Moving averages and exponential smoothing | Stable products, short horizons, a baseline | Simple, transparent, hard to beat on slow movers | Ignores promotions, prices and external drivers |
| Statistical time series (seasonal ARIMA, ETS) | Products with clear seasonality and long history | Handles trend and season with few parameters | One model per series; struggles with many short or sparse series |
| Gradient-boosted trees on engineered features | Large catalogues with promotions, prices, calendar and store effects | One global model learns across products; handles drivers and new items | Needs feature engineering and careful validation on time |
| Neural sequence models | Very large catalogues with rich histories | Learns patterns across series automatically | Data-hungry, harder to explain, more infrastructure |
| Hierarchical reconciliation | Forecasts needed at several levels (SKU, category, region) | Makes levels add up | An extra step on top of any base model |
For most retailers, distributors and manufacturers we work with, a global gradient-boosted model on well-engineered features is the practical choice, with a simple statistical baseline kept alongside to prove it is earning its keep. The scikit-learn documentation covers the fundamentals and XGBoost is a common implementation; the important work is in the features and the validation, not the library.
The inputs that make ML forecasting retail work
Sales history, cleaned for what it hides
Sales are not demand. A product that sold zero last week because it was out of stock did not have zero demand. Correcting for stock-outs, either by flagging them as missing or by estimating lost sales, is the single most important cleaning step. Returns, cancellations and inter-store transfers also need consistent treatment.
Calendar and seasonality
Day of week, month, festivals (which move on the calendar in India and need a lookup table), school holidays, paydays and the local events that matter for your category. Weather helps for some categories and is noise for others; test it rather than assume.
Promotions and price
A forecast that does not know a promotion is coming will under-forecast the promotion and over-forecast the week after. The promotions calendar, the discount depth, the display placement and the price relative to competitors are features, and they must be available for the future periods being forecast, not just the past. This is where most forecasting projects stall, because the promotions plan lives in a spreadsheet nobody wants to integrate. Integrate it.
Product attributes for new items
Category, brand, price band, size and any attribute that lets the model borrow from similar products. This is what allows a forecast for a new SKU with no history, the forecasting equivalent of the cold-start problem.
Validate on time, or the accuracy is fiction
Random train-test splits leak the future into training and produce accuracy numbers that vanish in production. Forecasting must be validated with a rolling origin: train on data up to a date, forecast the next horizon, roll forward, repeat across at least a year so every season is tested. Report accuracy per grain and horizon, and report it against the simple baseline. The metric should reflect the decision: for replenishment, the cost of stock-outs and overstock weighted by margin and holding cost is more useful than a symmetric percentage error that treats an under-forecast on a high-margin item the same as an over-forecast on a cheap one. The mechanics of leakage are covered in data leakage: the silent killer of ML projects.
Forecast ranges, not points
Purchasing decisions depend on uncertainty. A product with a forecast of a hundred units and a tight range needs a different safety stock from one with the same forecast and a wide range. Produce prediction intervals, or quantile forecasts, and let the replenishment logic use the quantile that matches the service level for that product. A point forecast forces the planner to guess the uncertainty, and they will guess it the same for everything.
Inventory forecasting AI in production: drift and monitoring
A forecast degrades. Assortments change, a competitor opens nearby, a channel shifts from store to online, a category's seasonality moves. Monitoring compares forecast with actuals every period, by grain, and raises a flag when error rises above what rolling validation predicted. Retraining runs on a schedule, typically monthly, and additionally when drift is detected. Every season is a test: the model that was right last winter must be checked against this one before its output is trusted for the season's buys. Monitoring and retraining infrastructure for a mid-size company is covered in MLOps for mid-size companies.
Feeding purchasing and replenishment
A forecast nobody uses has no value. The output must land where the decision is made: the ERP's replenishment module, the purchasing team's planning sheet, the production scheduler. That is integration work, and it includes the planner's override. Planners know things the model does not, such as a supplier problem or a marketing launch, and the system should record overrides, apply them, and later compare the override with the model to learn which was right. Over time this builds trust in both directions. Where the ERP is old, exposing a forecast into it is the kind of targeted change we make under legacy-to-AI modernisation rather than a rewrite.
A worked example
A retail chain with several hundred stores and a large seasonal catalogue was replenishing from a planner's spreadsheet built on last year's sales plus judgement. Stock-outs on promoted lines and overstock after festivals were both routine. We defined the forecast at product by store by week over a six-week horizon, because that was the replenishment cycle. Sales history was corrected for stock-outs using inventory records, the festival calendar was tabulated, and the promotions plan was integrated from the marketing team's system, which took longer than the modelling. A global gradient-boosted model with quantile outputs was validated by rolling origin across a full year against a seasonal-smoothing baseline, and it beat the baseline most clearly on promoted and seasonal lines, which was where the money was. The forecast was written into the ERP's replenishment screen with an override field, and monitoring compared forecast with actuals weekly. The planners' overrides were recorded and reviewed monthly. The engagement was scoped under AI/ML development, with integration work of the kind described on the retail industry page.
Team and timeline
A forecasting build needs a data scientist for features, models and validation, a data engineer for the sales, inventory and promotions pipelines, an integration engineer for the ERP or planning tool, and a planning owner on the client side who defines the decision and reviews overrides. A first production forecast at one grain takes eight to twelve weeks, most of it data and integration. It is delivered under AI/ML development, from $17,500 / ₹11.2L; a ProofRun POC sprint at $6,250–10,500 will validate on your own history against a baseline in three weeks before you commit. Monthly retraining and drift monitoring sit under a Care Plan; see the pricing page.
Before you start: a checklist
- Write down the decision the forecast drives, with its grain, horizon and the cost of error in each direction
- Confirm inventory records exist so stock-outs can be corrected in the sales history
- Locate the promotions calendar and confirm future promotions can be supplied to the model
- Build a festival and events lookup table for your markets
- Agree the baseline the model must beat
- Plan rolling-origin validation across at least one full year
- Decide where the forecast lands and how planners override it
- Set the retraining schedule and the drift threshold that triggers an early retrain
Glossary
- Grain: the level at which the forecast is produced, such as SKU by store by week
- Horizon: how far ahead the forecast reaches
- Rolling-origin validation: testing by training up to a date, forecasting ahead, and rolling forward repeatedly
- Global model: one model trained across all products rather than one per series
- Quantile forecast: a forecast of a range, giving the value below which demand falls with a chosen probability
- Drift: a change in demand patterns that makes a trained model less accurate
- Hierarchical reconciliation: adjusting forecasts so SKU, category and region levels add up
Related reading
See LLM or ML: choosing the right tool for why forecasting is a classical ML problem, and the dispatch platform for a logistics operator for an example of operational data feeding daily decisions. Programme prices are on the pricing page.
Forecast at the grain of the decision, validate on time, ship ranges, and check the model every season; that is the whole discipline.
Frequently asked questions
What data do you need for demand forecasting with machine learning?
▾
Sales history corrected for stock-outs, inventory records, a calendar of festivals and events, the promotions and price plan for past and future periods, and product attributes so new items can borrow from similar ones.
How accurate is ML demand prediction?
▾
It depends on the grain, horizon and category, which is why accuracy must be reported per grain against a simple baseline using rolling-origin validation across a full year. Any single headline accuracy figure without that context is not meaningful.
How often should a demand forecasting model be retrained?
▾
Monthly on a schedule, and earlier when monitoring shows error rising above what validation predicted. Every season is a fresh test. A Care Plan under AI/ML development covers retraining and drift alerts.