AI route optimisation: from VRP solver to live dispatch

Q: How accurate are the ETAs?

Standard map-based ETAs typically carry an error of 10 to 20 per cent on urban routes. With machine-learned ETA models that we train on your historical journey times, including stop times, driver effects and customer-specific factors, we bring that error down to 5 to 10 per cent. More importantly, the spread of the error becomes more predictable, which makes SLA reporting reliable. We make no empty promises about this without data from your own operation.

Last-mile, field service, waste collection or courier networks: every route plan is at its core a Vehicle Routing Problem. We build custom AI route optimisation software that solves VRPTW, CVRP, dial-a-ride and multi-depot scenarios using OR-Tools, VROOM and Hexaly, fed by real-time traffic data from HERE, TomTom or Mapbox. The result: shorter routes, fewer empty kilometres, better ETAs, and a dispatcher with time left over for exceptions.

VRPTW & CVRP solver Real-time re-routing Dynamic dispatching ETA prediction Last-mile clustering

Discuss your routing case View applications

What AI route optimisation is and isn't

Not every planning tool with a map attached is route optimisation. We build solutions that explicitly model the underlying combinatorial problem, and that problem has a name: the Vehicle Routing Problem.

The Vehicle Routing Problem (VRP) has been one of the most studied optimisation problems in operations research since Dantzig and Ramser first formulated it in 1959. In practice it appears in dozens of variants. The Capacitated VRP (CVRP) takes vehicle load capacity into account, the VRP with Time Windows (VRPTW) adds customer arrival windows, the Multi-Depot VRP handles several starting bases, the Pickup-and-Delivery Problem (PDP) links loading and unloading addresses, and the Dial-a-Ride Problem (DARP) covers passengers who must be picked up and dropped off within service-quality limits on journey time. Each one calls for a different solving strategy.

A VRP with twenty stops and one vehicle can be solved on a laptop. A daily plan for a fleet of sixty vans, with time windows, capacity limits, driving and rest-time rules and stochastic traffic information, is a different matter. That is where solvers come in: open-source libraries such as OR-Tools and VROOM, or commercial engines such as Hexaly (formerly LocalSolver). The real challenge is not running such a solver, but modelling your operational reality correctly and integrating the output into your existing planning and on-board computer stack.

"AI" appears in this landscape in several places. It lies in the metaheuristics (simulated annealing, tabu search, Large Neighbourhood Search, genetic algorithms, Lin-Kernighan variants) that solvers use to find good solutions within limited time for problems where exact methods are too slow. It appears in machine-learned ETA prediction based on historical journey times and real-time traffic. And it appears in dynamic dispatching, where reinforcement learning or online optimisation decides how an incoming order is best assigned to a vehicle already on the road, without overturning the entire day's plan.

VRP variants we model

Choosing the right solver starts with the right problem formulation. Below are the variants that come up most often in Dutch fleet and logistics operations in practice.

🕒

VRPTW: time windows

Customers expect delivery between 09:00 and 12:00, or an engineer between 13:00 and 17:00. The VRP with Time Windows adds an earliest and latest arrival time to each stop, plus optional on-site service time. It is essential for next-day delivery, field service planning and healthcare logistics. We model both strict windows and soft windows with penalty costs for minor overruns.

📦

CVRP: capacity constraints

A refuse collection vehicle has a load volume, a delivery van has a weight limit, and a courier has a number of parcel slots. The Capacitated VRP ensures that no vehicle exceeds its maximum and schedules intermediate emptying or reloading runs at depots or transfer points. It can be combined with multiple compartments for chilled plus ambient goods, or residual waste plus recyclables.

🔁

PDP & DARP

Pickup-and-Delivery links a loading address to an unloading address: the vehicle that collects at one place delivers at another. DARP adds passengers, think of Dutch WMO transport or school transport with a maximum journey time per person. Both require sequencing constraints (load first, then unload) and ride-time limits, which make the search space considerably harder than a standard VRP.

🏭

Multi-depot VRP

Does your organisation have several dispatch bases, cross-docks or city microhubs? The Multi-Depot VRP assigns the best starting depot to each route based on the geographic spread of customers and the available capacity at each location. It is essential for national courier networks and urban last-mile distribution in zero-emission zones.

⏱️

VRP with breaks and driving and rest times

European driving and rest-time rules (Regulation 561/2006) and the working-time provisions for delivery and courier services require breaks, daily rest and weekly rest. Our solvers incorporate mandatory breaks explicitly, with flexible time windows, and are compatible with digital tachograph data. No more plans that look right on paper but result in violations in practice.

🔄

Dynamic VRP

Same-day delivery, taxi dispatch and emergency repairs cannot wait until tomorrow. Dynamic VRP makes the decisions online: a new order comes in, which vehicle picks it up, and how does that fit into the current route without harming the SLAs for other stops? We build insertion heuristics and rolling-horizon rescheduling that re-evaluate the state of the world every few minutes.

How Appfront builds route optimisation

We do not build a black-box app where you can call "stops in, route out". Our approach starts with your operational reality: which vehicle types, which contractual SLAs, which depots, which delivery agreements, and which exceptions your planners currently resolve by hand. Only once these are explicit do we write the objective function and the constraints the solver uses.

In practice we build three layers on top of each other. At the bottom is the routing engine: for road distances and duration matrices we use OSRM, Valhalla or GraphHopper on your own infrastructure where the data allows it, or HERE Routing, TomTom Routing and Mapbox Directions when you want ready-made traffic data and truck attributes. On top of that runs the solver: OR-Tools for most classic VRPTW/CVRP cases, VROOM for fast constructive heuristics across hundreds of stops, and Hexaly for hard cases where mixed objectives and complex constraints pull against each other. Above that sits a dispatch layer that streams to your onboard computer or driver app and tracks what is actually happening.

We work iteratively, with measurable results at each phase. A proof of concept on a week of historical orders shows in numbers how many kilometres and hours the solver saves compared with your current planning. Only once that is convincing do we move to production integration with your TMS, ERP and onboard computer.

AI logistics optimisation Transport software Planning and scheduling software Fleet management app

From first planning question to production rollout

Routing projects stall when the solver is ready before the business logic has been settled. Our phasing tackles that in the right order.

Constraint discovery

Together with your planners and drivers, we map out which hard and soft constraints actually apply: time windows, vehicle capacities, depot opening hours, customer-specific restrictions, breaks and driving and rest times. The output is a formal problem definition the solver can work with.

Proof of concept on historical orders

Using an extract of your historical trip and order data, we run the first solver runs in OR-Tools or VROOM. We compare the output with your actual routes from the same week: kilometres, hours, vehicle deployment. Without that comparison, any routing figure is just marketing.

Integration and dispatch loop

The solver is connected to your order source, mapping service and on-board computer. We build a dispatch loop that calls the right optimisation for each new planning session or incoming order and sends the result to the driver app or on-board computer.

Live tuning and monitoring

A production routing system needs monitoring: why does the solver choose this suboptimal trip, why is the ETA error on corridor X larger than elsewhere? We instrument the pipeline, retrain ETA models on fresh travel times, and adjust objective weights as the market changes.

Technology behind the routing stack

The choice of solver, routing engine and data sources depends on your scale, geography and compliance requirements. We have no preferred vendor that is "always the answer". We choose based on what fits your problem.

For the optimisation itself, Google OR-Tools is our first workhorse. It is open-source, production-ready, supports VRPTW, CVRP, PDP, multi-depot and breaks via the Routing Library, and offers Python, C++ and Java bindings. For very large constructive runs across thousands of stops, we turn to VROOM, which is written purely in C++ and designed for speed. For cases where the objective function is heavily mixed — for example, minimise kilometres, balance workload and respect customer priorities — Hexaly (LocalSolver) takes over where OR-Tools struggles.

For road distance and duration matrices, we integrate several services depending on the case. HERE Maps is strong for truck attributes such as permitted bridges, height profiles and hazardous goods routes. TomTom provides accurate European traffic data and historical speed profiles. Mapbox Directions is a good choice for consumer-facing apps with attractive map rendering. For self-hosted scenarios with high query volumes, we run OSRM, Valhalla or GraphHopper on your own infrastructure, using OpenStreetMap as the base data. For public transport and GTFS-RT feeds, we connect directly to NDOV-loket for Dutch public transport data when multimodal routing is needed.

OR-Tools VROOM Hexaly Lin-Kernighan Simulated annealing Tabu search Genetic algorithms HERE Routing TomTom Routing Mapbox Directions OSRM Valhalla GraphHopper GTFS-RT Python FastAPI PostGIS Kafka

Applications by sector

Routing software has a different objective function and a different story for each sector. A refuse collection vehicle is optimised differently from a bicycle courier.

Last-mile and e-commerce

Parcel services with growing volumes and shrinking delivery margins need a dynamic VRP that respects customer delivery windows, schedules failed deliveries for a second attempt and avoids zero-emission zones in cities for diesel delivery vans. Through clustering at postcode level and re-optimisation during the route, our clients get more stops per hour from the same fleet — without making drivers work harder.

Refuse collection and waste management

Municipal and commercial waste collection services plan weekly routes for residual, garden, paper and PMD (plastic, metal and drinks cartons) streams, often with containers that must be emptied on demand. CVRP with multi-compartment vehicles, sensor-driven fill-level data from smart bins and hard time windows for disposal sites produces a plan that minimises driving and avoids empty trips to containers that are not yet full.

Couriers — same-day and next-day

For next-day couriers, everything revolves around start-of-day optimisation: distributing all orders in one batch across drivers and vehicles. Same-day couriers need a dynamic VRP that continuously slots new orders into routes already under way. For urban bicycle couriers, we also integrate cycling routes and elevation changes, as automobile routing from Mapbox does not provide a suitable answer there.

Field service and mobile workforce

Engineers servicing lifts, climate systems, telecoms or central heating boilers work with appointment windows, skills required per job and parts stock in the van. A routing engine plus skills matching schedules the day so that the right engineer arrives at the right time with the right spare parts. ETA updates to the customer via SMS or app happen automatically.

Dial-a-ride: special transport, pupil and taxi services

Special needs transport and traditional taxi dispatch are DARP problems: multiple passengers per vehicle, individual pick-up and drop-off windows and strict maximum journey times per person. We build solutions that allow ride-sharing where this is legally and qualitatively permissible, and that keep trips strictly separate where regulations require it — for example, in medical taxi transport.

Construction and home-delivered meals

Construction logistics with cross-dock hubs and tight just-in-time time slots on site calls for multi-depot VRP plus appointment scheduling. Restaurant delivery requires ultra-short cycle times and near-real-time rescheduling. Both have in common that ETA prediction based on traffic data is crucial to deliver predictably.

Building a courier app Building a transport app Transport planning API Fleet tracking dashboard Geo app development

ETA prediction and real-time re-routing

A schedule is a snapshot. Traffic, weather, customer delays and breakdowns mean reality diverges from the plan the moment the first driver pulls away. This is where AI route optimisation takes the second step.

Machine-learned ETAs

Standard mapping services give a traffic-averaged ETA. We train models on your own historical journey times, factored by driver, vehicle type, time of day and customer stop time. The result: ETAs that reflect your reality, not those of an average satnav user. Important for SLA reporting, customer notifications and realistic capacity planning.

Real-time re-routing

When there is a jam, an accident or a stop that takes longer than expected, the system recalculates the remaining route for the vehicle concerned and, where necessary, passes stops on to colleague drivers. Re-optimisation happens in seconds using insertion heuristics, rather than rerunning the entire day plan.

Geofencing and stop detection

Geofences around depots and customer addresses automatically detect arrival and departure, without the driver having to press a button. The data feeds the ETA models, triggers customer notifications and provides evidence for proof of delivery. For restricted zones (ports, factory sites), geofencing also supports automatic check-ins.

Live traffic feeds

HERE Traffic, TomTom Traffic and GTFS-RT for public transport deliver real-time speed updates per road segment. Our dispatch layer feeds that data back into the routing engine so that re-optimisations run on current speeds. For critical corridors we proactively monitor incident feeds and flag routes that are affected by problems.

Google Maps integration eCMR integration Adaption TMS integration

Why Appfront for route optimisation

OR engineers, not plug-in installers

Our routing projects are led by engineers who can work with OR-Tools in Python and C++, write callbacks for specific constraints, and understand the difference between first-improvement and best-improvement in local search. That difference determines whether your plan is ready in ten seconds or ten minutes.

Transport and logistics domain expertise

We have been building transport and logistics software for years. We know the difference between a digital tachograph and an on-board computer, between eCMR and CMR, between a TMS and a fleet management app. That domain knowledge translates directly into better modelling of your VRP.

Integration-first mindset

A routing engine that doesn't talk to your order source, ERP and on-board computer is an academic exercise. We build integrations with Adaption, transport planning APIs, fleet tracking dashboards and on-board computer systems, so the optimisation lands in the system your drivers already use today.

Get in touch Transport digitalisation consultancy Transport software partner AI development overview

Frequently asked questions about AI route optimisation

What is the difference between route planning and route optimisation?

Route planning determines the best sequence of stops for a single vehicle; in essence, that is a Travelling Salesman Problem. Route optimisation assigns stops to multiple vehicles at once, with capacity limits, time windows and breaks, which is a Vehicle Routing Problem. The combinatorial search space of VRP grows far faster than TSP, so you need heuristic solvers such as OR-Tools, VROOM or Hexaly to find a workable solution within seconds or minutes.

Do you work with OR-Tools or a commercial solver?

Both. For most classic VRPTW and CVRP cases, Google OR-Tools solves the problem very well and is open source, so you aren't tied to a licensing model per vehicle or per call. For very large or highly complex objective functions — multi-criteria optimisation, hard and soft constraints, non-convex objectives — we turn to Hexaly, as its solving time is significantly better there. We always document why we make a given choice.

Which mapping service is best for truck routing?

For truck routing with truck attributes (bridges, weight restrictions, height restrictions, hazardous goods routes), HERE is usually the strongest choice, with TomTom as a solid European alternative. Mapbox Directions supports truck routing but is less comprehensive for Europe. For self-hosted scenarios, Valhalla or GraphHopper running a truck profile on OpenStreetMap data works well for medium-sized fleets that want to be independent of API credits.

How do you handle driving and rest times?

We model breaks explicitly as constraints in the solver. For heavy transport (over 3.5 tonnes) we follow Regulation (EC) No 561/2006 — 4.5 hours of driving, then a 45-minute break, daily rest of nine or eleven hours, and weekly rest of 24 or 45 hours. For lighter transport and couriers we follow the Dutch Working Hours Decree (Arbeidstijdenbesluit). The solver may only schedule a route if the driver remains compliant, and the plan is auditable against tachograph data.

How accurate are the ETAs?

Standard map-based ETAs typically carry an error of 10–20% on urban routes. With machine-learned ETA models that we train on your historical journey times, including stop times, driver effects and customer-specific factors, we bring that error down to 5–10% — and, more importantly, the spread of errors becomes more predictable, which makes SLA reporting reliable. We make no blanket promises on this without data from your own operation.

Does your solution work for same-day delivery?

Yes. Same-day delivery requires a dynamic VRP — orders arrive while vehicles are already on the road. We implement rolling-horizon optimisation: every few minutes the current state of the world is reassessed and new orders are inserted into ongoing routes using insertion heuristics. Recalculating the entire day's plan is rarely necessary and would also confuse the drivers.

Can you integrate with an existing TMS or on-board computer?

Yes, that is usually the norm. We build integrations with TMS systems such as Adaption, with on-board computer suppliers and with fleet tracking platforms. The solver receives orders and vehicle information via an API and sends routes back to the on-board computer or driver app. Where possible we avoid parallel systems: the existing TMS remains the source of truth for planning status.

What data do you need for a proof of concept?

One to two weeks of historical order data, including customer addresses, requested time windows, volumes and weights; your vehicle deployment over that same period (which vehicle ran which route); and ideally actual arrival and departure times per stop too. With that input we run our solver and compare the result against your actual routes. Only then will you know whether the savings are large enough to proceed.

Make your routing challenge concrete?

Send us your planning question — a week of historical orders is enough for a first solver run. No obligation, with an honest benchmark against your current planning.

Schedule a conversation