The wrong question to start with
The question almost every business asks first is "where would AI have the biggest impact?" It sounds like the right question and it is not, because the honest answer is usually a process that is complex, politically owned, spans four systems and carries real consequences when it goes wrong. Aim there first and you will spend six months on an integration project, learn very little, and arrive at a go-live where nobody is quite willing to trust the output.
The better question is: which process will teach us the most, for the least risk, while returning enough to justify the next one?
That reframing matters because your first AI automation project is doing two jobs at once. It is delivering a business result, and it is educating the organisation: the people who will operate it, the people who will approve its output, and the executives who will fund the second one. The second job is worth more than the first and almost nobody scopes for it.
Four properties of a good first candidate
A strong first candidate has all four of these. Three out of four is workable. Two is a warning.
1. It happens often
Volume is what turns a small per-item saving into a number worth reporting. A process that runs forty times a day at four minutes each is a far better first project than one that runs twice a month and takes a day, even though the second one feels more painful. Frequency also gives you evidence quickly: after two weeks you have hundreds of runs to look at rather than three.
As a rough floor, look for something that happens at least a few times a day, or consumes at least a day of someone's week in aggregate.
2. The input is documents or messages
The largest capability jump of the past few years is in reading unstructured input: emails, PDFs, forms, scanned documents, transcribed calls, photos with text in them. If your process starts with a person opening something and typing what they read into a system, that is the sweet spot, and it is where the previous generation of automation tools consistently failed.
Processes that start with already-structured data are usually better served by an integration than by AI. That is a good finding, not a disappointing one, and it is usually cheaper.
3. The rules exist and can be written down
There is a difference between a decision that requires judgement and one that requires knowledge somebody happens to hold. "Apply the contract price where one exists, otherwise standard tier, and flag anything below the margin threshold" is a rule. "Sarah knows which customers we make exceptions for" is knowledge, and it needs to become a rule before it can be automated.
Discovering that a rule cannot be written down is itself valuable. It usually means the rule is inconsistent, which is a process problem worth knowing about regardless of what you automate.
4. Getting it wrong is recoverable
This is the constraint people resist most and should not. On your first project, the cost of an error should be rework, not a regulatory breach, a lost customer or a payment out the door. You are going to find edge cases you did not anticipate, which is the entire point of shipping something, and you want to find them somewhere the recovery is cheap.
There is a second reason. The team's willingness to trust the second system is set almost entirely by what happened with the first. A first project that produced two embarrassing errors in front of a customer will cost you a year of organisational appetite, whatever the numbers said.
Three traps that look like good candidates
The everything project
"Let's build an assistant that can answer any question about our business." It demonstrates beautifully and never quite ships, because "any question" has no definition of done, no evaluation set, and no way to tell whether this month's version is better than last month's. Scope that cannot be finished cannot be measured, and work that cannot be measured does not get a second round of funding.
The process about to change
If a system is being replaced next quarter, if the team is restructuring, or if a regulation is mid-consultation, automating that process is building on a moving foundation. Wait. There will be another candidate.
The one nobody will give you access to
Sometimes the best process on paper belongs to a manager who does not want anyone looking closely at it. You will find out during discovery, and you will find out slowly. If access to the people doing the work is grudging, pick something else. The technical work is rarely what kills these projects.
Ranking what's left
Once you have a shortlist of three to six, score each on four axes and let the ranking fall out. Keeping it mechanical is what stops prioritisation becoming a negotiation.
| Axis | The question | Weight it heavily when |
|---|---|---|
| Value | Hours, cost or cycle time recovered per year | The business case has to stand on its own |
| Feasibility | Is the data reachable and the system integrable? | You have been burned by an integration before |
| Consequence of error | What happens when it gets one wrong? | This is your first project |
| Compounding | Does solving this unlock the next three? | You intend to do more than one |
The last axis is the one most people skip and it is usually decisive. Cleaning up how work arrives, by deduplicating channels, standardising a document intake or getting one system's data reachable, is rarely the most exciting item on a list, and it is often the item that makes the next five possible. A slightly smaller win that unblocks a queue beats a larger isolated one more often than you would expect.
How big should the first one be?
Smaller than feels satisfying. A useful test: if the first version cannot be in production within about twelve weeks of starting, the scope is too large for a first project. Cut it until it fits.
Cutting scope well means removing breadth, not depth. Automate one document type completely, including the exceptions, the approval gate and the logging, rather than four document types partially. A narrow thing that runs properly in production teaches you far more than a broad thing that runs in a demo.
It also gives you the honest per-run economics, the real exception rate and the actual reaction of the team, which are the three inputs you need to scope project two sensibly.
What a good first project looks like
Concretely, a first project that tends to go well has this shape:
- One clearly named process, one document type, one team
- Fifty to a few hundred runs a week
- A rule set that fits on a page
- One approval gate, on the action that commits something
- A single agreed metric, measured before and after
- A defined exception path that a named person owns
- Live at suggest-only, with the autonomy dial moved later on evidence
Notice how little of that is about the AI. The model is the least interesting decision in the list, which is generally a sign that a project has been scoped by someone who has shipped one before.
The one that gets skipped
Finally: run the whole thing against a baseline you captured before you started. Not an estimate reconstructed afterwards from memory, which will be shaped by whether people liked the outcome. Two weeks of real timings, real volumes and a real error rate, recorded while the process is still manual.
It is a slightly tedious fortnight, and it is the difference between reporting a result and asserting one.