Simulation
Change what the planner is told to value, and watch the “best” route plan change with it. An objective function is a policy decision disguised as arithmetic.
Every transport optimiser needs a definition of better. Before it can compare two plans, something has to tell it whether a plan that saves £400 but breaks a delivery promise is an improvement or a failure. That definition is the objective function, and it is almost never a single number. It is a weighted combination of things that genuinely conflict: total cost, service adherence, vehicle utilisation, driver hours, empty running.
This simulation makes those weights adjustable. You set how much the planner cares about each objective, run the optimisation, and see which candidate plan wins. The point is not that one configuration is correct. The point is that the answer moves — sometimes dramatically — when the weighting moves, even though the orders, the fleet, and the algorithm have not changed at all.
That is why the objective function is a product decision rather than a technical one. Somebody has to decide what the business is actually optimising for, and that decision is usually made implicitly, by whoever configured the system years ago and has since left.
Start by running the simulation with the default weights and note which plan is selected and what the vehicle fill distribution looks like. Then push a single weight to an extreme — make cost overwhelmingly dominant, for instance — and run it again. Watch the What changed? panel: it explains which trade-off the optimiser just accepted on your behalf.
Two behaviours are worth hunting for deliberately.
The first is the tipping point. Adjust one weight gradually and you will often see nothing happen for several steps, then an abrupt switch to a structurally different plan. Optimisers do not degrade smoothly. A small change in stated priorities can reorganise an entire day’s work, which is exactly why planners distrust systems that change their answer for no visible reason.
The second is the hidden cost. When you optimise hard for one objective, look at what quietly got worse. Maximum utilisation frequently means fuller vehicles and later deliveries. Best cost frequently means longer driver days. Nothing in the arithmetic flags this as a problem, because you told it not to care.
If you take one thing from this model: an optimiser cannot be wrong about priorities it was never given. Most complaints that “the optimisation is rubbish” turn out to be complaints about an objective function nobody has reviewed since implementation. Before tuning an algorithm, it is worth checking whether the system is being asked the right question — and whether the people who own the consequences agree with the weights.
Series guide
This series uses My Name is Earl as a recurring way to explain transport optimisation. Earl gives us the objective, Joy gives us the constraints, Crabman gives us hidden operational knowledge, and Camden County gives us the messy operating system in which every plan has to survive.
The Objective Function
Optimisation role: Earl represents the decision objective: the thing the system is trying to improve.
Transport meaning: In transport, this is the definition of a better plan: lower cost, fewer empty miles, better service, improved utilisation, lower risk, or a weighted compromise across all of them.
Example: A TMS optimiser needs to know whether it is protecting cost, service, utilisation, carbon, resilience, or some agreed balance.
The Optimisation Target
Optimisation role: The list turns vague improvement into a structured set of outcomes.
Transport meaning: Transport planning needs the same clarity. Before an optimiser can help, the system must know what matters and how success will be measured.
Example: A planning model without a clear target is just a fast way to produce a confident but questionable answer.
The Feedback Loop
Optimisation role: Karma represents delayed consequences: decisions that return later as effects elsewhere in the system.
Transport meaning: A cheap plan may create late deliveries, rework, waiting time, driver pressure, customer escalation, and future operational drag.
Example: Reducing vehicles today can increase failed deliveries tomorrow, which then creates replanning work and service recovery cost.
The Constraint
Optimisation role: Joy represents rules, limits, and non-negotiables that restrict the solution space.
Transport meaning: Driver hours, delivery windows, site rules, trailer compatibility, customer requirements, vehicle capacity, and depot opening times all decide what is actually feasible.
Example: A route that looks profitable is still unusable if the vehicle cannot access the site or the driver cannot complete the hours legally.
Local Optimisation
Optimisation role: Randy represents well-meaning local decisions that solve the immediate problem but damage the wider system.
Transport meaning: A depot, planner, or customer-specific workaround can look sensible locally while increasing cost, complexity, or risk across the network.
Example: One depot protects its own resources, but the overall network ends up with more empty running and poorer asset utilisation.
Unknown Knowledge
Optimisation role: Crabman represents operational knowledge that exists but may not be visible in the formal model.
Transport meaning: Planners and drivers often know things the system does not: awkward yards, slow sites, unreliable booking slots, or routes that work on paper but not in reality.
Example: The database says the delivery window is valid, but the planner knows the customer never unloads before 09:30.
Flexible Capacity
Optimisation role: Catalina represents scarce capability that can be used in different ways.
Transport meaning: Flexible resources matter: multi-skilled drivers, specialist vehicles, ADR capability, chilled/frozen compatibility, tail-lift equipment, or assets that can cover multiple work types.
Example: A flexible vehicle or driver can protect the plan when demand changes, but that flexibility is itself a scarce resource.
The Operating Environment
Optimisation role: Camden County represents the messy, changing system in which the model has to operate.
Transport meaning: Transport planning happens in a live environment of late orders, delays, missing data, changing requirements, congestion, customer exceptions, and imperfect information.
Example: A plan that works in a clean dataset may collapse once real arrivals, delays, amendments, and site behaviour are included.
The Reset Point
Optimisation role: The motel represents where the system recovers, resets, and exposes its true state.
Transport meaning: Depots, yards, cross-docks, loading bays, and trailer parks are not passive locations. They are capacity points where plans either recover or fail.
Example: A route plan can look efficient while the depot quietly becomes the bottleneck that breaks the next wave of work.
Future Consequences
Optimisation role: They represent the future state created by current decisions.
Transport meaning: Transport optimisation should consider tomorrow’s capacity, customer confidence, driver availability, asset positioning, and accumulated operational debt.
Example: A plan that wins today by burning goodwill, buffers, or driver capacity may weaken the system for the next planning cycle.
Interactive simulation · Birmingham, UK
100 transport jobs · 1–5 pallets each · 14-pallet vehicles. Depot in Birmingham city centre. All deliveries within 30 miles. Each visible route is drawn as depot → stop → stop → depot legs, with every leg coloured by remaining load fill.
Set your weights above and click Run to see how the model changes vehicle count, fill rate, route shape, service risk and unrouted work.
Change one input at a time, run the model, and compare the result with the starting state. Then repeat the experiment with a different constraint or strategy so you can see which relationships drive the outcome.
Look for trade-offs, thresholds, feedback loops, and points where a locally attractive decision produces a worse system-wide result. The simulation is intended to make the article's idea observable, not to predict a real operation.
This is a deliberately simplified model. It omits the data quality, exceptions, human judgement, and operational constraints of a live system, so treat its behaviour as an illustration of a mechanism rather than as a planning recommendation.
Read: Earl’s List Is the Objective Function →
Explore the complete Transport Optimisation Explained series