Checked on August 27, 2026.
AI demand forecasting estimates future demand by product, location, and time period so you can make decisions about purchasing, replenishment, production, and promotions. A project starts not with choosing a neural network, but with answering three questions: what are we forecasting, over what horizon, and which decision will change.
Sales do not always equal demand: when stock is zero, the system sees zero sales, even if customers wanted the item. That is why data quality for inventory, promotions, pricing, and availability is often more important than model complexity.
In brief: define SKU×location×day/week, the decision horizon, a simple baseline, and a rolling backtest. Evaluate bias, horizon-specific error, and decision cost. In production, store both the original forecast and any manual adjustment with the reason.
Contents
- How to define the problem
- What data you need
- Why sales are not the same as demand
- Baselines and models
- Time-based validation
- Hierarchy of SKUs, stores, and categories
- Quality and business metrics
- Uncertainty and safety stock
- Production architecture
- Manual adjustments and monitoring
- Pilot plan
- FAQ
- How AI Dawn implements demand forecasting
- Conclusion
How to define the problem
Granularity is determined by the decision:
| Decision | Target series | Horizon |
|---|---|---|
| store replenishment | SKU×location×day | lead time + ordering cycle |
| supplier purchasing | SKU/category×week | lead time and MOQ |
| production | product/line×week | production cycle |
| budget | category/region×month | financial period |
| staffing | flow/location×hour | shift schedule |
A single “company-wide demand model” rarely works for everyone. A monthly forecast may be good for finance, but useless for daily replenishment.
What data you need
Minimum layer:
- sales and returns;
- inventory and availability over time;
- prices and discounts;
- promotion and merchandising calendar;
- product and geographic hierarchy;
- store openings/closures;
- lead time, MOQ, and supplier calendar;
- known events and holidays.
Check for missing values, SKU changes, duplicates, time zones, and the update timestamp. A feature may be known today or only become available after the forecast date. The latter cannot be used in training: that is leakage.
Why sales are not the same as demand
If the item was out of stock, observed sales are limited by inventory. A model trained without an availability feature will lock in a low forecast exactly where there was a shortage.
Approaches:
- exclude stockout intervals from part of training;
- reconstruct censored demand from nearby locations/periods;
- use views/searches as a proxy with explicit labeling;
- model the probability of availability separately;
- store the reconstruction confidence.
No method can create true demand out of thin air. The report should separate observed sales and estimated lost demand.
Baselines and models
Start with seasonal naive: demand equals the equivalent prior period. Add a moving average or a simple exponential model. A complex ML system must consistently beat the baseline in a rolling backtest and on business cost.
Candidates:
- statistical ETS/ARIMA for stable series;
- gradient boosting with lags, calendar, price, and promotions;
- global models trained on many SKUs;
- probabilistic models for intervals and scenarios;
- ensembles of multiple forecasts.
The choice depends on history length, number of series, intermittency, features, and explainability requirements. There is no universal winner.
Time-based validation
Randomly shuffling rows is prohibited: the model will see the future. Use rolling forecasting origin — sequential windows where train is always earlier than test. Forecasting: Principles and Practice describes this kind of time-series cross-validation and evaluation at the required multi-step horizon.
The backtest should mirror production:
- the same features available on that date;
- the same horizon;
- the actual retraining frequency;
- a promo calendar known in advance;
- cold-start products;
- mode-switch periods.
Show the error by horizon: day +1 and day +28 are different tasks.
Hierarchy of SKUs, stores, and categories
Finance expects regions to roll up into the company, and categories into the overall plan. Independent forecasts may not reconcile. Hierarchical forecasting uses reconciliation so the levels stay aligned.
Retail often combines nested and crossed dimensions: product, category, store, region, channel. M5 competition became a well-known example of a large retail time-series hierarchy. But its results do not guarantee performance for your assortment.
Quality and business metrics
| Metric | Benefit | Limitation |
|---|---|---|
| MAE | clear absolute error | large SKUs dominate |
| WAPE | aggregated relative error | hides bias by group |
| MASE | comparison with naive | requires a correct baseline |
| Bias | systematic over/under forecast | does not show dispersion |
| Pinball loss | quantile quality | less intuitive for business users |
MAPE is unstable when demand is zero or very low. Always segment by ABC/XYZ, new items, promo, stockout, and horizon.
Business metrics: service level, write-offs, emergency transfers, frozen inventory, and the cost of error. A model may improve WAPE but hurt inventory if it systematically underforecasts important items.
Uncertainty and inventory
A point forecast is not a promise. Inventory decisions require intervals or quantiles. A higher service level selects a higher quantile, taking lead-time demand and supply variability into account.
Separate:
- demand uncertainty;
- supply uncertainty;
- business policy on service level;
- MOQ, pack-size, and shelf-life constraints.
AI provides the distribution, and the optimizer turns it into an order under approved rules.
Production architecture
ERP/POS/WMS → feature pipeline → forecast service → reconciliation → inventory optimizer → planner UI → ERP
Version the data snapshot, model, features, and forecast. Each record should include target date, horizon, created_at, and the predictors available at that moment. Otherwise, a backtest after an incident is not reproducible.
Do not let the forecast service create an order directly. A separate layer applies constraints, permissions, and approval.
Manual adjustments and monitoring
The planner knows about a local renovation, display change, or contract that is not in the data. Store the base forecast, override, reason, author, and final result. Compare performance before and after the override, but do not penalize justified rare events.
Monitor:
- error and bias by segment;
- feature drift and the share of Unknown;
- stockout intervals;
- override rate and value add;
- pipeline freshness;
- hierarchy reconciliation gaps;
- impact on orders and inventory.
Pilot plan
- Choose a category and one replenishment decision.
- Lock down the baseline, sources, constraints, and acceptance criteria.
- Rebuild historical snapshots without leakage.
- Build a seasonal naive model and a rolling backtest.
- Add ML and compare by segment and cost.
- Run a shadow forecast alongside the current plan.
- Connect a limited recommendation flow with approval.
FAQ
How much history do you need for demand forecasting?
It depends on seasonality and frequency. For short series, simple models, aggregation, and a global model across similar products are useful; complexity cannot replace missing history.
How do you forecast a new product?
Use analogs, attributes, price, channel, and launch scenarios, then update the forecast quickly based on the first sales. Do not copy the analog's history without adjustments.
Which metric matters most?
A set: error and bias by horizon/segment plus decision cost — stockout, inventory, write-off, and service level.
Do you need to account for promos?
Yes, but only promos known at the time of forecasting. Future actual performance cannot be mixed into the features.
Can AI automatically place an order?
After a mature pilot — in limited, low-risk segments and with guardrails. At the start, the model provides a recommendation, and the optimizer and planner apply the rules.
How AI Dawn implements demand forecasting
AI Dawn starts with one decision: it fixes the current metrics, data sources, constraints, and acceptance criteria. Then the team can:
- collect historical snapshots and eliminate leakage/stockout distortion;
- build a baseline, ML forecasts, hierarchy, and intervals;
- integrate recommendations with ERP/WMS and the planner interface;
- run a shadow pilot, monitoring, training, and handoff of procedures.
Bottom Line
Demand forecasting is part of the inventory decision, not a model competition. The right objective, a proper time-based backtest, stockout awareness, and a consistent hierarchy matter more than a trendy algorithm.
Start with one category and one time horizon. If the forecast beats a simple baseline, keeps bias under control, and improves the decision in shadow mode, you can gradually connect it to planning.