Most writing about automation assumes the answer is yes and only debates the how. This is the other article, because the projects that go badly nearly always went badly at the decision to start rather than during the build.
Six situations where the right answer is to leave it alone.
1. The process is about to change
Automation locks a process in. That is the point of it and it is also the risk.
If you are changing accounting system next year, restructuring the team, moving premises or renegotiating with the supplier at the heart of the process, wait. An automation built around arrangements that are about to change is money spent twice.
Ask directly: will this process look the same in eighteen months? If the honest answer is no, the automation should wait for the change rather than precede it.
2. It requires judgement rather than rules
The test is whether you can write the process as unambiguous if-this-then-that steps. If describing it involves it depends, you get a feel for it or we usually but not always, the process contains judgement.
Judgement does not automate. What you get instead is a set of rules that approximates it, applied confidently to every case including the ones where the exception mattered.
What to do instead: automate around the judgement. Gather the information the decision needs, present it in one place, capture the decision and act on it automatically once made. That is often eighty per cent of the time saving with none of the risk.
3. It happens rarely
A monthly task taking an hour saves twelve hours a year. Against a build cost of a day or two plus ongoing maintenance, that does not work, and the arithmetic gets worse when you include the fact that nobody will remember how it works by the time it breaks.
Frequency matters more than duration, because the saving compounds, and the maintenance does not.
What to do instead: write a good checklist. Genuinely. A well-written one-page procedure for a monthly task is worth more than an automation nobody trusts, and it costs an hour.
4. The human contact is the point
Some interactions are the relationship rather than an administrative step within it. A conversation with a customer who has a problem. A call to a supplier you have worked with for a decade. Checking in with somebody who has gone quiet.
Automating these produces the specific hollowness everyone recognises — the personalised message that is obviously not personal, the follow-up that arrives on schedule whatever the circumstances.
What to do instead: automate the prompt and leave the contact human. A reminder that a customer has not been spoken to in ninety days is useful. An automated message pretending to be that conversation is worse than nothing.
Automate the reminder to call. Never automate the call.
5. The underlying data is unreliable
Automation makes bad data arrive faster and look more official.
If the job system is only updated when somebody remembers, if the customer records have four versions of the same company, if the stock figures are approximately right, then automating anything downstream of that spreads the unreliability into places where it was previously contained.
What to do instead: fix the source. That usually means connecting systems so records maintain themselves rather than asking people to be more diligent, which has never worked anywhere.
6. Nobody will be able to maintain it
An automation is a small piece of software. It has dependencies, those dependencies change and something will break within two years.
If it is built by one enthusiastic person with no documentation, in a tool nobody else uses, owned by their personal account, then what you have built is a liability with a delayed fuse.
What to do instead: either build it properly — documented, owned by a service account, second owner named, failure alerting configured — or do not build it. The middle option is the expensive one, and it is what most failed automations actually were.
The question worth asking first
Before can we automate this, ask should this process exist at all.
A surprising number of candidate processes are the residue of something that ended. A report for a customer who left. An approval step introduced after an incident in 2019. A reconciliation between two systems, one of which is no longer used for anything.
Deleting a process is faster, cheaper and more reliable than automating it. It is also the outcome nobody proposes, because proposing to automate something sounds like progress and proposing to stop it sounds like giving up.
Our IT consultancy team spends a good part of its time telling businesses which of their candidate processes are not worth automating. If you would like that opinion before you spend anything, get in touch.
