Imagine forecasting monthly demand for a spare part:
0, 0, 0, 18, 0, 0, 0, 0, 12, 0, 0, 0
You test a few models, compare the usual accuracy metrics, and then add the simplest baseline possible: forecast zero every month.
And it wins.
The reason is simple. Most months really are zero, so the baseline keeps getting rewarded for predicting nothing. It avoids making large errors during all those quiet periods, and on paper, it can look surprisingly strong.
But now imagine taking that forecast to the inventory team and saying:
"Our best forecast is zero, so stock nothing next month."
That is where the problem becomes obvious.
For intermittent demand, the periods that matter most are often the rare ones when demand actually appears. Missing one of those spikes can mean a stockout, an emergency replenishment, delayed maintenance, or an unhappy customer. A model can therefore look great according to an aggregate error metric while still being difficult to use for the actual business decision.
That's the trap with intermittent demand: the forecast that looks best on paper may still be the one the business can't actually use.
So what can we do differently? Here are three practical ways to approach the problem.
1. Separate occurrence from size
Instead of treating the entire series as one continuous forecasting problem, separate two questions:
Will demand happen? And if it does, how large will it be?
Croston-style methods do this by modeling demand size and the gaps between demand events separately, rather than averaging everything together. TSB goes a step further by explicitly modeling the probability that demand occurs in a given period.
This is especially useful when zeros are not just noise but an important structural feature of the series. Rather than allowing all those zeros to dominate the forecast, these methods try to capture the underlying arrival process behind the demand.
That does not mean they will predict every spike perfectly. But they give the model a more appropriate structure for the problem than simply asking it to minimize error across a mostly-zero series.
2. Use better metrics
The metric you optimize can completely change which model appears to be "best."
If most observations are zero, metrics like MAE or WAPE can heavily reward a model that stays close to zero. That may be statistically reasonable, but it can hide the mistakes that matter most operationally.
So don't evaluate intermittent demand with just one number.
Alongside aggregate accuracy, look at metrics such as performance on non-zero periods, demand-occurrence accuracy, bias, service level, stockout frequency, or the cost of over- versus under-forecasting.
You can also evaluate the two parts of the problem separately:
- How well did the model predict whether demand would occur?
- How well did it estimate the size when it did?
The goal is not to find a "perfect" metric. It is to make sure your evaluation reflects the decision the forecast is supposed to support.
3. Look for forward signals
Sometimes history alone simply does not contain enough information to predict the next spike.
A spare part may be ordered because a machine is scheduled for maintenance. A product may suddenly move because of a promotion. A component may be needed because a customer has already placed an order upstream.
These are all signals that may be invisible in the target series itself.
Maintenance schedules, promotions, order books, planned usage, lead times, calendar effects, or other business variables can give the model information about why demand might occur next.
Feeding these in as exogenous variables gives the model a reason to predict something other than zero when the evidence actually supports it.
And that is often the real lesson with intermittent demand: better forecasting is not always about using a more complicated model. Sometimes it is about structuring the problem differently, evaluating it with the right metrics, and giving the model more useful information.
If intermittent demand is giving your forecasts trouble, give the Nixtlaverse a try and see what works for your data.