Single-depot routing is a solved problem you can buy off the shelf. Multi-depot routing introduces a second decision — which depot serves this customer — and that decision is usually made once, informally, and never revisited.
The three levels of multi-depot planning
Level 1: Independent depots. Each depot has a fixed customer list and plans in isolation. Simple, and it wastes capacity at every boundary. Most networks start here and many stay here.
Level 2: Flexible boundaries. Customers near a boundary can be served by either depot, decided periodically based on load and geography. Captures most of the available gain with modest complexity.
Level 3: Fully integrated network planning. The optimiser assigns every customer to a depot and vehicle each planning cycle. Highest efficiency, highest data and process demands, hardest for the organisation to absorb.
Most operations should aim for level 2 and treat level 3 as a later ambition — the incremental gain from 2 to 3 is usually far smaller than from 1 to 2, and the change management cost is far larger.
Re-assign only the customers whose nearest depot differs from their assigned depot by more than 20 minutes of drive time.
Where the waste hides at boundaries
- Overlapping tails. Two depots each send a vehicle into the same fringe area to serve a handful of customers, and both routes finish with long, low-density runs.
- Asymmetric loading. One depot is at 95% capacity and adds overtime while its neighbour runs at 70%.
- Historical assignment. A customer assigned to depot A in 2016 when they were near it, since when a new depot opened five miles away.
- Product constraints treated as depot constraints. Only depot A stocks a chilled line, so all of that customer's volume ships from A, including ambient stock the nearer depot holds.
Quantify it before designing anything: for each customer, compute the drive time from every depot. Sort by "distance to assigned depot minus distance to nearest depot". A handful of customers usually account for a disproportionate share of the total waste.
The assignment criteria that matter
| Criterion | Why it matters |
|---|---|
| Drive time from depot | Direct cost driver |
| Stock availability | An assignment that cannot be fulfilled is not an assignment |
| Depot capacity | Dock doors, pick capacity, vehicle count, staff |
| Vehicle type fit | Tail-lifts, temperature control, weight limits |
| Service continuity | Same driver and delivery time preserved |
| Return leg utility | Backhaul or collection opportunities |
| Commercial ownership | Which depot's sales team owns the account |
The last one causes more arguments than all the others combined, because it is a compensation question disguised as a logistics question. Settle it explicitly — usually by decoupling account ownership from physical fulfilment — or the network design will be relitigated every quarter.
Planning patterns that work
Zone-based with flex bands. Each depot owns a core zone; a defined band between zones is planned jointly and allocated daily by load. Straightforward to explain and to audit.
Primary and secondary assignment. Every customer has a primary depot and an authorised secondary. Overflow goes to the secondary only when the primary is over capacity. Keeps service predictable while giving the system a valve.
Trunk and satellite. A large depot trunks pre-loaded stock to satellite points where local vehicles complete the last leg. Common in urban delivery and in operations using small vehicles for access reasons. Adds a scheduling dependency: the satellite plan cannot start before the trunk arrives, and the routing tool must model that link.
Depot as a constraint, not a container. Advanced networks stop thinking "customers belong to depots" and start thinking "vehicles start and end somewhere". Powerful, and it demands genuinely reliable stock visibility across sites.
What to check in the software
Multi-depot capability is a common gap between demo and reality. Ask:
- Can it assign customers to depots as part of optimisation, or only route within a fixed assignment?
- Can a vehicle start at one depot and end at another?
- Can it model per-depot capacity limits — dock doors, loading windows, pick throughput?
- Can it respect stock availability by depot, or does it assume everything is available everywhere?
- Can it produce a network-level comparison of scenarios, not just route-level?
- How does it handle depot-specific driver rules and shift patterns?
Products that answer no to "can a vehicle end at a different depot" are single-depot products with a depot dropdown.
Reviewing network structure
Route planning software will optimise within your network; it will not tell you the network is wrong. Separately, on an annual cycle, ask:
- Would a depot in a different location serve the same customers with fewer vehicle-hours?
- Are any depots small enough that their fixed cost exceeds the drive time they save?
- Has demand shifted geographically since the network was designed?
- Are we paying for capacity at three sites that two could carry?
These are strategic questions, usually answered with a network modelling exercise rather than daily routing software — but the routing system's historical data is the best input available for them.
Common questions
How often should depot assignments be reviewed?
Quarterly for boundary customers, annually for the whole base. Any new depot opening or closure obviously forces a full review, as does a shift of more than about 10% in regional volume.
Should we allow cross-depot service by default?
No — allow it deliberately, within defined bands. Unrestricted cross-depot service makes stock, settlement and accountability harder to reason about, and the incremental efficiency over a well-designed flex band is small.
What is the biggest hidden cost of multi-depot networks?
Inventory. Every additional stocking point raises total safety stock and the risk of the wrong stock being in the wrong place. A network design that looks efficient in transport terms can be expensive once working capital is included.
Can routing software model trunking?
Some can, many cannot properly. If trunk-and-satellite is core to your operation, make it a scripted test in the demo, including what happens when a trunk runs late.
How do we split shared customers between depots?
By delivery, not by customer, where products and stock allow — chilled from the chilled depot, ambient from the nearest. This requires order-line-level routing capability, which is worth confirming explicitly during evaluation.
