Automation will not fix a broken process

Faster is not the same as better

Automation is very good at doing the same thing over and over without getting bored. That is exactly what makes it dangerous applied to a process that is already wrong. It removes the one thing catching the errors, which was a person finding the work tedious enough to notice when something looked odd.

A manual process with a mistake in it produces a handful of bad outputs a week, and someone usually spots them. The automated version produces hundreds, and nobody is watching, because the entire point was that nobody had to.

Map it before you build it

Before deciding anything I write down what actually happens now, step by step, with a time against each step. Not what the process document says happens. What the person does on a Tuesday.

That map usually settles the question by itself. Often two of the eleven steps account for most of the time, and neither of them needs automation, they need a decision nobody has made. Sometimes the process turns out to exist because of a tool the team stopped using a year ago.

If you cannot write the rule down, it is not ready

The test I use is simple. Can the rule be stated clearly enough that two people applying it separately would reach the same result?

If qualifying a lead means "you know it when you see it", then automating it will encode whatever the last person happened to do, and you will not find out for months. That does not mean never. It means the rule has to be agreed first, which is a conversation rather than a build. A good share of the automation work I am asked for is really an unmade decision wearing a technical costume.

Three things worth automating first

Moving data between places, where the rule is obvious and the work is pure transport.

Anything on a schedule that a person currently has to remember, because remembering is the part that fails.

Assembly work: taking things that already exist and putting them into a shape somebody asked for. High volume, low judgement, and when it goes wrong you can see it.

When the answer is no

Sometimes the honest recommendation is that a process should be fixed or dropped rather than automated, and that is not a smaller piece of work. It is usually the more valuable one, because it removes the job instead of industrialising it.

I would rather say that at the start than build something impressive that makes a bad decision run on a schedule. If the underlying process is broken, automating it just means being wrong faster, in more places, with fewer people watching.