Case study
A propane and heating fuel distributor delivering to roughly 9,000 rural households and farms across New Brunswick and Nova Scotia now opens dispatch to a route plan built from three years of delivery history, tank telemetry and degree day records.
Named only with client approval Figures marked are illustrative Reply within one business day
Forecast engine
Demand forecast - next 8 weeks
94.2%
Accuracy
+18%
Vs baseline
8w
Horizon
Retrained nightly on 14 months of order behaviour.
OlDevs built a customer tank level demand forecasting system for a propane and heating fuel distributor delivering to roughly 9,000 rural households and farms across New Brunswick and Nova Scotia.Gradient boosted trees in Python, trained on three years of delivery history, tank telemetry and degree day records, run nightly and write forecasts with confidence bands into the dispatch board the planners already work from. Planner overrides are captured and fed back as a training signal instead of being lost in a side file. The distributor reports −31% forecast error and −24% emergency refill runs, with 6 depots planning from one forecast.
Key facts
The challenge
Delivery volume swung with the weather, but the weekly plan was a spreadsheet one person rebuilt every Monday from last year's numbers and a feel for how cold it was going to get. Trucks ran half empty in mild weeks and missed customers during cold snaps, and the emergency refills that followed consumed the margin on long rural routes. Nobody could say in advance which of the six depots was about to run short.
The weekly plan was rebuilt by hand every Monday from last year's numbers and a personal read on the coming cold. One person held the method in their head, so the quality of the plan moved with their availability and no part of it could be checked or improved.
Mild weeks sent trucks out under loaded on long rural routes, so the cost of getting a litre to a farm gate climbed at exactly the moment volume fell. Capacity was booked against a guess rather than against what the tanks in that district actually needed.
When temperatures dropped the plan missed customers, and the emergency refills that followed ate the margin on long rural routes. Each unplanned run pulled a truck off its scheduled route, which pushed more customers into the same position the next day.
Nobody could say in advance which of the six depots was about to run short. Stock was judged depot by depot with no shared view of the week ahead, so one location could sit on volume it did not need while another ran itself down.
What we built
We built a demand model at the level of the individual customer tank, trained on three years of delivery history, tank telemetry and degree day records, using gradient boosted trees in Python. Forecasts run nightly and land in the dispatch board the planners already work from, each with a confidence band so they know when to hold capacity in reserve. Planner overrides are captured and fed back as a training signal rather than lost in a side file.
Gradient boosted trees in Python, trained on three years of delivery history, tank telemetry and degree day records. Forecasting each customer tank rather than each depot means the weekly plan reflects the real draw sitting along every route.
Forecasts are produced overnight and written into the dispatch board planners already work from, so nobody opens a modelling tool to get a route plan. The week is on screen when dispatch starts instead of being rebuilt from last year's numbers.
Each forecast carries a confidence band, so a planner can see when a figure is firm and when the week is genuinely uncertain. A wide band during unsettled weather becomes a prompt to hold a truck in reserve rather than a surprise on the day.
When a planner changes a forecast, the change and its context are recorded and fed back as a training signal. Local knowledge about a farm, a road or a customer now improves the next model instead of quietly contradicting it in a side file.
Process
Data review
We pulled three years of delivery history, tank telemetry and degree day records into one place and worked out what was genuinely usable before any modelling began.
Understanding the Monday plan
We worked through how the weekly spreadsheet was actually built, because the judgement inside it was the thing a forecast had to match before it could improve on anything.
Model build
Gradient boosted trees trained per customer tank in Python, with a working version for the planning team to look at every week rather than a progress report.
Dispatch integration
Forecasts and confidence bands were written into the dispatch board the planners already use, with a nightly run scheduled so the plan is waiting each morning.
Handover and retraining
We set up override capture, documented the retraining routine and went through reading confidence bands with the planning team before handing over all code and accounts.
Stack
Modelling
Data
Scheduling and delivery
Feedback and upkeep
−31%
Forecast error
−24%
Emergency refill runs
6
Depots on one forecast
Outcomes
−31% forecast error, so route capacity is now booked against a number the planning team can look at and explain rather than a read on how cold the week feels.
−24% emergency refill runs. Fewer trucks are pulled off a scheduled route mid week, which keeps the following day's plan intact instead of compounding the problem.
6 depots on one forecast means a shortfall at one location is visible days before it turns into a missed delivery, and stock can be moved while there is still time to move it.
The weekly rebuild is gone. Planners start from a plan that is already on screen and spend their time on the exceptions the confidence bands flag rather than on assembling the plan.
In their words
We stopped arguing about the weather on Monday morning, because the route plan is already on the screen when dispatch opens.
Operations manager, rural fuel distributor
Energy distribution
FAQ
This model was trained on three years of delivery history alongside tank telemetry and degree day records, which gave it several full heating seasons to learn from. Less history can still work, but seasonal demand needs at least a couple of complete cycles before a forecast holds up during a cold snap rather than only in an average week.
That is what the confidence bands are for. When conditions move outside the patterns in the training data, the band widens and the planner sees that the forecast is uncertain, which is the signal to hold capacity in reserve. The model is not asked to be right about everything, only to be honest about what it does not know.
No. Forecasts are written into the dispatch board the planners already work from, so the daily routine does not change. The new part is reading a confidence band and knowing when to reserve a truck, which we covered with the planning team directly during handover rather than in a manual nobody opens.
It is captured rather than lost. When a planner overrides a forecast, the change and its context are recorded and fed back as a training signal, so the next version of the model learns from it. Judgement about a particular farm or a road that closes in winter becomes part of the system instead of a note in a side file.
The client does. OlDevs hands over all code, data pipelines, model artefacts and accounts at the end of the engagement, along with the retraining routine and its documentation. There is no dependency on us to keep the nightly run going, and nothing is locked behind a platform you would have to keep paying us to reach.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.