A commercial laundry: fourteen van routes replanned nightly, not by hand
A commercial laundry in Essex was replanning fourteen delivery routes every evening with a transport manager, a wall map, and a magnetic board. The planning took three hours.
The reading
A commercial laundry serving hotels, restaurants, and care homes across Essex, Hertfordshire, and north-east London. Fourteen vans, 340 regular customers, roughly 1,100 drop-and-collect visits per week. The transport manager, in post since 2008, planned the next day's routes each evening on a magnetic board, moving customer tags between van columns.
The planning took three hours on a quiet day and five on a busy one. It was good; the transport manager was skilled, and years of local knowledge about which hotels wanted deliveries before 10am and which care homes had awkward parking were embedded in his hands.
He had been promoted to operations director in principle for eighteen months. He had not been promoted in practice because no one else could do the planning.
The board and the hands
The board worked. The problem was that the board required him, every evening, and that his judgement, however good, had never been written down. The firm was running a sophisticated optimisation problem on one person's memory and a sheet of magnetic metal.
The directors had looked at off-the-shelf route planning software. Each attempt had failed because the software did not know that the care home in Billericay insisted on the same driver, or that the restaurant in Shoreditch would not accept deliveries during their lunch service.
- 14 vans, 340 customers, ~1,100 weekly visits
- 3-5 hours of nightly manual planning
- Transport manager's promotion blocked by indispensability
- Previous off-the-shelf tools unable to encode customer constraints
- No mileage or time measurement against plan
What we built
We wrote a route optimiser specific to the firm's constraints, with a constraint language the transport manager could edit himself. Each customer had a record of their windows, their preferred driver (if any), their access notes, and their service frequency. The optimiser produced a next-day plan in about four minutes. The transport manager reviewed it, overrode roughly 8% of allocations, and the plan was issued.
The technical choice we weighed longest: whether to use a commercial solver or write our own. We used a commercial solver (OR-Tools) and spent our effort on the constraint modelling, which was the actual difficulty. The firm's edge was in knowing their customers, not in solver cleverness, and the constraints had to be in a form the transport manager could read.
Stack: a Python service, OR-Tools for the optimisation, Postgres for the customer model, a web UI for review and override.
The numbers at ninety days
| What | Before | After |
|---|---|---|
| Nightly planning time | 3-5 hr | 15 min review |
| Total weekly van mileage | 11,400 | 9,700 |
| Overtime hours per week | 46 | 18 |
| On-time delivery rate | 91% | 97% |
| Transport manager's actual day job | 40% planning | Operations director |
The constraint, not the optimisation
The commercial route planners had failed because they treated the problem as optimisation. The firm's problem was constraint modelling: knowing, correctly, what each customer needed. Once the constraints were right, the optimisation was easy.
The one-week training test applied to the new deputy transport manager: she could run the system, including overrides, in a week. She could not have run the magnetic board in a year. The firm now has two people who can do the job because the job has been written down.