Solutions / Demand forecasting

Demand & sales forecasting

A demand forecast per SKU and period, rebuilt daily from your own sales history, seasonality, promotions and lead times — with an accuracy number you can check against last month.

Operations Planning ML
Daily refresh
by SKU, 4–12 weeks ahead
Accuracy reported
per SKU class, honestly
Promo-aware
not a naive trend line
Who it is for

Operations, supply-chain and finance teams planning inventory or capacity across hundreds of SKUs or more.

Short answer

Every SKU gets a forecast for the periods you plan on, built from cleaned sales history, seasonality, price and promotion calendars, and supplier lead times. Slow movers are handled with rules rather than pretend precision, stock-outs are treated as censored demand instead of zero demand, and every forecast carries an error range so planners know which numbers to trust.

The problem

Planning runs on a spreadsheet that averages the last three months and ignores everything else.

01

The average hides the pattern

A three-month moving average is blind to seasonality, promotions and trend at once. It is wrong in a predictable direction every quarter, and everyone compensates with a gut adjustment nobody records.

02

Stock-outs poison the history

A week with no stock reads as a week with no demand. Train anything on that and it will confidently under-forecast the products that sell best.

03

Nobody measures the forecast

Plans are made, reality happens, and the two are never compared. Without an error number there is no way to know whether the new process is better than the old spreadsheet.

How it works

From trigger to result, step by step.

01

Clean the history first

Stock-outs marked as censored, promotions and price changes flagged, one-off events separated from pattern, returns netted. This is unglamorous and it decides how good everything after it can be.

02

Build the drivers

Seasonality, day-of-week and holiday effects, promotion calendar, price, new-product cannibalisation, and external drivers where they genuinely help rather than where they look impressive.

03

Model by SKU class, not one size fits all

Fast movers get statistical and gradient-boosted models; intermittent and slow movers get methods built for sparse demand or explicit rules. Pretending a model can forecast an item that sells four times a year is how trust dies.

04

Report error against a baseline

Accuracy is measured on held-out periods and compared with your current method, per SKU class. We publish where the forecast is reliable and where it is not, before anyone plans on it.

05

Fit it into how planning actually works

Forecasts land in your planning tool or ERP with an override field and a reason box. Human overrides are tracked, so within a quarter you can see where the model or the planner is systematically better.

Before / after

What changes on the ground.

Today, by hand
×A three-month average in a spreadsheet
×Stock-outs recorded as zero demand
×Promotions handled by memory
×No one knows the forecast error
With the automation running
Per-SKU forecasts refreshed daily
Censored demand corrected before training
Promotions and seasonality in the model
Accuracy published per SKU class
What you get

Delivered, not demoed.

A cleaned, promotion-aware demand history you keep
Models chosen per SKU class, including rules for slow movers
Forecast error reported against your current baseline
Delivery into your ERP or planning tool with overrides and reasons
Monitoring, retraining schedule and a handover session
Built with

We build in your stack rather than moving you onto ours. The list below is what this solution most often connects to — other systems are a scoping question, not a blocker.

Python statsmodels Prophet LightGBM BigQuery dbt Airflow 1C SAP Power BI
Time to production6–10 weeks
Build priceFixed quote
First stepFree mini-audit
Honest limits

When this is not the right solution.

·With less than a year of history there is no seasonality to learn, and seasonality is most of the value. Rules plus a planner will do better until you have the data.
·If your assortment turns over completely every season, forecasting the SKU is meaningless. There is a real project there, but it forecasts categories and attributes, not items.
·If the plan gets overridden regardless of what it says, a better forecast changes nothing. That is a process conversation, and it should happen before any model is built.

Questions we get about this one

It depends on your demand pattern, and anyone quoting a percentage before seeing your data is guessing. We report error per SKU class against your current method on a held-out period, before you plan on it.

Bring us the process that hurts.

The mini-audit is free: we take your version of this process apart and tell you plainly whether automating it pays. If it does, you get a scope and a fixed price.