Learnings from building our own sales forecast
Building a sales forecast is not easy. The sheer complexity that comes with it can easily be underestimated. How we built it anyway and which learnings we had along the way is the topic of this blog post.
)
As part of a customer project, I was given the task of improving the sales forecast. The existing forecast was really just a simple "take the average of the last n days and distribute it over the future".
It started with us wanting to include the seasonality of our articles. We wanted to roughly model that there are articles which sell less in winter and more in summer.
On top of that, we wanted to try out the so-called zero-shot foundation models. These are basically machine learning models that predict time series similar to how LLMs work, achieving state-of-the-art performance without being trained on your own data.
With this, we wanted to improve our 365-day forecast. In this blog post, I want to look at the thoughts that went into it and where our naive forecast reached its limit.
What is it for?
The sales forecast tells us how many articles we need to buy today, so that we still have enough in stock next week. There are two main problems that a forecast can have:
Underforecasting | Overforecasting |
|---|---|
If we order too little, sales cannot be realized | If we order too much, the warehouse fills up and storage costs come up |
So we need a sales forecast which is able to predict neither too much nor too little. Usually, underforecasting is much worse than overforecasting, since missed sales often cost more than the storage costs.
Furthermore, the articles you sell are usually not the same identical articles you buy. Instead, the sellable article consists of other articles through a production chain. These are the articles we need to buy. This means the predicted demand first has to be broken down to the purchasable base articles, before you can predict which articles need to be ordered and how many.
The naive forecast
As mentioned in the beginning, our first forecast was a naive model:
We take the average sales of the last n days and simply distribute them over the next m days
And this naive approach is actually not that bad. Of course, we might sell less in one month and more in another than predicted. On average however, this forecast is surprisingly accurate in many cases.
If reordering from suppliers and producing the articles takes long enough, errors average out quite well.
But where does this naive forecast fail? In essence, it fails whenever we don't buy enough and the warehouse runs empty. A simple example:
It's right before Black Friday & Black Week. Based on the last month, our naive average doesn't expect particularly high sales. In reality however, we sell a lot more articles during Black Week. We buy too few articles beforehand and during Black Week our warehouse runs empty. Afterwards, sales drop because we lose our Sales-Rank on Amazon. It takes weeks to months until the next supplier order arrives at the warehouse. So we not only miss the Black Week sales, but also further sales long after that.
What does a better forecast need?
Now you want to adjust the forecast, but what can even influence a sale?
Seasonality: Christmas articles sell more in winter than in summer
Trends: An article has a natural growth in its sales
The article price as well as marketing and discounts boost sales
Holidays, vacations, Black Friday, weekends etc. often have a positive effect on sales
In general, this list is very long. Once you've spent some time with it, it doesn't even sound absurd anymore to include e.g. the average temperature in Germany in the sales forecast. The more data you have available, the better you can model all external influences on your sales.
However, there is a hidden danger: more doesn't always help more. Adding an external influence can just as well make the forecast worse. So every single step has to be evaluated.
How do I validate my forecast?
Validating a sales forecast is not easy. If you look at individual articles by hand, you often get a wrong feeling for what the forecast can actually do.
That's why you need backtesting, where you run the forecast for the past and then compare it against the actual sales. Only this way you can get a feeling for "how good" a forecast model really is and whether changes to the forecast actually led to an improvement.
What can such a forecast look like technically?
In general, different influences require different handling.
For example, you can use a statistical "STL-Decomposition" to split a sales time series into a trend and a seasonality, to include periodic effects.
We decided to try out a zero-shot model. The two main candidates were TimesFM by Google (2024) and Chronos-2 by Amazon (2025). You then feed them with sales numbers, holidays, price histories and other information relevant for the forecast. Our tests showed that TimesFM was the better model in our case.
Outlook
Our current forecast is far from perfect, but it already shows significant improvements over the old forecast.
Building a good forecast is a long process, in which you have to find and fix new edge cases and bugs again and again.
In my opinion, it's a must-have to build evaluation views and benchmarks for your model, so you can make correct statements about it.
)
)
)
)
)
)
)
)
)
)