← All posts
Playbooks

What makes a process worth automating, and what doesn't

The first automation sets the tone for everything after it. These are the four things we look for, and the tempting candidates we have learned to avoid.

Nuno Oliveira
Nuno Oliveira
Co-Founder
What makes a process worth automating, and what doesn't

The first automation matters more than the ones that come after it. It sets the expectations, it decides whether the rest of the team gets curious or defensive, and it is the one people will point at a year later when somebody asks whether any of this was worth doing.

So it is worth being fussy about which one you pick. Here is what we look for.

Four signs of a good candidate

It happens a lot. Volume is what turns a small saving into a number worth reporting. A task that takes twenty minutes and runs four times a day beats one that swallows a whole day but happens twice a year. The second feels more painful. The first pays back faster.

Somebody can explain the rules. They do not have to be written down anywhere, and they usually aren't. But if a person on the team can walk you through how they decide, step by step, that logic can be encoded. If the honest answer is "you get a feel for it after a few years", look elsewhere, or automate only the part that comes before the judgement.

The inputs are consistent enough. Invoices arrive in a hundred layouts but always carry a supplier, a date and an amount. That is consistent enough. A process where every case starts from scratch and needs its own investigation is not.

Mistakes are cheap. Your first automation should be somewhere an error costs a few minutes to fix, not a client or a filing deadline. Confidence comes from watching something run quietly for three months. Start where you can afford to learn.

The tempting ones that go wrong

The process everybody complains about is not automatically the right choice. Sometimes it is loud precisely because it is messy, or political, or because nobody agrees on how it should work. Fix it as a process first. Then automate it.

Be careful with anything that forces someone to define a rule they have been comfortably leaving vague. The technical work is the easy half of that project. It will stall in a meeting, not in the code.

And automating a badly designed process only makes the mess happen faster and more often. We have walked away from projects for this reason. It is a better conversation to have in week one than in month three.

Finally, some work is slow on purpose. A difficult call with a client takes an hour because the hour is the point.

How we actually pick

In the first conversations we are mostly listening for two things. What do people spend time on that they would rather not, and what falls apart when somebody is busy or on holiday. Those two questions surface most of the good candidates without anyone having to prepare anything in advance.

After that it is arithmetic. How often, how long, how many people. We take the one with the best ratio of impact to complexity, which is almost never the most impressive project on the list. We want something working reliably within a few weeks, because that makes the second project a much easier conversation.