Quick answer: A process is ready for AI when it is repetitive, rule-based, high-volume and already documented. Those four conditions matter more than which tool you pick. Work that fails them — judgement calls, exceptions, anything with no written process — will cost more to automate than it saves, however good the model is.
Introduction
Most conversations about adopting AI start with the tool. Which model, which platform, which vendor, which subscription. The decision gets made on a demo, and the demo always works, because demos are built from the cases that work.
The better starting point is the work itself. Some of what your business does every day is almost ideally suited to automation. Some of it is actively hostile to it. The difference is not how technical the task looks — it is how predictable it is.
This article sets out the four conditions that make a process a good candidate, the signals that it is a bad one, and how to sequence the work so the first project pays for the second.
The Four Conditions
A process is a good automation candidate when it is repetitive, rule-based, high-volume and already documented. All four matter, and the fourth is the one people skip.
1. Repetitive
The same shape of task, over and over. Not identical inputs — invoices differ, enquiries differ — but the same decision being made each time. If someone on your team could describe the task once and have a new starter do it by Friday, it is repetitive in the sense that matters.
2. Rule-based
The decision follows rules rather than judgement. “If the invoice total does not match the purchase order, flag it” is a rule. “Decide whether this client relationship is worth the discount” is judgement. The first can be automated and checked. The second cannot, and attempts to do it anyway are where most disappointing AI projects come from.
A useful test: if two experienced members of your team would reach different answers from the same inputs, it is judgement, not a rule.
3. High-volume
Volume is what turns a small per-item saving into a number worth the effort. Two minutes saved on something that happens four times a month is not a project. Two minutes saved on something that happens four hundred times a month is most of a working week.
This is also the condition that makes the business case honest. If you cannot say roughly how many times a month the task happens, you cannot say what automating it is worth, and you are deciding on enthusiasm.
4. Already documented
This is the one that gets skipped, and it is the best predictor of whether a project finishes. If the process exists only in one person’s head, the automation project becomes a process-documentation project wearing a disguise — and those take far longer than anyone budgets, because the documentation keeps revealing exceptions nobody mentioned.
If the process is written down, most of the hard thinking is already done. If it is not, write it down first. That has value even if you never automate anything.
What Usually Qualifies
The work that meets all four conditions is almost always unglamorous. That is not a coincidence — the tasks that are predictable enough to automate are the same tasks that are boring enough that nobody wants to do them.
- Document handling. Invoices, purchase orders, delivery notes and forms arriving as PDFs, photographs and email attachments, each supplier formatting things their own way, someone retyping the totals. This is often the single fastest payback available, which is why we wrote about document processing separately.
- First-line enquiry handling. Order status, opening hours, delivery timelines, “do you work with businesses like mine”. The same twenty questions, asked endlessly.
- Lead qualification. Checking an enquiry against fixed criteria before it reaches a salesperson.
- Data entry and reconciliation. Moving structured information between systems that do not talk to each other.
- Appointment booking. Checking a calendar, offering slots, confirming, reminding.
What Usually Does Not
Work fails the test when the rules are unstated, the volume is low, or the cost of being wrong is high.
- Anything where an error is expensive and hard to spot. Automation does not reduce your error rate by itself; it changes where errors come from. If a mistake surfaces immediately and cheaply, that is manageable. If it surfaces six weeks later in a client’s accounts, think again.
- Relationship work. Negotiation, difficult conversations, anything where the point is that a person is paying attention.
- Processes still being argued about. If the team disagrees on how something should work, automating it just encodes one side of the argument and makes it harder to change.
- One-off projects. No repetition, no payback.
Sequence Matters More Than Scope
Start with the process that is boring, frequent and already written down — even if it is not the one that would impress anyone.
The reason is practical. A first project that works builds the internal case for the second. A first project that is ambitious, slips, and ends up half-adopted makes every later proposal harder, regardless of merit. Most organisations get one or two attempts at this before the appetite goes.
It also helps that the unglamorous processes are the ones where you can measure the result. If invoice handling took eleven hours a week and now takes three, nobody needs convincing. If a “customer experience transformation” is going well, everybody has an opinion and nobody has a number.
Governance belongs in the sequence too, not bolted on afterwards — something that becomes more pressing as systems start taking actions rather than just answering, which we covered in AI agents and governance.
A Note on Tools
The tool question matters far less than it appears, and it is reversible. Models improve every few months and switching costs are low if the process around them is documented. The process work is the part that lasts.
This is also why the comparison between automation approaches is less of a choice than vendors suggest. Rule-based robotic process automation and model-based approaches solve overlapping problems, and the right answer is often both — a distinction worth understanding before you buy either, which is why we set it out in RPA and what AI changes about automation.
Where to Start
List the five tasks your team complains about most. For each, answer four questions: does it repeat, does it follow rules, how many times a month, and is it written down anywhere.
The one that scores well on all four is your first project. If nothing scores well on the fourth, your first project is documentation — and that is a more useful outcome than it sounds.
If you would rather work through it against a structured set of questions, our AI Readiness Scorecard asks nine of them and returns where you are likely to see a return first, and where you would currently be wasting money. It takes about four minutes.