They rarely fail technically

The build usually works.

What fails is everything around it — the description, the ownership, the review, the maintenance.

Which is good news, because those are all decidable before anything is built.

Eight patterns, in rough order of how much they cost.

1. Automating an undocumented process

The most common, and the most expensive.

Somebody describes the process. It gets built. Halfway through testing, three things emerge: an exception nobody mentioned, two people doing it differently, and a step nobody can explain.

Why it happens: the written procedure describes what should happen. The actual process includes exceptions people handle without noticing.

What to do instead: watch the work being done, several times, by more than one person. Ask what is annoying about it — that question surfaces the friction the procedure omits.

2. Automating a process nobody questioned

Making the wrong thing faster.

If a process has unnecessary steps, duplicated work, or produces a report nobody reads, automating it means doing something pointless more efficiently.

What to do instead: before building, ask of every step — why does this exist, who uses the output, what would break if we stopped?

Removing three of eight steps saves more than automating all eight, and costs nothing to maintain.

3. No owner

Every automation needs a named person who understands it, receives the alerts, and fixes or escalates.

Not a team. A person.

What happens without one: something changes, it breaks, and it stays broken. Or worse, it half-works and nobody notices.

The most common route to an abandoned automation is that whoever built it moved on and nobody inherited it.

What to do instead: name the owner before go-live, and transfer ownership explicitly when they leave.

4. Silent failure

A workflow that fails and tells nobody is worse than no workflow, because everyone assumes the work is being done.

The gap is discovered weeks later, and by then nobody can reconstruct what was missed.

And the worst version: a scheduled job that stopped running entirely. It produces no error at all — just silence, which looks exactly like everything working.

What to do instead: alerts to a named person on failure, and monitoring for the absence of a run.

5. Picking the tool first

Choosing RPA, or an AI platform, or a workflow tool, and then fitting the process to it.

Why it costs: you end up using an expensive, fragile tool for something a setting already did.

What to do instead: work down the list. Existing system settings, then a workflow tool, then a custom integration, then RPA, then AI. Stop at the first that works.

Most requests are satisfied at the first two.

6. No baseline

Nobody measured the manual process, so nobody can say whether the automation helped.

Consequence: marginal automations survive for years, and good ones never get repeated because the case was never made.

What to do instead: record time per run, frequency, error rate and delay — before you build. It takes an afternoon.

7. Removing the human too early

A review step gets skipped because the output has been good for three months.

Then one bad output goes to a customer, or into the ledger.

What to do instead: keep review permanent wherever money moves or a customer sees the output. And sample deliberately, because a system cannot reliably tell you when it is unsure.

8. Automating a disagreement

Two departments describe the process differently, and neither is wrong — they have genuinely different views of what should happen.

Asking software to keep both versions alive does not work. It produces an automation nobody trusts and both sides work around.

What to do instead: recognise that this is a decision, not a technical problem. Get it decided before building.

A useful signal: if the requirements keep changing during the build, the underlying disagreement was never settled.

The pattern underneath

Read back through and something is consistent.

Almost every failure is a decision that was not made — about the process, about ownership, about who reviews, about whether the step should exist.

None of them are about the technology.

Which means the highest-return work in an automation project happens in conversations before anything is built.

The checks worth making

Six questions. A “no” to any is a reason to pause.

Is the process documented, including exceptions?

Has every step been questioned?

Does an existing system setting already do it?

Who owns it after go-live?

How will we know if it fails?

Have we measured the baseline?

These take a conversation. The build takes considerably longer, and it is much harder to undo.

When to stop a project

Worth stating, because it rarely happens and often should.

Stop if the process cannot be agreed. That is a management problem.

Stop if nobody will own it. You are building a future liability.

Stop if the saving does not clear the maintenance cost. Marginal automations get abandoned anyway.

Stop if the process is about to change. Wait, and automate the new one.

Stopping is cheaper than finishing something that will not be used.

The short version

Automation projects fail in the decisions, not the build.

Watch the process, question every step, name an owner, and make failure visible — including the run that simply never started.

Work down the tool list and stop at the first that works. Most requests are satisfied by a setting.

And take a baseline. Without one you cannot say whether anything improved, which means you cannot make the case for doing it again.