Your routing optimiser produces a good plan and the transport planner changes it every morning. What is going wrong?

The plan is optimal and unrunnable

Start from the likeliest explanation, which is that the solver is working correctly. It found a good solution to the problem it was given, and the problem it was given is missing things.

Every override has a reason, and the reasons are almost always real constraints that live in a planner's head. A yard only one driver can reverse into. A customer whose site manager leaves at three. A vehicle with an intermittent tail-lift fault that nobody logged. A drop that must be same-vehicle as another because it is one customer receiving one order in two cartons.

None of that is in the data, so the solver cannot honour it, so the plan is infeasible in the physical world while being optimal in the model. Treating this as the planner being obstructive is the mistake that kills routing projects, because they will keep overriding — correctly — and the system will be judged as useless.

The reframing that matters: a worse plan that gets run beats a better plan that gets rewritten.

Hard, soft, and where the argument actually is

Most disagreements between a planner and a solver turn out to be about which kind of constraint something is.

A hard constraint makes a plan invalid. Vehicle capacity, driver hours, licence class, a physical access restriction. Violate one and the plan cannot happen.

A soft constraint carries a penalty in the objective. A preferred delivery window, a preference for keeping a driver on a familiar area, a target for parcels per route. Violate one and the plan is worse but runnable.

The planner's override is frequently a case where the business treats something as hard and the model has it as soft — or the reverse, where the model refuses to break a window that everyone on the ground knows is advisory, and the planner has to intervene to get a feasible day.

So the first diagnostic question is not "why did it produce this plan" but "for each thing they changed, is that a hard constraint we modelled as soft, a soft one we weighted wrongly, or something we never represented at all". The three have different fixes.

Capture the override, cheaply

You cannot fix constraints you cannot see, and asking planners to file a form is a request that will be ignored under time pressure at seven in the morning.

The workable design is to make the reason a single click from a short list, attached automatically to the change the system already recorded: which stop moved, from which route to which, at what time. Free text as an optional extra for the unusual ones.

override reasons, one month, one depot
  Customer access or timing not in the data        41%
  Driver knowledge of the area                     23%
  Vehicle unsuitable for the drop                  14%
  Two stops must share a vehicle                    9%
  Balancing workload across drivers                 8%
  Other                                             5%

Now the backlog writes itself. The top row is a data-quality project — customer site constraints that need capturing once and reusing. The third is a vehicle-attribute model. The fourth is a same-vehicle constraint the solver supports and nobody configured. None of those is an optimisation improvement, which is the point.

The objective is a separate question

Once the plan is feasible, there is a second argument about what "good" means, and it is a business question wearing mathematical clothing.

Minimising total distance, minimising vehicle count, maximising on-time performance and balancing workload across drivers pull in different directions. A plan with one fewer vehicle usually has longer routes and more risk of missing a window. A perfectly balanced plan is rarely the cheapest.

The weights that express this belong to the business and should be visible and adjustable, not buried. And they change seasonally: in peak the priority is throughput, in quiet months it is cost, and a fixed objective is wrong for part of the year.

Two practical constraints on the whole exercise are worth naming. The problem is NP-hard, so nobody solves it to proven optimality at operational scale — you are running a heuristic against a wall-clock budget, which is minutes for overnight planning and seconds for redispatch when a driver calls in sick. And the input matrix is a model too: travel times taken as free-flow rather than time-of-day dependent produce plans that are optimistic in exactly the hours that matter.

Prove it, or the argument never ends

The last piece, and the reason adoption arguments persist. Without measurement, "the solver's plan is worse" and "the planner's plan is worse" are both assertions.

The comparison that settles it is not plan against plan on paper — it is planned against actual. Record, for both the generated plan and the plan as run, the distance, the vehicle count, the on-time rate and the failed deliveries. After a few weeks you know whether the overrides improved the day or merely changed it, and you know it per reason code.

That evidence usually shows both things: some overrides are recovering constraints the model lacks and are clearly right, and some are habit. Being able to separate the two, with numbers, is what turns a contested rollout into a working one — and it is a far better answer in an interview than any discussion of metaheuristics.

The overrides are the requirements document. Capture the reason, feed the recurring ones back as constraints, and stop treating a planner who knows something the model does not as a user problem.