Automating One Workflow First: How to Pick the Right One

Every business that automates something successfully automated one thing first. The ones that try to fix everything at once tend to produce a half-finished system nobody trusts, which quietly gets worked around until it is switched off.

So the first decision is which one. Most businesses get this wrong in a predictable way.

The loudest complaint is usually the wrong target

Ask a team what wastes their time and you will get a fast, confident answer. It will be the task they find most irritating.

Irritation and cost are different things. The most annoying task is often something done twice a week that takes twenty minutes and involves a system everyone hates. Genuinely unpleasant. Roughly forty minutes a week.

Meanwhile the thing costing real money is usually invisible, because it is not a task anyone performs. It is a gap — the enquiry nobody answered, the follow-up nobody sent. Nobody complains about work they are not doing.

Three questions that actually rank candidates

For each candidate process, answer these. The one scoring highest across all three wins — not the one scoring highest on any single question.

How often does it happen?

Frequency compounds. A daily task at ten minutes is over forty hours a year. A monthly task at two hours is twenty-four. The monthly one feels bigger every time it happens, which is exactly why it gets nominated and the daily one does not.

How much of it is genuinely the same every time?

This is the automation question. A process that is 90% identical with a 10% judgement call automates well — handle the 90%, escalate the rest. A process where every instance is meaningfully different does not, no matter how much time it consumes.

Be honest here rather than optimistic. "It's basically always the same" is worth testing against twenty real examples before you build anything on it.

What does a delay cost?

The multiplier everyone forgets. Some tasks are equally fine done now or on Thursday. Others lose most of their value within hours.

Internal admin is usually delay-tolerant. Anything touching a customer who is currently deciding something is not. This is why lead response and booking outrank internal reporting almost every time, even when the reporting takes more hours.

Running the numbers on a real-ish example

Take a clinic weighing two options. The numbers below are illustrative — the point is the shape of the comparison, not the values.

Reconciliation consumes more hours and generates all the complaints. Booking wins clearly on the two criteria that decide whether automation works — repeatability and cost of delay — and it is the one nobody would have raised in the meeting.

What our two clients actually started with

Both live deployments we run began this way, with one narrow process rather than a department.

Aion Lab started with routine inbound support questions — high frequency, highly repeatable, and the same fifteen questions in rotation. Not the most interesting problem in their business. The most automatable one.

Atom Medicals started with appointment booking. Front desk was handling it between in-person patients, which meant it was always interrupting something more important, and enquiries arriving outside hours were simply lost.

Neither started with the thing that annoyed staff most. Both started with the thing that was repeatable and time-sensitive.

Three things not to automate first

• Anything requiring professional judgement. Diagnosis, legal advice, bespoke quotes with real risk. These need a person, and a system that guesses at them is worse than no system.
• A process that is currently broken. Automating a bad process gives you a bad process running faster and more consistently. Fix it manually first, then automate the version that works.
• Anything you cannot describe precisely. If you cannot write down the rules in a page, it is not ready. That is not a technology limitation — it means the decision logic still lives in someone's head and needs to come out before it can be built.

Then, and only then, the second one

Once the first is running and the team trusts it, the second is substantially easier — the knowledge base exists, the integrations are in place, and, less obviously, people have stopped being suspicious of it.

That last part matters more than the technical head start. The main reason automation projects fail is not that the system did not work. It is that nobody believed it did, so they kept doing the task manually alongside it, and eventually someone asked why they were paying for both.

One workflow, working properly, in production, trusted. Then the next.