NiravProof of work
← All projects

Data / Analytics

Case 05 / 10

Demand forecasting across 600+ SKUs

Statistical forecasting at portfolio scale that improved accuracy and drove $3M+ in cost savings through better procurement and inventory decisions.

Botrista · 2023–2025 · Supply Chain Planner; owner of the forecasting models

  • 600+ SKUs moved from judgment-based to model-based forecasting.
  • $3M+ in cost savings, 24% accuracy improvement.
  • Built inside Google Sheets, because that is where the planners already worked.
$3M+ cost savings from forecast accuracy

The numbers

  • $3,000,000+
    Cost savings
  • 24%
    Forecast accuracy improvement
  • 600+
    SKUs under model-based forecasting
  • Google Sheets
  • Apps Script
  • LLM-assisted development
  • Statistical forecasting

Open the actual model

Interactive — synthetic data

Click the sheet tabs along the bottom — each one is a real tab from the actual model.

docs.google.com/spreadsheets/d/1Qm4…Forecast
Demand Forecast Model — v22File  Edit  View  Insert  Format  Data  Extensions
🖨100%$%.00Σ
fx=FORECAST.ETS(B2, $C$2:$C$61, $A$2:$A$61)
ABCDEFGH
1SKUTrailing 12mo Avg/moSeasonality IdxNext-Mo ForecastError %
2SKU-A104241801.1246803.1%
3SKU-A119726400.9424804.8%
4SKU-A125631101.0532602.2%
5SKU-A130918900.88166011.4%
6SKU-A138822701.0223101.9%
7SKU-A141714201.3118606.7%
8
9
10
11
12
13
14
15
16
Forecast vs trailing average
A1042A1197A1256A1309A1388A1417
Trailing avgForecast

Built on the actual substrate — Google Sheets plus Apps Script, not a purpose-built app. SKU codes and figures are synthetic; the sheet structure and formulas are representative. - Procurement and inventory planning

How it fits together

  1. 1Source data consolidation
  2. 2Automated cleaning
  3. 3Per-SKU forecast with seasonality
  4. 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.

This was built in Google Sheets with Apps Script automation and LLM-assisted development. 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 off a spreadsheet substrate 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.