How to forecast demand

demand forecasting is time series forecasting applied to a specific, expensive decision: how much to buy, make, staff or stock before you actually know what will sell. Get it wrong high and you've tied up cash in inventory that sits or spoils; get it wrong low and you've lost sales and, often, the customer along with them. The two failure modes are asymmetric in cost, which matters more to how you should build and judge a forecast than which specific algorithm you pick.

Start with a baseline worth beating

Before reaching for a sophisticated model, compute the two or three simplest forecasts possible and treat them as the bar everything else has to clear:

• Naive: next period equals this period.
• Seasonal naive: next period equals the same period last cycle (last week, same week last year).
• Moving average: the mean of the last N periods.

These take minutes to build and are frequently competitive with far more complex models on short, noisy series. If a machine-learning model can't beat seasonal naive on your actual data, the extra complexity isn't earning its keep, and you should say so rather than shipping the fancier model because it feels more rigorous.

Seasonality is usually the thing that matters most

seasonality — a repeating pattern tied to the calendar (weekly, monthly, yearly) — dominates the accuracy of most demand forecasts more than the choice of algorithm does. Getting it right means correctly identifying every repeating cycle that actually applies (day-of-week retail patterns, monthly billing cycles, annual holiday spikes) and being honest about cycles that look seasonal but aren't reliably repeating (a one-off promotion, a competitor's stockout that temporarily shifted demand to you). A model fit on eighteen months of data literally cannot have learned an annual pattern properly — it has seen the peak once. Know how many full cycles of each seasonal pattern your training history actually contains before trusting the model's handling of it.

Choosing a forecasting approach

A single time series, need something fast and interpretable. Prophet, Meta's open-source library, fits trend, seasonality and holiday effects with minimal tuning and is deliberately forgiving of missing data and outliers — the right first tool for a straightforward series with one dominant seasonal pattern, and a reasonable baseline to beat with anything more complex.

Comparing many model types against the same data before committing to one. Darts wraps classical statistical models, gradient-boosting models and deep-learning architectures behind one consistent interface, so you can backtest several approaches side by side without rewriting data-handling code for each.

Forecasting at real scale — thousands or millions of individual series (every SKU at every location, for instance). Nixtla's open-source libraries are built specifically to fit huge numbers of series in parallel rather than one at a time, and its hosted TimeGPT product offers a forecast with no model training at all for teams that want a fast baseline across many series without building pipelines first.

When you need a planning platform, not just a model

A model produces a number; a demand-planning platform turns that number into purchase orders, replenishment schedules and a process a planning team actually runs every week. This is a different kind of tool from a forecasting library, and the right one depends heavily on scale and industry:

• Enterprise-scale, cross-industry, needing plans to update instantly as conditions change. Kinaxis's concurrency architecture keeps demand, supply and inventory plans synchronized in real time rather than on a batch cycle.
• Retail or grocery, where forecasting has to connect directly to assortment, pricing and store execution. RELEX Solutions is built specifically around retail-native features like planogram and fresh-inventory management alongside the forecast itself.
• Small or mid-sized business already running an ERP, wanting forecasting layered on top rather than a platform replacement. Netstock connects to 60+ existing ERPs and is scoped for a faster, lighter implementation than an enterprise suite.

Judging accuracy honestly

• Backtest on a genuine holdout, not the data the model was fit on. Backtesting properly means training on data up to a cutoff date and evaluating only on periods after it — evaluating on data the model has already seen will always look better than the model actually performs going forward.
• Weight errors by their real cost, not symmetrically. A model that's very accurate on average but occasionally forecasts far too low on your highest-margin product can be worse for the business than a model with a higher average error that never misses that badly on the products that matter most.
• Compare against the seasonal naive baseline every time, not just against last quarter's model. A model can improve release over release while still losing to a baseline nobody bothered to check.
• Track accuracy by segment, not only in aggregate. An aggregate error can look fine while the forecast is badly wrong for a specific product line or region that a blended number hides.

Rolling forecasts over static ones

A one-time annual forecast goes stale the moment real demand starts to diverge from it. A rolling forecast — re-forecasting on a regular cadence (monthly is common) and extending the horizon forward each time — keeps the plan current and gives the business an early read on whether it's tracking to plan or drifting away from it, which matters more for operational decisions than a forecast that was accurate on the day it was made and stale a month later. Most of the platforms above, and a well-built pipeline using the open-source libraries, support this as a scheduled, repeating job rather than a one-off exercise.

Questions to ask before you commit

• Does the model or platform beat a naive seasonal baseline on our actual historical data, and by how much?
• How many full seasonal cycles does our training history actually contain?
• Is accuracy measured on a genuine holdout period, or on data the model has already seen?
• Does the forecast update on a rolling cadence, or does it need to be manually rebuilt each period?
• For a planning platform: how tightly does the forecast connect to the actual purchase order or replenishment decision, or does someone still have to translate it by hand?

Common mistakes

• Reaching for a sophisticated model before checking whether a naive baseline is already competitive.
• Fitting a model on too little history to have seen a full seasonal cycle, then trusting its seasonal adjustment.
• Evaluating accuracy on data the model was trained on rather than a genuine future holdout.
• Treating sales forecasting (a revenue-planning exercise, often top-down) and unit-level demand forecasting as interchangeable when they need different granularity and different owners.
• Building a static annual forecast and not revisiting it until it's already badly wrong.

Once a demand forecast exists, customer-level value and inventory decisions both depend on how much you trust it — check the accuracy honestly before committing budget to it. Browse forecasting platforms and libraries and supply chain and demand planning tools for the full field.