What to automate first (and what never to automate)

Conversations about automation almost always start with the tool: Zapier or n8n, an agent or a script, whether a language model belongs in there. It is the wrong question, and you find out six months later, when there are four half-finished automations and somebody is still copying data by hand.

The right question is which process. And for that there is a test that works better than intuition.

The test: frequency times pain, divided by variation

Rank your candidate processes by three numbers anyone on your team can estimate in ten minutes:

• Frequency. How many times a month it happens.
• Pain. How many minutes it takes each time, counting the interruptions it causes.
• Variation. How many exceptions it has per ten runs.

The first two multiply: a five-minute process that runs 200 times a month hurts more than a three-hour one that runs once. The third divides, and it is the one most people ignore.

A low-variation process gets automated once and forgotten. A high-variation one gets automated, breaks on case 11, someone patches it, breaks on case 23, and ends up costing more maintenance than the manual work it replaced.

What usually wins

At the companies we work with, the top spots are almost always unglamorous:

• Reconciliations. Matching the bank statement against invoicing, gateway payments against orders, system inventory against the warehouse. High frequency, clear rules, pain concentrated on one or two people.
• Recurring reports. The report someone assembles on the first Monday of the month by pasting four exports into a spreadsheet.
• Onboarding and offboarding. Creating users in five systems when someone joins, and removing them when they leave. What you gain here is not only time: it is closing the security hole of accounts nobody deactivated.
• Moving data between systems. The CRM that does not talk to billing, reconciled by hand every Friday.

What they have in common: rules you can explain on one page, structured inputs and outputs, and a result you can verify automatically.

Three signs a process is not ready

Nobody can describe the whole thing. If understanding the process means asking three people and each tells a different version, you do not have a process — you have a habit. Automating a habit freezes the mistakes in place and makes them faster. Write it down first; sometimes, writing it down, you find half the steps were unnecessary.

The exception is the rule. If more than three in ten runs need human judgement, what you have is not a repetitive process, it is a job. Automate the part that does repeat — fetch the data, pre-fill the form, set it up for someone to decide — and leave the decision where it is.

There is no way to tell whether it worked. Every automation fails silently at some point. If you cannot define an automatic check ("the totals match", "there are as many rows as orders"), you will hear about the failure from your customer. And if you cannot define the check, you do not understand the process well enough yet.

Where AI fits (and where it doesn't)

A language model is excellent at reading messy text: a PDF invoice each supplier lays out differently, a customer email you need four fields out of, a product description that needs classifying.

It is a poor candidate for deciding. Not because it gets things wrong, but because it does not get them right every time, and in reconciliation, payments or inventory, 98% accuracy means somebody has to review 100% to find the 2%.

The rule we use: the model extracts and proposes, deterministic rules validate and execute. The model pulls the tax ID, the total and the date out of the PDF; a rule checks that the tax ID exists in the database and that the total matches the purchase order. If it matches, it goes through on its own. If not, it lands in a review queue with the document next to it.

That way a model error becomes work, not a wrong ledger entry.

Start with one, and measure it

One finished, measured automation is worth more than four half-built ones. Finished means: it runs on its own, it alerts when it fails, and someone knows what to do when it alerts.

Before you start, write down two numbers: how many minutes the process costs per month today, and how many errors it produced last quarter. Without that baseline, the conversation afterwards is about impressions, and impressions do not defend a budget.

After a month you will know whether the test held. And if it did, you pick the second process exactly the same way.

• automation
• process
• ai