AI process automation: where to actually start

AI process automation gets sold like a light switch: flip it and your company starts running itself. In practice it's the opposite of a switch. It's plumbing work: understanding how information actually moves between people and systems today, finding the places where it gets stuck, and replacing those stretches with something that runs without constant supervision. The interesting part is that this work, done well, pays for itself in months. Done badly, it produces a nice-looking pilot nobody uses after sixty days.

This guide is what we tell a management team that asks where to start: which processes are genuine candidates, how to estimate the return before spending anything, how a project that reaches production is structured, and which mistakes nearly every company makes on the first attempt.

What is AI process automation, really?

Automating a process has always been possible. What AI changes is which kinds of steps can be automated. Until recently, an automated flow could only handle structured information and explicit rules: if field A is greater than 100, send email B. Everything else — reading a scanned delivery note, understanding an email from an angry customer, deciding whether two records are the same company spelled two different ways — needed a person.

AI doesn't replace classic automation; it adds layers that used to be impossible:

• Understanding documents and free text. Invoices, contracts, emails, work orders, scanned PDFs. Pulling reliable data out of those is machine work now.
• Classification with fuzzy criteria. Routing a ticket to the right team, detecting the tone of a complaint, prioritising leads by what they actually say rather than the industry they ticked on a form.
• Drafting. Replies, summaries, reports, proposals. The machine drafts, a person reviews and signs.
• Chained intermediate decisions. This is where AI agents come in, executing several steps in sequence while querying systems along the way.

A useful mental rule: classic automation solves the steps where the answer is always the same; AI solves the steps where the answer depends on interpreting something. Almost every real process mixes both, and the projects that work use both tools, not just one.

Which processes should you automate first?

The criterion isn't "which one hurts most" or "which one sounds most innovative". It's the combination of volume, repetitiveness and tolerance for error. A process that happens 400 times a month, always the same way, where a mistake is easy to catch and correct, is the best first candidate even if it isn't the one generating noise in meetings.

This matrix helps rank candidates in a one-hour session:

| Type of process | Volume | Cost of an error | Priority | |---|---|---|---| | Supplier invoice entry | High | Low (reviewed before payment) | Start here | | Classifying and routing inbound email | High | Low | Start here | | First-level customer replies | High | Medium | Second wave, with human review | | Recurring internal reporting | Medium | Low | Second wave | | Bank and accounting reconciliation | Medium | Medium | Second wave | | Credit or pricing decisions | Low | High | Assist, don't automate | | Final legal or contractual communication | Low | High | Don't automate |

The three starting points that work best in mid-sized companies, in order of how often we see them:

1. Document capture into the ERP. Invoices, delivery notes and orders that someone types in today. It's the most measurable case there is: minutes per document, multiplied by documents per month. 2. Triaging the operational inbox. The generic mailbox where orders, incidents, questions and spam all land together, and someone spends two hours a day distributing them. 3. Preparing reports that get rebuilt every week. Someone exports, pastes, formats and sends. That someone is usually expensive and could be doing something else.

If nobody can describe the process you want to automate from start to finish, the problem isn't technology yet. It's the process.

How do you calculate the ROI of an automated process?

This is where most proposals turn to smoke. The honest way to estimate the return is boring and it works:

1. Measure the current state with data, not impressions. How many times a month the process happens, how many minutes each occurrence takes, how many people touch it. Two weeks of measurement is enough. 2. Estimate the share the machine can realistically take on. It's almost never 100%. A good document capture project automates 80–90% of cases and leaves the rest to a person; that number is already excellent. 3. Add the cost of running the automation. Licences, model consumption, maintenance, and the time of whoever reviews the exceptions. Ignoring this line is what turns a laboratory ROI into a disappointment. 4. Count the non-salary benefits. Fewer errors reaching the customer, faster month-end close, quicker responses, information available for decisions. They don't always convert into direct euros, but they do convert. 5. Set the break-even point before you start. "This project pays for itself if we reach X documents processed without intervention within Y months." In writing. Beforehand.

Here's what the calculation looks like with round, illustrative numbers, purely to show the structure: 600 invoices a month × 6 minutes of handling = 60 hours monthly. If automation covers 85% and leaves 9 hours of exception review, the gross saving is 51 hours a month. Subtract the monthly cost of running the system. What's left, divided by the implementation cost, gives you the months to break even. If your provider can't build this table with you, they haven't understood your process.

Which mistakes burn the most budget?

The same ones, over and over, regardless of sector:

• Automating a broken process. Automation amplifies whatever is already there. If the current process has three unnecessary approvals, automating it gives you three very fast unnecessary approvals. Simplify first, automate second.
• Starting with the hardest case to "prove the value". The hard case eats six months and produces doubt. The easy case produces a win in six weeks and funds the next conversation.
• Confusing a pilot with production. A pilot that works on 20 cases hand-picked by the team says nothing about 2,000 real ones. It's one of the main reasons AI pilots fail.
• Not designing the exception path. The 10–15% of cases the machine can't resolve need a clear destination, a responsible person and a deadline. Without that, exceptions pile up quietly until someone finds out too late.
• Forgetting who maintains the system. Formats change, suppliers change their templates, systems get updated. An automation with no owner degrades within months.
• Not measuring afterwards. Surprisingly common: everything gets measured precisely to justify the investment, and never measured again once it's live.

How is a project that reaches production structured?

A sensible AI process automation project fits into roughly eight to twelve weeks for the first process. These are the phases and what should come out of each:

| Phase | Typical duration | What comes out of it | |---|---|---| | Mapping and measurement | 1–2 weeks | Documented process, real volumes, agreed break-even point | | Solution design | 1 week | What the machine automates, what stays with the person, exception path | | Build and integration | 3–5 weeks | Flow running against the real systems, not against a copy | | Parallel run | 2–3 weeks | Machine and person doing the same work, comparing results | | Go live | 1 week | Cutover, team training, monitoring dashboard | | Follow-up | Ongoing | Monthly metrics, adjustments, next candidate process |

The phase almost everyone skips is the parallel run, and it's the one that decides whether the project survives. For two or three weeks the work is done twice and results are compared case by case. It's uncomfortable, it costs hours, and it's the only way to know the real accuracy rate before the system has consequences.

What shouldn't you automate yet?

Some processes deserve the answer "assist, don't automate": the machine prepares and proposes, the person decides and signs.

• Decisions with high, irreversible legal or financial consequences.
• Processes where the exception is the norm and every case differs from the last.
• Work that depends on context written down nowhere, existing only in two people's heads.
• Any process involving sensitive personal data where it's still unclear where it gets processed and under what safeguards. That gets resolved first, not later.
• Processes about to change completely within six months for a business reason you already know about.

Choosing not to automate something isn't a defeat. It's the decision that protects the budget for the processes where automation does work.

Frequently asked questions

How long does it take to see a return on AI process automation? For high-volume, low-risk processes — document capture, email triage, recurring reports — break-even usually lands between three and nine months, depending on real volume and implementation cost. What you should never accept is a promised return with no prior measurement of your current process.

Do your data need to be in order before automating? To automate one specific process, you don't need a full data project first. You do need the systems involved in that process to be accessible and the incoming information to be consistent. When the goal is analytics or decision-making, the bar for data quality rises considerably.

Can you automate without an internal technical team? Yes, and that's the norm in mid-sized companies. What you can't do is automate without an internal process owner: someone who knows the flow, validates the criteria and decides on exceptions. That role can't be outsourced, even if the build can.

What happens to the jobs affected? What we see in practice is reallocation, not reduction: the freed-up hours go to work that was pending or that nobody was doing for lack of time. It's worth saying this to the team clearly before starting, because an automation project the team perceives as a threat meets resistance at every phase.

The honest summary

AI process automation isn't a leap of faith or a trend you need to join before understanding it. It's an exercise in prioritisation: pick two or three measurable processes, do them properly, measure the result, and use that win to fund the next one. Companies that work this way accumulate advantage in a boring, steady fashion. The ones that start with the most spectacular case usually end up with a demo and an invoice.

If you want to know which processes in your company are genuine candidates before committing budget, the audit maps exactly that: processes, volumes and priority, with judgement and without selling you anything. And if you already have a specific process in mind and want a second opinion, let's talk.