The Hidden Cost of Automation Is the Work Nobody Wrote Down

The work you cannot see is the work that overruns the budget

Every automation project I have been asked to rescue overran for the same reason: the process that got costed was the process on paper, and the process that got automated was the one people actually run. The gap between those two is not a rounding error. In the processes I have measured, the undocumented half was the larger half, and it appears in no estimate because nothing in the organisation produces a record of it.

The most recent measurement was a supplier-onboarding process at a 900-person manufacturer. The documented flow was six steps and, by the process owner's own count, roughly 20 minutes of human touch per supplier. Following forty consecutive supplier records and timing every touch produced a median of 71 minutes. The missing 51 minutes sat in eleven places: a credit check chased by phone, two spreadsheets maintained outside the ERP, an insurance-certificate email thread, and a re-key step caused by a field the intake form did not collect.

The undocumented work — the exceptions, the phone call, the spreadsheet nobody admits to — is usually more than half of a process, and it stays invisible until you try to automate it.

That is the whole argument in one sentence. Automation does not remove that work; it is the first instrument that makes it visible, because a machine can only execute what someone has written down, and someone can only write down what they know is there.

What does "undocumented" actually consist of?

Four categories, and they fail the business case in different ways.

All four are work. All four consume hours from people you already pay. None of them generate a timestamp, a case record or a report, which means none of them appear in the sources a business case is normally built from — the ERP extract, the ticket system, the time-and-motion study done three years ago.

Why do the estimates keep missing it?

Three mechanisms, and they compound.

The first is that process maps have an audience. A map is produced for an auditor, a new joiner or an ISO folder, and all three audiences need the intended path. Exception handling is filed off because it is unowned and mildly embarrassing. If your estimate came from a diagram or a standard operating procedure, you costed design intent, not behaviour.

The second is interview bias, and it is not dishonesty. Asked to describe their work, people describe the official version. I once had an analyst tell me her job was "processing purchase orders" while, in front of me, she performed a bank reconciliation that appeared in no job description and no salary band. The workaround had become so routine that it was no longer a fact worth mentioning.

The third is who does the estimating. The manager who owns the budget is usually the person with the least visibility of the exception path, because exceptions travel upward as complaints and escalations rather than as case counts. Nobody files a report saying "I spent forty minutes on the phone again."

Is the phone call the real specification?

Often, yes. In that onboarding process, nine of forty records detoured to the same named analyst, and the detour was a short call. Everyone in the room knew it. Nobody had written it down, so no document existed to hand to a build.

This matters for two reasons beyond the schedule. A process whose critical branch runs through one person is fragile in a way that has nothing to do with AI: that person's holiday is a process outage. And when you automate, the call has to become an explicit rule — what happens when the credit check returns "refer"? If you can extract the rule from the person who makes it, you can automate most of the branch and leave a small, honest manual queue for the rest. If nobody can articulate the rule, you will get a model that produces plausible answers, which is worse than a queue, because a queue is visibly long and a wrong answer is not.

What does the arithmetic do to a business case?

Take the onboarding example and price it with the client's own finance figures rather than a market average I would be inventing. Their loaded rate for an operations analyst was roughly ¥150 an hour including benefits and overhead.

Both the 27% exception rate and the 72% share of undocumented hours come from the same forty records, which is enough to see a distribution and not enough to size a once-a-quarter event; I would not defend the decimal, only the direction. The integration count is the part finance usually finds harder, because it changes the shape of the purchase rather than the size of it. A one-integration build is a project. A three-integration build with a human override path is a small system, and small systems need an owner after go-live.

There is a second tradeoff worth naming, because it cuts the other way. Automation can create hidden work rather than remove it. I have watched a chat-based intake form raise request volume by roughly a third while lowering average request quality, because it became easier to ask. The hours saved at intake reappeared downstream as triage, handled by the same two people, and the net effect in the first quarter was close to zero. If you automate the front of a process, measure the back of it too.

What should you do before signing anything?

Five things, in order, none of which require a licence.

• Choose one unit of work that can be counted — one supplier, one claim, one order — and follow forty consecutive instances rather than surveying the team.
• Record touch minutes and waiting hours separately. Waiting is where the calendar time goes; touch is where the labour goes, and they are different budgets. Recording forty consecutive cases in a four-column waiting-time log instead of buying a process-mining licence takes one person two weeks and costs nothing beyond their time.
• Put two lines in the business case: automating the happy path, and handling the exception path. Fund the first deliberately and size the second honestly, even if the second line is a manual queue.
• Name the people the exceptions currently route to, and pay them for an hour a week as specification authors. A build that never talks to them will guess, and it will guess wrong in the branch that matters most.
• Write down what happens to the 20% to 30% you decide not to automate. A named manual owner is a design decision. An unowned fallback becomes an outage nobody is watching.

If a vendor or an internal team resists the first two, that is information about the estimate, not about your process.

The measurement is cheaper than the overrun

The hidden work does not wait politely while you decide whether to automate; it keeps being done by people, at a cost that never appears as a line item and never appears in a headcount request either. That is precisely why it overruns projects: it is real labour that the organisation has agreed not to see. The honest sequence is to measure the exception path first, price it as its own line, and only then decide whether the happy-path build is worth the integration bill behind it. In my measurements the exception path has always been the larger half, which means the first project is frequently not automation at all but reducing the exceptions that create the work. Either way, the number to bring into a budget conversation is total touch time, not documented touch time.