Which Business Processes Should I Automate First With AI?

Automate the process that is high volume, rule-based, and already measured, in that order. In practice that means support ticket triage, invoice and expense processing, lead qualification and routing, or recurring reporting, because each one runs hundreds of times a month, follows a policy someone can write down in a page, and already carries a number you can use to prove the agent worked. Leave anything that needs judgement, negotiation, or a legal signature until you have one agent live in production for 90 days. The first process is not the one that impresses the board. It is the one boring enough to get right.

Why CEOs get this wrong

The common mistake is starting with the hardest process because it is the one that hurts most. A CEO looks at the org chart, spots the bottleneck that costs the company real money, and points the first AI project straight at it. That process is usually the one with the most exceptions, the least documentation, and the most senior people defending it. Six months later the pilot is dead and the company concludes AI does not work here.

The numbers back that up. Somewhere between 70 and 80 percent of corporate AI pilots never reach production, and the reason is almost never model quality. It is scope. I have watched a 120 person company burn nine months and about 400,000 US dollars trying to automate contract review, a process with 40 edge cases and a general counsel who was never going to accept an agent output without reading it anyway. The same team automated invoice coding in seven weeks and got back 60 hours a month on the first try.

The framework I use with clients

Five steps. Run every candidate process through them before anyone writes a line of code.

1. Count the runs. Only consider a process that executes at least 200 times a month. Below that, the build cost never clears the saving and you are automating for the story. Pull the count from your helpdesk, your accounting system, or your CRM, not from a manager estimate, because estimates run 2 to 3 times high.
2. Test whether the rules fit on one page. Ask the person who does the work to write the decision rules down. If it takes more than a page, or if they answer more than 3 questions with it depends, the process is judgement work and belongs in phase two. One page means an agent can follow it and you can test it.
3. Check the data is already reachable. The agent needs read and write access through an API to every system in the loop. If the process touches a spreadsheet on someone laptop or a legacy system with no API, fix that first or pick a different process. Access, not intelligence, is what stalls 8 out of 10 builds I inherit.
4. Set the baseline before you build. Three numbers: runs per month, minutes per run, error rate today. Without them you cannot prove the agent worked, and an unproven agent gets cut in the next budget round. Write the three numbers in the project brief and get the process owner to sign it.
5. Run it in shadow mode for two weeks. The agent proposes, a human approves, and you log every disagreement. When the agreement rate holds above 95 percent for 10 straight working days, cut over and keep the human on exceptions only. Skipping this step is how a company ends up rolling back in week three with the team convinced the whole idea was wrong.

From my operating seat

I run finance and operations for companies as a fractional CFO, and the first agent I build is nearly always in my own function, because that is where the numbers are cleanest. At one client we started with invoice coding: 1,400 invoices a month, about 3 minutes each, a coding error rate near 6 percent. The agent went live in seven weeks, took the error rate under 1 percent, and gave the finance team back roughly 70 hours a month. That saving paid for the next two agents, which is the real reason to start small. The first one funds the programme.

When I sold my last company, the thing a buyer probed hardest was not the tooling, it was whether the process still ran when a key person left. Agents built on documented rules survive that question. Agents built on one person tribal knowledge do not, and they get discounted in diligence along with everything else that walks out the door. So I write the rules down first and build second, every time. Slower in week one, far cheaper by month six.

How do I measure ROI on an AI agent?

Hours removed times fully loaded hourly cost, minus build and running cost, over 12 months. Baseline the process first: runs per month, minutes per run, error rate. A triage agent handling 2,000 tickets a month at 4 minutes each takes out about 133 hours, roughly 5,300 US dollars a month at a 40 dollar loaded rate. Set that against a 25,000 dollar build and 800 dollars a month in tokens and tooling and it pays back in about 6 months. If you cannot state the baseline in one sentence, you are not ready to build.

Should I buy an AI tool or build my own agent?

Buy when the process is generic and a vendor already sees more of it than you ever will: meeting notes, transcription, code assistance, most CRM enrichment. Build when the process runs on your own data, your own policies, and your own systems, because that is where a vendor cannot match you and where the advantage compounds. Buy the commodity, build the moat. A 40 person company should be paying for 6 to 10 tools and building 1 or 2 agents, not the reverse.

How long does it take to get an AI agent into production?

Six to ten weeks for a first agent on a well-scoped process, assuming the data is already reachable. Two weeks to document the process and set the baseline, three to four weeks to build and test against historical cases, two weeks in shadow mode, then a staged cutover. Teams that skip shadow mode ship faster and roll back more often. The delay is almost never the model. It is access to the systems the agent has to read and write.

About this article: Written by Hayat Amin, fractional CFO, AI agent operator, and IP & data strategist with three exits. Last updated 2026-07-24.