How AI can be employed in different layers of a route optimisation engine

We hear a lot about AI. But the more useful question is how it can be applied
inside the design and implementation of a route optimisation engine to make a
measurable difference in real logistics operations.

The gap between AI potential and real-world adoption

AI-driven last-mile solutions can improve operational efficiency by 30–40%.
Yet in Europe, only 6% of logistics providers have applied AI to their core
operations at scale.

That represents a significant gap, but also a significant opportunity,
particularly for last-mile delivery, morning distribution, food delivery,
and other logistics operations where small improvements in planning efficiency
can have a substantial impact at scale.

Let’s start with the route optimisation solver algorithm, which is the core
part of a

Route Optimisation Engine
.

AI should not live in only one layer

Using AI to design cutting-edge route optimisation algorithms

Many route optimisation solutions rely primarily on an existing solver —
such as OR-Tools, VRoom, PyVRP, or A* — expose it through an API, and add
surrounding logic.

There is nothing inherently wrong with that approach.

For this purpose, we need to build intelligence into multiple layers of the
route optimisation engine itself, rather than treating AI as an additional
feature placed on top of a traditional solver.

This article aims to dig into different layers where the full potential of AI
can be realised to build a cutting-edge route optimisation engine.

A major part of optimisation happens before the final route is generated

One of the most important parts of route optimisation happens before the final
route sequence is generated.

Solving a VRP, or even a TSP, without appropriate clustering mechanisms can often
lead to routes that are mathematically valid but operationally inefficient.

Such routes may also be less likely to be accepted by dispatchers and drivers.

In single-route optimisation, clustering can help avoid unnecessary detours
and repeated visits to the same geographical areas.

In multi-route optimisation, it can help reduce overlap between routes and
create clearer geographical responsibility for each vehicle.

Nevertheless, clustering alone may not be sufficient, particularly for
large-scale problems.

Hierarchical clustering can complement the initial clustering mechanism by
reducing the size of the problem space in a divide-and-conquer manner.

Large clusters can be further divided into smaller groups of stops, allowing
the optimisation algorithm to work with more manageable and geographically
coherent sub-problems.

One clustering strategy does not fit every region and every day

A clustering strategy that performs well in central Stockholm may not be the
best choice for a rural delivery region.

Even within the same city, different areas can have very different delivery
densities, geographical shapes, and road-network characteristics.

For this reason, clustering parameters should not remain static.

They can adapt by region and over time based on signals such as:

Can we quantify how “good” a route feels to a dispatcher or driver?

Because a mathematically efficient route is not always an operationally good route.

A route may still contain:

These are exactly the kinds of patterns that experienced dispatchers and
couriers often recognise immediately and may correct manually, even when the
route performs well according to conventional metrics such as distance or duration.

An efficient route optimisation engine should therefore evaluate not only
numerical efficiency, but also the shape and operational quality of the route.

This score can then become another measurable criterion for both evaluating
optimisation results and guiding the design of the optimisation algorithm itself,
alongside traditional objectives such as distance, duration, and cost.

Optimisation quality is not static

Even a route optimisation engine that performs very well today may gradually
become less effective as the operating environment changes.

A robust optimisation engine should therefore be able to recognise when its
own performance begins to deteriorate.

These signals can help trigger further analysis, parameter adjustment,
retraining, or changes to the optimisation strategy.

This creates a continuous improvement loop around the optimisation engine,
where performance is not only measured at the time a route is generated,
but monitored over time so that the system can adapt as operational conditions change.

ETA prediction should learn from actual operations

ETA prediction is another layer where AI becomes operationally important.

Machine-learning models can be used to learn from actual route execution and
adapt as operational behaviour changes, rather than relying on real-time data
that is not useful for the planning phase of routes, which is done early in
the morning or even the previous day.

Depending on available customer data, models can be retrained:

The system can start from existing models and progressively adapt to the
individual customer’s operation.

Once execution begins, real-time signals can further update ETA predictions.

Planning tells us what should happen. Operations tell us what actually happened.

When customers choose to provide operational feedback, the planned can be
compared against the actual.

Signals may include:

These signals can improve clustering, ETA prediction, route-quality evaluation,
and other intelligence layers over time.

How our route optimisation engine applies AI across different layers

For TrendRoute.ai, AI is intelligence distributed throughout the optimisation engine.

AI as an intelligence layer throughout the optimisation engine

Explore TrendRoute.ai →