Godi.AI
Case study · Supply chain

How a European energy major saved €500K/year with AI demand forecasting

From rule-based Excel to a production Random Forest · 400 variables · 92% accuracy · 12 weeks

By Santiago Patino Serna·Founder Godi.AI · MSc École Polytechnique · 5.5 years Lead Data/AI at Primagaz·9-min read
€500K
saved/year
92%
forecast accuracy
−35%
logistics costs
12 wk
kickoff → prod

TL;DR

  • Excel + rule-based forecast, 4 analysts spending 60% of their week rebuilding spreadsheets.
  • Random Forest on 400 variables (weather, sales history, contract types, geography, holidays) → 92% accuracy vs 78% baseline.
  • Production in 12 weeks: Python + scikit-learn, daily batch pipeline, monitoring + drift detection.
  • Outcome: −35% logistics costs in pilot, €500K annual savings at full run.

The context

A European energy major — 2M+ residential and B2B clients across France, ~1,500 trucks, bulk propane distribution. Highly seasonal market (winter peaks 3× summer baseline), regulated, where supply chain is the #1 cost driver. Fuel, drivers, depot inventory — everything depends on a reliable forecast.

The problem

Existing forecast ran on Excel + 4-5 rule-based Python scripts. Analysts (team of 4) spent 60% of their time rebuilding files weekly — little real time for variance analysis. Three direct consequences:

  • Over-stocking in low-demand zones (tied-up capital).
  • Stockouts in high-demand zones → emergency deliveries at 2-3× standard cost.
  • Trucks deadheading (returning empty) due to routing built on bad forecasts.
Forecast error cost ~5-8% of total logistics spend. On hundreds of millions in annual logistics, the math adds up fast.

Why off-the-shelf approaches failed

Two paths had been tried and abandoned before me:

  • One-click BI forecasting: SaaS tools offer univariate time-series forecasting. On a seasonal multi-zone product with 400 exogenous variables, results were worse than the human baseline.
  • Deep learning: an internal LSTM POC ran for 4 months, hit 87% accuracy, but no business team could interpret the outputs. Zero adoption, project shelved.

The lesson: accuracy isn't the metric. It's adoption × accuracy. An 87% model nobody uses is worth less than an 85% model the whole ops team adopts.

The approach

Four architecture decisions, each motivated by business context:

1.Random Forest over XGBoost or Deep Learning

RF is interpretable (direct feature importance + SHAP), robust to missing data (huge in the real world), fast to retrain (1h weekly) and performs nearly as well as XGBoost on this kind of structured data. The business team could debug a forecast in 2 minutes.

2.Forecast at zone × day, not global

The business reasons in "depot × delivery day". Aligning the model granularity with the operational decision unit doubled adoption.

3.Daily batch pipeline, not real-time

Logistics planning is decided the day before. No streaming needed. A 4 AM cron, output to data warehouse, picked up by the planning tool at 6 AM. Simple and robust.

4.Monitoring + drift detection from day 1 of prod

Feature distributions tracked vs train baseline, Slack alert if drift > 2σ. Weather changes, prices change, pandemic breaks patterns: without monitoring, the model drifts silently.

Implementation · 12 weeks

  1. Weeks 1-2 · Diagnostic & data audit

    12 source systems analyzed, 400+ variables identified (sales, weather, contracts, geo, holidays, economic). 60 interviews in 2 weeks with ops, IT, finance, sales. Output: 1 end-to-end schema, 1 measured baseline at 78%.

  2. Weeks 3-6 · Baseline model & validation

    Random Forest + 12-month rolling cross-validation. Iteration over 8 feature-engineering versions. Final pick: 400 features, RF ensemble + post-hoc corrections for holidays and weather peaks.

  3. Weeks 7-9 · Production pipeline

    Python + scikit-learn on AWS. Daily cron, data warehouse writes, weekly retraining. Integration tests with the planning tool. 50-page handoff documentation for the internal data team.

  4. Weeks 10-12 · Gradual rollout & training

    10% of volume (3 pilot depots) week 10, 50% week 11, 100% week 12. Comparison vs control group at each step. 2 critical bugs caught and fixed in pilot — invisible in synthetic tests.

Measured results

Measured over the first 6 months in production (vs prior 6 months, same seasonality):

  • Forecast accuracy: 78% → 92% (+14 pts)
  • Logistics costs: −35% in pilot, −22% full rollout (effect diluted on less-forecastable zones)
  • Annual savings: €500K extrapolated full run
  • Analyst time: 60% spreadsheets → 15% (rest goes to high-value scenario analysis)
  • Time-to-value: 12 weeks kickoff → first production delivery

Lessons

Interpretability isn't a nice-to-have

Without it, the business team doesn't trust the model, and it ends up shelved. RF + SHAP made every forecast "debuggable" in 2 minutes — that's what took adoption from 30% to 95%.

Real data is 20% messier than your dev set

During rollout, we found: inconsistent timezones across 3 systems, legacy contracts with empty fields, undocumented regional holidays. If you only test on synthetic, you find these bugs at the client.

Gradual rollout saved the project

The 2 critical bugs caught in 10% pilot would have blocked operations at 100%. Lesson: never go 100% on day 1, regardless of sponsor pressure.

The handoff doc is worth more than the model

6 months after I left, the internal data team retrained the model, added 30 features, expanded to 2 new countries. Without the 50-page handoff, the project would have stalled.

Tech stack

Python 3.10scikit-learnpandasAWS Batch + S3Snowflake (data warehouse)Airflow (orchestration)Slack (alerting)MLflow (tracking)

Got a similar problem?

If you have a forecasting, supply chain, classification or extraction problem where AI could unlock a bottleneck, let's talk. Free 15-min diagnostic, no commitment.

How a European energy major saved 500K€/year with AI demand forecasting | Godi.AI | Godi.AI