Do we need machine learning, or will simpler methods work?
Most retailers get the majority of the available benefit from well-implemented statistical baselines before machine learning adds anything. Seasonal decomposition, moving averages weighted for recency, and explicit handling of promotions and stockouts typically beat an untuned model trained on unclean history. We start with a baseline you can explain, measure its error by category and location, and only introduce gradient-boosted or other learned models where the baseline demonstrably underperforms and the data volume justifies it. The decision is empirical, not fashionable.
How much sales history do we need before a forecast is useful?
Two full years is comfortable, because it lets the model see each seasonal peak twice and separate seasonality from trend. Eighteen months is workable. Twelve months or less means seasonality has to be borrowed from a category or location group rather than learned per SKU, which is a legitimate technique but should be stated openly rather than hidden inside a number. For brand new products there is no history at all, so the forecast comes from an attribute-similar reference set and is expected to be corrected quickly once real sales arrive.
Why do stockouts make forecasts worse if they are not handled?
Because a stockout records low sales, and a naive model reads that as low demand. The next forecast is lowered, less stock is ordered, and the shortage repeats. This is one of the most common reasons a forecasting project fails to earn trust. We treat out-of-stock periods as censored observations, estimate what demand would have been from comparable periods and locations, and train on the corrected series. Recording availability history alongside sales history is a prerequisite, and where it does not exist we usually have to build it first.
Can this generate purchase orders automatically?
It can generate suggested orders, and we recommend running them as suggestions that a buyer approves before any automatic release. The suggestion combines the forecast with lead time, supplier order multiples and minimums, current on-hand and on-order, and target service level. Once a category has run for a few cycles and the buyer is overriding rarely, you can move low-risk categories to automatic release with exception thresholds. Starting fully automatic is how organisations lose confidence in a system after one bad week.
How is this different from the reporting our POS or ecommerce platform already provides?
Platform reporting tells you what happened inside that platform. It is accurate and useful for its own scope, and it stops at the boundary. What it will not do is combine store and online sales into one demand signal per product and location, reconcile them against stock availability, project forward, or account for promotions that ran in one channel and cannibalised another. This work sits above your operating systems, reading from all of them, and answers forward-looking questions rather than historical ones.
What does forecast accuracy realistically look like?
It depends entirely on the aggregation level, and any promise made without knowing your data is a sales tactic. Forecasting a category at national level for a month is a fundamentally easier problem than forecasting one SKU in one store for one day, and the error will differ by a large multiple. We measure error at the level the decision is actually made at, report it per category and location, and compare against a naive baseline so the improvement is attributable. We will not quote a number for your business before profiling your history.
How do promotions get handled?
Explicitly, because a promotion is a deliberate demand distortion and must be modelled as one. Past promotional periods are flagged with their mechanic, discount depth, and any supporting media, so the model can learn the uplift and its shape rather than mistaking it for underlying trend. Planned future promotions are entered as inputs and lift the forecast accordingly. This also lets you look backwards honestly at whether a promotion generated incremental demand, pulled forward demand from the following weeks, or simply cannibalised a full-price line.
Where does the data come from, and what if it is messy?
Typically the POS or ecommerce order history, product and category master data, stock movement and availability history, promotion calendars, and supplier lead times. Messy is normal. Product hierarchies change over time, SKUs get retired and reissued, and location groupings shift after a refit. Data profiling is the first phase of every engagement precisely because these issues determine what is buildable. We report what we find, including where the history is too broken to support a claim, rather than modelling on top of it silently.
Will people actually use it?
Only if it fits the working rhythm of the person making the decision and shows its reasoning. A buyer will not act on a number with no explanation. We surface the drivers behind each figure, including base demand, seasonality, promotion effect, and recent trend, along with the confidence range, and we design around the review cycle that already exists rather than asking the team to invent a new one. Adoption is a design requirement in this kind of project, not an afterthought for training.
How long does an initial build take?
A first working version covering one category group and a defined set of locations is typically eight to fourteen weeks, including data profiling, pipeline, baseline model, evaluation harness, and the operator interface. Extending to the full estate is then largely a data and calibration exercise rather than new engineering. Building for every category at once is slower to first value and gives you no early evidence about whether the approach works on your data, so we do not recommend it.
Does this run inside our existing systems or alongside them?
Alongside. It reads from your operating systems, holds its own analytical store shaped for time-series work, and writes results back as suggestions and enriched data where that is useful. Forecasting workloads are analytical and periodic, while transactional systems are tuned for high-frequency small operations, so running heavy aggregation inside a live POS or ecommerce database degrades both. Separation also means the forecasting layer can be rebuilt or replaced without touching anything that takes money.
