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.
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.
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.