Demand forecasting for small businesses: a practical guide that starts simple

Most small and mid-size businesses already forecast demand. It's just done in someone's head or in a spreadsheet: "last Ramadan we sold about this much, so order a bit more." Sometimes that works. Often it leads to stockouts on the best sellers and dead stock on everything else.

You don't need a data science department to do better. You need clean sales history, a few honest baselines, and a way to check whether a model actually beats them. This guide walks through how I approach demand forecasting, from the simplest methods to machine learning, and when it isn't worth the effort.

What you need before you start

Sales history at the level you decide at. If you reorder per product per store each week, you need weekly sales per product per store. Two years is a good start, because it covers each season at least twice.
Stockout information. Days when a product was out of stock show zero sales, but demand wasn't zero. If you don't flag those days, the model learns that nobody wanted it.
Known events. Promotions, price changes, holidays, store openings and closures.
A decision to improve. Forecasts are only useful if they change an order, a staffing plan or a production schedule.

Demand forecasting starts with baselines

Before any model, set up simple baselines. They're cheap, easy to explain, and surprisingly hard to beat:

Naive: next week will be like this week.
Seasonal naive: next week will be like the same week last year (or the same weekday last week, for daily data).
Moving average: the average of the last few weeks.

Every more complex model must beat these, measured the same way. If it doesn't, keep the baseline. I've seen teams spend months on a model that a seasonal naive forecast matched.

Statistical models

The next step is classical time series models:

Exponential smoothing weights recent history more than old history, and its seasonal versions (often called Holt-Winters) handle trend and yearly patterns. It's robust and works well for many products with regular sales.
ARIMA-family models capture how each period depends on previous ones. With seasonal terms and external variables, they can include effects like promotions.

These models are well understood, fast, and give you forecast intervals almost for free. For a few hundred products with steady sales, they're often enough.

When you have many products, many stores and lots of external drivers, gradient-boosted trees often do well. Instead of modelling each series alone, you train one model across all of them, with features such as:

recent sales (last week, average of the last four weeks, same week last year),
calendar features (week of year, day of week, month, paydays),
promotions, price and discount depth,
holidays and special periods,
product and store attributes.

One global model can learn patterns shared across products, which helps new or slow-moving items that have little history of their own. Libraries like CatBoost and XGBoost both work here; I compare them in CatBoost vs XGBoost.

Ramadan and other moving holidays

This matters a lot for businesses in Morocco, the Gulf and Egypt. The Islamic calendar is lunar, so Ramadan and the two Eids move about 11 days earlier each year relative to the Gregorian calendar. A model that only knows "week 12" or "March" will put the Ramadan effect in the wrong place next year.

The fix is to add explicit features: days until Ramadan starts, whether a date falls within Ramadan, days since Eid, and so on. Do the same for Easter, Chinese New Year, Black Friday or any event that doesn't fall on the same date every year. Also expect behaviour to shift during Ramadan itself: different shopping hours, more food and gift sales, lower demand in some categories.

Backtesting: test like you'll use it

Never evaluate a forecast with a random train/test split. It lets the model see the future. Instead, use backtesting:

Train on data up to a cut-off date.
Forecast the next few weeks.
Compare with what really happened.
Move the cut-off forward and repeat.

This mimics how the forecast will be used and shows how performance varies across seasons. Make sure features only use information you would have had at forecast time. Using "this week's promotion" is fine only if the promotion was planned in advance.

Choosing the right error metric

MAE (mean absolute error) is easy to read: on average, we're off by this many units.
MAPE (mean absolute percentage error) is popular but breaks with zeros and blows up on low-volume products, where being off by 2 units can look like a 200% error.
WAPE (total absolute error divided by total sales) is a good default for retail: it's a percentage, it handles zeros, and it weights products by volume.

Also check bias: a forecast that's always 10% too low is a systematic problem, even if its average error looks acceptable.

From forecast to reorder decision

A single number isn't enough to decide how much to order. You need a sense of uncertainty. Forecast intervals or quantile forecasts tell you the range of likely demand. Then you choose a service level per product: for a best seller, you might order enough to cover demand in most weeks; for a slow, expensive item, you accept more risk of running out.

Combine that with lead times, minimum order quantities and shelf life, and the forecast turns into a suggested order your buyer can approve or adjust. Keeping a person in the loop at first is how you build trust, and it's the same approach I recommend in AI automation for MENA businesses.

When it isn't worth it

Very little history or constantly changing products. Judgement plus simple rules may be better.
Tiny volumes where the cost of error is low.
No decision attached. If nobody will change an order based on the forecast, don't build it.

Working together

I'm Driss Briksine, a software and ML engineer with a master's in statistics and data science from Hasselt University and a bachelor's in data science from UM6P. I build forecasting and ML systems and the software that puts them in front of the people who make decisions. See my work, including the CPT Dashboard, an ML system validated the strict way.

If you have sales history and a decision you'd like to make with more confidence, send me a short brief.