Demand Forecasting: Methods, Accuracy and Decisions

Demand forecasting is the practice of estimating how many units of a product customers will buy, at a given location, over a given future period. It is the number underneath a purchase order, a production run, a staffing roster and a safety-stock level, which is why an error in it propagates into every decision downstream of it.

Most of what gets written about demand forecasting is about algorithms. Almost none of what decides whether a forecast is any good is. The methods have been documented for fifty years and the useful ones are free in any statistics library. What separates a forecast that changes an order from one that fills a dashboard is the grain you forecast at, the data you feed it, the baseline you honestly compare it against, and whether the number ever reaches the system that raises the order.

This piece covers what demand forecasting is and how it differs from demand planning, the types and horizons it comes in, the methods ladder from a naive baseline through statistical models to machine learning, why the top of that ladder so often loses to the bottom, the data each level needs and at what grain, how accuracy gets measured and mismeasured, and how a forecast turns into an ordering decision.

The short version

• Demand forecasting estimates units per item per location per period. Demand planning is the process that turns that estimate into an agreed plan, and demand sensing is the short-horizon correction applied to it. The three get used interchangeably and are three different jobs.
• The methods ladder runs from naive baselines through exponential smoothing and ARIMA, then Croston for intermittent items, then gradient-boosted trees, then neural sequence models. Each rung has to beat the rung below it on your data, at your grain, or it does not ship.
• Simple beats sophisticated more often than vendors admit. A study of eight consumer and industrial businesses found 52% of their forecasts failed to beat a naive benchmark. In the M5 competition the winning machine-learning method beat the best statistical benchmark by 40% at the top of the hierarchy and by 3% at the product-store level, which is the level replenishment actually runs on.
• Granularity decides feasibility more than model choice does. SKU by location by day, 24 months deep, with true demand separated from shipments, is the realistic floor.
• The accuracy metric you pick changes which model looks best. MAPE breaks on low-volume items, WAPE holds up, and bias is a separate failure mode that a good error score will hide completely.
• Forecast value added is the only accuracy question worth asking: does this step in the process beat a naive baseline, at the grain where the decision is made?
• A forecast is not a decision. The order needs the distribution rather than the point estimate, plus a cost asymmetry, a service target, and a write-back path into the system that raises the order.

What demand forecasting is, and what it is not

Demand forecasting fits a model to historical demand so it can estimate a quantity for a period that has not happened yet. The output is three things joined together: an item, a location, and a period. Anything vaguer than that is a market opinion rather than a forecast, because you cannot place an order against it.

Three terms sit close enough together that vendor material treats them as synonyms, and they are not.

Demand forecasting produces the number. It is a statistics problem, and it is the only one of the three where you can do everything right and still be wrong, because the future is allowed to disagree with you.

Demand planning is the cross-functional process that turns the number into an agreed plan. Sales has a target, marketing has a calendar, finance has a budget, and the planning process reconciles them into one set of figures the business commits to. It is a governance problem, and it is where a good forecast most often goes to die.

Demand sensing is a short-horizon correction. It adjusts the next few weeks using downstream signals such as point-of-sale data, open orders or channel inventory, on the argument that recent reality beats a model fitted months ago. It solves a narrow problem well and is regularly sold as if it solved the whole one.

Why it matters is easiest to see by following the number rather than by listing benefits. The forecast sets how much stock sits in working capital, how much of that stock goes obsolete, how many customer orders get filled on schedule, how much capacity and labour get rostered, and what finance puts in next year's budget. Because it feeds all of those at once, it gets judged in several currencies that pull against each other: service level, working capital, write-offs and planner time. A forecasting change that lifts one and quietly wrecks another is not an improvement, which is the reason accuracy on its own makes a poor scorecard.

Demand forecasting is also the largest and most valuable application of predictive analytics in a supply chain, which is why the rest of that field borrows its machinery. Lead-time prediction, stockout risk scoring and supplier delay models all reuse the same pipeline, the same backtesting discipline and the same argument about baselines.

The commercial pressure behind all of it is real. Gartner expects 70% of large organizations to adopt AI-based supply chain forecasting by 2030, moving away from the traditional statistical engines most planning systems still run. The Business Continuity Institute's Supply Chain Resilience Report 2024 found that almost 80% of organizations had their supply chain disrupted in the preceding twelve months, with third-party failure the leading cause at 43.6%. When disruption is the normal weather, a plan built on last year's average stops being useful.

The types of demand forecasting, and which one you need

Four axes describe nearly every forecast anyone actually runs, and picking the wrong point on any of them wastes the model behind it.

Passive against active. Passive forecasting extrapolates history on the assumption that your commercial behaviour stays roughly as it was. Active forecasting models planned changes explicitly: a price move, a promotion, a new listing, a range cull. Passive is cheaper and honest for stable, low-intervention catalogs. Active is mandatory the moment your own actions are the largest driver of demand, which in promoted retail categories they usually are.

Short, medium and long horizon. Short-horizon forecasts, from days to a few months, drive replenishment and scheduling. Medium-horizon forecasts, a quarter to a year, drive production planning, capacity and hiring. Long-horizon forecasts, one to five years, drive capital investment and network design. They need different methods and tolerate very different errors, and the mistake is running one engine and reporting its output to all three audiences.

Macro against micro. Macro or aggregate forecasts sit at category, region or total-business level. Micro forecasts sit at SKU by location. The arithmetic here is unforgiving: errors cancel as you aggregate, so a macro forecast will always look more accurate than the micro forecast built from the same model, and only one of them can raise a purchase order.

Internal against external drivers. Internal forecasting uses your own transaction, promotion and pricing history. External forecasting adds weather, macroeconomic indicators, competitor pricing or search interest. External data is the first thing teams want to add and close to the last thing that helps, because internal data almost always still has unextracted signal in it.

The rule that ties the four together: the decision sets the horizon and the grain, not the model. If replenishment runs weekly at SKU by store, that is what you forecast and that is where you measure, however much better the numbers look one level up.

The demand forecasting process, step by step

Six steps, and they run as a repeating cycle rather than a project with an end date.

1. Define the decision. Name the recurring decision the forecast has to change, who makes it, and how often. That fixes the horizon and the grain before any method gets picked.
2. Assemble the history at that grain. Extract it, reconcile it across systems, and repair what is wrong with it, starting with whether it records demand or shipments.
3. Score a naive baseline. Run seasonal naive over the same history and horizon. That number is what everything you build afterwards has to beat, and without it nothing later can be judged.
4. Fit and select per segment. Choose methods by the shape of the data rather than by preference, and validate on a rolling-origin backtest at the decision grain.
5. Turn the forecast into a quantity. Add lead-time variability, a service target and the cost asymmetry between stocking out and overstocking, then write the resulting order into the system that executes it.
6. Record and feed back. Log what was recommended, what a human overrode and what actually happened, so the next cycle can score itself.

That is the cycle once it runs. Standing one up from nothing is a different sequence, covered at the end.

The demand forecasting methods ladder

There is no best demand forecasting method, and looking for one wastes more time in this field than any other single habit. What exists is a ladder, where each rung earns its place only by beating the rung below it on your data.

Rung zero: the naive baseline. Seasonal naive predicts that this week equals the same week last year. Simple naive predicts that next period equals this one. Both cost nothing, both run in a line of SQL, and both are the number every other method has to beat. If a proposed model cannot outperform seasonal naive on a proper backtest, it should not ship, whatever its architecture.

Rung one: classical statistical methods. Moving averages, exponential smoothing in the ETS family, Holt-Winters for series that trend and seasonally cycle at once, and ARIMA for long, regular histories. They use only the series' own past, they fit in seconds across tens of thousands of items, and they fail in ways a planner can explain in a meeting. On stable, fast-moving products they remain genuinely hard to beat.

Rung two: causal and econometric models. Where the driver is external and measurable, a regression relates demand to price, income, competitor activity or a leading indicator rather than to its own past. Econometric models are the standard tool in economics for exactly this, and the barometric approach, which forecasts from indicators that turn before demand does, belongs here too. They earn their keep on longer horizons and at category level, where a macro driver moves the whole series and the series' own history cannot see it coming.

Rung three: intermittent-demand methods. This one is a sideways step rather than an upgrade, taken because of a data shape. Croston's method, published in 1972, splits a lumpy series into demand size and the interval between demands and smooths each separately. The Syntetos-Boylan Approximation corrects the upward bias in the original by a factor of one minus half the smoothing parameter. This family exists because most real catalogs have a long tail that sells in unpredictable single units, and it is the case general-purpose forecasting tools handle worst.

Rung four: gradient-boosted trees. LightGBM and XGBoost are the workhorse when you have exogenous drivers and many correlated series. They ingest price, promotions, calendar effects and related-product behaviour that a univariate method cannot see, and they learn across series rather than fitting each one alone. Every one of the top 50 methods in the M5 competition used this cross-learning approach.

Rung five: neural sequence models. LSTM, N-BEATS and DeepAR earn their place at genuine volume with long, rich histories. Below that they are an expensive way to reproduce a simpler model's answer with worse interpretability and a harder conversation when a planner asks why the number moved.

Alongside the ladder sit the qualitative methods, and they are not a lower form of forecasting. The Delphi method, developed at RAND by Norman Dalkey and Olaf Helmer, runs anonymous expert rounds with controlled feedback until opinions converge. Sales force composite aggregates territory-level estimates from the people who talk to buyers. Jury of executive opinion collects senior management views, and market research surveys stated purchase intent. All four earn their place where history cannot help: a genuinely new product, a market entry, a structural break, a category nobody has sold into before. The failure is using them where history is available and abundant, because structured judgment is expensive and, as the accuracy section below shows, systematically optimistic.

That last row is not filler. The M5 winner did not find a superior algorithm. He built 220 LightGBM variants and forecast each series with an equal-weighted average of six of them, and the runner-up and third place used the same combining approach with different components. Averaging several decent models beats hunting for one excellent one, and it has beaten it in every M competition since the 1980s.

A worked demand forecasting example

The bottom three rungs are worth seeing as arithmetic, because the gap between them is smaller than the vocabulary suggests. Take eight weeks of demand for one SKU at one store: 120, 135, 110, 150, 130, 145, 160, 140.

Naive forecasts week 9 as last week's actual, so 140.

A three-week moving average takes the last three weeks: (145 + 160 + 140) / 3, so 148.

Simple exponential smoothing with a smoothing constant of 0.3 weights each new observation at 30% and carries 70% of the previous forecast forward. Started at the first actual and rolled through the series, it arrives at 141 for week 9.

Three methods, three answers within eight units of each other. That closeness is the point. On a stable series the sophisticated method is not buying you much, and the only way to know whether it is buying you anything is to score all three against the same actuals over many periods, which is what the accuracy section does next.

Why complex demand forecasting models lose to simple baselines

Start with the uncomfortable result. Steve Morlidge studied eight consumer and industrial businesses and found that 52% of their forecasts failed to beat a naive no-change benchmark, a figure reported in the Forecasting: theory and practice review published in the International Journal of Forecasting. More than half of the output of funded, staffed forecasting processes was worse than a rule that costs nothing to run. That is the baseline expectation you should carry into any vendor conversation.

The M5 competition is the cleanest public evidence on where sophistication does pay, and it is worth reading carefully rather than quoting selectively. The dataset was 42,840 Walmart series, 30,490 of them at the product-store level, forecast 28 days ahead by more than 5,500 teams.

Machine learning won, and it won decisively. The top method beat the best statistical benchmark by 22.4% overall, where the winners of the earlier M3 and M4 competitions had managed less than 10% over their benchmarks. Anyone claiming machine learning has nothing to offer demand forecasting is arguing against the evidence.

Then read where the win came from. The paper reports that average improvement over the benchmark was 40% at the top of the hierarchy, roughly 23% at the middle levels, and 3% at the product, product-state, and product-store levels. The authors state plainly that the gains "mainly refer to the top and middle parts of the hierarchies, and are rather limited" at the bottom.

The bottom is where replenishment happens. Nobody raises a purchase order at the national-total level.

It gets sharper. The winning team, best overall, ranked 13th, 12th, and 11th out of the top 50 at the three most granular levels. The runner-up ranked 48th, 49th, and 48th there. A method can be first in the competition and near the bottom of the field on the series you actually need.

None of this argues for avoiding machine learning in demand forecasting. It argues for three specific habits: benchmark at the level of the decision rather than at the level that flatters the number, keep a naive baseline running permanently as the thing to beat, and treat method selection as segment-by-segment rather than one winner for the whole catalog. The M5 authors call this "horses for courses," and the data backs them up.

A model that wins on the leaderboard and loses at SKU by store has not helped anyone. Replenishment runs at the bottom of the hierarchy, and that is where the benchmark belongs.

What data demand forecasting needs, and at what granularity

This is the section vendors skip, and it decides whether anything above applies to you. The rule: you need history at the grain the decision is made, over enough time to see the pattern repeat. The realistic floor looks like this.

Transaction history at SKU by location by day, 24 months deep. Two full seasonal cycles is the minimum for a model to tell seasonality apart from a one-off. Eighteen months works if seasonality is mild. Twelve months is guessing, because the model has seen every season exactly once and cannot know which parts repeat.

True demand, not shipments. The most damaging data problem in demand forecasting and the least discussed. Train on what you shipped and every historical stockout reads as a period of low demand. The model learns it, forecasts low, you order less, and you stock out again. The fix is unconstraining: flag periods where availability was limited and reconstruct what demand would have been. It matters more than the choice of algorithm.

A promotion and price calendar with dates and discount depth. Without it, a promotional spike gets absorbed into the seasonality estimate, and the model expects that spike again next year with no promotion behind it.

Lead times stored as a distribution, not an average. A supplier that delivers in 14 days plus or minus 1 and a supplier that averages 14 days but ranges from 7 to 30 need completely different buffers. Recording only the mean throws away the variance, which is precisely the quantity safety stock is calculated from.

Master data that survives change. SKU hierarchy, product lifecycle stage, and the mapping from a discontinued item to its replacement. Without the last one, a successor product looks like a brand-new item with no history, and a mature item looks like it fell off a cliff.

The M5 evidence supports putting external signals last. Adding promotion and event variables to an exponential smoothing model improved accuracy by 25.5% at the top of the hierarchy but turned negative at the most granular levels. More features is not monotonically better, and the granular levels are the ones that pay.

New items have no history, and pretending otherwise produces confident nonsense. Two approaches work: analog modeling, where the new SKU inherits a curve from similar items, and attribute-based modeling, where demand is predicted from product attributes rather than the item's own past.

How demand forecast accuracy is measured

Three numbers do almost all the work, and the differences between them are not academic.

MAPE (mean absolute percentage error) averages the absolute error as a percentage of actual demand. It is the default in most planning tools and the wrong default for a large share of demand data.

WAPE (weighted absolute percentage error) divides total absolute error by total actual demand. It weights every unit equally rather than every series equally, which matches how inventory cost behaves.

Bias (mean signed error) sums the errors with their signs intact. It answers a completely different question: not how big the misses are, but whether they lean.

MAPE has two documented problems that matter enormously in demand forecasting. It is infinite or undefined when the actual is zero, which happens constantly at SKU by store by day. And it puts a heavier penalty on one direction of error than the other: an over-forecast can only ever be 100% wrong relative to a small actual, while an under-forecast has no ceiling. That asymmetry means optimizing for MAPE quietly rewards forecasting low, which drives exactly the understocking the exercise was supposed to prevent. Hyndman and Athanasopoulos document both problems and recommend scaled errors instead.

WAPE sidesteps both. It stays defined as long as total demand across the aggregation is not zero, and because it weights by volume, a tiny erratic item cannot dominate the score the way it does under MAPE.

Two SKUs in one week make the divergence concrete. SKU A sold 1,000 units against a forecast of 900. SKU B sold 4 against a forecast of 8.

MAPE averages the two percentage errors and reports 55%. WAPE divides total absolute error by total demand, 104 over 1,004, and reports 10.4%. Bias sums the signed errors, minus 96 over 1,004, and reports that the forecast ran 9.6% low. Same two forecasts, three numbers, and the one most planning tools show by default is the one a four-unit item took hostage.

Bias is not an alternative to either. It is a separate check, and it is the one teams skip. A forecast can post a respectable WAPE and still run 8% high every single month, which shows up as steadily accumulating inventory that nobody attributes to the forecast because the accuracy report looks fine. Error size and error direction are independent failures, and only tracking one leaves the other invisible.

Why the wrong accuracy metric hides real demand forecasting failures

Three traps account for most of the accuracy reporting we see that is technically true and practically useless.

The metric determines the winner. In M5 the winning team was ranked first on the competition's weighted metric and 13th under a per-series rank comparison, while the runner-up dropped to 47th. The authors' reading is that the top methods optimized heavily for expensive, fast-moving products because that is what the scoring metric rewarded, at the cost of accuracy on everything else. If a vendor benchmark shows a model winning, the first question is which measure it was tuned against and whether that measure matches what your business pays for.

Aggregation inflates the number. Errors cancel when you add series together. The same forecast can report 8% error at category by month and 45% at SKU by store by week, and both figures are arithmetically correct. Any accuracy claim without a stated grain and horizon is uninterpretable. This is the most common way forecast performance gets reported flatteringly without anyone technically lying.

Absolute accuracy is the wrong question. The right one is whether the forecast beats a naive baseline on the same data, at the same grain, over the same period. That question has a name and a method, and it is the subject of the next section.

Forecast value added, and how to run it

Forecast value added measures the change in accuracy that a given step in your forecasting process produces, relative to a naive baseline. The concept comes from Michael Gilliland at SAS, and its usefulness is that it scores the process rather than the model. The statistical engine, the planner override, the consensus meeting and the executive adjustment each get their own line, and each one can come out negative.

The arithmetic is trivial. Run the naive baseline over the same history. Score every stage of your process at the same grain and horizon. Subtract. A stage that lowers error has added value. A stage that raises it has destroyed value, and the fix is to remove the stage rather than to improve it.

Those figures are illustrative, but the pattern they show is the common one, and it is why the exercise is uncomfortable enough that most organizations never run it. Morlidge's finding that 52% of forecasts across eight businesses failed to beat the naive benchmark is the same result seen from the other end: a majority of forecasting effort, measured properly, produces a worse answer than doing nothing clever at all.

Run this once a quarter, publish it, and two things follow. Stages that destroy value get cut, which frees planner time. And the argument about whether to buy a more sophisticated engine becomes a measurement rather than a debate.

When demand planner overrides help and when they hurt

Human adjustment of a statistical forecast is the single most common step in demand planning, and it has been studied properly. Robert Fildes, Paul Goodwin, Michael Lawrence and Konstantinos Nikolopoulos collected more than 60,000 forecasts and outcomes from four supply-chain companies and compared the system forecast against the planner-adjusted one.

In three of the four companies, adjustments raised accuracy on average. That result is worth stating first, because the fashionable position is that planners only make things worse and the data does not support it.

The detail is where the operating rules come from. Larger adjustments produced greater average improvements, while the smaller adjustments often damaged accuracy. Reflexive tinkering with a number that was already close is where the damage is done, not the occasional big correction based on something the model genuinely could not see. And upward adjustments were much less likely to improve accuracy than downward ones, and were made in the wrong direction more often, which the authors read as a general bias toward optimism.

Four rules fall out of that, and they cost nothing to implement:

1. Record every override with the reason, the size, and the direction, in the system rather than in an email.
2. Suppress small adjustments. Set a threshold below which the system simply does not accept a change, because those are the ones that measurably lose money.
3. Hold upward moves to a higher bar than downward ones, since that is where the optimism lives.
4. Score overrides with forecast value added, by segment and by planner, and feed the result back to the people making them.

Backtesting a demand forecast before it ships

One methodological point undoes a lot of otherwise careful work. A random train-test split is invalid on time series, because it lets the model learn from data that comes after what it is predicting. The result looks excellent in validation and collapses in production.

The correct approach is rolling-origin evaluation, sometimes called walk-forward validation. Fit on data up to a cutoff, forecast the next H periods, score, move the cutoff forward, repeat. Two details matter: H must equal the real planning horizon, so a model used for four-week-ahead planning is validated four weeks ahead rather than one day ahead, and the same seasonal naive baseline runs through the identical procedure so the comparison is fair.

The M5 organizers noted that a significant number of teams failed to pick their own best submission from what they had produced, because their validation strategy did not predict which model would generalize. If that happens to teams competing for prize money, it happens to internal projects with less scrutiny.

From demand forecast to ordering decision

Everything above produces a number. A number is not a decision, and the gap between them is where most demand forecasting programs quietly stall as a dashboard nobody opens.

Step one: stop using the point forecast. Expected demand is the least useful part of the output for an inventory decision. What you need is the distribution, because the buffer protects against the tail, not against the average. A forecast of 100 units with a standard deviation of 10 and a forecast of 100 units with a standard deviation of 60 call for completely different stock positions, and a point estimate cannot tell them apart.

Step two: state the cost asymmetry. Stocking out and overstocking do not cost the same, and the ratio between them sets the service level you should target. A high-margin item with a cheap warehouse and a loyal customer who will not wait justifies a very high service level. A low-margin item that goes obsolete in a season does not. Applying one blanket service target across a whole catalog is the default in most systems and it is wrong in both directions at once.

Step three: do the arithmetic that turns a distribution into a quantity. The chain is mechanical once the pieces exist: forecast demand over the lead time, combine demand variability with lead-time variability into the standard deviation of demand over that lead time, convert the target service level into a z-factor, multiply to get safety stock, add expected lead-time demand to get the reorder point. This is the point where a lead-time distribution stops being a data-hygiene nicety and becomes a term in the formula.

Step four: decide what executes without a human. Fast-moving, low-value, stable items can replenish automatically because reviewing each one is impossible at volume and the cost of any single error is small. Erratic, high-value, or newly launched items go to a planner as ranked exceptions with the reason attached. Gartner expects 60% of supply chain disruptions to be resolved without human intervention by 2031, while also noting that autonomous planning has passed its peak of inflated expectations. Both things are true, and the honest position is to automate the segments where being wrong is cheap and keep judgment where it is not.

Step five: write the decision back. The recommended order has to land in the ERP, the WMS, or the TMS as an actual document, idempotently, with an audit trail. A forecast that stops at a dashboard requires a human to retype it into the system that matters, and that human will not do it consistently. This is the step that separates a project with measurable return from one with an impressive demo, and it is the step most analytics vendors leave to you because it touches systems they do not own. It is also the least glamorous part of any AI integration engagement and reliably the one that decides whether the rest was worth doing.

1. Forecast distribution over the lead time, not a single number
2. Lead-time distribution per supplier and lane, combined with demand variability
3. Service target set per segment from the cost of stockout against the cost of holding
4. Safety stock from the combined variability and the service target
5. Reorder point as expected lead-time demand plus safety stock
6. Order raised in the ERP, or routed to a planner as an exception
7. Outcome recorded and fed back so the next cycle scores itself

The last step closes the loop. Without recording what the system recommended, what a human overrode, and what happened, nobody can tell whether the model is improving or whether the planners have quietly stopped trusting it.

Predictive analytics in a supply chain: where else the same machinery applies

Demand forecasting is the anchor use case for predictive analytics in a supply chain, and once its pipeline exists, several neighbouring problems reuse it: the same history extraction, the same rolling-origin backtest, the same argument about baselines, pointed at a different target variable. Analytics in a supply chain is often drawn as a ladder, with descriptive reporting saying what happened, diagnostics saying why, prediction saying what comes next, and prescriptive optimization saying what to do. Demand forecasting sits on the third rung and feeds the fourth, though a working operation runs all four at once on different problems rather than occupying one rung.

Lead-time prediction is quietly the highest return per unit of effort. Most planning systems treat supplier lead time as a fixed number somebody typed in years ago. Predicting it per supplier, per lane, per season, and treating it as a distribution, directly improves safety stock, because lead-time variability enters the formula alongside demand variability. Plenty of teams go hunting for a better demand model while a stale lead-time field two tables over is the thing costing them money.

Stockout and excess risk reframes forecasting as classification. Instead of a quantity, predict the probability that an item at a location breaches its floor or its ceiling in the next N days. Planners find this easier to act on than a number with a confidence interval, and the output is a ranked worklist rather than a table.

Supplier delay prediction scores an inbound shipment on how likely it is to miss its promised date, using supplier history, lane, mode, season, and transit events. On the supply chain visibility side, this is where carrier EDI status messages stop being a tracking screen and become a feature set.

Predictive maintenance on fleet and equipment predicts component failure from telematics, sensor readings, and work-order history. It is genuinely a different discipline, and we cover the mechanics separately in how predictive maintenance software works.

Returns forecasting predicts what comes back, when, and in what condition. Most planning tools serve it badly, and where return rates run high, an unmodeled return stream makes every inventory position wrong in a direction nobody is watching.

Notice how different the grains are. A demand model and a maintenance model share almost nothing operationally, which is why "we are doing predictive analytics" is not a project and each of these is.

Demand forecasting tools, and how to choose one

Three options cover the field, and the choice is usually settled by where your data lives rather than by feature lists.

The forecasting engine inside your ERP or planning suite. Every serious planning platform ships one, typically exponential smoothing with some seasonality handling. It is already integrated, which is worth more than most people credit, and it is often the incumbent your new model has to beat. Our piece on supply chain planning software covers what these engines do and where their limits sit.

A specialist demand planning product. Stronger models, promotion handling, hierarchy reconciliation and a planner workbench, at the cost of another integration and a licence that scales with your catalog.

A model you own, on your own data platform. Open libraries make the modeling itself cheap. What you are buying with a build is control over the segmentation, the baseline comparison and the write-back path, which is exactly where the off-the-shelf options tend to be rigid.

Whichever route, apply one test before signing anything: ask the vendor to run their forecast against a seasonal naive baseline on your data, at your grain, over your horizon. A vendor who will not do that has told you something.

Where demand forecasting breaks in production

Four failure modes account for most of what goes wrong after go-live.

Drift. A competitor enters, a category changes shape, and a model fitted on the old world degrades without announcing it. Monitor accuracy continuously against the same baseline, alert when the gap narrows, and set a retraining cadence deliberately rather than leaving it to whoever remembers.

Silent input failures. A feed changes format, a promotion calendar stops updating, a store code is retired. The model keeps producing plausible numbers from broken inputs, which is more dangerous than an outright failure. Validate on ingest, where it is cheapest to catch. That is the discipline we built into HaulBreeze, where bulk imports are checked on entry so bad rows never reach the data layer.

Infrastructure cost that scales the wrong way. One model over a whole catalog and one model per SKU produce very different bills. Thousands of per-item models sound thorough and become an operational burden nobody scoped. Cross-learning is usually both cheaper and more accurate.

Loss of trust. A planner overrides the system a few times, the overrides go unrecorded, and within a quarter the model is decorative. Track override rates by segment. A rising rate is the earliest reliable signal that something is wrong, and it shows up before any accuracy metric moves.

How to start with demand forecasting

The cycle above describes a forecasting process that already runs. Building one from nothing is a different sequence, and this is the order we run it in.

Audit the data at the grain the decision needs. Not "do we have sales history" but "do we have 24 months at SKU by location by day, and is it demand or shipments." This usually takes a week and usually reveals the real project.

Score the baseline before anyone writes a model. Seasonal naive over a rolling-origin backtest at the decision grain. Given how often funded processes fail to clear that bar, treat clearing it as the first milestone rather than a formality.

Ship one segment, not the catalog. One product family, one region, one supplier group. Prove the forecast beats the baseline and that the decision downstream actually changes.

Wire the write-back early, while the scope is still small. Teams that leave integration for last meet the hardest part with the least time left.

Then widen. Add segments and exogenous features, escalate to bigger models where measured accuracy justifies it. Every expansion earns its place against the baseline.

McKinsey found that early adopters of AI-enabled supply chain management improved logistics costs by 15%, inventory levels by 35%, and service levels by 65% relative to slower-moving competitors. Those outcomes belong to organizations that got the demand forecasting data and the decision loop right, not to organizations that bought the most sophisticated model. The M5 authors make a related point from the opposite direction: translating a forecast error reduction into a cost saving is "far from trivial," because it depends entirely on holding costs, replenishment policy, and network structure. The prediction is the easy half.

Demand forecasting rewards the boring parts. Separate demand history from shipment history, keep a naive baseline permanently in the comparison, measure at the grain where the order is raised, score every step of the process against that baseline, and write the answer back into the system that acts on it. Do that and a modest model will outperform a sophisticated one nobody trusts. This article sits inside our broader guide to AI in supply chain, and the neighbouring pieces on supply chain planning software and logistics management software cover the systems this forecast plugs into.

We build these systems rather than write about them. HaulBreeze is our own supply chain platform, built on a single data layer so inventory and orders never disagree, and Conveya is a transportation management rebuild running real-time shipment tracking in production. Both came out of our logistics and supply chain practice, and both taught us the same lesson this article is built on: the model is rarely the hard part.