Why most automation automates the wrong thing
The visible bottleneck is rarely the expensive one. On where the time actually goes, and why the obvious candidate is usually a symptom.
Ask a team what to automate and they will tell you what annoys them. That is a genuinely useful signal and it is not the same signal as cost. Annoyance tracks how unpleasant a task is and how often you have to think about it. Cost tracks frequency multiplied by duration multiplied by the price of the person doing it, plus what it costs when it goes wrong. Those two rankings overlap far less than anyone expects.
The three places the money actually is
Across the engagements we have run and the process maps we have drawn, the expensive work is almost always in one of three places, and none of them is the thing the team nominated.
- Waiting. Work sitting in a queue between two hops, invisible because no system owns it while it waits. Queue time routinely exceeds handling time by an order of magnitude and is almost never instrumented.
- Re-entry. The same fact typed into a second system by a person, because the two were never connected. Cheap per occurrence, enormous per year, and a reliable source of errors that surface months later.
- Rework. Everything downstream of a decision made without the right information. This is the biggest of the three and the hardest to see, because it does not look like rework. It looks like normal work.
The task people ask you to automate is usually the last visible step of a problem that started three hops earlier.
Why the obvious candidate is a symptom
Take a common one: a team spends hours a week writing follow-up messages, so somebody proposes automating the writing. Drafting is the visible task, so drafting is what gets nominated. But drafting is not slow because writing is slow. It is slow because the person writing has to reconstruct the context first, and they have to reconstruct it because it was never captured when the enquiry arrived.
Automate the drafting and you get faster production of messages that still require the same reconstruction, so the saving is a fraction of the projection and everybody quietly concludes that the technology underdelivered. Capture the context at the point of entry and the drafting problem largely dissolves, along with three other problems nobody had connected to it.
This is what the aggregate research keeps describing from the other end. Where businesses report gains, the gains are consistently real and consistently modest, which is the signature of automating the last step rather than the process.
Half report a saving. Most of that half report a small one. A saving under ten per cent is what you get when you speed up a step; it is not what you get when you remove the reason the step existed.
Breadth is not depth
There is a second version of the same error, visible at national scale. Businesses adopt several tools, each touching one task, and none of them touching the process the tasks belong to.
Under two technologies per adopting business, two years into the fastest technology adoption cycle in living memory. That is not a picture of businesses rebuilding how they work. It is a picture of businesses adding a tool, finding it helps a bit, and stopping.
The question worth asking instead
Not what takes the longest. Not what people hate. Ask what a piece of work costs from the moment it enters the business to the moment it is finished, then ask where in that path the cost is concentrated. The answer is frequently a fifteen-second decision that determines two weeks of downstream handling, and fixing a fifteen-second decision is cheap.
It is also the least satisfying answer to present, because nobody was complaining about that step. The teams who get real results are the ones willing to act on a diagnosis that does not match the symptom they came in with.