Case Study - Create Your Way

For the exec · 30 second read

The verdict

9 of 12 depots live

75%

Of dispatch decisions now made without a planner

Planners stopped rebuilding the schedule by hand every morning, and late deliveries fell with it.

41%

Fewer late deliveries

Drop in pallets arriving outside the agreed window.

6 hrs

Planner time returned daily

Manual replanning across the three largest depots.

11 wks

To first depot live

From kickoff to Rotterdam running on the new scheduler.

Want the proof behind this? →

Back to the question ↑

For the buyer · 3 minute read

The proof

Haldern Freight moves 4,000 pallets a day across twelve depots. Every morning, three planners rebuilt the entire schedule by hand.

Each depot planned in its own spreadsheet, with no view of the depot next door. A single late truck in Duisburg was absorbed locally, then reappeared two days later as a missed window in Ghent, with nobody able to trace why. Haldern had already bought a routing product twice; both times it was quietly abandoned within a quarter because it could not accommodate the overrides planners knew were necessary.

So we did not start with a solver. We started with the overrides, on the assumption that the planners were right and the previous tools had simply refused to listen. The scheduler we eventually built earns its decisions against those overrides rather than against an optimum nobody in the business recognised.

Before

/

After

22%

Late deliveries

3 hrs

Daily replanning, per depot

0

Depots on a shared plan

Twelve depots planning in isolation, each in its own spreadsheet, each absorbing the others’ delays without knowing it.

13%

Late deliveries

20 min

Daily replanning, per depot

9

Depots on a shared plan

One plan, regenerated hourly, with planners intervening by exception. Nine depots live in eight months; the remaining three are scheduled for Q3.

“We stopped arguing about whose spreadsheet was right and started arguing about the actual routes.”

Marit Deveraux · Head of Operations, Haldern Freight

“The first week was uncomfortable. By the third, nobody wanted their spreadsheet back.”

Tomas Ek · Depot Manager, Rotterdam

Outcomes

Late deliveries down across every live depot

−41%

Planner hours returned to the operation each day

6 hrs

Depots running on one shared plan

9 of 12

Empty return legs removed from the network

−18%

What it took

Eight months, a team of five, two of them embedded on site. The decision that made the rest possible was an unpopular one: we froze the depot spreadsheets in week three, before the scheduler was fully trusted. It forced the edge cases into the open while there was still budget to fix them.

Show me how it was built →

Back to the question ↑

For the practitioner · 8 minute read

The build

Method

01 Shadow the planners

02 Model one depot

03 Roll out by corridor

04 Hand over the tuning

8 months · 5 people, 2 embedded on site

Phase 01

Shadow the planners

Two weeks sitting in the 06:00 planning session at Rotterdam, Ghent and Duisburg. We logged every manual override and the reason given for it: 312 in total. That log became the test set for everything that followed, and the argument we used whenever the model and a planner disagreed.

Phase 02

Model one depot

Rotterdam only, running in shadow mode beside the human plan for six weeks. Where the two disagreed we asked the planner which was right. That answer decided whether we shipped, not the solver’s objective score. Shadow mode caught 40 of the 312 overrides we had modelled wrongly.

Phase 03

Roll out by corridor

We cut the geography-first rollout. Depots that share freight have to go live together or the shared plan means nothing, so we rolled out by corridor instead: three depots at a time, each corridor fully live before the next started. This added six weeks to the plan and removed the biggest source of risk from it.

Phase 04

Hand over the tuning

Constraints moved into a config file the planners edit themselves. They own the cost weights and the depot cut-off times; we own the solver. Two planners were trained as config owners, with a weekly review for the first quarter after handover.

Stack

Scheduling

OR-Tools CP-SAT, on a 90-second solve budget

Data

Postgres 15, with dbt for the depot feeds

Interface

React planner console, one screen per depot

Monitoring

Grafana, alerting on solve time and override rate

The detail · open a row

The overrides we could not model

Roughly one override in nine came down to something written nowhere: a customer who takes deliveries early on Fridays, a loading bay that floods in heavy rain, a driver who is not allowed on one particular site. We spent three weeks trying to infer these from historical data and got nowhere. In the end we stopped trying and gave planners a place to record them as hard constraints instead. That took four days and solved it.

Freezing the spreadsheets early

The settings that actually mattered

What we would do differently

We built the planner console before we knew what planners would actually need to override, so version one shipped with the wrong three buttons and a fortnight was spent unpicking it. Shadow mode should have run two weeks longer with the console sketched on paper. We would also have brought the two config owners in at phase two rather than phase four. They found problems in the constraint model that we did not.

Just give me the verdict →

Back to the question ↑

Haldern Freight · Case study · 2025

What brought you here?

1

I need the number

30 second read

2

I need proof

3 minute read

3

I need the how

8 minute read

For the exec · 30 second read

The verdict

9 of 12 depots live

Of dispatch decisions now made without a planner

Planners stopped rebuilding the schedule by hand every morning, and late deliveries fell with it.

41%

Fewer late deliveries

6 hrs

Planner time returned daily

11 wks

To first depot live

22%

Late deliveries

3 hrs

Daily replanning, per depot

0

Depots on a shared plan

13%

Late deliveries

20 min

Daily replanning, per depot

9

Depots on a shared plan

Scheduling

OR-Tools CP-SAT, on a 90-second solve budget

Data

Postgres 15, with dbt for the depot feeds

Interface

React planner console, one screen per depot

Monitoring

Grafana, alerting on solve time and override rate

The overrides we could not model

Freezing the spreadsheets early

The settings that actually mattered

What we would do differently

Haldern Freight

Credits

Reusing this template