Data / Analytics
Case 08 / 13
Demand forecasting across 600+ SKUs
Python regression and time-series forecasts across 600+ SKUs that improved forecast accuracy 24% and enabled $3M+ in procurement and planning savings.
Botrista · 2023–2025 · Demand Planner; owner of the forecasting models
- 600+ SKUs moved from judgment-based to model-based forecasting.
- 24% better forecast accuracy, enabling $3M+ in procurement and planning savings.
- Models in Python, delivered through Google Sheets, because that is where the planners already worked.
The numbers
- $3M+Procurement and planning savings
- 24%Forecast accuracy improvement
- 600+SKUs under model-based forecasting
- Python
- Regression
- Time-series models
- Google Sheets
- Apps Script
Open the actual model
Interactive — synthetic dataClick the sheet tabs along the bottom — each one is a real tab from the actual model.
| A | B | C | D | E | F | G | H | |
|---|---|---|---|---|---|---|---|---|
| 1 | SKU▾ | Trailing 12mo Avg/mo▾ | Seasonality Idx▾ | Next-Mo Forecast▾ | Error %▾ | |||
| 2 | SKU-A1042 | 4180 | 1.12 | 4680 | 3.1% | |||
| 3 | SKU-A1197 | 2640 | 0.94 | 2480 | 4.8% | |||
| 4 | SKU-A1256 | 3110 | 1.05 | 3260 | 2.2% | |||
| 5 | SKU-A1309 | 1890 | 0.88 | 1660 | 11.4% | |||
| 6 | SKU-A1388 | 2270 | 1.02 | 2310 | 1.9% | |||
| 7 | SKU-A1417 | 1420 | 1.31 | 1860 | 6.7% | |||
| 8 | ||||||||
| 9 | ||||||||
| 10 | ||||||||
| 11 | ||||||||
| 12 | ||||||||
| 13 | ||||||||
| 14 | ||||||||
| 15 | ||||||||
| 16 |
The forecasts reach planners in the tool they already used, Google Sheets, so that is what this mockup shows. SKU codes and figures are synthetic; the sheet structure and formulas are representative.
How it fits together
- 1Source data consolidation
- 2Automated cleaning
- 3Per-SKU forecast with seasonality
- 4Error measurement
Read the full case study Hide the case study
The problem
Demand planning across 600+ SKUs was manual and judgment-driven. Forecast error propagated straight into procurement, inventory, and production planning decisions, and nobody could say how large that error was because it was not being measured.
Why it mattered
At that SKU count, forecast error is expensive in both directions. Excess inventory ties up capital and creates obsolescence; shortfalls hit service levels and revenue. The planning function was also a bottleneck — manual forecasting at that scale consumed the cycle time that should have gone to analysis.
What I built
Statistical forecasting models across the full SKU portfolio, incorporating seasonality and trend, with an automated data pipeline replacing manual consolidation.
The models themselves were statistical — regression and time-series methods in Python — and the outputs were delivered into Google Sheets with Apps Script automation. That was a deliberate constraint rather than a limitation I worked around: the organization’s planning workflows already lived in Sheets, and adoption mattered more than tooling elegance. A better model that Procurement would not use is worth less than a good model wired into the process they already run.
What I learned
Accuracy improvements only convert to savings if the downstream process actually consumes the forecast. The modelling was less than half the work. Getting procurement to plan against model output rather than judgment was the rest, and it took longer.
What I would do next
Move the delivery layer off spreadsheets onto a proper analytical stack. Segment SKUs so high-volume and intermittent-demand items get different methods rather than one approach applied uniformly. Hierarchical reconciliation across product families.
Prior employer. Described without supplier, customer, or product information. Any figures in the demo are synthetic.