Demand forecasting rarely exists for its own sake — a retailer forecasting next week's demand for a product needs that number to decide how much inventory to order; a call center forecasting next Tuesday's call volume needs that number to decide how many agents to schedule. This matters because the cost of a forecasting error is almost never symmetric: over-forecasting inventory ties up cash and risks markdowns or spoilage, while under-forecasting causes stockouts and lost sales — and the relative severity of those two outcomes differs by product, season, and business context.

Good forecasting systems are built with this downstream decision in mind, not just to minimize a generic error metric. A forecast that's off by the same average amount can be far more costly in one direction than the other, which is why many production systems forecast a full predictive distribution — not just a single number — so downstream inventory or staffing decisions can set safety margins deliberately rather than treating the point forecast as certain.

What classical time series brings that plain ML often misses

Classical time-series methods (moving averages, exponential smoothing, ARIMA-family models) were built specifically around three structural properties common in demand data: trend (a gradual long-term increase or decrease), seasonality (repeating patterns tied to the calendar — day of week, holidays, time of year), and autocorrelation (today's value being informative about tomorrow's, beyond what other features explain). These models handle those properties natively and need very little data to produce a sane baseline forecast, which makes them a strong, cheap starting point and a sanity-check baseline even in systems that ultimately use something more sophisticated.

What classical methods generally can't do well is incorporate rich side information: promotions, pricing changes, weather, local events, competitor actions, or interactions between thousands of related products (a promotion on one product cannibalizing demand for a substitute). This is where machine learning — gradient-boosted trees or neural sequence models trained across many products and locations at once — adds real value: it can learn shared patterns across a huge number of related time series and incorporate heterogeneous features that classical univariate time-series models have no natural way to use.

Classical time series vs. ML forecasting approaches

Dimension	Classical time series (ARIMA, exponential smoothing)	ML forecasting (gradient boosting, sequence models)
Data needed	Works reasonably with a single series, limited history	Benefits from large volume across many related series
Handles trend/seasonality natively	Yes, built in	Must be engineered as features or learned from data
Incorporates external features (price, weather, promos)	Poorly or not at all	Naturally, as additional input features
Learns cross-product/cross-location patterns	No — typically one model per series	Yes — one model can learn shared structure across many series
Interpretability	High	Lower, though feature-importance tools help

Note

Many production forecasting systems don't pick one family exclusively — they decompose demand into a classical trend-and-seasonality component and let an ML model predict the residual, the part classical decomposition can't explain, driven by promotions, events, and cross-product effects. This combines the data efficiency and stability of classical methods with the flexibility of ML for the harder-to-model part of demand, and tends to be more robust than relying purely on either approach alone, especially for products with short or sparse sales history where an ML model alone would struggle to learn reliable patterns.

Accuracy metrics, and why the obvious one has a flaw

MAPE (Mean Absolute Percentage Error) expresses average forecast error as a percentage of actual demand, which is intuitive to communicate to business stakeholders — "we're off by about 12% on average." Its major flaw is that it's undefined or wildly distorted when actual demand is zero or very close to zero, which happens constantly for slow-moving or intermittent products, making MAPE unreliable exactly for the products where forecasting accuracy often matters most for inventory decisions.

MAE (Mean Absolute Error) reports error in the original units (units sold, calls received), avoiding the division-by-near-zero problem but losing the easy cross-product comparability that a percentage metric offers. RMSE (Root Mean Squared Error) penalizes large errors disproportionately more than small ones by squaring before averaging, useful when a few big misses are much more costly than many small ones. WAPE (Weighted Absolute Percentage Error), which weights errors by actual volume before computing a percentage, is a common fix for MAPE's zero-demand problem, since it naturally downweights the distorting effect of low-volume series rather than treating every series's percentage error as equally important.

python

Note

Forecasting accuracy tends to be worst around the events that matter most to the business — new product launches with no sales history, demand spikes around unusual promotions or external shocks, and structural shifts in customer behavior. Standard backtesting on stable historical periods can understate how a forecasting system will perform exactly when accurate forecasts are most valuable, so production systems typically track performance specifically during these high-stakes windows, not just average accuracy across normal periods.

What's next

Demand forecasting and search ranking are both examples of ML embedded inside a larger operational decision, where the model's raw accuracy is only half the story. Zooming out from applied domains, the choice between a small, cheap model and a large frontier model — covered next in Small Language Models vs. LLMs — is itself a cost-versus-capability tradeoff with the same shape seen throughout these applied systems.

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →