The arithmetic of automation, seen up close in field service

We spent six weeks inside an industrial maintenance contractor before we proposed anything. The brief said the problem was reporting. It wasn't reporting. Two days of watching schedulers work through some 12,000 work orders a month made that obvious, and dashboards had nothing to do with it.

Whether something's worth automating is a sum, and the sum is usually not close once you do it honestly. The mistake is doing it on the happy path and ignoring the ongoing cost of the exceptions.

THE TERMS PEOPLE LEAVE OUT

The build cost gets estimated. What gets missed is the exception handling, which is most of the code, and the ongoing maintenance as the surrounding systems change underneath you. An integration is not a one-off cost, it's a subscription.

The other omission is the cost of automation being wrong at volume. A person processing a hundred items makes a handful of individual errors. A rule processing a hundred thousand makes the same error a hundred thousand times, and the cleanup is a project.

PARTIAL AUTOMATION IS USUALLY THE ANSWER

Handling the eighty percent that's unambiguous and routing the rest to a person is often several times better value than chasing full coverage. The last twenty percent contains all the ambiguity, so it's most of the work and most of the risk.

It's a harder thing to sell, because "we automated eighty percent" sounds like a partial success. It's usually the whole win, and the remaining twenty percent is where people should be spending their attention anyway.

The clearest thing we saw was how schedulers handled a contested work order. On paper it's one step. In practice it's five, three of them over the phone, none of them written down. Which is why nobody could ever explain first-time fix rate to their director.

THE NUMBER THAT ACTUALLY MATTERS

Hours saved is the metric everyone reaches for and it's rarely the one that justifies the work. More often it's a reduction in variance: fewer things going wrong, fewer statutory deadlines missed, fewer disputes. That's the number to put in the business case.

Ask what happens today when it goes wrong, and how often. Frequency times consequence is usually a bigger number than the labour saving, and unlike the labour saving it's a number the client already believes.

Here it showed up as a queue nobody owned. Some 12,000 work orders a month went through it, and schedulers had learned to check it twice a day because the alternative was a technician drove three hours to a job someone had already closed. A better queue wasn't the answer. Making ownership a property of the work order was.

WHERE IT GOES WRONG

• Chasing the last twenty percent, which holds all the ambiguity and most of the risk.
• Justifying the work on hours saved, when the real return is fewer things going wrong.
• Costing the happy path, when exception handling is most of the code.
• Treating an integration as a one-off build rather than an ongoing subscription.

Do the sum with exceptions included. Then automate the eighty percent and route the rest.

WHAT WE TOOK AWAY

The work shipped and first-time fix rate moved, but the thing we're proudest of is smaller than the system: schedulers stopped keeping a private spreadsheet. That's usually the honest signal that the model finally matches the job.