Why Routing Software Fails: The Feasible Day Test

A routing or scheduling project almost always arrives framed as an optimisation problem. Cut the miles. Fit another two jobs into the day. Level the load across the crew. The software gets built, it produces a schedule that is measurably better on the stated objective, and then the dispatchers edit it every morning until it looks like what they would have drawn by hand. Within a quarter the optimiser is advisory, and within two it is switched off.

The postmortem usually blames the algorithm, the data or change management. It is none of those. The project optimised before anyone had established that the system could produce a single **feasible** day — one schedule the people who run dispatch would accept without touching it. This article covers how to establish that first, using a check we call the Feasible Day Test, and what to build once you have run it. It is written for operations and technology leaders scoping a field service, delivery, home-care, installation or logistics system.

The optimiser was never the hard part

Vehicle routing is one of the most studied problems in operations research, and mature implementations are freely available. Google's OR-Tools solves capacitated routing with time windows, multiple depots, pickup-and-delivery pairing and vehicle-specific costs, with worked examples in four languages (Vehicle Routing Problem, Google OR-Tools). If the risk in your project were the algorithm, you could download the algorithm this afternoon.

The risk sits one layer below, in the constraint model: the conditions that make a route legal in your business. A solver handed an incomplete constraint model does not fail loudly. It returns a confident, provably optimal answer to a question nobody asked. Nothing in the output says *this engineer is not certified for that appliance*, or *that van cannot reach that site before two o'clock*. The schedule looks excellent right up to the moment a human reads it.

That asymmetry is the whole problem. Missing constraints are invisible in the output and obvious to the dispatcher, which is exactly the arrangement that produces a rejected system.

Feasible before optimal

Two words get used interchangeably in these projects and mean very different things.

**Feasible** means every rule that would cause a dispatcher, a regulator or a customer to reject the route is encoded, and the route satisfies all of them. **Optimal** means that among feasible routes, this one is cheapest against some objective.

Optimality is meaningless without a complete feasible set. Optimising over an incomplete one is not a partial success; it systematically produces schedules that are cheaper *because* they violate the rules you forgot to write down. The solver finds those violations reliably, because they are where the savings are.

So the order is not negotiable: establish feasibility, then optimise. Almost every failed scheduling implementation inverted it.

The Feasible Day Test

Five checks. None needs a vendor, a solver or a licence, and the whole thing can be run in a fortnight against a system you have not built yet.

1. Reproduce one real day, unedited

   Take a day already worked. Same jobs, same crew, same vehicles, same weather. Ask your proposed system — or a spreadsheet standing in for it — to produce a schedule the dispatcher who ran that day would sign off. Not a better one; the same *class* of schedule. If it cannot, you have found the gap while it is still a conversation rather than a change request.

2. Make the dispatcher say why, out loud

   Every edit a dispatcher makes to a generated schedule is a constraint you have not modelled. Sit next to them while they make the edits and ask why after each one. *Why not send Ravi? Why does that job need the afternoon? Why are those two never on the same run?*

   The output of this step is a list of sentences, not a system. Twenty to sixty of them is normal. Anything you cannot write as a sentence, you cannot encode.

3. Sort every constraint into hard, soft, or preference

   This is the step teams skip, and it is the one that decides whether the finished system is usable.

• **Hard.** Legal, contractual or physical. Violating it is a breach or a safety event: certification for the equipment, licence class for the vehicle, drivers' hours, cold-chain temperature, controlled-drug custody, a two-person lift.
• **Soft.** Permissible but costly. Overtime, an SLA breach with a known penalty, a second visit.
• **Preference.** Habit or convenience. This engineer usually takes the north patch. This driver likes an early finish.

Conflating these is fatal in both directions. Model a preference as hard and the solver returns "no feasible solution" on a normal Tuesday, destroying trust immediately. Model a hard rule as soft and the solver trades it away for four miles, destroying something more important. Force a decision on every line; where the business genuinely cannot decide, that is a governance finding, not a modelling detail.

1. Find the constraints that live in no system of record

   These are the expensive ones, and they are the reason this test exists.

   The gate code that makes one job take forty minutes rather than twenty. The customer who will only accept one engineer after a bad visit years ago. The site whose loading bay is unusable over lunch. The apprentice who must be paired with a senior on anything involving gas.

   None of that is in the ERP, the CRM or the field service tool, because none of it was ever needed to raise an invoice. It lives in a dispatcher's head and on a laminated sheet taped to a monitor. Until it becomes data with an owner and a change process, no scheduler can produce a feasible day.

   This is usually the finding that reprices the project, and finding it in week two is worth far more than finding it in month seven. The same pattern shows up in planning — see why supply chain AI fails on data rather than models.

2. Name who owns the exception at seven in the morning

   A schedule that is feasible on paper still meets a van that will not start. Before go-live, decide three things: who is allowed to override the system, what the system does with the rest of the day when they do, and whether the override is captured.

   Capture it. The override log is the only honest, continuously updated record of where your constraint model is wrong, and it is generated for free by people doing their jobs. Teams that log overrides get a constraint model that improves. Teams that do not get a system that quietly drifts back to manual.

Why the constraints are missing in the first place

Three mechanisms, and they are worth naming because they tell you where else to look.

**Systems of record capture what was billed, not what was possible.** A completed work order records the engineer who went. It does not record the four who could not have gone, which is precisely what a scheduler needs.

**Constraint knowledge is risk knowledge, so it concentrates in experienced people.** Which customer complains, which site is awkward, which pairing is unsafe: all learned by being there when it went wrong, and none of it written down.

**Constraints change and have nowhere to be changed.** A new certification, a new depot, a renegotiated SLA. With no owned place to record a rule, the rule stays in the head of whoever learned it.

Build the feasibility checker first

The practical recommendation that falls out of this test is a small one, and it is not the optimiser.

Build a **feasibility checker**: a service that takes a proposed assignment — this job, this person, this vehicle, this time — and returns legal or not legal, with a reason. That is it.

It is a fraction of the work of a routing engine, and useful from the first week: it validates the schedules your dispatchers already build by hand and catches the certification mismatch before the van leaves. It turns the constraint model into an artefact you can version, test and argue about. And when you do build or buy an optimiser, the checker *is* its constraint set, already proven against real days.

When a rule beats a solver, and a solver beats a model

Worth conceding plainly, because the alternative is selling something that will not survive contact with the operation.

If you run one depot, a dozen vans and a stable geography, a well-chosen dispatch rule plus a feasibility checker may be the whole answer, and the optimiser may never pay for itself. Say so early.

Where constraints are hard and known, a classical constraint solver beats a learned model on the dimension that matters: it can prove a route legal and explain why one is not. Machine learning earns its place further up the pipeline, where the *inputs* are uncertain — how long this job will take at this site with this engineer, whether the customer will be in, whether the part is on the van. Those estimates feed the solver; they do not replace it. AI field service scheduling sits on top of a feasibility layer, never instead of one.

The sequence, then: rules and a feasibility checker, then a constraint solver, then learned models for the uncertain inputs. Projects that run it in that order tend to ship. Projects that start at the end tend to become advisory.

Frequently asked questions

How long does the Feasible Day Test take?

Two weeks of part-time effort for a mid-sized operation: a day shadowing dispatch, a few days writing up and classifying constraints, and a session with operations to settle the hard-versus-soft arguments. Deliberately cheaper than the scoping workshop it replaces.

We already bought a scheduling product. Is this still worth running?

More so. A bought product has a fixed constraint vocabulary, and the test tells you which of your rules it cannot express before you configure around them. Rules the product cannot hold are the ones your dispatchers will keep in their heads, which caps how much of the schedule you can automate.

Does this apply outside field service?

Yes. Anything where work is assigned to constrained resources against time: home care visits, clinical rostering, last-mile delivery, installation crews, port and yard moves, machine scheduling on a shop floor. The constraint sources differ; the failure mode does not.

Should the feasibility checker be built or bought?

Built, almost always. The rules it encodes are specific to your operation, they are the thing competitors cannot copy, and the checker is small. Buy the optimiser, if you buy anything.

Where to take this next

Run the Feasible Day Test before you write the requirements document. It costs a fortnight and it routinely changes the shape of the project — usually by revealing that the first deliverable is a constraint model with an owner, not an optimisation engine.

Moweb builds scheduling, dispatch and planning systems for operations where the constraints are real and mostly undocumented. For a second opinion on a scheduling project — including the opinion that you do not need an optimiser — talk to our team, or see how we approach supply chain and logistics software and applied AI and machine learning.