Article · Implementation
How to Choose and Map Which Processes to Automate with AI
Not every process is a good candidate for an agent, and choosing badly is the most expensive mistake in the whole implementation: a process with no volume, unpredictable exceptions, or disconnected from the P&L produces a pilot that works and that nobody uses. Before mapping anything you have to select well. And once selected, mapping a process is concrete work along four axes. This is about both: which processes to automate with AI and how you put them in writing.
This article is one phase of the full guide on how to implement AI agents, the one that decides what you are going to work on. Doing it well saves months later.
The criteria for choosing a good candidate
A good candidate meets five conditions. It does not need to max out all of them, but if it fails several, find another process.
| Criterion | What to look for | Why it matters |
|---|---|---|
| Volume | Frequent, repeated cases, not once a month | Without volume, automation does not pay off the work of encoding it |
| Known rules | A logic that exists, even if it lives in someone’s head today | If nobody knows why a decision is made, there is nothing to encode |
| Typifiable exceptions | Oddities you can group and name | Exceptions you cannot typify end up handing the work back to a person |
| Measurable outcome | You can say whether a case went well or badly | No measure means no evaluation, and no evaluation means no production |
| Proximity to the business | Tied to revenue, margin or service | A lab pilot, disconnected from the P&L, ends up on the shelf |
The last criterion is the most ignored and the one that weighs most. The pilots I have watched die shared a trait. They were technically flashy and commercially irrelevant. Pick the process that matters to someone in the business, not the one that looks good in a demo. I analyze the underlying reason in why enterprise AI pilots fail.
The processes that look good and are not
Two frequent traps. The first: the creative or expert-judgment process disguised as repetitive. If every case demands fresh judgment, there is no pattern to encode, however much volume it has. The second: the process with rules nobody can explain. When you ask “why is this customer treated differently?” and the answer is “it has always been done this way”, the first job is not technical but reconstructing the rule or deciding to remove it. That exercise is often as valuable as the automation itself.
If the process is not a candidate, where does it go?
Rejecting a process leaves open the most useful question of this phase. What do you do with it then. A rejection with no destination ends up as a process that runs exactly as before and a meeting that repeats six months later. Almost every rejection I have seen lands in one of six destinations, and what decides which is the specific reason the process failed the filter.
| Why it fails the filter | What to do instead |
|---|---|
| It runs the same way every time and has no real exceptions | Classic automation or RPA. Paying for the capacity to decide on a process that decides nothing is cost you do not need, and I compare them in RPA or AI agents |
| It is deterministic and only chains systems that already have APIs | A visual automation tool, cheaper to build and to maintain, which I analyze in no-code automation or custom agents |
| The problem is that people cannot find information, not that nobody executes | A chatbot with an LLM over your knowledge base, the distinction I cover in chatbot or AI agent |
| Every case demands expert judgment and the person must keep it | A copilot that assists that person without taking the decision away, per the split I explain in copilot or AI agent |
| Nobody can explain why a given decision is made | Reconstruct the rule or remove it. That is business work, not technology work, and it comes first |
| Low volume, or you cannot say whether a case went well | Leave it where it is. Come back when there is volume or when a measure of the outcome exists |
Two rejections look alike and behave differently. Some processes will never be candidates because their nature does not call for it: the first three rows will still be better served by another tool even if their volume grows tenfold. Others are not candidates yet, because they lack a written rule, volume, or a way to measure the outcome. Those go back on the list, and they usually come back in better shape than the ones that qualified on the first pass. Confusing the two types is expensive in both directions. You force an agent where it is surplus, or you bury for good a process that only needed documentation.
There is a financial reason to put this routing in writing rather than leave it in the head of whoever ran the selection. The cost of picking the wrong process does not show up in the provider’s proposal. It shows up months later, in exceptions nobody mapped and in maintenance that does not pay off the work it saves, two of the line items I break down in what implementing AI agents costs. A reasoned, dated rejection is cheaper than a pilot that reaches production and should never have left the list.
How you map a process: four axes
Once the process is selected, mapping it means making it explicit along four axes. An agent executes what you define, so the quality of the map is the ceiling on the quality of the system.
Inputs. What the process receives and through which channel: an email, an order in the ERP, an attached document, a transcribed call. Include the real messy formats, not the ideal one. If 30% of orders arrive as a badly scanned PDF, that is an input of the process, not an exception.
Rules. The logic that turns the input into an outcome: what gets checked, what it is matched against, what decides the next step. This is where tacit knowledge surfaces. The proof that the map is complete is that a person from outside the department could follow the rules and reach the same result.
Exceptions. The cases that fall outside the rules, grouped and with their reason. For each one, a design decision: does the agent resolve it within widened rules, or escalate it to a person with the context prepared? This column is what separates a demo from an operation.
Outcome. What it means for the case to have ended well: the final state, the updated record, the issued document. And how it is checked. Without a precisely defined outcome you cannot build the evaluation on which the move to production depends: test cases with known answers, a quality threshold, and a review of failures.
That four-axis map is the first phase of turning the operating model into code, and the input for everything that comes after.
A hypothetical example: invoice matching at a distributor
Imagine an €80M distributor that receives around 4,000 supplier invoices a month. This is an invented example to illustrate the mapping, not a real case. I choose it because it meets the five criteria: high volume, known rules, groupable exceptions, a measurable outcome (matched or not) and direct proximity to margin.
- Inputs: invoices as PDFs by email, of variable quality, plus the corresponding order and delivery note in the ERP.
- Rules: check the invoice’s amount, quantities and references against the order and the delivery note, match and flag for payment within an agreed tolerance, and hold outside tolerance.
- Exceptions: invoices with no associated order, price differences within a margin negotiated with certain suppliers, partial deliveries invoiced in full, a supplier who invoices in another currency. Each group has a reason and a decision: the first three the agent can resolve with widened rules, and the currency one is escalated until the rule is defined.
- Outcome: invoice matched and flagged for payment, or held with the reason noted and, where appropriate, escalated to the right person.
Mapping this process seriously uncovers things before you touch any technology: that the “tolerance” was not written down anywhere, that two people applied it differently, and that 10% of the holds came from a single supplier with a special agreement nobody had documented. That finding alone justifies the exercise, agent or no agent.
From selection to map, and from map to implementation
Choosing well and mapping rigorously is what turns an automation idea into something you can deploy. The map tells you which permissions the agent needs, which exceptions have to be closed before production, and what the evaluation measures. Without it, the jump from pilot to production is made blind.
Even before mapping, it is worth checking that the house is prepared —accessible data and an owner with authority— which is what I review in prepare your company for agents. And the full ground of which processes operate with agents today, by function, is in AI agents in operations and in the pillar on AI agents for business.
Frequently Asked Questions
Which processes should be automated with AI first?
The ones that meet five conditions: enough volume, known rules, exceptions you can typify, a measurable outcome, and proximity to revenue, margin or service. Invoice matching, order tracking, patterned support cases or document-heavy back office tend to meet them. The more measurable the outcome, the better the first candidate.
How do I know if a process is too complex for an agent?
If every case demands fresh expert judgment, or if nobody can explain why a given decision is made, the process is not ready to be encoded. That does not always disqualify it: sometimes the first job is to reconstruct the rule or document the exception, and that exercise already adds value on its own.
What does mapping a process for automation involve?
Putting it in writing along four axes: the inputs it receives (in their real formats, not the ideal ones), the rules that govern it, the exceptions grouped with their reason, and the outcome that defines when a case ended well. That map is the raw material of the system: its quality sets the ceiling on what the agent can do.
If my process is not a candidate for an agent, what do I do with it?
Route it by the reason it failed. No exceptions, RPA or classic automation. Deterministic with systems that expose APIs, a visual automation tool. If what is missing is people finding information, a chatbot over your knowledge base. And if nobody can explain the rule, the prior job is reconstructing it, which is business work rather than technology work.
Can a process rejected today become a candidate later?
Yes, and it pays to tell it apart from the one that never will. A deterministic process with no exceptions will still be better served by another tool however much it grows. A process rejected for lack of volume, written rules or a measure of the outcome goes back on the list as soon as that is fixed, and it usually deploys better than the ones that qualified first time. Note the date of the rejection and the reason, so it gets revisited on merit rather than on persistence.
How long does it take to map a process?
For a bounded candidate process, weeks, not months. The time goes into making explicit the rules and exceptions that live in two or three people’s heads today. Trying to map the entire company at once turns a simple requirement into a yearlong program and defers the first test.