Blueprint · Reference Scenario
Retail Demand Forecasting
Per-SKU, per-store demand forecasts feeding replenishment — promo-aware, cold-start-capable, and backtested before anyone trusts it.
01 · PROBLEM
Replenishment runs on gut feel and spreadsheets
Buyers set orders from experience, last-year sales, and spreadsheet models that ignore promotions, cannibalization, and new-SKU cold starts. The result is the classic retail scissors: stockouts on winners, markdowns on losers, and working capital trapped on shelves.
This blueprint describes a forecasting system that produces daily, SKU × store demand forecasts consumed directly by replenishment — with promo effects modeled explicitly, new SKUs handled by hierarchy priors, and every forecast version backtested before promotion.
02 · SCALE
Illustrative scale (scenario assumptions)
- Catalog
- ~50,000 active SKUs across ~800 stores → ~40M SKU-store combinations
- Cadence
- Daily forecasts, 8-week horizon, refreshed overnight
- History
- 3 years of POS history; promo calendar 6 months forward
- Freshness SLA
- Forecasts available by 5 AM local before replenishment runs
- Consumers
- Replenishment engine, labor planning, promo planning
03 · CONSTRAINTS
What the design had to respect
- Promo-driven demand: a large share of volume moves on promotion; a model that can't separate base from promo lift is useless.
- Cold starts: hundreds of new SKUs per season with no history.
- Planner trust: buyers override forecasts; overrides must be logged and measured, not fought.
- Batch economics: 40M combinations nightly rules out per-combination heavy models; segmentation is mandatory.
- Existing stack: ERP remains the system of record; the forecast system proposes, ERP disposes.
04 · ARCHITECTURE
System design
POS, ERP, and external signals land in a feature store (lags, rolling statistics, promo flags, calendar features). Models train per product segment on walk-forward backtests; a registry manages champion/challenger versions. Batch inference writes forecasts the replenishment API consumes; monitoring tracks error drift and triggers retraining. Planner overrides flow back as labeled data — the system learns from being corrected.
05 · DECISIONS
Key tradeoffs
| Decision | Chosen | Why |
|---|---|---|
| Model family | Gradient boosting per segment, not one global deep model | Interpretable, fast to retrain, and segments match how buyers think; deep models didn't beat GBM on backtests enough to justify ops cost |
| Promo handling | Explicit promo features + separate lift estimation | Buyers plan promos; the model must answer "what if we promote?" — black-box models can't |
| Cold start | Hierarchy priors (category/store-cluster averages), then blend to actuals | No history is a data problem, not a modeling problem; priors shrink gracefully as data arrives |
| Serving | Nightly batch, not real-time API | Replenishment decides once daily; batch is 10× cheaper and simpler to monitor |
| Overrides | Logged, measured, fed back — never blocked | Blocking overrides kills adoption; measuring them turns planners into labelers |
06 · IMPLEMENTATION
Phased delivery
07 · SECURITY & GOVERNANCE
Controls
- POS data is PCI-adjacent: tokenize payment-adjacent fields before they enter the feature store; analysts work on aggregates.
- Model versions, training data snapshots, and promo calendars are versioned together — every forecast is reproducible.
- Override audit: who changed what forecast, when, and whether the override helped (measured, reported).
- Access: planners see their categories; data scientists see features, not raw POS.
08 · RESULTS
Success criteria (illustrative targets, not achieved outcomes)
- Forecast error (WAPE) beats the seasonal-naive baseline by a statistically significant margin on walk-forward backtests before any live rollout.
- Promo-lift estimates within agreed tolerance on holdout promotions.
- Override rate declines over the pilot as planner trust builds — overrides are the adoption metric.
- Stockout and markdown rates move in the right direction versus control categories.
These are acceptance thresholds for the scenario design. We publish measured client outcomes only with permission — which is why this page carries the reference-scenario label.
09 · LESSONS LEARNED
What generalizes
- The backtest harness is the product. Teams that skip rigorous walk-forward evaluation argue about models forever; teams that build it converge fast.
- Promo modeling is a business conversation, not a feature. The promo calendar's accuracy bounds forecast accuracy — fix the calendar feed before tuning models.
- Overrides are labels. The planners correcting your model are doing free labeling work; design for it instead of resenting it.
- Segment before you scale. One global model is elegant and wrong; segments match the business's mental model and parallelize training.
10 · TECHNOLOGIES
11 · RELATED
Lakehouse pattern
The data foundation this forecasting platform assumes: one governed copy, bronze → silver → gold.
Read pattern →Engineering
Our practice for ML platforms, feature stores, and production data systems.
Explore practice →SaaS CDC Lakehouse
The companion reference blueprint: streaming ingestion into a medallion lakehouse.
Read blueprint →Start here
Talk to an Architect
Bring your hardest AI, data, or modernization problem. We'll tell you plainly whether we can help — and what it takes.