Every business has a list of processes that feel like they should be automated. Most of that list is wrong — not because the processes are fine, but because the obvious candidates are often the worst ones to start with.

Here is a way to sort the list that holds up in practice.

Automate stable, frequent, and boring

The three conditions that make automation pay are stability, frequency, and low judgment. A process that runs the same way every time, runs often, and requires no interpretation is a good candidate. Data moving between two systems. A confirmation that fires after a form is submitted. A weekly report assembled from the same three sources.

A process that changes shape depending on the customer, the season, or who is asking is a bad candidate — not permanently, but until it has been standardised. Automating an unstable process locks in whichever version happened to exist on the day it was built.

Standardise before you automate

This is the step most projects skip, and the reason many automations quietly get switched off within months. If three people do a task three different ways, the automation encodes one of those ways and makes the other two wrong.

Automation is not a substitute for a decision about how the work should be done. It is what you do after making that decision.

Standardising is cheaper than automating, and sometimes captures most of the benefit on its own. It is not unusual to write down a process, discover two of its seven steps exist only out of habit, and recover the time without building anything.

Where AI tools fit, and where they do not

Language models are good at drafting, summarising, classifying, and extracting structure from messy text. They are unreliable where accuracy is non-negotiable and unverifiable — financial figures, legal commitments, anything sent to a customer without review.

The distinction that matters is not what the tool can produce but whether a human sees the output before it has consequences. Drafting a reply for review is a good use. Sending it unread is a decision to accept occasional errors in your customer communication, and should be made deliberately rather than by default.

The maintenance nobody budgets for

Automations break. A platform changes an API, a field gets renamed, a form adds a question, and something silently stops firing. Unmonitored automation is worse than manual work, because the failure is invisible until a customer points it out.

Anything you automate needs an owner, a check, and a fallback. That is an ongoing cost, and it is the main reason automation projects benefit from a dedicated resource rather than a one-off build.

Start with the audit

A useful first engagement is not a build. It is a written map: which processes exist, how often they run, how long they take, how much judgment they involve, and which systems they touch. That document usually reorders the priority list immediately, because the processes that feel most annoying are frequently not the ones consuming the most time.

• High frequency, low judgment, stable — automate first.
• High frequency, high judgment — standardise and support with tooling, do not remove the human.
• Low frequency, high complexity — leave alone; the build cost exceeds the return.
• Unstable — fix the process before touching automation.

A realistic expectation

Automation rarely removes a role. It removes the parts of several roles that nobody wanted, which shows up as capacity rather than headcount reduction. That is a real return, but it needs to be framed correctly — teams told automation will replace work brace for it; teams told it will remove the tedious parts help build it.