Webfleet Work App and the WEBFLEET planner: design ceilings and the optimization decision layer

What Webfleet does well, taken on its own terms

Webfleet is the European telematics platform under Bridgestone Mobility Solutions, built from TomTom Telematics. The surface area:

• WEBFLEET console. The SaaS back-office: vehicle tracking, geofences and alerts, OptiDrive 360 driver behavior scoring, Tachograph Manager for HGV compliance, Logbook, reporting, dashboards with up to 27 KPIs.
• Webfleet Work App. The driver and field mobile app (iOS and Android): orders and tasks, electronic Proof of Delivery, two-way messaging, working-hours logging, OptiDrive scoring, secure-truck-parking booking, temperature alerts, license checks, 24+ languages, QR-code onboarding.
• PRO Driver Terminals. Ruggedized in-cab tablets, including the Driver Terminal PRO X launched at CV Show 2026.
• LINK series trackers. Hardware estate (LINK 740 hardwired, others) installed per vehicle.
• Webfleet Video. Fleet dashcams for safety and incident playback.
• TPMS. Tyre Pressure Monitoring System (Bridgestone heritage).
• OptiDrive 360. Driver behavior coaching with scoring, gamified training and feedback.
• Webfleet AI Assistant. Recent (2026) addition for fleet managers to interact with fleet data conversationally.
• WEBFLEET planner. A-to-B route planner with waypoints, traffic-aware navigation, and TomTom-heritage HGV restrictions (bridge heights, weight, hazardous-goods routing).
• Integration partner ecosystem. Constraint VRP (time windows, capacity, skills, multi-depot, multi-day) is delivered through partners such as third-party route optimization tools.

For European fleet operations across light commercial, services and distribution, this is the right product. Webfleet covers the vehicle, GPS trail, tachograph log, OptiDrive score, Webfleet Video record and TPMS data end to end, with deep HGV map intelligence. The friction is in a specific decision layer alongside the planning surface, not in the telematics estate itself.

Four patterns where the planning surface reaches its design ceiling

Each pattern has its own dedicated sub-page in this cluster. Here they are in one view:

• Optimizer-driven assignment. The WEBFLEET planner is described as an A-to-B route planner with waypoints, traffic-aware navigation and HGV restrictions. When the planner is spending the morning hand-balancing jobs across drivers, depots and skills, the decision layer that needs to fill in is the optimization engine: a constraint-based assignment that takes stops, drivers, vehicles, depots, skills, time windows and SLAs as inputs and produces the assignments under an objective. Webfleet’s own integration partner directory routes this to a third-party route optimization tool; eLogii plugs directly into WEBFLEET.connect with a single commercial relationship.
• Multi-depot rebalancing. The WEBFLEET planner product page documents time windows, vehicle capacity, driver certifications and overnight trips as supported constraints. Multi-depot is not surfaced. Regional service organizations with three or four depots, contractors with branch networks, and recurring programs across regions need the optimizer to treat all depots as a single problem. The output is one consistent plan across depots, not the sum of per-depot plans.
• Recurring service programs at scale. Recurring or template routes are not a named capability on the WEBFLEET planner page. At thousands of recurring jobs with SLAs varying by contract, with cadence drift to keep capacity balanced, calendar entries are no longer the same thing as optimization. The optimizer needs to model task and route template groups as constraint inputs, balance recurring against reactive break-fix, and protect SLA-locked stops.
• The 100-orders-per-device cap. Third-party integration partner documentation reports that Webfleet caps orders pushed to a single device at 100. For dense urban distribution and parcel operations running 120-180 stops per driver per day, that ceiling shapes the planning surface around a smaller-fleet, fewer-stops-per-driver model. A dedicated optimization layer plugged into WEBFLEET.connect can plan the full route as a single unit on the eLogii side and stream it to the driver in segments that respect the cap.

Each pattern is addressable on its own. Most operations start with whichever is leaking the most.

How to tell if your operation has hit one of them

The diagnostic signals are operational, not headcount-based. Some patterns from operations that have moved to a combined Webfleet + eLogii stack:

• The planner has become the optimizer. The planner spends the morning hand-balancing rather than reviewing. The bus-factor of the planning operation is one or two people, even with the WEBFLEET A-to-B planner running.
• SLA misses are concentrated in specific programs or depots. The recurring service book or the regional book is leaking against SLAs; the rest of the operation is fine.
• Cross-depot capacity drift. One depot runs hot, another runs underused, drive time creeps up. No one has time to spot it in real time.
• Recurring programs run as separate calendars. Quarterly preventive, monthly inspection cadences exist as their own calendar entries reconciled by hand against the day’s reactive book.
• The partner-integration tax is biting. The team is paying twice for the routing layer (once for Webfleet, once for a third-party route optimization tool) and the planner is switching between two UIs.
• Daily order counts are at the 100/device cap. Routes have to be split across multiple device sessions or carried in spreadsheets because Webfleet won’t push more than 100 orders to a single driver device.
• Planning time grows faster than the operation. Doubling the driver count more than doubles the planner load.

Each of these is a signal that the optimization decision layer alongside the WEBFLEET planner is the bottleneck. The right answer is to add the engine, not to replace the telematics estate.

At a glance: an 80-driver European distribution organization

A European distribution organization running mixed B2B and last-mile delivery across a regional book. Eighty drivers in the field, four depots, two planners. Roughly 50% recurring B2B accounts on SLA terms, the rest reactive same-day urgent jobs and ad-hoc B2C drops. All four patterns hit at once.

Each pattern shows up in a specific place. The optimizer-driven assignment pattern shows up in the planning room each morning: two planners hand-balancing the daily mix instead of reviewing an optimized plan, with the WEBFLEET planner running A-to-B today and a third-party route-optimization trial sitting in a tab nobody quite uses. The multi-depot rebalancing pattern shows up when a driver at depot 3 is off sick and the day’s reactive work has to be redistributed to depots 1, 2 and 4 by hand. The recurring-program optimization pattern shows up as creeping SLA misses on the quarterly B2B book; calendar entries existed correctly, route-level routing wasn’t the bottleneck, but the interaction between recurring B2B and reactive same-day work across the same drivers was. The 100-orders-per-device pattern shows up on the two densest urban routes where the driver does 140-150 stops a day; the planner has been splitting those routes across two device sessions to fit under the cap. Each pattern is addressable on its own. Operations at this shape most often start with whichever is leaking the most visible cost, then expand on the same integration.

What eLogii adds, in one place

The constraint-based optimization decision layer that runs alongside the WEBFLEET planner:

• Two engines. Default engine for high-throughput daily planning (100 tasks in under 10 seconds). Advanced engine for multi-depot, multi-day, long-haul and constraint-heavy operations.
• Six configurable modes. 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).
• Multi-day, multi-depot, multi-driver in one run. Single optimization across the routing horizons the planning surface is not designed to solve.
• Task and route template groups. Weekly, monthly, quarterly and bespoke cadences modeled directly as constraint inputs.
• Rule-based re-optimization. Operator-visible rules; live re-optimize while protecting locked SLAs and customer-confirmed slots.
• Slot booking co-pilot. Route-aware availability that returns only slots that fit the current optimized plan.
• REST-callable. All six modes plus slot availability plus optimization triggers exposed as REST endpoints. Seven webhook events including live driver GPS and Route ETAs Update.
• Single commercial relationship. One contract for the routing layer, plugged directly into WEBFLEET.connect rather than via the partner ecosystem.

How the integration sits with Webfleet

Webfleet stays the system of record for GPS, OptiDrive 360, tachograph and Webfleet Video record. The operational system (FSM or ERP) stays the system of record 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.

1. Read from the operational source. eLogii reads stops, drivers, vehicles, depots and skills from the FSM, ERP or Webfleet directly via WEBFLEET.connect.
2. Optimize in eLogii. The run produces assignments and routes under the chosen objective, respecting SLAs and customer-confirmed slots.
3. Write back. Optimized routes and ETAs flow back over WEBFLEET.connect. The driver opens the Webfleet Work App or PRO Driver Terminal in the cab; Webfleet captures the 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 routing they follow is the one eLogii planned.

Most teams complete the connector build in 3 to 5 weeks. The most common first wave is whichever of the four patterns is leaking the most.

Frequently asked questions

Where does the Webfleet planning surface reach its design ceiling?

Four patterns. First, optimizer-driven assignment: when the planner needs to decide assignments under hundreds of competing constraints, not just draw A-to-B routes on the WEBFLEET planner. Second, multi-depot rebalancing: when work needs to flow between three or four depots based on capacity, skills and SLA (multi-depot is not surfaced as a documented constraint on the WEBFLEET planner page). Third, recurring service programs at scale: thousands of recurring jobs with interacting SLAs and cadences (recurring routes are not surfaced as a named capability on the WEBFLEET planner page). Fourth, the documented 100-orders-per-device cap third-party integration partner documentation reports when pushing routes to a single Webfleet device. Each of these is a different facet of the same problem: the optimization decision layer alongside the WEBFLEET planner and Work App.

Does this mean Webfleet is the wrong tool?

No. Webfleet is the telematics platform for the vehicle, GPS, OptiDrive 360, Tachograph Manager, Webfleet Video, TPMS and LINK/PRO Driver Terminal estate. The WEBFLEET planner and Webfleet Work App are useful surfaces for European mid-size fleet operations on top of that telematics estate. For a wide band of fleet and field-service operations, this is exactly the right tool. eLogii is not a telematics platform. It is the constraint-based routing and optimization decision layer for operations where the assignment problem is the bottleneck.

How do I know if my operation has outgrown the WEBFLEET planner?

Diagnostic signals: the planner spends the morning hand-balancing rather than reviewing; SLA misses are concentrated in specific recurring programs or depots; the bus-factor of the planning operation is one or two people; cross-depot work feels like it should be balanced more but no one has time to look; recurring service programs run as separate calendars reconciled by hand; daily order counts are bumping against the 100-orders-per-device cap third-party integration documentation reports; the team is paying twice (once for Webfleet, once for a partner tool) for the routing layer. Each is a sign that the assignment problem has grown past what the WEBFLEET planner (with or without a partner integration) is designed to solve. Adding eLogii is the answer to that specific layer; Webfleet keeps owning the GPS, OptiDrive 360, tachograph and Webfleet Video record.

How does the integration 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; runs the optimization across the chosen pattern (multi-depot, recurring program, fleet-scale, all of them); writes optimized routes and ETAs back over WEBFLEET.connect. 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. Typical connector build: 3 to 5 weeks.

Can I start with just one of these patterns?

Yes, and that is how most teams start. The most common first wave is whichever pattern is leaking the most: multi-depot rebalancing for regional service organizations, recurring program optimization for compliance and preventive books, the per-device-cap workaround for operations bumping into the 100-orders-per-device ceiling, optimizer-driven assignment for any operation where the planner is the bottleneck. Once one pattern is live and the lift is visible, the others follow on the same integration.