The Route Optimizer Made the Day Longer

Why this matters

A six-tech HVAC shop switched on the route optimizer in its field software at the start of spring tune-up season. The vendor's dashboard said it was working: planned miles per tech-day fell by about 18 percent in the first two weeks. The techs said the opposite. They were getting home later, the office was fielding angry calls about missed arrival windows, and the owner was paying overtime he had not paid the season before.

Both were telling the truth about different numbers. This is how the shop worked out which number to believe, ruled out the obvious suspects one at a time, and found the cause. The general picture of what optimizers cannot see is covered separately; this case is about diagnosing it when it happens. See related: What a Scheduling Optimizer Ignores.

The signal, in the shop's own numbers

The owner pulled two weeks before the optimizer (manual dispatch) and the first two weeks with it. Six techs, ten working days each, so 60 tech-days in each period.

The planned figure fell from 62 to 51, which is the 18 percent the dashboard was reporting. The actual figure rose from 67 to 71. That gap was the first real clue: the plan was getting shorter while the day was getting longer, so whatever was happening was happening after the plan was made.

Suspect one: the drive-time estimates are wrong

The owner's first theory was that the optimizer's map underestimated traffic, so its tidy routes were tidy only on paper. It is a reasonable guess, because drive times come from a map service at typical traffic and spring roadwork is not typical.

The test. Compare planned against actual drive time leg by leg, but only on legs that were in the plan, so unplanned trips do not muddy it. The GPS log made this easy. Under manual dispatch, planned legs ran about 8 percent over their estimates. Under the optimizer, planned legs also ran about 8 percent over.

The verdict. The estimates were off by the same amount before and after, so they could not explain a change. Eliminated. It also accounted for part of the miles: 51 planned miles running 8 percent over comes to about 55 actual miles on planned legs. The other 16 miles of the 71 had to come from legs that were never in the plan.

Suspect two: the job-duration templates are light

The second theory was that the optimizer packed more jobs into a day because it trusted the job templates, and the templates were short, so techs ran late all day.

The test. Planned against actual on-site time per job type, before and after. Two job types were genuinely light: the template for a heat pump tune-up was 60 minutes and the median actual was about 80, and a first visit to a new customer ran long as well. But both had been light by the same margin before the optimizer, and the number of jobs planned per tech-day had barely moved.

The verdict. A real problem, worth fixing on its own (the shop updated both templates), but not new, so not the cause. Eliminated as the explanation for the change.

Suspect three: the plans are breaking promises

With drive estimates and durations ruled out, the 16 unplanned miles a day pointed at reshuffles and return trips. The dispatcher, asked directly, said she had been moving jobs around midday "all the time" since the switch. Why?

The test. For the second week, take every job that had a promised arrival window and compare its planned arrival against the window. Of 61 windowed jobs, 14 were planned outside their window, about 23 percent of the 61. The arrival windows were stored in a notes field from the old booking process, and the optimizer could not read notes, so it was free to put a 12 to 2 appointment at 9:15 if that saved a few miles.

Following the 14 through the day explained the extra miles. The dispatcher caught 5 before trucks left. The other 9 went out as planned. Of those 9, 6 customers were not home or could not accept the early or late arrival and were rebooked, each a second trip to the same address on another day; 3 waited it out. On top of that, techs and the dispatcher reshuffled the day each time a window was about to be missed, which broke the optimized sequence anyway and added the cross-town legs the optimizer had been designed to avoid.

Here is one tech's Tuesday from that week, planned against what happened:

TECH B, TUESDAY      PLANNED        ACTUAL
07:30 leave shop     07:30          07:30
Job 1 tune-up        08:05          08:05  done
Job 2 window 12-2    09:15          09:15  not home,
                                           rebooked Thu
Job 3 tune-up        10:30          09:40  done
Job 4 ductless start 11:45          11:00  not certified,
                                           swapped to A
Job 5 window 8-10    13:00          12:15  customer left
                                           at 10, rebooked
Job 6 tune-up        14:20          13:20  done
Job 2 call-back      -              14:45  phoned, no
                                           answer
Job 7 window 3-5     15:40          16:10  done, late
Back at shop         16:50          17:55

Of seven planned jobs, four were completed (one of them late), two were rebooked for a second trip, and one was handed to another tech mid-day, and the tech got back 65 minutes after the plan said he would. The planned day was efficient. The actual day bought four completed jobs with the driving of seven, and booked two more trips to addresses already visited.

The verdict. Confirmed as a cause.

Suspect four: the right tech is not on the job

Tech B's job 4 pointed at a second cause. The shop requires one of its two manufacturer-certified techs for ductless system startups, because the warranty registration depends on it. That requirement lived in the dispatcher's head and in a job template description, not in a skill field.

The test. For the same week, list every job whose type required a qualification and check the assigned tech. Seven jobs were assigned to someone without it. Four were discovered on arrival, each one a mid-day swap that pulled a certified tech across town; three were caught by the dispatcher the night before.

The verdict. Confirmed as a second cause, and it explains part of the overtime: the certified techs' days were extended by the swaps they absorbed.

The number that lied, and why

The figure that misled everyone was "planned miles per tech-day". It was accurate. It measured the plan, and the plan was never the day. The optimizer reported its own objective, which it had genuinely minimized, and the shop read that as a measure of the operation.

Two numbers would have caught it in the first week. Actual miles per tech-day from the vehicles, which went the wrong way from day one. And the count of windowed jobs planned outside their window, which nobody was tracking because under manual dispatch a human never did that.

The fix and the confirmation

The changes were small and specific, and each one targeted a confirmed cause:

1. Arrival windows moved from notes into the time-window constraint field for every open job, and the booking screen was changed so new windows are entered there. The optimizer now cannot plan outside them.
2. Qualifications added as required skills on the ductless startup job type, plus two others the dispatcher named on review (gas line work and a commercial rooftop type).
3. The two light templates corrected, which was not the cause of the change but was found along the way.
4. A daily one-line check added for the dispatcher: any windowed job planned outside its window, and any job whose required skill does not match its tech. With the constraints in place both counts should be zero, and a nonzero count means a booking was entered the old way.

The shop ran two more weeks, again 60 tech-days:

Planned miles rose from 51 to 56 once the optimizer had to respect windows and skills, which is the honest price of the constraints. Those 56 planned miles running about 8 percent over come to about 60 actual, now with almost no unplanned legs. Against the manual baseline the shop ended up with fewer actual miles (about 60 against 67), more jobs per tech-day (5.6 against 5.4), and less overtime (7 hours against 9). The optimizer had been worth having all along; it had been solving the wrong problem.

What the shop would do differently

Start a new optimizer the way you would onboard a new dispatcher: run it in parallel for a week with a human making the actual calls, compare the two plans job by job, and write down every place the tool's plan breaks a promise. Each one is either a missing constraint or a reason to override. And measure the day, not the plan, from the first morning. A tool that grades its own homework will always report that the homework was good. Changes to how the optimizer is configured should then go through the shop's change control so the next settings update does not silently undo the fix. See related: The Automation Change Control SOP.

References

• See related: What a Scheduling Optimizer Ignores
• See related: Measuring Whether an AI Tool Actually Saved Time
• See related: The Automation Change Control SOP
• See related: Mapping a Process Before You Automate It