Choosing what to automate

The hardest part of business automation is not the automation. It is the choice of what to automate.

Most teams carry a long list of candidates. Most of those candidates look good in a one-line description and turn out, on closer inspection, to be more expensive to automate than to leave alone. A smaller subset look unexciting on paper and compound into the biggest wins of the year. The challenge is telling them apart before you spend engineering time finding out the hard way.

The framework below has three dimensions: frequency, variability, and blast radius. None of them are clever on their own. The combination is what tells you whether to start.

Frequency: how often does this happen?

The most reliable predictor of whether automation pays off is how often the underlying work actually happens. A rough heuristic: something that happens many times a day is a strong candidate, since even small per-instance savings accumulate fast. A few times a week is usually worth automating, but watch the build cost. A few times a month should only be automated if it is also genuinely painful or error-prone. A few times a year is almost never worth it — write a good checklist and revisit if frequency changes.

Frequency is not just about saved time. Frequent tasks generate the data you need to improve the automation, and they create the feedback loops that build trust in the system.

Variability: how much does each instance differ?

The more two instances of a task look alike, the easier they are to automate well. Low variability means the same inputs, the same outputs, the same edge cases — classic automation territory where rules and pipelines do well. Medium variability means a predictable shape with judgement required on a minority of cases; this is where AI workflows often shine, especially with a human in the loop on the harder ones. High variability means every instance is different, requires context that lives in someone's head, and the right answer is genuinely contested. In that territory, you might automate the straightforward portion if you can, but the rest is better left to humans with good tools.

The mistake worth watching out for is automating the easy 70% in a way that makes the remaining 30% harder to handle. The people who used to own the whole task lose context and practice, and end up worse at the cases they still own.

Blast radius: what happens when it goes wrong?

Every automation will produce a wrong answer at some point. The question is what it costs when that happens.

A tiny blast radius — one user gets a slightly wrong email, something easy to fix that nobody notices outside the immediate team — means you can automate freely. A medium blast radius, such as a customer contacted incorrectly or an invoice with a wrong line, means automating carefully with monitoring and a clear rollback path. A large blast radius covers anything where money moves, contracts are signed, regulated reports are filed, or customers are billed — automate only with strong human review, evals, and audit trails, and treat it like a serious integration project. A catastrophic blast radius is anything that could damage trust, breach regulation, or cause material financial loss in a single bad run. That should use automation to assist a human, not replace one.

As blast radius grows, more of the budget should go into the parts of the system that catch mistakes rather than the parts that produce the work.

Putting the three together

When you plot candidates against all three dimensions, a few patterns emerge. High frequency, low variability, and low blast radius is where to start — these are the wins that pay for everything else and build the internal credibility for bigger projects. High frequency, medium variability, and medium blast radius is where most of the genuinely interesting AI workflow work lives. High frequency with high blast radius is worth the investment but not where to begin. Low frequency in almost any combination usually does not justify the engineering cost. High variability with low frequency is best left to humans — the automation cost will exceed any savings, and you risk losing institutional knowledge in the process.

This is not a scoring rubric. It is a way to make the trade-offs visible before you commit engineering time. Most automation projects that fail were set up to fail at this stage, and could have been redirected with an honest afternoon conversation.

A short checklist before you start

Before committing to automating a workflow, five questions are worth answering honestly. How often does it happen, across a representative month? How variable are the inputs — pick three real recent examples and compare them. What is the worst credible outcome of one bad run? Who owns the workflow today, and who will own it after automation? And how will you know the automation is still working in six months?

If you cannot answer all five, you are not ready to automate. Getting to the answers typically takes a single afternoon and is among the highest-leverage things you can do for the project.

Where things go wrong

The most expensive automation failures tend to follow recognisable patterns. Pet-project automation is built around a workflow one engineer found interesting, that nobody else particularly needs. Vanity automation gets built to feature in a presentation rather than to take work off anyone's desk. Brittle big-bang automation replaces an entire process in one release with no way back. Orphaned automation works for a year, then quietly breaks because nobody is watching it.

The framework above is designed to catch the first three. The question about six-month monitoring is designed to catch the fourth.

If you are sorting through a list of candidates and not sure where to start, feel free to reach out at tim@quolo.io.