What a Scheduling Optimizer Ignores

Why this matters

A route or schedule optimizer is the most literal tool a shop will ever use. It finds the best answer to exactly the question it was given, and the question it is usually given is "which order of these jobs drives the fewest miles in the time available?" Everything else a good dispatcher weighs, the arrival window promised on the phone, which tech can actually do the work, where the truck can park, which customer is still upset about last spring, does not exist for it unless someone has turned it into data. The result looks optimal on screen and goes wrong on the street.

This card covers what an optimizer cannot see, which of those blind spots you can fix by entering data and which you cannot, and the override discipline that keeps a dispatcher's judgment from turning into either blind trust or a daily fight with the tool. A full case of an optimized day going wrong is told separately. See related: The Route Optimizer Made the Day Longer.

What the tool is actually solving

Under the interface, an optimizer has two parts. An objective, the number it is trying to make small, almost always drive time or miles, sometimes overtime or idle gaps. And constraints, the rules a solution must obey, such as a tech's shift length or a job's fixed appointment. It searches orders and assignments until it finds one that obeys every constraint and gets the objective as low as it can.

Two consequences follow, and they explain nearly every bad optimized day:

• Anything that is not a constraint is free to break. If an arrival window is stored as a note rather than as a time constraint, the tool cannot read the note, and it will happily put an 8 to 10 job at 11:40 because that saves four miles.
• The inputs are estimates it treats as facts. Job durations come from a template ("water heater swap, 3 hours"). Drive times come from a map service at typical traffic. A template that is an hour light on a job type, or a map that does not know the bridge closes for school traffic, produces a plan that is precise and wrong.

The optimizer is not making judgment calls badly. It is not making them at all.

Blind spots, sorted by what you can do about them

The useful way to sort what an optimizer ignores is not by topic but by remedy, because that decides whether the fix is a setting, a note, or a human.

Encodable, and usually just not entered yet. These are facts the tool can respect if you give them to it as constraints:

• Customer arrival windows promised at booking.
• Required skills and licenses per job type (a gas line, a backflow test, a second-story roof).
• Jobs that need two people or a specific vehicle.
• Fixed external times: an inspector's appointment, a supply-house will-call that closes at noon.
• Parts staged on a particular truck.

If a dispatcher overrides for one of these more than occasionally, the configuration is incomplete, and every override is a symptom of that.

Encodable only crudely. These are real and physical, and most tools can only approximate them, usually as a time restriction or a fixed duration padding:

• Access and parking. A downtown condo where the loading zone is usable only before 9; a street with no parking for a box truck after the commuter lot fills; a gated community whose guard house stops letting contractors in at 4; a steep gravel drive the trailer cannot climb when wet.
• Local traffic the map averages away. A school drop-off zone that adds fifteen minutes at 8:10 and none at 9:00.
• Site conditions that set duration. A crawlspace job that takes twice as long in a house the tech has not been in before.

These are best recorded on the customer or site record, with the time effect stated in minutes ("box truck cannot park after 11, plan a smaller vehicle or before 11"), so the dispatcher sees them at the moment of overriding.

Not data at all, or not data you should automate. Relationships and judgment:

• The customer who must not get the new tech. An elderly customer who was frightened by a rushed visit and now trusts one person. A customer with an open complaint whose next visit is a recovery visit, and should go to someone senior. A property where a tech had a confrontation with the occupant and should not go alone.
• The tech who needs a lighter day. First week back after an injury, or a new hire who should not get three unfamiliar job types in a row.

These belong with a person. A "preferred tech" or "do not assign" field on the customer record can carry the decision once it is made, but it should carry a short, factual reason that the dispatcher can act on and would be comfortable having the customer read, because under some state privacy laws customers can ask what you hold about them.

One boundary belongs here because it trips up owners in good faith. A customer request rooted in a tech's sex, race, religion, national origin, age or another protected characteristic ("don't send me a woman", "I want someone who speaks like me") is not a scheduling preference. Honoring it can expose the shop under employment discrimination law: federal Title VII reaches employers with 15 or more employees, and many state laws reach much smaller shops, some down to a single employee. Do not encode it and do not quietly honor it; talk to an employment attorney about how to respond to the customer. This is not legal advice.

The override discipline

An optimizer works when the dispatcher can override it freely and the shop learns from every override. It fails when overrides are either forbidden (the plan is the plan) or invisible (the dispatcher drags jobs around and nobody knows why). Four rules hold the middle:

1. Override only for a reason you can name in a few words. "Window 8 to 10", "needs gas cert", "no truck parking after 11", "recovery visit, send senior". If the reason is "it just looks wrong", look again; sometimes the tool has found something real.
2. Log each override in one line: the job, what you changed, the reason in those few words. In most field software this is a note on the job; a shared sheet works too.
3. A reason that repeats becomes configuration. A workable default: the same reason three times in 30 days goes on the list to encode, as a constraint if it is encodable, or as a site note with a time effect if it is not.
4. Re-run the optimizer after encoding, and watch the override count fall. If it does not fall, the encoding did not capture the real rule.

The log is what turns judgment into a system. Without it, the dispatcher's knowledge stays in one head and leaves with them.

Worked example: one tech, one day

A plumbing shop's optimizer produces this plan for its senior tech: seven jobs, 41 miles, 96 minutes of driving. The dispatcher reviews it before 7 a.m. and finds four problems.

After the overrides, and with the second tech's route re-optimized to absorb the gas job, the senior tech's day is 49 miles and 112 minutes of driving. The overrides cost 16 minutes of driving, 112 minus 96, on this route.

Compare that cost in the same unit as what it prevented. The 8 to 10 window broken at 10:40 likely means a customer who took the morning off, a rebooking, and a second trip to the same address; that second trip alone is easily more than 16 minutes of driving, before the job time and the goodwill. The condo at 1:15 means a tech circling for parking or carrying a water heater three blocks, which on that street the dispatcher has seen add 40 minutes. The gas job on an unqualified tech is a job that cannot be done at all on arrival. The recovery visit on the newest tech risks turning an open complaint into a lost customer. The optimized plan was shorter on paper and longer in every measure the shop actually pays for.

What the log showed a month later. The dispatcher had logged 23 overrides across all routes. Tallied by reason: windows 9, skills 6, access and parking 5, relationship 3, which is 23. Windows and skills were both over the three-in-30-days default and were encoded as constraints that week. The five access overrides were spread across three addresses, so each address got a site note with its time effect. The three relationship overrides were three different customers, each given a preferred-tech note with a factual reason. In the following month the same routes produced 6 overrides.

What would change the answer. On a day of simple, uniform work (a dense block of maintenance visits, every tech qualified for all of them, no promised windows) the optimizer's plan is close to right and most overrides cost more than they save; the dispatcher should accept it and spend the morning elsewhere. The more the day mixes skills, windows and unfamiliar sites, the more of the decision lives outside the tool, and the more the override discipline earns its time.

When the optimizer is right and you are wrong

Overrides are not automatically correct. A dispatcher who has run the same geography for years carries habits that were right once: the bridge that used to back up, the customer who used to insist on mornings. The tool has no habits, which is sometimes its advantage. The override log protects against this too: when a reason shows up that nobody can explain anymore, test it. Let the optimizer's version run once, on a low-stakes day, and see what happens.

References

• Title VII of the Civil Rights Act of 1964, 42 U.S.C. 2000e and following, employer coverage at 15 or more employees; state fair employment statutes as enacted
• See related: The Route Optimizer Made the Day Longer
• See related: What AI Cannot Know About Your Job Site
• See related: The Automation Change Control SOP