How Does AI Route Optimisation Work in Road Freight?

Route optimisation is not the act of drawing the road a vehicle will take. It is the act of choosing the lowest total-cost plan out of constraints that contradict one another. A calculation that only hunts for the shortest way usually produces the most expensive trip of the day.

The reason is plain. Distance, time and money do not pull in the same direction. The motorway corridor is short but paid for at every gate; the free corridor is longer and burns more fuel; the fastest option of all can cost more than either. What makes one corridor the best one depends on which objective that job puts first.

Is route optimisation about finding the shortest way?

No. Route optimisation tries to minimise the total cost of a trip rather than its distance, and distance is only one component of that cost. What makes a trip expensive is rarely the kilometres covered; it is the items that switch on while those kilometres are being covered.

Those items have different drivers. Fuel grows with distance, toll charges with the amount of motorway used, driver cost with elapsed time. The vehicle is not a cost item but a resource: while committed to one job it cannot go to another. Push one down and another goes up.

The optimisation problem is born there. Finding the shortest path between two points is long solved; the hard part is holding several objectives at once. We went through the cost items that make up a single move in how a road freight rate is calculated; optimisation looks for the corridor and sequence that minimise their sum.

Why is the shortest distance not the lowest cost?

Because the corridor that shortens the distance usually runs on paid roads, and the kilometres you save are handed back at the gates. Between the same two points, a motorway-heavy corridor and a state-road corridor produce clearly different cost totals.

The table below shows which way each objective pulls the route and which other objective it collides with. None of these rows is a mistake; the problem is that you cannot have them all at once.

In plain sentences: the shortest-distance objective pulls towards a direct, motorway-heavy corridor and raises the toll bill. The lowest-toll objective pulls the other way, onto the free state-road corridor, and distance, duration and fuel burn all rise. The shortest-duration objective picks fast, uninterrupted roads, lifting tolls and, on some vehicle classes, consumption. The delivery window works differently again: it forces whichever corridor guarantees arrival on time and eliminates the cheapest alternative before it is ever costed.

The remaining four rows are other faces of the same tension. Driver driving and rest hours favour roads with usable rest points, which breaks the sequence the shortest route would have used. Weight, height and road restrictions impose the roads the vehicle can legally use; those are usually longer and sometimes tolled. Reducing the empty return pulls the vehicle towards the area holding a backload and lengthens the outbound leg. Using fewer vehicles loads more stops onto one vehicle, straining the delivery windows and the day's driving hours.

So distance and toll charges have to be visible at the same moment, over the real route. Seferi Route Engine works out distance and duration over the actual road corridor and gives the toll figure by listing the gates one by one rather than as a lump-sum allowance — the precondition for comparing two alternatives at all.

When does a delivery window override distance?

A delivery window overrides distance whenever missing the arrival time makes the trip pointless. A vehicle reaching a booked unloading bay outside its slot cannot tip that day even on the cheapest corridor, and the saving becomes a cost that rolls to tomorrow.

The shape of the constraint matters: a delivery window is not a cost item, it is an elimination. Cost items trade against each other — a little more distance for a little less toll. A window does not trade. So optimisation first strikes out the alternatives that cannot meet it, then compares cost across what is left. This is the point most often confused in the field: when a vehicle runs late the instinct is a faster corridor, yet the answer usually lies in the sequence.

Waiting times make it harder still. Loading at a site can take half an hour or three. That duration lives in your own records, not in the road calculation, and no model sees it unless it is captured.

Why is the empty return a problem of the whole route rather than one trip?

The empty return is not one vehicle's problem; it is the outcome of a balance formed by all the trips dispatched that day. In the corridor where one vehicle runs back empty, another usually needs to go out loaded — yet looked at separately the two trips never reveal the pairing.

The classic flow: a job comes in, the planner finds a suitable vehicle and assigns it; the next job arrives and the same thing happens. Each step is reasonable, the aggregate rarely is, because nobody looked at the whole board. The contribution of optimisation begins here: it takes the jobs as one set, measures empty kilometres across the whole plan rather than on a single trip, and looks for the combinations that turn one vehicle's return leg into another job's outbound leg.

One thing has to be said plainly: no level of saving can be promised here. The gain varies with the lane, the balance of loads and that day's job list. Where backloads are plentiful the improvement stays modest; in a corridor worked one way only, the difference is obvious.

Which corridors do vehicle type and weight limits rule out from the start?

Vehicle type and weight limits are hard constraints that disable alternatives before optimisation begins. A bridge with a weight limit, an underpass with a height restriction or a road closed to certain vehicle classes takes that corridor off the list however cheap it would have been.

These constraints have two properties. They do not flex: you can trade between cost items, but you cannot drive down a road you cannot drive down. And they are specific to the vehicle — between the same two points, the corridor open to a panel van and the one open to a tractor unit are not the same.

The common mistake is calculating the route independently of the vehicle. A corridor produced on a general-purpose map does not know the vehicle class and can suggest a road closed to heavy goods vehicles. Toll charges vary by class too, so a figure worked out for a van and carried into a quote for a tractor unit makes the cost wrong from the first line.

Why does the order of stops matter more than the corridor?

On a multi-stop trip the total cost is set by the sequence in which the stops are visited, not the road chosen between them. The spread between alternative corridors linking two points is bounded; the spread between sequences over the same set of stops is many times wider.

The reason is combinatorial: as stops are added, the count of orderings quickly passes what anyone can scan by hand. On a five-stop round a planner can try a few sequences by eye; over a fifteen-stop day the sequence used is not the best one but the first one that came to mind. The price is paid invisibly: the vehicle enters the same area twice, doubles back, and misses a second run. None of it is logged as an error, because the deliveries were made.

Delivery windows constrain the sequence further. A customer with a morning slot breaks the order that makes geographical sense; a depot closing in the early afternoon pulls every stop behind it forward. This is why multi-stop planning solves the sequence first and the corridor afterwards.

How does AI actually build this calculation?

Artificial intelligence does not know the road. It writes a cost against every option, strikes out whatever fails the constraints, and searches for the lowest total among the combinations that survive. Four steps, no magic in any of them.

1. The constraints are defined. Weight, dimensions, vehicle class, delivery windows, driver hours and customer-specific conditions. This step alone eliminates part of the alternatives.
2. A cost is written against every option. Distance, duration, toll charges and the time the vehicle stays committed become a common measure, so unlike items can be compared.
3. Combinations are searched. Which job on which vehicle, which stop in which position. What is sought is not one corridor but the distribution of the whole day.
4. Durations are learned from past records. How long loading actually takes at a site, and when a corridor slows down, is read out of previous trips.

The fourth step is the part that improves over time, and it depends entirely on data. If waiting times are not recorded the model cannot learn them; if arrival and departure times are not kept the estimates stay theoretical. Optimisation quality rests less on the algorithm than on your own record-keeping — we covered what happens when that data is scattered across files in where transport tracking in Excel breaks down.

The practical conclusion: freight software that keeps trip, vehicle and customer data in one place is the precondition for optimisation, not an add-on to it. Constraints the system does not hold are constraints the model cannot respect. Artificial intelligence is better treated as a layer built on top of your records, which is how AI is used across the product, from the quoting screen to the planning board.

What can AI not do, and why must planner approval stay?

Artificial intelligence cannot account for anything that never enters the model — and much of any operation never does. A customer who will not work with a particular driver, a site running a stock count today, a driver who has known the region for years, a job tied to a verbal commitment: none of it is written in any field. The table below separates the machine's part of the calculation from the person's.

Row by row: the model works out distance and duration over the real corridor; whether that estimate is realistic for this lane is said by the person who knows it. It sums the gates on the route for the vehicle class in question; whether that charge is passed on to the customer is a commercial decision. It produces the stop orderings that satisfy the constraints, while the person who knows the relationship decides which customer is seen first. It lists the vehicles that fit the weight, volume and road limits; which driver goes to that customer is a separate question.

The last three rows carry the same split. The model derives waiting time as an average from past records; only a person knows the site has a stock count or a shift change today. It measures empty kilometres across the whole plan; whether waiting for a backload is worth it is the planner's call. It recalculates the distribution when a constraint changes; applying, amending or rejecting that plan stays in human hands.

The right design is for the suggestion to arrive as a plan: which vehicle, which jobs, in what order, and why. Once the reasoning is visible the planner can read it, change a line, or reject it outright — and reverse it after it has been applied.

The same holds on the quoting side: the model builds the price, sales decides whether it is acceptable, as we covered in preparing quotes with AI. The machine's job is to calculate and the person's job is to decide. Software that keeps that boundary lightens the daily workload; software that erases it keeps the planner correcting the system.

Is route optimisation about finding the shortest way?

No. Route optimisation tries to minimise the total cost of a trip rather than its distance, and distance is only one component of that cost. Between the same two points, a motorway-heavy corridor is shorter and faster but carries toll charges, while a state-road corridor produces no toll charges but runs longer, burns more fuel and keeps the driver on the road for more hours. Which one is right depends on what that particular job puts first. If the delivery time is critical, duration decides; if the margin is thin, tolls decide; if vehicles are scarce, the moment the vehicle comes free decides. The job of optimisation is not to pick one of these objectives but to produce a plan that holds all of them at once.

Why is the shortest route not always the cheapest route?

Because the corridor that shortens the distance usually runs on paid roads, and the kilometres you save are paid back at the gates. Three main items pull in different directions on a road move: fuel grows with distance, toll charges grow with the amount of motorway used, and driver cost grows with elapsed time. Move to the free corridor and the toll bill goes to zero while distance and duration stretch; move to the motorway and the duration falls while the toll bill switches on. The right decision comes from adding those three into a single total and comparing the alternatives. A decision made without adding them up is not a route choice, it is a habit.

How does AI reduce empty running?

By assessing every trip of the day together rather than one trip at a time. An empty return looks like the problem of a single vehicle, but the solution is hidden in the route as a whole: in the corridor where one vehicle runs back empty, another vehicle probably needs to go out loaded. When jobs are handed to vehicles one by one in the order they arrive, that pairing is never formed, because nobody allocates thirty jobs across twenty vehicles while looking at all of them at once. This is where optimisation contributes: it takes the jobs as one set instead of one at a time, and measures empty kilometres across the whole plan rather than on a single trip. No fixed level of saving can be promised; the gain varies with the lane, the balance of loads and that day's job list.

Why does the order of stops matter on a multi-stop trip?

Because on a multi-stop trip the total cost is set by the sequence in which the stops are visited, not by the corridor chosen between them. A trip with five stops can be sequenced in a large number of ways, and the spread between those sequences is far wider than the spread between two alternative corridors. The wrong order sends the vehicle into the same area twice, forces backtracking, and makes a second run in the same day impossible. Stops with booked delivery windows constrain the sequence further: a customer with a morning slot can break the order that makes the most geographical sense. That is why multi-stop planning solves the sequence first and the corridor second.

Should an AI-suggested route be applied without planner approval?

No; the suggestion should be presented as a plan, and the decision to apply it should stay with the planner. Every operation holds information the model cannot see: a customer who does not want to work with a particular driver, a site running a stock count today, a driver who knows the region, or a job tied to a commitment given verbally. Most of this is written down nowhere, and even when it is, it belongs to that day only. The model finds the best combination that fits the constraints; the planner adds the reality that sits outside them. The right design is that the plan is shown, its reasoning is visible, and it can still be reversed after approval.