Multi-depot routing alongside Webfleet

What Webfleet documents about depots and route planning

The WEBFLEET features page documents A-to-B route planning with waypoints, traffic-aware navigation and TomTom-heritage HGV restrictions (bridge heights, weight, hazardous-goods routing). Stops, drivers and vehicles can be associated with specific depots; the planner shows the A-to-B route for a depot or filter set on a calendar and map view.

What the WEBFLEET planner does not surface as a lead capability is cross-depot optimization as a first-class input: a single run that takes all depots as inputs, rebalances stops across them under shared constraints, and outputs assignments that may move work between depots. Multi-depot is not listed as a documented constraint on the public planner page. Webfleet’s own integration partner directory routes this type of work to third-party route optimization tools. That decision layer is a different shape of product, and eLogii owns it directly via WEBFLEET.connect.

What cross-depot optimization looks like in practice

Three concrete patterns make the case for multi-depot as a single optimization input:

• Regional service organizations with multiple depots. Utilities, telecom, facilities and distribution operations with three or four depots across a region. Stops come in centrally. The right depot for a given stop is usually the closest with the right skill and available capacity, but not always: a depot running hot needs work taken off it; a depot underused needs work brought to it; an SLA-locked recurring visit may need a less-obvious depot to hit the window.
• Service arms with branch networks. Heavy equipment, building materials, food and beverage distribution. Routes start and end at different depots in the same plan; consolidation across branches drops drive time.
• Hub-and-spoke programs. Drivers start from one depot, pick up parts or stock from a hub at another, then continue to customer sites. The optimizer needs to plan across the depot graph, not within one depot at a time.

In each case, the right answer is decided by the optimizer, not the planner. The dispatcher steers the rules and signs off on the run.

At a glance: an 80-driver four-depot distribution network

A regional European distribution operation running four depots across DACH and the UK. Eighty drivers in the field. Daily delivery routes for recurring commercial accounts; reactive same-day urgent deliveries with SLA terms; parts pickup between depots when a route needs stock from elsewhere in the network. Webfleet handles the telematics cleanly: GPS trail on every vehicle, Tachograph Manager handling EU HGV compliance, OptiDrive 360 scoring the drivers, Webfleet Video on the heaviest vehicles.

The friction sits at the depot interface. Depot A runs hot most weeks while depot D runs underused; capacity drift accumulates because no one has time to look across depots in real time, and the WEBFLEET planner is configured per-depot so it can’t see the imbalance. Routes that should start at depot A, pick up at depot B, then continue to customers run as two separate trips because the planner can only see one depot view at a time. Drive time creeps. The team had evaluated a third-party route optimization tool through Webfleet’s integration partner directory but the second commercial relationship and the dual UI was off-putting. A cross-depot optimization run via eLogii takes all four depots as one input, drops drive time around 15–20% across the network, and rebalances capacity within roughly +/- 5%, plugged directly into WEBFLEET.connect. Webfleet continues to own the GPS, OptiDrive, tachograph and Webfleet Video record; what changes is which depot does which stop.

The workaround in Webfleet and where it breaks

Two workarounds. The first is planner-driven: the planner assigns stops to depots based on rules of thumb (closest, skill match, current capacity), then the WEBFLEET planner routes A-to-B within each depot. The second is a partner integration (third-party route optimization tools) that handles constraint VRP outside Webfleet and pushes routes back in. At small numbers of depots and stable work mix, the planner-only path is fine. The friction shows up at scale: capacity at one depot stays underused while another runs hot; drive time grows because work isn’t reassigned to the depot that should actually do it; SLA hits depend on the planner spotting the constraint in time; the WEBFLEET planner is hard to use cleanly across multiple depots at once because multi-depot is not a documented constraint on the public page. The partner-integration path solves the constraint side but adds a second commercial relationship, a second UI and a data-handoff between systems. The longer the operation runs without a directly-integrated cross-depot optimization step, the more drift accumulates.

How eLogii handles multi-depot routing

Multi-depot is a first-class input. Each depot has a location, opening hours, vehicle pool, skill mix, capacity and (where it matters) shift patterns. Drivers are associated with home depots but the optimizer can reassign work between depots when constraints allow. A single run produces one consistent plan.

• Single optimization across depots. Both the Default engine (high-throughput daily planning) and the Advanced engine (constraint-heavy, long-horizon) take multi-depot as input. The output is one plan, not the sum of per-depot plans.
• Routes that cross depots. A route can start at one depot, end at another, or pick up at a third (parts collection, vehicle changeover, hand-off to a colleague). Modeled directly, not bolted on.
• Capacity balancing across depots. If one depot is over capacity for the day, the optimizer reassigns work to a depot with headroom, respecting skill, drive time and SLA constraints.
• Multi-depot recurring programs. Quarterly preventive maintenance, monthly inspections, weekly commercial service running across depots is modeled as recurring inputs, not as separate calendars reconciled by hand.
• Rule-based protection. The dispatcher can protect specific assignments, lock customer-confirmed slots, exclude depots from a given run. Visible rules, not buried defaults.

How the integration sits with Webfleet

Webfleet stays in place as the system of record for GPS, OptiDrive 360, tachograph and Webfleet Video record. The operational system of record (FSM or ERP) stays in place for the work record. The connector is custom-built against both APIs; there is no published eLogii to Webfleet integration on either side. An iPaaS (Workato, MuleSoft) is a common middleware choice.

1. Read from the operational source. eLogii reads stops, drivers, vehicles, depots, skills and capacity from the FSM, ERP or Webfleet directly via WEBFLEET.connect.
2. Optimize across depots in eLogii. A single run produces assignments and routes across all depots with skills, capacity, time windows, SLAs and recurring cadences honored.
3. Write back. Routes and ETAs are written back over WEBFLEET.connect, mapped to the right depot and driver. The driver opens the Webfleet Work App or PRO Driver Terminal in the cab. Webfleet captures the in-cab GPS, OptiDrive, tachograph and Webfleet Video stream on top of the planned route.
4. Driver experience unchanged. The driver opens the same mobile app. The cross-depot decisions are already baked into the assignments.

Most teams complete the connector build in 3 to 5 weeks. Typical first wave: the regional book where cross-depot rebalancing is the dominant planning task, or the service arm running parallel to the contract-maintenance business.

Frequently asked questions

Does Webfleet support multi-depot routing?

Webfleet supports planning per depot via the WEBFLEET planner: stops, vehicles and drivers can be associated with specific depots, and the planner shows A-to-B routes with waypoints. The planner page documents traffic-aware navigation and HGV restrictions (bridge heights, weight, hazardous-goods routing) drawn from the TomTom map heritage. Multi-depot is not explicitly listed as a supported constraint on the public product page. What it does not position as a lead surface is cross-depot optimization as a first-class input: a single optimization run that considers all depots together, rebalances stops across depots under skill and capacity constraints, and produces assignments that may move stops between depots when the math says they should move. Webfleet’s own integration partner directory routes this to a third-party route optimization tool. That is the decision layer eLogii adds directly, plugged into WEBFLEET.connect.

What does cross-depot optimization mean in practice?

Three concrete patterns. First, regional service organizations with three or four depots: the optimizer needs to decide which depot a stop goes to based on skill availability, drive time, current capacity and SLA, not just which depot is closest. Second, service arms with branch networks: routes start and end at different depots in the same plan, and consolidation across branches drops drive time materially. Third, hub-and-spoke programs where drivers can start from one depot, pick up parts from another, then continue to customer sites. None of these are solvable as the sum of single-depot optimizations.

What is the workaround in Webfleet and where does it break?

Two workarounds. The first is planner-driven: the planner assigns work to each depot based on rules of thumb, then the WEBFLEET planner routes A-to-B within each depot. The second is a partner integration (third-party route optimization tools) that handles constraint VRP outside Webfleet and pushes routes back in. The planner-only path doesn’t scale past a few depots and a stable work mix. The partner-integration path adds a second commercial relationship, a second UI and a data-handoff between systems. Both leave the cross-depot view in a manager’s head or in a separate tool. Capacity at one depot stays underused while another runs hot. Drive time grows because work isn’t reassigned to the depot that should actually do it. The longer the operation runs, the more this drift accumulates.

How does eLogii handle multi-depot routing?

Multi-depot is a first-class input to the optimizer. Each depot has a location, opening hours, vehicle pool, skill mix and capacity. Drivers are associated with home depots but the optimizer can reassign work between depots when constraints allow. A single optimization run produces routes that may start at one depot, end at another, or pick up at a third. The output is one consistent plan, not the sum of per-depot plans. Both the Default engine and the Advanced engine handle multi-depot inputs.

How does the multi-depot integration with Webfleet work?

Custom integration against WEBFLEET.connect (OAuth 2.0) and the operational system of record (FSM or ERP). eLogii reads stops, drivers, vehicles, depots and skills from the operational systems. The optimization run treats all depots as a single problem. Routes and ETAs are written back over WEBFLEET.connect, mapped to the appropriate depots and drivers; the driver opens the Webfleet Work App or PRO Driver Terminal in the cab and follows the assigned route. Webfleet captures the in-cab GPS, OptiDrive, tachograph and Webfleet Video stream. Typical connector build: 3 to 5 weeks.