Why automation projects fail (it's not the AI)

Why do automation projects fail? Almost never because the model wasn’t good enough. In the failed projects we get called in to look at, the software worked — it just automated the wrong thing. Someone pointed an AI at a process that was already broken, and a broken process, automated, doesn’t become intelligent. It becomes broken at higher speed.

This came up on Hacker News recently around Frederick Van Brabant’s post “I don’t think AI will make your processes go faster”, and the discussion landed exactly where our scoping calls land: the slow step is rarely the task everyone points at. It’s the fuzzy handoff two steps before it.

The bottleneck is almost never the task you can see

The task people ask us to automate is the visible one: typing invoice data into the accounting system, tagging tickets, copying orders between tools. It’s visible because it’s repetitive, and repetitive feels slow.

But time the whole process end to end and the picture usually changes. The invoice sits in a shared inbox for two days before anyone touches it. The ticket bounces between two teams because nobody agreed who owns billing questions. The typing itself takes ninety seconds.

Automate the ninety seconds and you’ve built something real that changes nothing. The invoice still sits for two days — now in a queue instead of an inbox. Van Brabant’s version of this, for software teams: AI made the coding fast, so all the time moved upstream into scoping and requirements. The work didn’t shrink; it relocated.

A broken process, automated, fails faster

The second failure pattern is worse than the first. The first wastes a build; the second amplifies a problem.

When a process has an unresolved ambiguity in it — two teams that categorise expenses differently, a “rule” that three people apply three ways — humans quietly absorb it. They ask a colleague, make a judgment call, fix it later. The process looks fine because people are patching it in real time, hundreds of times a month.

Automation removes the patching and keeps the ambiguity. Now the inconsistency gets applied instantly, confidently, at volume — and nobody’s judgment call is catching it. We’ve seen an automated categoriser faithfully reproduce a disagreement between two departments for six weeks before anyone noticed, because each department assumed the system agreed with them.

The fix isn’t a better model. It’s a decision: pick one rule, write it down, then automate the written rule. That decision costs a meeting. Skipping it costs a rebuild.

The three reasons automation projects actually fail

Across the projects we’ve scoped, built, or been asked to rescue, failures trace back to one of three things — and none of them is model quality:

1. The wrong bottleneck. The automated step wasn’t the slow step. Throughput doesn’t change, sponsors lose faith, the tool gets abandoned. This is the most common one.
2. Rules nobody agreed on. The process ran on informal human judgment, and automating it froze one version of that judgment — usually the version belonging to whoever sat in the scoping meeting.
3. No owner after launch. The process changed three months later, nobody told the software, and the error rate climbed quietly until someone stopped trusting the output. Software needs a named person who cares that it keeps working.

Notice that all three are process findings, not engineering findings. That’s why they’re cheap to catch before the build and expensive to discover after it.

How to find the real bottleneck before you build

You don’t need consultants or a process-mining suite. You need a week of honest timestamps:

• Follow five real items end to end — five actual invoices, tickets, or orders, not the idealised flow from the onboarding doc. Note when each one arrives, when each person touches it, and when it’s done.
• Separate touch time from wait time. Almost always, touch time is minutes and wait time is days. The wait is the bottleneck, and waits are caused by handoffs, unclear ownership, and missing information — not by slow typing.
• Ask the person who does the task where it hurts. They know. The gap between what the manager thinks the process is and what the operator actually does is where failed automation projects are born.
• Write the rules down and read them back. If two people who do the job disagree with the write-up, you’ve found the ambiguity that would have sunk the build.

Often this exercise ends with a boring conclusion: move a handoff, name an owner, agree on one rule — and only then automate the repetitive core, which is now well-defined enough to automate reliably.

What this means for scoping

This is why our AI automation engagements start with the process, not the model — Havoric is an AI automation and web development agency, and the first thing we do on any automation project is walk the process end to end with the people who run it. Half the time the honest answer after that walk is “not yet”, and we say so. The five-question checklist we run on every scoping call exists precisely to catch these three failure modes before anyone writes code.

Automation works. We build it for a living. But it works when it’s pointed at a well-understood process with agreed rules and a named owner — and it fails, predictably and expensively, when it’s used as a substitute for understanding the process in the first place.

Fix the process. Then automate it. In that order, the projects don’t fail.