Automation is usually pitched as 'doing the same thing, faster.' Which is true, in the same way a photocopier is 'better writing.' A photocopier doesn't improve your document. It reproduces it—faithfully, at scale, typo and all.

Automation does the same. It multiplies what you give it, good or bad. Bad automation doesn't fail. It succeeds at the wrong thing, consistently, and on schedule. So here are eight rules to stop your automation programme becoming a high-speed duplicator of nonsense.

Rule 1: Don’t automate tradition

Most processes were not designed. They were added to. Like barnacles.

Someone once had a bad day. So an approval appeared. Someone once made a mistake. So a form field became mandatory. Someone once got shouted at. So a "quick check" became a permanent checkpoint.

Soon you have a nine-step ritual to move $50 between accounts. Nobody knows why, but everyone swears it's required.

If you automate that, you don't improve the business. You preserve its odd customs in code. And code is where bad ideas often go to become immortal.

A quick test: if the best defence of a step is "we've always done it," you're not looking at a process. You're looking at a superstition.

Rule 2: Map reality, not mythology

Before you automate, find out what actually happens. Not what the SOP claims. Not what the manager hopes. What happens on a Tuesday at 4:47pm.

Map the whole thing:

• The happy path. Usually fiction.

• The exceptions. Usually the job.

• The waiting. Usually the cost.

• The handoffs. Where things vanish.

• The systems touched. The passwords used. The favours called in.

• The shadow steps. The private spreadsheets. The copied email templates.

Then ask the rude question: not "why do we do it this way?" but "why do we do it at all?"

If you can't explain a step without saying "compliance" in the tone of a priest, it's probably an artefact.

Also, watch for the secret driver: blame. Many steps exist to spread it around or move it up the hierarchy.

That's not process design. That's organisational insurance.

Rule 3: Measure the current state, or you are just rearranging furniture

People love 'improvement' that feels productive. New tools. New dashboards. New terminology. None of that proves anything. So take a baseline first and use measures that describe reality, not intention.

Throughput
How many completed items per day or week. Completed, not 'touched'. Count by type: standard vs exception, clean vs messy.

Cycle time
From request received to customer-visible done. Track median and 90th percentile. Averages lie politely. Split active time from waiting time. Waiting is usually the villain.

Touch time
Human minutes per item, across roles. Also count touches. Five two-minute interruptions is worse than one ten-minute block.

Error and rework
How often you fix what you already did. Track the loops: "Missing info → chase customer → resubmit → recheck." Rework is where productivity goes to die quietly.

WIP and queues
How much work is parked—in an inbox, in an approval step, in one person's head. Queues are invisible parking lots. They look calm. They're not.

Add one metric that stops everyone cheating:

First-pass yield
The percentage that completes without correction. It tells you if you improved quality, not just speed.

Once you can say, "Cycle time is 12 days but touch time is 9 minutes," you stop arguing about effort and start attacking waiting.

Rule 4: Optimise before you automate

Automation can do two things:

1. Make the same steps faster.

2. Remove steps so you do less work.

The second is the real prize. It's just less theatrical.

Nobody applauds "we deleted three approvals." They applaud "we launched a workflow with a dashboard." One saves money. The other photographs well.

Speeding up nonsense gives you nonsense at a grand scale. Faster emails. Faster copying and pasting. Faster mistakes.

So do the unglamorous work first:

• Delete steps that exist because of superstition or misguided tradition.

• Reduce approvals to where risk genuinely exists.

• Standardise inputs. Stop letting people write free-form novels into structured fields.

• Move decisions to the person with the information.

• Fix upstream data. Stop building downstream industries devoted to cleaning it.

To borrow Michael Hammer's blunt line: don't automate, obliterate.

If a step is unnecessary, the best automation is deletion. It never breaks. It never needs support. It never gets a licence renewal. It's perfect.

Rule 5: Plan, prototype, prove

Automation fails in three predictable ways:

• It cannot handle awkward cases.

• It cannot explain what it did.

• It works until a tiny assumption changes.

So act like an engineer. And like a sceptic.

Plan
Define “done”. Define boundaries. Define exceptions.
If you cannot describe the edge cases, they will become the main case.

Prototype
Use real data if you can. If you cannot, use a close counterfeit.
Prototype the user experience too. Defaults and form design often drive 80% of behaviour.

Prove
Compare outcomes to baseline. Not vibes to hope.
If the prototype cannot show logs, traceability, and decision points, it is not a prototype. It is a demo.

A demo is what you do when you want approval.
A prototype is what you do when you want truth.

Rule 6: Choose the right kind of automation, not the sexiest

There is a sensible hierarchy:

1. Delete the step.

2. Configure the system of record.

3. Integrate via APIs or events.

4. Use UI automation and RPA only when you must.

UI automation is a very fast intern. A diligent one. But easily startled.

It clicks what you told it to click.
Then someone moves a button. Renames a field. Adds a pop-up.
And your “robot workforce” sits there, politely failing at scale.

Use it when there is no better option. Do not pretend it is infrastructure.

Rule 7: Use AI where it is strong, and keep accountability human

AI is excellent at:

• classifying and routing

• extracting from messy inputs

• summarising and drafting

• spotting anomalies

• suggesting next steps

AI is risky at:

• final approvals

• compliance-critical decisions

• anything you cannot justify in plain English

Here is the governance rule that still holds, whether or not IBM said it first: computers cannot be held accountable. Humans can.

So let machines recommend.
Require humans to own the decision.

This also fits Toyota’s idea of building in quality. Automation should surface abnormalities. It should stop defects flowing downstream. It should not quietly manufacture errors all day because the model felt confident.

If your AI cannot explain itself at the level of “here is why this was routed to Team B,” keep it away from anything with regulatory consequences.

Rule 8: Automations do not “go live.” They move in.

Most organisations treat deployment like a graduation. Ribbon cut. Screenshot taken. Everyone moves on.

Then the automation decays.

Permissions change. Inputs drift. Someone edits a template. A vendor updates a UI.
Nothing explodes. It just quietly gets worse. Until it becomes customer-visible.

So operate automation like production software:

• Version control and change logs.

• Observability: logs you can use, traces you can follow.

• Alerts that matter: “the right outcome happened,” not “the bot ran.”

• Access discipline: least privilege, credential ownership, periodic reviews.

• Runbooks: what fails, how it fails, who gets paged, how to fail safely.

• Post-deploy reviews: what broke, what surprised you, what you would redesign.

If AI is involved, add extra locks:

• drift monitoring

• scheduled sampling and human review

• escalation rules for low confidence and high risk

An automation is not an appliance. It is closer to a new member of staff. Fast. Tireless. And perfectly capable of making the same mistake ten thousand times a day.

So yes, ship it.
Then act like it has moved into your house.

The punchline

Bad automation does not fail. It succeeds at the wrong thing. Then it makes the wrong thing hard to undo.

So the sequence matters:

Understand → Measure → Simplify → Design → Automate → Operate

Do that, and you do not merely automate a process. You remove nonsense. You reduce risk. You build something that survives change without requiring a priest, a spreadsheet, and a small sacrifice every Friday afternoon.

Book a process audit or discovery call

If you’re exploring AI in business process automation and want to avoid expensive experiments, start with a structured discovery.

A process audit will identify where workflow automation, RPA, and AI actually fit, quantify value (time, cycle time, errors, cost-to-serve), and define the controls needed for a safe rollout.

• Learn more: process audit

• Or reach out directly: Contact Us