How to Automate Your Way to Exactly the Same Problems, But Faster

Many businesses rush into automation and end up with faster chaos instead of actual improvement. The bot works perfectly. The process it's running was broken to begin with. Congratulations, you've industrialised the problem. I've seen this happen more times than I'd like to admit, organisations that spent six figures on automation and came out the other side with the same dysfunction, just at higher velocity.

The instinct is understandable. Automation feels like progress. It looks decisive. It gives leadership something to point at in the quarterly update. But the technology is rarely the hard part. The hard part is everything that should have happened before anyone opened a vendor proposal.

Before you touch automation (AI or otherwise), eleven things need to be accounted for, roughly in this order.

Is the process properly documented?

Not a dusty flowchart nobody's looked at since 2019, living SOPs that a new person could actually follow on day one. If the process only exists in someone's head, you're not automating anything. You're bottling tribal knowledge and hoping nothing goes wrong when that person leaves, gets promoted, or decides they've had enough and hands in their notice on a Tuesday. That knowledge walks out the door with them, and the automation you built around it starts behaving in ways nobody can explain.

Has it been optimised first?

The sequence matters more than most people realise:

1. Institutionalise

2. Optimise

3. Automate.

In that order. Always. Strip the waste and unnecessary steps out before you speed anything up. Automating a broken process doesn't fix it, it just means the broken parts arrive faster, at scale, with less opportunity to catch them before they cause damage.

Is it genuinely repeatable with low exceptions?

Automation and AI hate surprises. They're brilliant at the predictable and genuinely terrible at the ambiguous. If 30-40% of cases need special handling, the bot will spend most of its operational life asking for human help, which rather defeats the purpose. Get exceptions under 10-15% before you start, and be honest about that number. Optimistic exception rates are one of the most common ways automation projects quietly fail.

What are the real volumes and frequency?

This is where rigour matters and where people often fudge the numbers to justify a decision already made. If the task happens a handful of times a week, the build, testing, and ongoing maintenance cost will almost certainly never pay off. Run the actual numbers. Not the numbers that make the business case look good, the numbers that are true.

How clean is your data?

Automation amplifies whatever's already there. It doesn't sort it out, it doesn't smooth over inconsistencies, it doesn't quietly compensate for the fact that half your customer records have the address in the wrong field. Duplicates, missing values, vague free-text notes columns and inconsistent formatting will come back to haunt you at scale, and they always do, usually at the worst possible moment, guaranteed.

Have the people who actually do the work been involved?

Not consulted in a single workshop that nobody took seriously, genuinely involved, early, with their input actually shaping the design. When people feel heard rather than threatened, adoption goes far more smoothly. The sabotage risk drops considerably too, which is a thing that happens more than anyone in leadership tends to admit. People are creative when they're defending their territory.

Is compliance and auditability covered?

Every automated decision needs to be traceable and defensible, not just now, but years from now when the regulator asks a question or something goes wrong and everyone wants to know exactly what the system did and why. In regulated environments this is non-negotiable. In unregulated environments it's still just good practice.

Who owns the exceptions?

Automation doesn't remove judgement from the system. It just shifts where that judgement lives. Someone needs to be clearly accountable for the cases the system can't handle, with the capacity, the authority, and the understanding to actually deal with them. Without that, exceptions quietly pile up in a folder nobody checks, and one day someone discovers a backlog that's been accumulating for eight months.

Have you calculated the true cost, including the cost of doing nothing?

Licences, development time, testing, change management, training, ongoing support, and the very real possibility that the tool sits underused in twelve months because adoption was never properly managed. All of it counts. The cost of doing nothing counts too (lost time, human error, process drag) but that calculation needs to be honest rather than inflated to justify a foregone conclusion.

What happens to the people once the task is automated?

This is the question most organisations skip until it's uncomfortable to answer. Will you retrain and redeploy into higher-value work, or quietly reduce headcount at the next opportunity? There's no universally right answer, but there is a right time to ask the question, and that time is before you start, not after you've committed. The answer shapes the culture you're building, whether you're intentional about it or not. People watch what happens to their colleagues. They draw conclusions.

Have you walked the entire process end-to-end with genuinely fresh eyes?

Not a process owner explaining how it's supposed to work, someone actually doing it, or watching someone do it, in real conditions. Video it. Time it. Count every click, every workaround, every moment where the person doing the task has quietly invented a fix for something that was never properly solved. You will find friction that no diagram, no documentation, and no steering committee has ever surfaced. You always do.

None of this is about slowing down. It's about not having to reverse at speed six months from now because the foundation wasn't right.

Automation done right compounds. The efficiency gains build on each other. The organisation gets genuinely better at what it does, not just faster at doing it. Done wrong, it makes yesterday's problems arrive faster, with less visibility, and considerably more confidence.

Architects don't rush foundations.