Where AI automation actually pays: choosing your first process

Most companies that ask us about AI automation already have a process in mind. About half the time, it's the wrong one — not because it couldn't be automated, but because the return doesn't justify the build, and nobody has done the arithmetic.

The failure mode is predictable. Someone picks the process that annoys them most, rather than the one that costs the most. Annoyance and cost correlate badly. The task everyone complains about is often a two-hour monthly irritation; the one nobody mentions is forty minutes a day, every day, across six people.

The only two numbers that matter first

Before any conversation about models, vendors or architecture, get two numbers for each candidate process:

• How often does it run? Per day, per week, per month.
• How long does one run take? Measured, not estimated from memory.

Multiply them out to annual hours, then multiply by a fully-loaded hourly cost. That number is the ceiling on what automation can possibly be worth. If the ceiling is smaller than the build cost, stop — no amount of clever engineering rescues that.

We put this arithmetic into a free ROI calculator because we were doing it manually on nearly every first call. The interesting output isn't the saving; it's the payback period. Anything beyond two years usually means the wrong process was chosen.

What makes a process a good candidate

Volume gets you into the conversation. These four characteristics decide whether it's worth doing.

1. The input arrives in a consistent-ish form

"Consistent-ish" is deliberate. Documents don't need to be identical — invoices from forty suppliers in forty layouts are fine. What matters is that the information present is consistent: every invoice has a total, a date, a supplier. Where the fields sit doesn't matter much. Where the fields sometimes don't exist at all, it matters a great deal.

2. Someone can articulate the rules

If you ask the person who does the work why they routed something a particular way, and the answer is "you just learn it", you have a discovery problem before you have an engineering problem. That's not a blocker — it's a two-week process-mapping exercise. But it has to happen, and it's much cheaper before development than during it.

3. A mistake is recoverable

The best first automation is one where an error costs an apology, not a lawsuit. Start where the blast radius is small, prove the accuracy, then move toward higher-stakes processes with the confidence — and the measurement infrastructure — you've built.

4. Somebody can review the uncertain cases

Every reliable production AI system routes low-confidence output to a human rather than guessing. If there's genuinely nobody who can do that, the design has to be far more conservative and correspondingly narrower. Teams that insist on full autonomy from day one almost always end up with less automation, not more.

The processes that look good and aren't

Three categories come up repeatedly and disappoint reliably.

Judgement-heavy work with low volume. Contract review is the classic example. It's expensive per instance, which makes it feel valuable, but if you review twelve contracts a year the automation will never pay for itself — and the stakes make the human review step mandatory anyway, so you save very little.

Processes that are about to change. If the underlying system is being replaced next year, or the regulation is under consultation, automate something else first. We've watched more than one carefully-built pipeline become irrelevant three months after go-live.

Anything gated behind an inaccessible system. If the data lives in a vendor product with no API and no database access, the real project is that access negotiation. Find out what your vendors actually permit before scoping anything — this is the most common late surprise we see, and it's entirely avoidable with one email.

What "automated" should actually mean

The word implies the humans go away. In practice, a well-built automation changes what the humans do rather than removing them, and being straight about that up front prevents a lot of disappointment later.

A document pipeline we built moved a team from reading and re-keying every document to reviewing roughly one in five. The other four went straight through. That's a genuine, large improvement — and it's a very different thing from "we automated document processing", which is how it would get written up in a case study somewhere else.

Set the expectation at the start: you're aiming for a coverage percentage, not a binary. Sixty to eighty percent is a realistic target for most document and data work. Push the threshold higher over time as the evaluation data tells you it's safe, not because someone promised a number in a proposal.

Measure before you build

This is the step almost everyone skips, and it's the one that decides whether the project can be defended afterwards.

Spend a month measuring the current process: volume, time per run, error rate, and how often exceptions occur. Two things come out of that. First, you get a baseline, without which you cannot prove the automation worked — which makes the follow-on budget very hard to argue for. Second, you very often discover the process isn't what everyone believed. The step people described as taking ten minutes takes thirty-five, and a step nobody mentioned takes an hour.

You also get the raw material for an evaluation set: real examples with known-correct answers. That set is what lets you measure accuracy honestly before the system touches anything live, and catch regressions when a model or prompt changes later.

The sequencing that works

1. List candidates and rank by annual volume × time per run. Ignore how annoying each one is.
2. Check access for the top three. Confirm in writing what your systems and vendors permit.
3. Measure the winner for a month. Build the baseline and the evaluation set.
4. Build a narrow first slice — one document type, one workflow — not the whole process.
5. Run in shadow mode alongside the manual process and compare outputs before switching anything over.
6. Then expand. The second automation costs a fraction of the first, because the ingestion, review queue, logging and monitoring already exist.

That last point is the one worth holding onto. The first automation carries all the platform cost. If you choose it well and build it properly, everything after it is comparatively cheap — which is exactly why choosing it badly is so expensive.

If you want to sanity-check where you stand before committing budget, the AI readiness assessment covers the data, process and sponsorship questions that sink most projects, and takes about three minutes.