Not everything should be automated. Here is how I decide.

The default assumption in AI and automation work is that more automation is better. It is not. I have built enough things now to know that the most important skill is not knowing how to automate — it is knowing what to automate and what to leave alone.

Here is how I actually think about it.

The first question is frequency

If something happens once a month it is probably not worth automating. The time saved over a year does not justify the time spent building, maintaining, and debugging. If something happens fifty times a week the calculation changes completely.

I look for tasks that are repetitive by nature. Same input, same process, same output. Every time. If I can describe the task in a sentence that starts with “every time X happens, someone does Y” I have found a candidate.

The second question is judgment

How much human judgment does this task actually require?

Some tasks look repetitive but require real decision-making each time. A manager reviewing a performance issue. A support agent deciding whether a customer complaint needs escalation. A finance person assessing whether an unusual transaction is legitimate. These are not good candidates for full automation. The variation is the point.

The best candidates are tasks where the decision is always the same. If the answer is always yes when condition A is true and always no when condition B is true, that is automatable. If the answer depends on context that is hard to capture in a rule, it is not.

The third question is the cost of being wrong

This is the one most people skip.

If the automation produces a wrong output, what happens? Is it a minor inconvenience that a human catches immediately? Or does it send the wrong document to the wrong person, trigger a payment, or create a compliance issue?

The higher the cost of a wrong output the more human oversight you need in the loop. I never remove the human check before I have enough evidence that the system is reliable. For the payroll processor I built at Clovr Labs, the matching logic had to be exact — sending the wrong payslip to the wrong person is not a recoverable mistake. I tested it extensively before running it live.

The fourth question is maintenance

Who maintains this when I am not around?

An automation built on three API integrations, a custom script, and a Zapier flow is powerful but fragile. If any one of those dependencies changes, the whole thing breaks. If the only person who understands how it works is me, that is a problem.

I try to build things that are as simple as possible while still solving the problem. The most elegant solution is not the most technically impressive one — it is the one that keeps working when things change and that someone else can understand and fix.

The fifth question is adoption

Will people actually use this?

I have built things that worked perfectly and nobody used because they required too much behaviour change. The best automation fits into how people already work. It removes a step they hated rather than adding a new step they have to remember.

If the new way is more complicated than the old way, it will not be adopted regardless of how clever the underlying architecture is.

The decision in practice

When someone comes to me with a potential automation I run through these questions quickly:

Does it happen often enough to be worth building? Does it require real judgment each time or is it always the same decision? What happens if it goes wrong? Can someone else maintain it? Will people actually use it?

If the answers are yes, no, not much, yes, and yes — I build it. If any of those answers go the other way I either redesign the approach or leave it manual.

The goal is not to automate everything. The goal is to remove the friction that does not need to exist so people can focus on the work that does.