Time series forecasting
What is time series forecasting?
Time series forecasting predicts the future values of something you measure at regular moments: sales per product per week, your bank balance at the end of each month, calls per hour at the helpdesk, units picked per day in the warehouse, kWh per day on the meter. You take the history of that one number, add what you already know about the coming period, and produce a best estimate for the coming weeks or months.
The difference with the wider field of predictive analytics is the time axis. A churn model scores one customer on today's data. A forecast follows one number forward through time: next week around 1,200 crates, the week after around 1,350 because of the heat wave and the long weekend. Predictive analytics is the umbrella; forecasting is the tool most SMEs need first, because buying, staffing and cash planning all run on it.
One thing to fix in your head early: a forecast is a distribution, not a number. Hyndman and Athanasopoulos, whose textbook Forecasting: Principles and Practice is the standard reference, put it plainly: point forecasts can be of almost no value without the accompanying prediction intervals. The number you see in the report is the middle of a range of possible futures. A forecast of 1,200 crates with a likely range of 1,050 to 1,380 is something you can order against. A bare 1,200 is a guess with a confident face.
What a series is made of
Almost every business series is a sum of a few parts, and you want to know which ones are in yours before you pick a method.
Level and trend. Where the series sits now, and the slow drift up or down over years: a growing customer base, a product being phased out.
Seasonality. A repeating pattern with a fixed, known period: the day of the week, the month of the year, the quarter. Ice cream in July, heating oil in November, Monday peaks at the helpdesk.
Calendar effects. These look like seasonality but move around. In Belgium that means the ten public holidays (Easter Monday, Ascension and Whit Monday land on a different date every year), the construction holiday in July that empties whole customer segments for three weeks and differs per province, school holidays, and the number of working days in a month. A March with 23 working days followed by a March with 20 shows a dip that has nothing to do with demand.
Promotions and external drivers. Your own actions (a price cut, a folder, a new listing at a retailer) and things outside your control (weather, a competitor's stockout). The ones you know in advance can go into the forecast. The ones you only know afterwards can only explain the error.
The remainder. What is left once trend, season and known drivers are taken out. Part of it you will never predict, and learning to leave it alone is half the craft.
Which method do you pick?
Four families cover nearly every SME case. Which one fits depends on how many series you have, how clean they are, and whether you have drivers to feed in.
Naive and seasonal naive. Naive says: next week equals this week. Seasonal naive says: next July equals last July, next Monday equals last Monday. These are the baseline every other method has to beat, and Hyndman's textbook is explicit that a new method should only be adopted if it does better. Surprisingly often, seasonal naive is hard to beat by much.
Exponential smoothing and ARIMA. The two classic statistical families. Exponential smoothing takes a weighted average of past values with the weights fading as observations get older, with variants that add trend and seasonality (the Holt-Winters method). ARIMA models the correlation between a value and its own recent past. Both fit one series at a time, need little data, and produce proper prediction intervals. They are the right choice for a handful of clean series: total monthly revenue, weekly hours at one site, a cash position.
Gradient-boosted trees with lag features. When you have hundreds or thousands of related series and drivers to go with them, you switch to a machine learning setup. You build a table where each row is one product in one week, with columns for the sales of the previous weeks, the same week last year, the price, a promotion flag, the holiday flags and the weekday mix. A boosted tree model such as LightGBM then learns across all series at once. This is what won the M5 competition in 2020, where teams forecast 30,490 daily product-store series from Walmart: almost all top-50 methods used LightGBM, and the winner beat the best exponential smoothing benchmark by 22 percent. The catch is that this setup needs an engineer, a feature pipeline and someone who keeps it running.
Foundation models for time series. Since 2024 a new family has appeared: models pretrained on very large collections of series, which forecast a new series without any training on your data. Google's TimesFM (February 2024, with TimesFM-3 in August 2026) and Amazon's Chronos (March 2024, with Chronos-2 in October 2025) are the best known. They are open, run on a normal machine, and the newer versions accept drivers such as promotions or holidays; Google has also wired TimesFM into BigQuery as a SQL function. They are a serious option for the many-series case with little engineering budget, but the vendor benchmarks are public research datasets, and you still have to test the model against seasonal naive on your own data before you trust it.
Tools, as examples only. Power BI puts a forecast with a confidence band on a line chart from the Analytics pane, one series at a time: fine for a monthly revenue view, nothing more. Azure Machine Learning has an AutoML forecasting job that sweeps naive, ARIMA, exponential smoothing, Prophet and boosted trees; Fabric notebooks run the same Python libraries, of which statsforecast from Nixtla covers the statistical family including Croston for intermittent demand, and Prophet is still common for seasonal series with holidays although it is now in maintenance mode. Some ERP systems ship forecasting of their own; Business Central has a Sales and Inventory Forecast extension that calls an Azure service per item.
Seasonal naive versus a machine learning forecast
The comparison that matters for an SME is this one: how much accuracy do I actually gain over the seasonal naive baseline, and what does it cost me to keep that gain alive?
What you gain. In the M5 competition, about a third of all teams beat seasonal naive with their final submission, and fewer than one in ten beat the best exponential smoothing benchmark. The winning boosted-tree setup was 22 percent better than that benchmark. Those numbers come from a retailer with promotions, prices, calendar data and thousands of correlated series to learn across. With a few isolated series and no drivers, the gap shrinks to a few percentage points, sometimes to nothing.
What it costs. Seasonal naive costs one formula. Exponential smoothing costs one afternoon and a library. A boosted-tree pipeline costs a feature table that has to be rebuilt every week, a retraining schedule, a monitoring job that compares forecasts with actuals, and a person who notices when the model quietly drifts after a price change or a range refresh. That maintenance is the real price. It pays off when the stock, the staffing or the cash involved is large enough that a few points of accuracy are worth real money, and it does not pay off for a series where a wrong forecast costs you a phone call.
A practical rule: run seasonal naive alongside whatever you build, forever. The day the clever model stops beating it, you have learned something.
How you measure a forecast
You measure on data the model has not seen, with a rolling backtest: pretend it is January, forecast February to April, compare with what happened; move to February, repeat. Ordinary cross-validation that shuffles rows leaks the future into the training set and gives you a flattering number.
MAPE (mean absolute percentage error) is the number most managers ask for because it reads as a percentage. It divides by the actual value, so on small numbers it explodes: a product that sells 2 units and was forecast at 4 scores a 100 percent error, a product that sells 2,000 and was forecast at 2,100 scores 5 percent. For slow movers and series with zeros, MAPE is undefined or meaningless.
MAE (mean absolute error) stays in units, crates or euros, and does not blow up. It is the better number to steer a warehouse on, because 40 crates too many is a cost you can price.
Bias is the average signed error. A forecast can have a decent MAPE and still be 8 percent too high every single week, which fills your warehouse. Check the sign as well as the size.
Against the baseline, always. Whatever metric you report, report the seasonal naive number next to it. A scaled error such as MASE does this in one figure: below 1 means you beat naive. The same idea sits behind forecast value added, a practice Michael Gilliland brought to demand planners: measure each step in your process (statistical forecast, planner's override, sales adjustment) against the naive forecast and against the previous step, and drop the steps that make the number worse. It is the only way to find out whether the planner's override helps or hurts.
Horizon, granularity and the planning loop
Two decisions shape everything else. The horizon is how far ahead you need the number: three weeks to place a purchase order, three months to plan staff, twelve months for a budget. The granularity is how fine the number has to be: per SKU per week for the buyer, per category per month for the board. Forecast at the level where the decision is taken, not finer: accuracy drops fast from category to SKU and from month to day, and intervals widen the further ahead you look.
Then the forecast has to live inside a loop, or it becomes a report nobody reads:
Forecast. The model produces the number and the range for each series at the agreed horizon.
Human override. The buyer or planner adjusts where they know something the model cannot: a customer leaving, a listing gained, a supplier problem. Each override is logged with a reason.
Order or plan. The purchase order, the shift roster or the cash plan is built from the adjusted forecast.
Measure the error. When the actuals arrive, error and bias are computed per series and per step, including the override step.
Feed back. Series that drift get retrained; overrides that consistently hurt get stopped; drivers that explain the error (a holiday you forgot) get added.
Worked example: a drinks wholesaler with 400 SKUs
A drinks wholesaler forecasts weekly demand for 400 SKUs to drive purchase orders with a two-week lead time. As a baseline, the team computes seasonal naive per SKU (same week last year, scaled by this year's trend) and backtests it over the last 26 weeks: 28 percent MAPE across the range, much worse on slow movers, much better on the top 50.
They then build a boosted-tree model with lag features, the Belgian holiday calendar, the construction holiday per province, a promotion flag from the ERP and the weekly temperature forecast. Same backtest: 19 percent MAPE. Bias drops from plus 6 percent (last year had a hotter summer, so the baseline ran high all season) to under 1 percent.
What does that mean in stock? Rounded: the wholesaler moves about 250,000 euros of goods per week at cost. The buffer stock they hold to cover forecast error scales roughly with that error. At 28 percent, the buffer sits around 70,000 euros; at 19 percent, around 47,000. That is some 20,000 euros less capital tied up, before counting the stockouts avoided on the top movers, where the model gained most. That rough arithmetic decides whether the pipeline is worth an engineer's day per month to maintain. And note what the 19 percent hides: it is an average over 400 series. The top 50 SKUs may sit at 8 percent and the bottom 100 at 40, and the buyer needs those two numbers more than the average.
What to watch out for with time series forecasting
Forecasting the average of intermittent demand. A spare part sells 0, 0, 0, 5, 0, 0, 2. A smoothing model forecasts about 1 per week, a quantity that never happens. Such series need methods built for intermittent demand (Croston's method and its successors) or, better, a different question: how likely is an order in the next four weeks, and how large is it when it comes.
Stockouts that hide true demand. Sales history is not demand history. If a product was out of stock for three weeks, the zeros teach the model that nobody wanted it. Flag stockout periods and exclude or impute them, or the forecast will keep you short on exactly the products you already ran out of.
A model that memorised last year's promotion calendar. If a promotion ran in week 14 last year, a model without a promotion feature will forecast a peak in week 14 this year whether or not you run one. Promotions are a driver, not a season: feed them in explicitly, past and planned.
One accuracy number for 3,000 SKUs. An overall MAPE of 22 percent tells the board something and the buyer nothing. Report accuracy per ABC class or volume band, and weight by value: being wrong on a product that moves 10,000 euros a week matters more than the same percentage on one that moves 100.
A forecast that changes what it forecasts. A low forecast leads to low stock, low stock leads to low sales, low sales confirm the forecast. Watch for that loop in the first year after introducing a model.
Treating the number as the answer. Order against the range, not the point. For a cheap product with a long shelf life and a wide interval, order towards the top of it; for a fresh product with a short shelf life, order towards the middle and accept some stockouts. The forecast gives you the distribution, and what you do with it is the business decision.