Single-depot routing is already hard. Multi-depot routing is a different problem category. When you add a second distribution center, you don't just double your complexity — you introduce a whole new class of decisions that most routing products weren't designed to handle well: which stop goes to which depot, how you balance vehicle capacity across locations, and what you do when real-time conditions make yesterday's stop assignment wrong.
We built multi-depot support into Routely because a meaningful portion of regional carriers in the Columbus metro run two to four distribution points. That might be a main warehouse on the east side plus a cross-dock facility near the I-270 outer belt, or a primary distribution center with a smaller satellite depot serving the northwest suburbs. The geography varies, but the operational problems show up in predictable places.
The stop assignment problem comes first
Before you can build routes, you need to decide which depot each stop should originate from. This is the multi-depot assignment problem, and there's no universally correct answer — it depends on vehicle capacity, time window constraints, route density, and driver availability at each location.
The naive approach is proximity: assign each stop to the nearest depot. This works reasonably well as a starting point but breaks down in several common situations. First, if your depots have different vehicle capacity profiles — say, one facility has larger box trucks and the other has cargo vans — proximity-based assignment ignores whether the cargo volume at a stop is appropriate for the vehicle type available at that depot. Second, proximity ignores time window feasibility. A stop that's geographically closer to Depot A might only be reachable within its service-level constraint from Depot B given current route density.
A better assignment algorithm treats the depot decision as part of the same optimization pass as stop sequencing. You're solving for minimum total route cost across all depots simultaneously, subject to vehicle capacity constraints at each location. This is computationally heavier than per-depot routing, but it produces assignments that account for the actual operational state of each facility rather than just map distance.
Vehicle capacity as a cross-depot constraint
One of the practical challenges in multi-depot operations is that vehicle capacity isn't just a per-route constraint — it's a cross-depot resource allocation problem. If Depot A has four drivers available this morning and Depot B has six, but Depot A's territory has 40% more stops than expected due to an order surge, you have options: you can overload Depot A's routes, you can re-assign some stops to Depot B (requiring longer initial drive-out), or you can shuffle a driver from B to A if your operations allow cross-depot driver assignments.
Most regional carriers we've worked with don't move drivers between depots mid-day — the logistics of getting a driver to the alternate location usually cost more time than the route benefit. But they do use morning stop reassignment as a buffer. If Depot A is running heavy on vehicle capacity, the optimizer can pull 8–12 stops from the A territory boundary and assign them to Depot B's vehicles, which may have slack capacity. The trade-off is a slightly longer drive-out from B to reach those border stops, weighted against overloading A's routes and risking late completions.
The right balance depends on where your service-level constraints are tightest. If you have customers with hard 2-hour delivery windows, overloading routes and running late is a worse outcome than the mild efficiency cost of a longer drive-out from the alternate depot.
The reassignment cost problem in real-time re-sequencing
Here's where multi-depot routing gets genuinely difficult in a live operations context: once a driver has departed Depot A with a manifest, you can re-sequence their remaining stops — but you can't reassign those stops to Depot B. The depot assignment is fixed at departure. The only re-sequencing lever available is within the driver's existing stop list.
This means that in multi-depot operations, the quality of the initial assignment matters more than in single-depot routing. If Depot A's routes are badly constructed at launch and run into capacity or time window problems during the day, you can't fix it by re-routing some stops through Depot B. The optimization window closes when the first vehicle leaves the dock.
The implication for system design: multi-depot routing systems need to spend more compute at planning time to get the initial assignment right, because the real-time correction surface is narrower. In single-depot routing, a suboptimal initial sequence can be largely recovered by good real-time re-sequencing. In multi-depot routing, a bad initial depot assignment is permanent for that dispatch cycle.
We're not saying real-time re-sequencing loses value in multi-depot environments — it's still essential for responding to traffic incidents, failed delivery attempts, and time window changes. But the expectation that live re-sequencing can compensate for poor planning-time decisions is less valid when you have multiple depots.
Cross-depot visibility for dispatchers
A practical issue that doesn't get discussed enough: multi-depot operations require dispatchers to have visibility across all active routes regardless of originating depot. In many carrier operations, each depot has its own dispatch queue and its own dispatcher. That structure makes organizational sense but creates a problem when real-time route management requires cross-depot awareness.
Consider a scenario: a time-sensitive delivery on the border zone between two depot territories is running late due to a traffic incident on the driver's route. The dispatcher at Depot A can see this — it's their driver. But there may be a Depot B driver two stops away from that location with spare capacity in their schedule. A unified dispatch view would surface this; separate per-depot views wouldn't.
This is an organizational design challenge as much as a software challenge. The technology can provide the unified view; whether dispatchers have the authority and workflow to act on cross-depot information is an operations decision. For carriers that are willing to give dispatchers cross-depot visibility, the routing efficiency gains are real. For carriers that prefer strict depot-based operational boundaries, the gains are more limited.
How route density shifts across depots
Route density — stops per square mile in the service territory — typically isn't uniform across depots. One facility may serve a dense inner-ring territory with 8–12 stops per route-mile; another may cover a lower-density outer suburban zone where drivers cover more ground per stop. This asymmetry affects how you should measure performance across depots.
A dispatcher comparing stops-per-route between the two depots will see the inner-ring depot outperform on that metric almost by definition. This creates a misleading picture of efficiency. The outer depot's drivers may be running perfectly optimized routes for their territory; the lower stop count per route reflects geography, not performance.
Better cross-depot performance metrics focus on on-time percentage, failed delivery attempt rate, and vehicle utilization (cargo weight and volume as a fraction of capacity) — measures that normalize for territory differences. Stop count per route is a useful operational planning number, not a cross-depot efficiency comparator.
What to look for in multi-depot routing software
When evaluating whether a routing system actually handles multi-depot well, the questions worth asking are concrete ones. Does the system solve depot assignment and stop sequencing in a single optimization pass, or does it run per-depot after a separate assignment step? How does it handle capacity constraints when one depot is running over and another has slack? What visibility does it provide into stop assignment rationale — can a dispatcher understand why a particular stop was assigned to Depot B instead of A?
In Routely, multi-depot operations produce a unified dispatch queue that shows all active routes across facilities, with per-depot filtering available but cross-depot visibility as the default. When the assignment optimizer moves a stop from one depot's territory to another, the reasoning is surfaced: "Stop reassigned to Depot B — Depot A route exceeding vehicle capacity limit." This matters because dispatchers who don't understand why assignments changed tend to override the optimizer manually, which usually makes things worse.
Multi-depot routing done well is genuinely hard. The combinatorial space is much larger than single-depot problems, the real-time correction surface is narrower, and the organizational dynamics of cross-depot visibility create friction. But for regional carriers who've grown past a single facility, getting it right is the difference between a fleet that scales and one that adds overhead proportional to every depot you open.
