Which process should you automate first?
Automate the process that scores highest on four criteria at once: it’s repeatable (done the same way every time), high-volume (frequent enough that small savings add up), rule-based (you can explain the logic in plain words), and data-ready (the information it needs already lives somewhere a machine can read). Then take your shortlist of candidates and plot each one on an effort/impact matrix, and pick the one sitting in the high-impact, low-effort corner. That single process is your pilot. Everything else waits.
The reason to be this strict is simple: your first automation isn’t really about saving hours. It’s about proving the approach works, cheaply, before you spend real money. A small, boring, high-frequency process that you nail in six weeks teaches your team more — and earns more internal trust — than an ambitious project that drags on for six months and quietly gets abandoned. The whole game of choosing an automation pilot is picking the candidate most likely to produce a clean, measurable win.
This guide gives you the four criteria as a scoring rubric, the effort/impact matrix with a worked example, and — just as important — the red flags that tell you a process should not be your first automation, no matter how tempting it looks. It’s written for the owner or operations lead of a small or mid-sized company who wants a method, not a sales pitch. No technical background required.
This article goes deep on picking the first process. For the full sequence around it — readiness audit, process clean-up, building on n8n, and EU AI Act compliance — see the pillar guide, AI Adoption for SMEs: A Step-by-Step Implementation Roadmap.
Why does picking the wrong first process sink the whole effort?
Most failed automation efforts don’t fail at the technology. They fail at selection. A company picks its most painful, most visible, most political process — the one everybody complains about — precisely because it’s painful. And that process is usually painful because it’s full of exceptions, judgment calls, and missing data: exactly the things that make it the worst possible first candidate.
When that first pilot stalls, the damage isn’t just the wasted budget. It’s the story that gets told afterwards: “we tried AI, it didn’t work for us.” That story is expensive. It makes the next attempt harder to fund and the team more skeptical. So the first pick carries weight far beyond its own line item — it sets whether automation gets a second chance at all.
The counterintuitive move is to pick something almost unglamorous. Not the crisis. A high-frequency, low-drama process where success is obvious and failure is cheap. You’re not trying to impress anyone with the first project. You’re trying to build a reference point — a working, measured example that makes the second project an easy decision. Where to start with AI is less about ambition and more about derisking.
What are the four criteria for choosing an automation pilot?
These four criteria are the consensus that has held across two decades of process automation, well before the current wave of AI tools — and they still hold, because they describe what makes any process mechanizable rather than what any specific technology can do. A process that’s repeatable, high-volume, rule-based, and data-ready is a strong candidate whether you automate it with a simple script, a workflow tool, or an AI agent. Score each candidate on all four; the best first pick is the one that’s strong on every axis, not brilliant on one and weak on the rest.
Criterion 1 — Is the process repeatable?
Repeatability asks whether the task is done essentially the same way every time, or differently depending on who’s doing it and what mood the day is in. The test: could you write the steps down clearly enough that a competent new hire could follow them without asking questions? If yes, it’s repeatable enough to automate. If every instance is a special case, it isn’t — yet.
Repeatability is the criterion people overestimate most. A process can feel routine while actually being riddled with undocumented exceptions that live only in one experienced employee’s head. Before you call something repeatable, watch it happen a few times, or ask the person who does it to talk you through three recent examples. The exceptions you discover are the real measure of how ready it is.
Criterion 2 — Is the volume high enough to matter?
Volume is what turns small per-instance savings into a return worth the build cost. A task you do 200 times a week, each taking ten minutes, is a far better first target than one you do twice a month, even if the twice-a-month task is more annoying. The classic illustration from automation practice: a process running 1,500 times a day beats one running five times a week, because the high-frequency one pays back the effort fastest and gives you the most data to verify the automation is behaving.
There’s a second, quieter reason volume matters for a pilot specifically: high frequency means you find out quickly whether it works. A process that runs once a month gives you one test per month. A process that runs hundreds of times a week surfaces every edge case and every bug within days, so you learn fast and fix fast.
Criterion 3 — Are the rules clear?
A process is rule-based when its logic can be expressed as explicit conditions — “if the invoice is under €500 and the vendor is on the approved list, route it for payment; otherwise send it to a manager.” The opposite is judgment-based work, where the right answer depends on experience, context, empathy, or weighing factors that resist being written as rules.
The plain-language test again does the work: if you can explain to a new employee exactly how to make the decision, the rule is clear enough. If your honest answer is “it depends, you just get a feel for it,” that’s not a rule — it’s expertise, and expertise is the thing you keep a human for. Clear rules are the difference between a process you can automate confidently and one where the automation will quietly make wrong calls you won’t catch until a customer does. This is also where AI changes the picture slightly: modern language models can handle fuzzier inputs than old rule engines (reading a messy email, classifying free text), but the underlying decision still needs a defensible rule behind it. AI lets you automate messier inputs, not murkier judgment.
Criterion 4 — Is the data available and machine-readable?
The last criterion is the one that silently kills more pilots than any other: can a machine actually get at the information the process needs? If the data lives in a CRM, a database, structured emails, spreadsheets, or any system with an API, you’re in good shape. If it lives in scanned PDFs of varying quality, in the heads of three colleagues, on sticky notes, or scattered across formats that change every time, your automation will spend all its energy fighting to read the inputs and never get to the actual work.
Data availability is worth checking before you fall in love with a candidate, because it’s the criterion least visible from the outside. A process can look perfectly automatable until you discover the one field you need only exists as a handwritten note on a form someone scans. Confirm the data is there, and machine-readable, before you commit.
A quick scoring rubric
Score each candidate process from 1 to 5 on each criterion, then add it up. Anything that scores low on data availability or rule clarity should be treated with suspicion no matter how high it totals — those two are the common points of failure.
| Criterion | Score 1 (poor candidate) | Score 5 (ideal candidate) |
|---|---|---|
| Repeatability | Every instance is a special case | Identical steps every time, fully documentable |
| Volume | A few times a month | Hundreds of times a week |
| Rule clarity | “It depends, you get a feel for it” | Explicit if/then logic anyone can follow |
| Data availability | Locked in heads, sticky notes, messy scans | Clean, structured, accessible via system or API |
How do you use an effort/impact matrix to make the final call?
Scoring tells you which processes are automatable. The effort/impact matrix tells you which one to do first. It’s a simple two-by-two: on one axis, the business impact of automating the process (hours saved, errors removed, cycle time cut, revenue unblocked); on the other, the effort to build and maintain the automation (technical difficulty, number of systems to integrate, data clean-up required, ongoing upkeep). Place each shortlisted candidate in one of four quadrants.
| Low effort | High effort | |
|---|---|---|
| High impact | Quick wins — start here | Major projects — plan for later |
| Low impact | Fill-ins — automate if trivial | Money pits — avoid |
- High impact, low effort — the quick-win quadrant. This is where your first pilot lives. A process here is valuable enough to be worth doing and easy enough that you’ll finish it. Pick the single strongest candidate in this box and stop looking.
- High impact, high effort — major projects. Genuinely worth doing, but not first. These are your second and third projects, attempted once your pilot has proven the approach and built the skills and trust to take on something bigger.
- Low impact, low effort — fill-ins. Automate these only if they’re nearly free, and never let them jump the queue ahead of a quick win. They’re filler, not strategy.
- Low impact, high effort — money pits. Avoid entirely. Surprisingly often, this is exactly where companies start, because the high-effort process is the painful one everyone notices. Effort is not the same as value.
What does a worked example look like?
Suppose a 40-person services company shortlists three candidates. A: routing and acknowledging inbound inquiries — happens ~150 times a week, follows a clear pattern, the data arrives as structured form submissions. B: producing the monthly board report — painful and senior-time-heavy, but happens once a month, pulls from five inconsistent sources, and involves a lot of judgment about what to highlight. C: tagging support tickets by topic — high volume, but low impact because nobody’s really blocked by untagged tickets.
Plot them. A is high-impact, low-effort — the quick win. B is high-impact but high-effort, and low-volume to boot — a major project for later, and a terrible first pilot despite being the most painful. C is low-impact, low-effort — a fill-in at best. The matrix points cleanly at A, even though a gut reaction would have grabbed B because it hurts the most. That gap — between what hurts and what to fix first — is exactly what the matrix exists to close.
What are the red flags of a process you should NOT automate first?
Some processes are bad first candidates even when they look attractive on a spreadsheet. These are the red flags. None of them means “never automate” — they mean “not your pilot.” A first project should be a clean test of the method, and each of these flags adds the kind of risk or noise that makes a clean test impossible.
- High cost of error with no easy reversal. If a mistake means a wrong quote sent to a client, a wrong refund issued, or a compliance breach, this is not where you learn. Build your confidence on something where errors are cheap and reversible, then bring rigorous human-in-the-loop controls to the high-stakes process later.
- Heavy judgment, empathy, or accountability. Hiring decisions, handling serious complaints, anything requiring a human to be accountable — these resist clear rules by nature. AI can assist (gather information, draft, summarize), but the decision stays with a person. Don’t make one of these your proving ground.
- Unstable rules that change often. If the logic shifts every quarter with new regulations or pricing, you’ll spend more time rebuilding the automation than it saves. Automation rewards stability; a moving target is the opposite. Wait until the process settles, or automate a stable sub-part of it.
- Missing or messy data. If the inputs aren’t machine-readable, the data clean-up alone can dwarf the automation. Either fix the data first as its own small project, or pick a different candidate whose data is already clean.
- A broken or undocumented process. Automating a broken process just lets you make mistakes faster — and AI scales whatever logic you feed it, including the bad logic. The discipline borrowed from lean operations is eliminate, simplify, standardize, then automate (the “ESSA” sequence used in manufacturing and, famously, in finance functions like Shell’s): remove the pointless steps, simplify the handoffs, write down one standard way of doing it, and only then automate. If you can’t document it cleanly, it isn’t ready.
- Rare, low-volume tasks. Even a perfect, rule-based, data-rich process isn’t worth a first automation if it only runs a handful of times a month. The payback is too slow and the learning loop too sparse. Save it for when automation is cheap and routine for you.
- Deeply political or contested processes. If a process is owned by several teams who disagree about how it should work, automating it means refereeing a turf war on top of a technical build. Pick something with one clear owner for your first project; you want one variable changing, not three.
A useful summary test: your first automation should be one where you’d be comfortable if it failed quietly tonight. If a quiet failure would cause real harm, embarrassment, or a customer-facing error, it’s not a pilot — it’s a project that needs the controls and experience you don’t have yet. Earn those on something safe.
How does AI change the “which process first” question?
For the most part, it doesn’t — and that’s worth saying plainly, because the hype implies otherwise. The four criteria and the effort/impact matrix predate the current AI wave and still govern the decision. What AI shifts is the boundary of what counts as rule-based and data-ready, not the logic of choosing.
Specifically, AI widens two of the four criteria. On data availability, language models can now read semi-structured and unstructured inputs — a free-text email, a varied invoice, a customer message — that old automation couldn’t parse, so processes that were previously blocked by messy inputs can become viable. On rule clarity, AI can handle fuzzier classification (“is this email a complaint, a question, or a sales lead?”) that’s hard to capture as explicit if/then rules. That genuinely expands the pool of candidates.
What AI does not do is remove the need for a defensible decision underneath, and it does not reduce the cost of error — if anything it raises it, because a confident wrong answer from an AI can be harder to spot than an obvious system failure. So when you score candidates, treat AI as a tool that lets you reach messier inputs, while keeping every other criterion exactly as strict. The red flags above all still apply. If anything, “high cost of error” deserves more caution in an AI pilot, not less.
The short version
Choosing your first automation is a selection problem, not a technology problem. Score each candidate on four criteria — repeatability, volume, clear rules, available data — and be especially suspicious of weak data or fuzzy rules. Plot your shortlist on an effort/impact matrix and pick the single strongest process in the high-impact, low-effort corner. Refuse the temptation to start with the most painful process; pain is not the same as suitability. Avoid the red flags: high error cost, heavy judgment, unstable rules, messy data, broken or undocumented workflows, rare tasks, and political turf wars. Your first pilot’s job is to produce one clean, measurable, low-risk win that earns the right to do the next one. Get the pick right and the rest of the roadmap gets dramatically easier.
This article is general operational guidance. For decisions involving regulated, high-risk, or customer-impacting processes, validate your approach against your own legal and compliance requirements.
Sources: McKinsey — The value of robotic process automation, ACCA — Shell case study: eliminate, simplify, standardise, then automate.
Educational material, not legal advice. As of 2026 — interpretation of the EU AI Act may change.