AI automation ROI: how to pick what to automate first

Most automation projects don't fail because the technology didn't work. They fail because the team automated the wrong thing first, something visible and exciting rather than something expensive and repetitive, and the return never showed up on a spreadsheet anyone cared about.

Automation is an investment, and like any investment it should be chosen on return, not on novelty. Here's the framework we use to decide what to automate first.

Score every candidate on four axes

For each manual process you're considering, score it on four things:

1. Volume. How often does it run? A task done 500 times a month is a far better target than one done twice.
2. Time per run. How long does each instance take a person? Multiply by volume and you have the raw hours at stake.
3. Rules clarity. How well-defined are the rules? Clear, deterministic rules automate cleanly. Fuzzy, judgement-heavy work needs a human in the loop and automates partially at best.
4. Error cost. What does a mistake cost today? High-error-cost processes done by tired humans are prime candidates, because consistency is where automation shines.

The best first project scores high on all four: high volume, meaningful time per run, clear rules, and real cost when it goes wrong. That's your highest-ROI target, and it's almost never the flashy one.

The quiet winners are usually document and data work

In most organisations the biggest wins hide in unglamorous places:

• Re-keying data between systems that don't talk to each other.
• Document extraction and classification, pulling fields off invoices, forms, and statements.
• Report assembly, the monthly pack someone builds by hand from five sources.
• Reconciliation, matching records across systems line by line.

None of these make a good demo. All of them drain hours every single week, and all of them have clear enough rules to automate reliably.

Match the tool to the job

There's no single right automation tool, and anyone who tells you otherwise is selling one. The job decides:

• n8n is a strong, cost-effective default for API-driven workflows, connecting systems, moving and transforming data, orchestrating steps across the tools you already use. It's open and flexible, which matters when your processes are specific to you.
• RPA (like UiPath) fits legacy desktop applications that have no API, where you genuinely need to drive a user interface the way a person would.
• LLM-powered steps (OpenAI, Anthropic) handle the fuzzy parts, summarising, classifying, extracting from messy text, but they belong inside a workflow with guardrails and human checkpoints, not as a free-floating chatbot.

Most real automations combine these: an n8n workflow that calls an LLM for the judgement step and routes anything low-confidence to a human. The orchestration is the product; the model is one component.

Beware the "ChatGPT wrapper" trap

A brittle demo that works once in a meeting is not automation. Production automation needs logging, error handling, retries, and a human-in-the-loop checkpoint wherever the stakes or the ambiguity justify it. The difference between a pilot that stalls and one that reaches production is almost always this engineering discipline, not the cleverness of the prompt.

Prove the ROI before you build

Before automating anything, write down the current cost: hours per month, loaded cost of those hours, and the cost of the errors the process produces today. After automation, measure the same things. If you can't state the before-and-after in numbers, you can't claim a return, and you shouldn't claim one.

This is the same evidence-first discipline we apply everywhere: don't take anyone's word that an automation saved money, including ours. Measure it. The automations worth building survive that scrutiny easily, which is exactly why you start with them.

Start with an audit, score your candidates, automate the expensive-and-repetitive ones first, and let the measured return fund the next wave.