AI Demand Forecasting Workflow: Data In, SKU-Level Forecasts Out

What AI demand forecasting actually changes

Classical forecasting fits a curve to each product's history: moving averages, exponential smoothing, ARIMA. It is fast and understandable and it is what most planning tools still do by default. Its limit is that it only knows the past of one series. It cannot know that the promotion calendar has a 2-for-1 next month, that the price went up last week, that it will be 35°C in the stores that sell fans, or that a competitor is out of stock.

Machine-learning forecasting — gradient-boosted trees over engineered features, or more recently foundation time-series models pre-trained on millions of series — learns across all your SKUs at once and takes those external signals as inputs. The M5 forecasting competition (Walmart data, 42,840 series) is the best public benchmark: the winning approaches were all gradient-boosted models with rich feature sets, and they beat the best classical benchmarks by a wide margin at the aggregate level while being roughly comparable on very intermittent SKUs. That pattern holds in practice: the gain is largest on high-volume, promotion-driven items and smallest on slow, erratic ones.

The “AI” in the workflow above is therefore mostly the ML model. The language-model agent has one job — explaining — because that is the part planners actually struggle with. A forecast that moved 40% with no reason attached gets overridden; the same forecast with “promotion week 34, last comparable promo lifted units 3.1×” gets trusted.

How accurate is it, and how to measure that honestly

Use weighted absolute percentage error (WAPE, sometimes written MAD/mean ratio) rather than plain MAPE. MAPE explodes on low-volume weeks and rewards under-forecasting; WAPE weights each SKU by its volume so the number reflects the business impact. Report it by segment — top 20% of SKUs by revenue, promoted vs non-promoted, new vs established — because a single site-wide number hides where the model is weak.

Two more metrics belong on the scorecard. Bias (signed error) tells you whether you are systematically over- or under-forecasting, which is what drives inventory cost. Forecast value added compares the model to a naive baseline (last year same week, or a 13-week moving average) and to the planners' overrides; if a step in the process does not reduce error, remove it.

Realistic expectations: against a spreadsheet or naive baseline, well-implemented ML forecasting typically cuts WAPE by 20–35% on the fast-moving half of the range in the first quarter, less on the tail. The inventory effect follows: safety stock is set from forecast error, so a third less error is a third less safety stock at the same service level.

Worked example: 800 SKUs, 12 locations, weekly

A mid-size distributor with 800 SKUs across 12 branches has 9,600 SKU-locations and three years of weekly history — about 1.5 million rows, small by ML standards. The workflow assembles the feature table Sunday night (sales, price, promo flag, holiday, regional temperature, web sessions for the 200 products with product pages) and calls a LightGBM endpoint that was trained once on the history and is retrained monthly.

Output: 9,600 × 13 weeks of p10/p50/p90 forecasts written to the forecast table. The replenishment sheet reads p50 for the order quantity and the p90–p50 gap for safety stock. Monday's Slack post lists last week's WAPE (say 28% overall, 19% on the A items), the bias (+3%, slightly over-forecasting), and the 20 biggest movers with one line each. The planner spends an hour on those 20 instead of a day on 800.

Implementation sequence

Week one: get the history out and clean, and compute the naive baseline's WAPE — that number is what you have to beat and most teams have never measured it. Week two: connect the signals that exist (promotions and price are usually enough to start; weather and web traffic come later). Week three: run the model in shadow mode next to the current process and score both. Week four: switch replenishment for the A items to the model, keep the rest on the old process, and expand as the scorecard justifies.

Do not start with a custom model. A hosted API (TimeGPT, or a Chronos endpoint) with your history gives you 80% of the gain in days; train your own only when you have a specific reason — proprietary signals, unusual seasonality, or data-residency constraints.

Where it goes wrong

Stockouts read as zero demand. If a SKU was out of stock for three weeks, the history says nobody wanted it; the model learns that and forecasts low, which causes the next stockout. The clean step has to mark those weeks as censored, using the inventory position, and either impute or exclude them.

New products with no history. The model cannot forecast what it has never seen; use analog products (same category, same price band) for the first 8–12 weeks and let the actuals take over. The workflow needs an explicit new-product path or those SKUs get nonsense.

Planner overrides that are never scored. Overrides feel like control, but unscored they are just noise. Store them, score them against the model monthly, and show planners the result; most teams find overrides help on promotions and hurt everywhere else.