When not to automate a process, and how to tell in advance

August 3, 20266 min read

Everyone selling automation has an interest in you automating something. That makes advice on the subject unreliable in a specific direction, and it leaves a gap where the honest answer belongs: quite often the correct move is to change nothing, or to fix the process by hand and leave the software out of it.

Below are five tests. Each one takes minutes, none of them costs anything, and between them they catch most of the projects that would have been written off later.

How often do automation projects actually fail?

Often enough that "will this work" deserves a real answer rather than reassurance. Ernst & Young has put the failure rate for robotic process automation projects at 30 to 50 percent. Research into causes traces roughly 40 percent of failures to poor process selection - the wrong thing was chosen before anyone wrote a line of code.

That second number is the useful one. It says the common failure is not bad engineering. It is a process that was never a good candidate, automated faithfully and expensively.

McKinsey's work on failed AI projects points the same way: the usual culprit is not the model or the compute, it is preventable organisational problems, with poor data quality at the top of the list. Bad inputs produce bad outputs faster than before, which is not the improvement anyone paid for.

Test one: is the process broken?

If the process is a mess today, automating it produces a fast mess. The software does exactly what it is told, at machine speed, without the quiet human corrections that were holding the old version together.

Those corrections are usually invisible until they stop. Somebody notices the address looks wrong and fixes it before the parcel ships. Somebody remembers that this particular client wants the invoice on the first of the month. Nobody writes that down, and nobody mentions it during the project, because it does not feel like part of the process. It feels like just doing your job.

Fix the process on paper first. Run the fixed version by hand for a fortnight. If it still works, it is a candidate. This costs two weeks and saves the entire budget when the answer is no.

Test two: can you explain it in five minutes?

Take the process and describe it out loud to someone who has never done it, in five minutes, with no notes. If you cannot, it is not ready.

This is not a test of you. Most processes in a small business live in one person's head, and getting them onto paper is genuinely hard work. But it is work that has to happen either way: an automation project starts with exactly this description, and if it does not exist, you will be paying somebody a professional rate to sit with you and produce it.

There is a second reason the test matters. A process nobody can explain is usually several processes wearing a coat. Splitting it into the three real things it does often reveals that one of them is worth automating and two are not.

Test three: does it happen often enough?

Multiply how often the task happens by how long it takes. That is the whole test.

A task that eats forty minutes twice a month costs you sixteen hours a year. Automating it might cost a few thousand to build and a subscription to run. The arithmetic does not care that the task is annoying, and annoyance is what usually drives these decisions.

The mirror image is worth watching for too. A two-minute task done thirty times a day is an hour a day, which is a much better candidate than it feels like, because each individual instance is too small to notice. Frequency beats duration. If you want the arithmetic laid out properly, we did that in what automation costs a small business.

Test four: is the human part the point?

Some interactions are the product. A client who has just received bad news, a complaint that has been escalating for a week, a negotiation where the tone matters more than the content - these are not moments to insert a well-timed sequence.

The test: if the person on the other end found out this was automated, would they feel served or handled? A booking confirmation, nobody minds. A note of condolence, everybody minds. Most cases sit somewhere between, and the honest question is which side of the line yours falls on.

This gets missed because the automation usually works. The reply goes out on time and reads well. What it costs is not visible in any dashboard, because it shows up as a client who quietly stops calling.

Test five: who owns it when it breaks?

Automation fails silently. That is its defining operational property and the one nobody budgets for.

An employee who stops doing a task will mention it. A workflow that stops firing will not. Reminders quietly cease going out; a supplier renames a field in an export and the whole thing has been passing empty records for a month before anyone notices the numbers look thin.

Research into automation failures lists ownership of integrations as a recurring cause: nobody owns the connections between the automation and the systems it touches, so when a vendor changes an API, the thing breaks and there is no obvious person whose job it is to fix it. In a company of eight people that person is you, and the honest question is whether you want that.

If the answer is no, the correct decision is either to buy the upkeep along with the build, or not to automate this particular thing.

What to do with the processes that fail these tests

Not automating is a decision with options attached, rather than a dead end.

Simplify instead. Cutting two steps from a five-step process is often worth more than automating all five, and it costs nothing but an afternoon.

Delegate instead. Some tasks want a person with clear instructions, not software. The instructions are the same document the automation would have needed, so the work is not wasted if you automate later.

Automate the boring half. A process where the judgement part is the point can often still hand its clerical half to software: gathering the documents, chasing the missing ones, filing what comes back. The decision stays yours.

Wait. A process that is about to change is a bad candidate today and might be a good one in six months.

Why we bother telling you this

We sell automation, which makes this article commercially awkward, and there are two reasons to write it anyway.

The plain one: a project that should not have happened ends badly for everyone involved, and the supplier who talked you into it is who you remember.

The less obvious one: this is what the paid audit is actually for. It costs $299 and three business days, and a real part of its value is finding the things you should not automate - which is precisely what a free consultation cannot do, because the free consultation exists to sell you the build.

If you already know which process you want to fix and just want the honest answer on whether it is worth it, that is the audit.