Where to start with workflow automation.

The hard part of automating a business is not the technology. It is that once you decide to do it, everything starts to look like a candidate. Every form somebody retypes, every spreadsheet emailed around, every status update chased by hand. The list is long with no obvious top to it, so the decision gets deferred, or worse, made by whoever complains loudest that week.

What follows is a way of choosing, and it fails less often than picking whatever annoys you most.

What a good first candidate looks like

Four things make a process worth automating early, and they compound. A process with all four is a strong candidate, one with two is worth a look, and one with none should be left alone however irritating it is.

The first is frequency, which turns a small saving into a real one. It is also what makes it worth debugging when it misbehaves. Ten minutes saved on something you do forty times a week is worth building, where the same ten minutes on something quarterly is a hobby.

The second is that it runs on rules, not judgement. You should be able to write it down as a series of "when this, do that" statements a colleague can follow without asking you anything. If describing the process takes three attempts and ends in "well, it depends", that dependence is the actual work, and not the part software does.

The third is that the judgement is low, or can be lifted out. Plenty of processes are mechanical with one decision buried inside, and those still qualify provided you can pull the decision out and leave it with a person. Sorting incoming enquiries by size and routing them is mechanical, while deciding which to take is not, so automate the sorting and keep the deciding.

The fourth is a pain you can name specifically. Not "this is inefficient", which is true of everything, but something closer to invoices going out four days late because they wait for one person to have a quiet afternoon. Named pain gives you the thing to measure afterwards, and it is the difference between a project you can judge and one you can only have opinions about.

What makes a bad one

Some processes fail the four points above. Others pass all four and are still the wrong choice, and those are worth naming, because they look good on paper.

The first is a process nobody agrees on. If three people describe it differently you do not have a process, you have three of them running under one name. Automating it picks a winner by accident, in code, without the conversation that should have chosen it. Have that conversation first, because often it is the whole fix and the software turns out unnecessary.

Then there is the process about to change, where automating something you plan to replace buys a few months of benefit and a rebuild. The same goes for a process that only exists because of a system you intend to move off.

Then there is the process where the exceptions are the job. Every process has exceptions, and the useful question is what share of cases they represent. If the exception rate is one in fifty, automate the forty-nine and handle the rest by hand. If it is one in three, you will spend most of your effort teaching software to recognise cases it then hands back to you, and you will have built an expensive way of doing the same work.

And there is the process you do not own. If it lives inside a supplier's system and you have no access to it, automation may still be the answer, but the project is a negotiation rather than a build. Find that out before you start, not four weeks in.

Why the biggest process is the wrong place to start

The instinct is to go after whatever costs the most. On a first project that is the wrong instinct, for three reasons.

The biggest process is usually the most entangled, touching the most people, the most systems and the most exceptions, so the build takes longest and the specification is hardest. First projects are where you learn how your business actually works once somebody writes it down. Learn that somewhere cheap.

It is also where failure hurts most. Something small breaking is an afternoon of annoyance, where your core operational flow breaking is a week of everyone working around it and a lasting reduction in anybody's appetite to try again. The second cost is the one that stays with you.

The third is that you learn less. A small automation delivered in a fortnight tells you whether your team adopts these things, whether your supplier is any good, and whether your estimate of the saving was close. A six-month project tells you the same three things six months later, by which point you have already committed.

Start with something whose failure is survivable and whose success is visible. Use what you learn to specify the big one properly.

Telling whether it worked

Most automation projects are never judged: they go live, the enthusiasm fades, and a year later nobody can say whether the money was well spent. Avoiding that costs almost nothing at the start.

Write down the current state before you change anything: how long the task takes, how often it is done, how often it goes wrong, and who does it. Rough numbers are fine. A figure you estimated in ten minutes beats a precise one you never collected.

Then agree what you expect to be different, in the same terms. If the answer is only that it will be faster, press harder: faster for whom, and what will they do with the time. If nobody will do anything differently because the task was ten minutes spread thinly across a week, that is a genuine finding, and the money belongs elsewhere.

Check after a month rather than a week, because the first week is unrepresentative in both directions: teething problems make it look worse, and novelty makes people more careful than they will remain. A month in, you are looking at the steady state.

And check whether people are using it. The commonest quiet failure is not that the automation broke, it is that somebody carried on doing it the old way as well, because they did not trust it. Sometimes that is caution and it fades. Sometimes it is a signal that the thing gets it wrong often enough to be worth checking, which you want to know before building anything else on top of it.

What this adds up to

The businesses that get value out of this do not start with a plan for their whole operation. They start with one dull, frequent, rule-based task that somebody names without hesitating when asked what wastes their week. They ship it, they measure it, and they use what they learned to pick the next one.

That sounds slower than the route you get pitched, but in practice it arrives sooner, because none of it has to be undone.

The next step is not a strategy document but picking one task, writing down those four numbers, and giving somebody a fortnight to change it. If nobody can name the task, that is the finding, and the answer is to watch how the work is actually done for a week.

That is how we scope this, because we would rather build one small thing you can judge in a fortnight than take a brief for a system nobody can evaluate until it is finished. If the first one does not pay for itself, a fortnight is a much better place to learn that than a quarter.