Most businesses do not have an automation problem. They have a prioritisation problem. There are always more tasks that could be automated than there is time, money or patience to automate, and the tasks that get picked are usually the ones that annoy whoever is loudest that week.
That is a bad selection method. The annoying task and the expensive task are frequently not the same task.
Here is a more reliable way to decide.
The four questions
Before writing a line of code or buying a tool, answer these about the specific process in front of you.
1. How often does it actually run?
Not how often it feels like it runs. Count it. A task that happens forty times a week is a different animal from one that happens twice a month, even if the twice-a-month one is far more irritating.
Multiply frequency by the time it takes. Twenty minutes, three times a day, is fifteen hours a month. Two hours, once a month, is two hours a month. The second one feels worse and costs less.
2. Is the process stable?
Automating a process means writing down its rules. If the rules change every quarter — because a client keeps changing their requirements, or because you are still figuring out how the work should be done — you will spend more time maintaining the automation than you saved by building it.
A process that has run the same way for a year is a good candidate. A process that was invented last month is not.
3. What happens when it goes wrong?
Every automation eventually produces a wrong result. The question is what that costs. Automatically formatting a report incorrectly is embarrassing. Automatically emailing the wrong invoice to the wrong customer is expensive. Automatically deleting something is unrecoverable.
The higher the cost of failure, the more the process needs a person in it — which does not mean skip the automation, it means put a human approval step in the middle.
4. Is the decision inside it mechanical or judgemental?
Some steps are lookups: find the customer record, copy the address, put it in the template. Those automate cleanly.
Some steps are judgements: decide whether this complaint needs the owner's attention. Those can be assisted but rarely replaced. The useful move is to automate everything around the judgement so the person only has to make the judgement.
The clearest signals a process should be automated
- The same information is typed into two or more systems by a person.
- Someone has a recurring calendar reminder to go and check whether something happened.
- A task is described internally as "you just have to remember to..."
- A step exists only to move data from one place to another.
- The process is documented well enough that a new hire can follow the document without asking questions. That document is effectively the specification.
- Work waits overnight or over a weekend purely because a human has to press something.
The clearest signals a process should be left alone
- It runs less than once a month and takes under an hour.
- Nobody can explain the rules the same way twice.
- The process only exists because of a temporary situation — a one-off migration, a client's interim requirement, a system being replaced next year.
- The real problem is that the process should not exist at all. Automating an unnecessary approval step makes the unnecessary approval permanent.
That last one is worth sitting with. A surprising amount of internal work exists because of a decision nobody remembers making. Automation makes it cheaper to keep doing, which means it will never be questioned again. Before you automate a step, ask what would break if you simply deleted it.
A rough sizing rule
You do not need a spreadsheet model, but you do need a number. Estimate:
- Hours saved per month — frequency times duration, honestly measured.
- Hours to build — including the discovery conversations and the testing, not just the coding.
- Hours to maintain per year — every integration breaks when a vendor changes something.
If the build cost is recovered in under six months of saved time, it is usually a straightforward yes. Between six and eighteen months, it depends on whether the process is stable and whether the time saved is time that gets reused for something valuable. Over eighteen months, you need a reason beyond time savings — accuracy, speed to the customer, or the ability to take on more work without hiring.
Two examples
A distributor's order confirmations. Orders arrive by email, someone re-keys them into the ERP, then sends a confirmation. Forty a day, three minutes each. High frequency, stable format, mechanical steps, low cost of error because the confirmation is reviewable before it sends. This is close to an ideal candidate — and the right build keeps a person confirming the parsed order rather than removing them entirely.
A design agency's proposal writing. Every proposal is different, pricing is judgement, scope is negotiated. The instinct is "automate proposals." The better move is to automate the parts around it: pulling the client's details in, assembling the standard sections, tracking whether the proposal was opened. The writing stays human because the writing is the product.
The decision test
- Counted the real frequency and duration, rather than estimating from memory
- The process has been stable for at least six months
- The rules can be written down without a long list of exceptions
- The cost of a wrong result is understood, and there is a review step if it is high
- The judgement calls have been separated from the mechanical steps
- Someone has asked whether the process should exist at all
- The time saved has somewhere useful to go
Where to start
Pick the process that scores highest on frequency and lowest on cost-of-failure, not the one that irritates you most. It will feel underwhelming. That is usually a sign you picked correctly.
The goal is not a fully automated business. It is a business where people spend their time on the parts that need a person.