WEBFLEET planner limitations: adding a constraint-based engine alongside Webfleet

What Webfleet documents about route planning

Webfleet positions the route planning module as a planner-facing tool on top of the WEBFLEET telematics platform. The route planning product page and integration partner directory together name the following:

• A-to-B route planner with waypoints. Plan a route from start to end with waypoints in between, sent directly to the driver via the Webfleet Work App or PRO Driver Terminal. Built around the planner setting up the route, not an autonomous solver.
• Traffic-aware navigation. TomTom-heritage traffic data drives ETAs and re-routing as conditions change.
• HGV restrictions. Bridge heights, weight, hazardous-goods routing and other commercial-vehicle restrictions in the map data. The strongest part of the Webfleet routing surface.
• Glossary-level reference to optimization. Webfleet’s route optimization glossary page describes “algorithms that pick fastest, fuel-efficient or sustainable routes” without documenting time-window, capacity, skill, multi-depot or multi-day constraints as native inputs.
• Partner ecosystem for constraint VRP. Webfleet’s own integration partner directory lists third-party route optimization tools as the named route-optimization partners that ship time-window, capacity, skill, multi-depot and multi-day constraints.

What the WEBFLEET planner does not position as the lead capability is a constraint-based optimization engine across the full operational problem: an input model that spans every stop, every driver, every vehicle, every depot, every skill, every time window, every SLA and every recurring cadence in one solver run, with a documented optimization API and operator-visible assignment and load-balancing modes. Constraint VRP is offloaded to the partner ecosystem; multi-depot, recurring routes and named multi-day horizons are not surfaced on the public product page. That decision layer is what eLogii adds, callable over REST and plugged directly into WEBFLEET.connect rather than via a partner.

Where the WEBFLEET planner reaches its boundary

The pattern is consistent across operations where this comes up:

• Planner-as-optimizer. The planner spends the morning hand-balancing jobs across drivers, depots and skills. The WEBFLEET planner makes the A-to-B route easy to draw; the constraint side (which driver, which depot, which time window, which skill) is the bottleneck.
• Multi-depot rebalancing. A service or distribution organization with three or four depots needs the optimizer to treat all depots as part of the same problem. Multi-depot is not listed as a supported constraint on the WEBFLEET planner page; cross-depot rebalancing as a single optimization input is operator work.
• Recurring service programs at scale. Quarterly preventive, monthly inspections, contract-driven recurring visits across a large customer base. Recurring or template routes are not surfaced on the WEBFLEET planner page; optimization across the recurring book, interacting with reactive break-fix, is its own problem.
• Constraint-heavy commercial service. A two-driver install over three days with a customer-confirmed start window, an asset-specific skill that needs the same crew back on day three, an overnight stop. The constraints are real and there are usually hundreds of jobs to satisfy them across.
• SLA-locked work mixed with flexible. The optimizer needs to protect the SLA-locked bookings, balance the flexible ones, and re-optimize on the fly when a no-access comes in.

At a glance: a 60-driver commercial services organization on Webfleet

A commercial services organization running break-fix and compliance work across three regional depots, primarily in DACH and the UK. Sixty drivers in the field. Two planners. The book splits roughly 50% recurring compliance visits (quarterly preventive against contracted SLA terms) and 50% reactive break-fix on regulated equipment with SLA terms. Webfleet covers 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 bottleneck shows up in the morning. Two planners spend an hour hand-balancing reactive against recurring, reconciling yesterday’s routes against today’s actual stops, and working around the driver off sick at depot 2 by manual moves across depots 1 and 3. The WEBFLEET planner runs A-to-B with waypoints because the constraint model needed to span three depots and a mix of recurring and reactive work is not the shape the planner is built around; the team had considered adding a third-party route optimization tool via the partner directory but the second commercial relationship and the dual UI was off-putting. Webfleet tracks the vehicle, the driver, the tachograph and the OptiDrive score cleanly; the cross-depot, cross-day routing decision is planner-led. Adding eLogii compresses that morning hour into a 10-minute review of a constraint-aware optimization run, plugged directly into WEBFLEET.connect with one commercial relationship; Webfleet continues to own the GPS, OptiDrive, tachograph and Webfleet Video record.

The workaround in Webfleet and where it breaks

The workaround is the planner, with either the WEBFLEET A-to-B planner alone or one of the integration partners (a third-party route optimization tool) bolted on. The A-to-B planner is good at what it’s built for and an experienced planner can carry a real operation on top of it. The partner integrations work well within their scope but introduce a second commercial relationship, a second UI, and a data-handoff between Webfleet and the partner system. The friction shows up at scale: time spent on planning grows non-linearly with the number of drivers and depots; the bus-factor of the operation is the one planner who knows the territory; cross-day and cross-depot constraints get carried in heads and spreadsheets, not in the model; recurring service programs run as separate calendars reconciled by hand; the partner-system handoff adds latency to live re-planning. When the planner takes leave, planning quality drops visibly.

None of this means Webfleet is the wrong tool. It means there is a constraint-based optimization decision layer the planner today (and the partner integrations partially) is the proxy for, and eLogii owns that layer, plugged directly into WEBFLEET.connect rather than via a partner.

How eLogii’s optimization engine handles this

eLogii’s engine takes a constraint model as input and produces both assignments and routes as output. The dispatcher steers it with rules they can see; the driver executes the plan in the Webfleet Work App or the PRO Driver Terminal in the cab.

• Two engines. The Default engine optimizes 100 tasks in under 10 seconds for high-throughput daily planning. The Advanced engine takes more factors into account and is the choice for multi-depot, multi-day, long-haul and constraint-heavy operations.
• Three assignment modes. Optimize Everything (creates fresh routes including all assignments), Add to Routes, Keep Existing Assignments (incorporates new stops while preserving driver assignments), and Add to Routes, Keep Existing Assignments and ETAs (inserts new stops into available slots without modifying existing stop sequences or ETAs).
• Three load-balancing modes. Most Efficient Routes (fewest vehicles), Balance the Minimum Number of Routes (across load, time, distance or stop count), and Use All Vehicles / Finish as Soon as Possible (maximize speed).
• REST-callable. All six modes are programmatic. Dispatchers can lock specific routes, manually reorder stops, or re-run with new constraints. The optimizer is not a black box.
• Rule-based re-optimization. Re-route a no-access visit to the nearest driver with the right skill, without moving any customer-confirmed bookings in the next 90 minutes. Visible to the dispatcher.

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 between eLogii and the stack is custom-built; there is no published eLogii to Webfleet integration on either side. Webfleet documents WEBFLEET.connect through its developer portal with OAuth 2.0 authentication. eLogii’s REST API has 70+ endpoints including the optimization endpoints. The flow:

1. Read from the operational source. eLogii reads stops, drivers, vehicles, depots and skills from the FSM, ERP or Webfleet directly via WEBFLEET.connect. Recurring service programs flow in alongside the daily job queue.
2. Optimize in eLogii. The run produces routes with assignments, start times, end times, overnight stops, depot start/end, SLA respect and recurring-cadence respect. Dispatcher reviews in eLogii’s dispatch desk or accepts an Auto run.
3. Write back. Routes and ETAs are written back to the operational system and over WEBFLEET.connect to the driver. Completion data flows back for the work record, asset history and reporting. 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 Webfleet Work App or the PRO Driver Terminal in the cab. The routing they follow is the one eLogii planned.

Most teams complete the connector build in 3 to 5 weeks. Typical first wave: the multi-depot regional book, a large recurring service program, or the business unit where the planning surface is leaking the most.

Frequently asked questions

Does Webfleet have an optimization engine?

Yes, in the sense that the WEBFLEET planner is described as an A-to-B route planner with waypoints, traffic-aware navigation and HGV restrictions (bridge heights, weight, hazardous-goods routing) drawn from the TomTom map heritage. What it does not surface as the lead capability is constraint-based optimization across time windows, capacity, skills, multi-depot and multi-day in one solver run; Webfleet’s own integration partner directory routes those jobs to third-party route optimization tools. Recurring service programs as a first-class input, operator-visible rule-based re-optimization, and a public REST surface for the optimizer itself with named assignment and load-balancing modes are not surfaced either. That decision layer is what eLogii adds, plugged directly into WEBFLEET.connect rather than via a partner.

What is the difference between the WEBFLEET planner and a constraint-based routing engine?

WEBFLEET planner: an A-to-B planner with waypoints, traffic-aware navigation and HGV restrictions drawn from TomTom maps, tuned around the day’s shape. Constraint-based routing engine: given a constraint model (skills, capacity, time windows, SLAs, depots, recurring cadences, cross-day dependencies), produce the assignments themselves against an objective, with operator-visible modes and rule-based re-optimization, callable as REST endpoints. The WEBFLEET planner does the first cleanly with deep HGV map intelligence. eLogii does both for the operations where the assignment problem spans depots, days and recurring programs. The two combine: Webfleet keeps the GPS, OptiDrive 360, tachograph and Webfleet Video stack; eLogii owns the constraint-based decision layer, plugged into WEBFLEET.connect.

When is the WEBFLEET planner with the Work App enough?

When planners can comfortably make assignments by hand against the day’s shape, with the WEBFLEET planner’s A-to-B routing handling the navigation side and the Webfleet Work App handling driver communication. This covers a wide band of European mid-size fleet operations on Webfleet. Outgrowth: when assignment becomes a constraint-satisfaction problem across multi-depot, recurring service programs and reactive work that doesn’t fit the A-to-B planner shape, the integration-partner pattern (a third-party route optimization tool) adds a second commercial relationship and a separate UI. A directly-integrated routing engine becomes the simpler answer.

How does eLogii’s optimization engine integrate with Webfleet?

Custom integration against WEBFLEET.connect (Webfleet’s REST API with OAuth 2.0) and the operational system of record (FSM or ERP). WEBFLEET.connect documents endpoints for job dispatch, predefined routes over-the-air, message queues and driver safety data. eLogii’s REST API has 70+ endpoints including the optimization endpoints, ApiKey auth and a full-parity sandbox. Once the connector is built: eLogii reads stops, drivers, vehicles, depots and skills from the operational systems, runs the optimization, writes optimized routes and ETAs back over WEBFLEET.connect. The driver opens the Webfleet Work App or the PRO Driver Terminal in the cab; the routing they follow is the one eLogii planned.

What does eLogii’s optimization engine look like in product terms?

Two engines and six configurable modes, all REST-callable. The Default engine optimizes 100 tasks in under 10 seconds for high-throughput daily planning. The Advanced engine handles multi-depot, multi-day, long-haul and constraint-heavy operations. Three assignment modes: Optimize Everything, Add to Routes Keep Existing Assignments, Add to Routes Keep Existing Assignments and ETAs. Three load-balancing modes: Most Efficient Routes, Balance the Minimum Number of Routes, Use All Vehicles / Finish as Soon as Possible. Each is callable programmatically and visible to the dispatcher as a control they can see and steer.