Where automation fails

Failure one: the process was never written down

An automation is a specification made executable. Where no specification exists, the build captures whatever the last person happened to do — including the shortcuts, the undocumented exception for one large customer, and the step that exists only because a system used three years ago required it.

The symptom appears after launch, as a steady stream of cases the automation "handles wrong". Usually it is handling them exactly as described; the description was incomplete.

Failure two: the systems disagree about what a record means

Where a process crosses two systems, the automation inherits every inconsistency between them. If "customer" means a billing account in one place and a contact in another, no amount of connection logic resolves it — someone has to decide which is authoritative and what happens to records that exist in only one of them.

Failure three: nobody owns it after launch

Automated processes are not finished objects. APIs change, plans change, and business rules change more often than either. Where no one owns the automation, the first breakage is discovered by a customer and the second is discovered in a quarterly report.

Ownership is a small commitment made explicit: who is notified when it fails, who is permitted to change the rules, and when it gets reviewed.

Failure four: the wrong work was chosen

Some work should stay manual. Anything with meaningful legal, financial or safety consequence, anything that depends on a relationship, and anything that changes so frequently that the rules never stabilise. Automating these produces a system that is either constantly wrong or constantly being rebuilt.

Failure five: speed applied to a broken step

Automation amplifies whatever the process already does. Where the underlying step is wrong — a routing rule sending enquiries to the wrong team, a follow-up sequence addressed to people who already bought — automating it produces more of the same error, faster and more consistently.

This is worth stating plainly because it is often described as an automation problem after the fact, when it was a process problem the whole time.

How to avoid most of this

Document the process before building it. Reconcile the record definitions between systems before connecting them. Name an owner before launch. Choose repeatable work first and leave judgment where it is. None of this requires new technology, and skipping it is the most reliable way to produce an automation that has to be undone.

If you want a structured view of where your own growth systems are losing work, the Growth Intelligence Assessment walks through it question by question.