CASE STUDY · LOGISTICS & SUPPLY CHAIN VISIBILITY
Building a demand forecasting model that cut overstock by 25%.
- 25%Overstock down 25% in the pilot categories over 3 months
- 10%Stockouts down 10%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
A forecasting model on sales history and external signals, with a planner interface.
We cleaned several years of sales history and built a forecast for each product group. The model used seasonality, promotions, price changes and a small set of external signals. Forecasts appeared in a planner screen that showed the prediction, a range around it, last year's actuals and the reason for any big change. Planners could adjust a forecast, add a note and see how it compared with actual sales later.
- 1Overstock in some lines and stockouts in others.
- 2Buying decisions relied on last year's numbers, a planner's experience and spreadsheets that few people understood.
- 3Fast lines ran short while slow lines tied up cash and shelf space.
- 4Planners knew the problem but had no consistent way to see what demand was likely to be, and no record of how past forecasts had performed.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Early forecasts looked poor for several products, and the cause was not the model
The product list had changed over time: codes were reused, items were merged and some were renamed. History for one product sometimes belonged to another. We built a mapping table with the planners, joined related items into continuous series, and flagged new products with little history so that the system used a group-level forecast instead.
- PROBLEM 02Accuracy improved once the history made sense
- PROBLEM 03A second hurdle was trust
Early on, a planner overrode several forecasts by hand and then saw sales go the other way, which showed that neither side was always right. We did not argue the point. We tracked overrides and compared the planner's number, the model's number and actual sales for every product.
- PROBLEM 04Some overrides added value, particularly for known one-off orders, and some did not
Planners now note the reason for an override, and the monthly review uses those reasons to improve both the model and their own judgement.
03 · THE PROCESS
How we ran it.
We worked with a data analyst on the client side and two planners. Their questions shaped the screens more than any specification did.
- 01Step 1
Weeks 1 to 3: data audit, product list clean-up, choice of pilot categories and agreement on how to measure success.
- 02Step 2
Weeks 4 to 7: baseline forecasts built and compared against the planners' own numbers on past periods.
- 03Step 3
Weeks 8 to 10: planner interface built and tested with two planners.
- 04Step 4
Weeks 11 to 12 and then 3 months of pilot: forecasts used for live buying in the pilot categories, with a weekly review.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Planners start from the forecast and spend their time on exceptions, not on building spreadsheets.
- NOW 02
Forecast accuracy is reviewed monthly, and the team discusses misses openly.
- NOW 03
Product data is kept tidy at the point of entry, because the team has seen the cost of messy history.
- NOW 04
The pilot approach is now used for adding further categories.
- 25%
Overstock down 25% in the pilot categories over 3 months
- 10%
Stockouts down 10%
05 · WHAT WE BUILT
How it works.
- The pipeline pulls sales, stock and price data from the client's systems each night, applies cleaning rules and stores a versioned dataset.
- We trained a model per product group and kept a simple seasonal baseline alongside it.
- The forecast was only shown when it beat the baseline on back-tests, otherwise the baseline was used.
- Each run stores forecasts and, later, actuals, so accuracy is measured continuously.
- Planner changes are logged with the user and reason.
- The system gives a range around each forecast, so planners can set safety stock by how uncertain a line is.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Overstock in some lines and stockouts in others. Buying decisions relied on last year's numbers, a planner's experience and spreadsheets that few people understood. Fast lines ran short while slow lines tied up cash and shelf space. Planners knew the problem but had no consistent way to see what demand was likely to be, and no record of how past forecasts had performed.
- What did Brandsmashers build?
- A forecasting model on sales history and external signals, with a planner interface. We cleaned several years of sales history and built a forecast for each product group. The model used seasonality, promotions, price changes and a small set of external signals. Forecasts appeared in a planner screen that showed the prediction, a range around it, last year's actuals and the reason for any big change. Planners could adjust a forecast, add a note and see how it compared with actual sales later.
- How was the work run?
- We worked with a data analyst on the client side and two planners. Their questions shaped the screens more than any specification did.
- What were the results?
- Overstock down 25% in the pilot categories over 3 months; stockouts down 10%.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
