Traffic-Aware Route Optimisation: Planning Around Real-World Congestion

Simon Webb
Feb 27
5 min read

Most route optimisation software assumes roads behave the same way all day.

They don’t.

Peak hour congestion, industrial traffic cycles, school zones and urban bottlenecks shift continuously throughout the day. Yet many last mile route optimisation systems still rely on static average travel times or a single “traffic state” applied across the entire optimisation.

At Tarot Analytics, we’ve rebuilt our optimisation engine to model traffic as a dynamic variable, not a fixed assumption. In practical terms, this is what traffic aware route optimisation actually requires: modelling how congestion evolves across the day, not just applying a single snapshot of conditions.

We recently sat down with MHD Supply Chain to discuss why traffic-aware route optimisation is harder than it first appears — and what it takes to make it practical at fleet scale.

Building real-world traffic into last-mile route optimisation featured in MHD Supply Chain February 2026

Originally published in MHD Supply Chain (February 2026)

Why Static Travel Times Fail in Last Mile Delivery

Traditional route optimisation engines typically use either average travel times or a single predefined traffic “state” (e.g. early morning, morning peak, evening) applied across the entire optimisation.

That approach appears reasonable — but it breaks down in real-world delivery operations.

Multi-stop delivery and distribution runs often span several hours.

Consider a typical morning run for an automotive parts distributor, furniture delivery fleet or retail replenishment operation. A driver may depart the warehouse at 5am, pass through peak hour between 8–9am, and continue into mid-morning conditions before finishing around midday.

Even if we apply a time-of-day traffic state, which one should we choose?

Early morning traffic state

Travel speeds are fast at departure. But as congestion builds, the driver falls behind schedule — risking missed delivery windows, overtime costs and late returns to the warehouse.

Peak hour traffic state

To avoid missing delivery windows, we assume worst-case congestion. The optimisation now indicates additional vehicles are required to complete the workload. Cost-per-delivery increases unnecessarily.

An average of the averages

The algorithm loses situational awareness. It cannot reason strategically — for example, avoiding city-bound stops during peak hour and sequencing them later in the run.

In each case, we are forced to make a compromise, and the model no longer reflects the reality on the road.

But traffic-aware routing is not new.

Consumer navigation apps have incorporated live congestion data for years. Food delivery and ridesharing platforms use traffic-aware routing every day.

So why can’t a fleet optimisation engine simply do the same?

Why Traffic Modelling is Hard at Scale

Short answer: data size and calculation time.

A navigation app calculates one route at a time. A food delivery platform may only be planning two or three stops ahead.

A optimisation engine, by contrast, must evaluate thousands, sometimes millions, of potential travel times in a single calculation to determine which vehicle should visit which jobs, and in what sequence.

This requires a fundamentally different data structure.

A modern route optimisation algorithm needs a travel time matrix

A Travel Time Matrix that can be used by a Route Optimisation Algorithm

Example Travel Time Matrix showing journey times between a depot and six jobs

The matrix lists the travel time between every pair of locations — A to B and B to A — allowing the optimisation engine to evaluate the cost of different job allocations and sequences as it searches for the optimal solution.

For one depot and six jobs, we have seven locations in total. That produces a 7 × 7 matrix — 49 travel times (N²).

Now scale that up.

A modest warehouse with 250 stops requires:

250 × 250 = 62,500 travel times.

A 400-stop morning run requires:

400 × 400 = 160,000 travel times.

And that is for a single traffic assumption.

True time-of-day traffic changes the problem entirely.

We no longer need just the travel time from A to B — we need the travel time from A to B at 7:30am, 10:00am, 12:30pm, and so on.

If we divide the day into five-minute intervals, that means 288 travel times for every origin-destination pair.

In effect, instead of one 2D travel time matrix, we now require 288 matrices, forming a 3D, time-dependent travel time structure.

2D "non-traffic" travel time matrix compared with a 3D "Traffic" travel time matrix

For 400 locations, that equates to more than 46 million travel time values to represent a full day of congestion dynamics.

And that assumes your routing data provider even allows that query volume.

Even if the data challenge can be solved, a second problem emerges: algorithmic complexity.

Traditional route optimisation engines rely on cost-delta shortcuts to evaluate route changes efficiently. When travel times are static, small changes in a route only require local recalculations.

Traffic breaks that shortcut.

If travel time depends on arrival time, then changing one stop in a sequence affects every subsequent leg of the route. The algorithm can no longer adjust locally — it must recalculate forward through the entire route.

The result is longer computation times.

For a 400-stop scenario, an optimisation that once completed in two minutes under static assumptions may now take 10–15 minutes with time-dependent travel times.

In logistics operations, even an additional five minutes can have real consequences — from delayed planning to earlier order cut-off times.

At that point, the operational cost of waiting can outweigh the theoretical benefit of traffic-aware routing.

How Tarot Makes Traffic-Aware Optimisation Practical

So, if the traditional approach doesn't work, how do we consider variable traffic in our optimisations?

Tarot Routing uses a hybrid data and machine learning approach to generate traffic-adjusted travel times instantly, without querying live traffic APIs millions of times during optimisation.

At a high level, our approach combines:

Machine learning models trained on large volumes of regional historical traffic data
Pre-computed baseline road network travel times
Efficient in-memory data structures that make time-dependent matrices computationally viable
A two-phase optimisation strategy that balances speed and accuracy

Instead of querying every travel time from scratch, our models learn how congestion behaves across the day.

The result is a traffic-aware optimisation engine that remains fast enough for operational use at scale.

If you’d like to explore the technical architecture in detail, including memory compression techniques and algorithm design, we’ve published a dedicated white paper.

👉 Download the Route Optimisation with Traffic White Paper

Impact on Fleet Performance

For many fleets, traffic’s impact is modest. Natural variation in driving times often absorbs small congestion fluctuations.

But for operations with:

City-adjacent depots
Dense urban delivery windows
Multi-wave distribution runs
High stop density

Traffic-aware optimisation can materially change outcomes.

Tarot’s traffic-aware optimisation typically runs approximately 50% longer than a static optimisation, for example, four minutes instead of two minutes for a 400-job scenario.

For urban operators, that additional computation time is worth the operational gains.

By intelligently sequencing routes to avoid peak congestion, customers operating in major metropolitan areas can save hundreds of driver-hours per week all while improving ETA accuracy and reducing overtime risk.