Somewhere in your organisation there is a process everyone agrees would look spectacular with AI on it: customer-facing, complicated, full of the judgement your best people are quietly proud of. It would demo beautifully. It is also, almost without exception, the worst place to start.
A first automation is not a showcase. It is a learning run: its job is to teach the organisation how to scope one of these things, who owns it when it misbehaves and how to tell whether it helped, while being wrong is still cheap. You do not learn to ride switch in a couloir. The question is not what is the most impressive thing AI could do here, but what is the dullest thing that eats hours.
Pick the run nobody films
The demo-worthy process is demo-worthy for a reason, and the reason is bad news: it is impressive because it is hard. Ambiguous inputs, contested rules, edge cases senior people resolve by instinct. Dull, meanwhile, is a technical property, not an insult: dull means stable, and stable is the only thing you can measure.
Consider how each fails. A dull one produces a queue item somebody clears on Tuesday while mildly annoyed. An impressive one produces a wrong number in a board pack, in front of the audience you were trying to convince. That does not cost you the pilot. It costs you the next three.
Your first automation is not buying you a result. It is buying you the organisational competence to attempt the second one.
What actually predicts success
Ask five vendors and you will get five variations on “start with a high-value process”, which is advice in the way that “ski the good snow” is advice. Six conditions do the actual separating.
| Criterion | What a good candidate looks like | What should worry you |
|---|---|---|
| Frequency | Daily, or many times a week, all year round | A few times a quarter, or only at year end |
| Hours consumed | A named person can say how long it takes and how often | Nobody can say, and nobody is keen to find out |
| Rules | Writable on one page, exceptions included | “You just get a feel for it” |
| Systems touched | Two or more, with a human copying between them | One screen, already down to a couple of clicks |
| Measurable outcome | A count, a duration or an error rate you could collect this week | The benefit is described as confidence or visibility |
| Consequence of error | Caught in review, costs minutes to correct | Reaches a customer, a regulator or the ledger |
The row people under-weight is the fourth. Work inside a single screen has usually been optimised already; the expensive, invisible work is a human acting as an integration layer, re-keying a value from one system into another. That person is a very expensive API with a lunch break. And if nobody can write the decision down, you have not found a candidate — you have found expertise.
Four ways to pick the wrong one
Four holes swallow most first automations, and all four are visible from the top.
Automating something already broken
A duplicate approval, a report nobody reads, a form that outlived the system it was built for: automate that and you get faster at doing the wrong thing, with the broken design now encoded in software. Walk it first and ask why each step exists. Steps with no defensible answer are free improvement.
Picking something seasonal
Year-end, the audit pack, the quarterly rebate run. Painful, which is why they come to mind, and impossible to prove anything about: one observation per period, and by the next one the team and the volumes have changed. A run that opens six days a year. Legitimate later, not first.
Picking something too rare to matter
The mirror image, and it hides better. Do the arithmetic on an envelope, with numbers made up on purpose: a hypothetical task of two hours, twelve times a year, returns twenty-four hours if automated perfectly. Less than a working week, against a build and something to maintain.
Choosing by who complained loudest
Somebody senior is vocally irritated by a task, so it tops the list. Volume of complaint measures proximity to power, not hours consumed; the expensive processes are endured in silence by people who assumed this was the job. One honourable exception: if colleagues have already gone around you and found their own tools, they have proved the demand for you. Find out what is running in the shadows.
Assist before it acts, and say where the rope goes
Most arguments about AI risk are really arguments about which of three different things is on the table. Assist: it finds, extracts, summarises and drafts, and a person decides what to do with it. Recommend: it proposes an action with its evidence, and a named human approves. Act: it executes within stated limits, all logged, and the owner who set the limits is accountable.
Your first automation belongs in the first of those. Not because acting is dangerous in principle, but because you lack the one thing that justifies write access: evidence. You do not know how often it is right, what it is reliably wrong about, or what a bad week does to your exception volume. Assist mode produces that evidence, and fails cheaply while doing it.
The other instinct to resist is widening. It handles supplier invoices, so why not all documents? Every widening feels free at the design stage and none of them are. Narrow it until it feels almost embarrassing: the narrow version reaches production and produces evidence, while the broad one meets its first real exception in testing and is quietly rebranded a proof of concept. Then write the permission boundary down, in language a process owner would sign.
- What may it read? Which systems, records and fields — not “the finance data”.
- What may it write? For a first automation, nothing — and writing that down makes it a decision rather than an oversight.
- What must it never touch? Payment details, personal data, anything under legal hold.
- Where does it stop and ask? The conditions that force it back to a human.
- What happens when it fails? Where the exception goes, who owns that queue, and how fast somebody notices it growing.
That is the boundary rope: not a claim that the snow beyond it is bad, but a promise that on this side somebody has checked and somebody is responsible.
Design approval around consequence, not confidence
Here is where designs go subtly wrong: routing by model confidence, high straight through and low to a human. But confidence is a property of the model and consequence is a property of your business. A system can be entirely confident and entirely wrong, so the errors that sail through unreviewed are exactly the ones nobody doubted.
The right question is never “how sure is it?” It is “if this is wrong, what does it cost, and how would we find out?”
So design approval around the cost of being wrong. Two properties do the work: how reversible the action is, and how visible it is outside the team.
- Cheap to reverse, invisible outside the team. A draft, an internal classification. Let it run and sample weekly.
- Cheap to reverse, but visible. Anything a customer or another team sees. Approve it until the sampled error rate says you need not.
- Expensive to reverse. Anything that moves money, posts to a system of record or leaves the building. A named human approves every time, and the log records which one.
- Irreversible or regulated. Not a candidate for a first automation at all.
Approval load drops, because you stop asking humans to rubber-stamp things that cost nothing to get wrong — which is how review becomes theatre. And be honest about the reviews that remain: if checking takes nearly as long as the work did, you have moved the process from doing to checking, not automated it.
Baseline before you touch it, then prove it worked
This is the stop everybody skips, and it decides whether the programme continues. Measure the process before you automate it, because afterwards nobody can reconstruct the before. Whoever built the thing remembers the old way as slower than it was; the sceptics remember it as faster. Neither is data.
It does not need a project, only two weeks of mild discipline while the process runs as it always has — then the same measures once the automation is live, over a comparable period and the same definitions. Count the runs, and for each one:
- Time. Human minutes per run, including the waiting, the chasing and the re-keying — and afterwards, the review time you added, or you are marking your own homework.
- Cycle time. Trigger to done — often what the business feels: four minutes of work that sat in a queue for two days.
- Errors and rework. How often it has to be redone or escalated. Afterwards, sample the output rather than counting the errors people reported.
- Exceptions. How often the standard path does not apply and a human has to think. The best predictor of how hard the build will be, and if the rate climbs later, your scope is drifting.
A tally sheet is fine. What makes it evidence rather than advocacy is that it was written down while nobody yet had an interest in what it said.
Then be sceptical of your own result, because a flattering number is easy to produce by accident. Reporting only the happy path looks excellent while the exception queue absorbs the hard cases. So does comparing against the worst week you could find. So do hours that were never released: twenty minutes a day each for six people is real, and it appears nowhere unless something changed — a hire avoided, a backlog cleared. And the automation has a bill that grows quietly as retries and extra steps accumulate, so watch cost per completed piece of work — its own unglamorous discipline.
A real result is usually more modest than the pilot deck implied. That is fine: a defensible number beats a spectacular one that falls apart under the first question.
Then take another lap
The point of a first automation is the second one. What you are really building is a method: how you choose candidates, where the boundary goes, who approves what, how you prove it. Get that right on something dull and the next one costs a fraction. If you are hunting and you run an ERP, ten concrete examples are a place to start.
It is not a thrilling way to begin. It is how people end up good at this: not by dropping into the steepest thing on the map, but by taking the same dull run until the hard ones stop looking hard.
