How do you measure the ROI of an AI project?

At some point the CFO, or the board, will ask whether the AI project worked. They'll mean whether the money came back, and if the answer is a feeling, the next project will be harder to approve than the first.

The arithmetic is simple. What makes it hard is that the measuring has to start before the build, and most projects start measuring after.

Choose one measure before anything is built

Every process has a number that tells you whether it's working. Invoice handling has hours a week, or the cost of processing one invoice. Support has time to first reply, or the share of tickets resolved without a second touch. Order entry has the time from an order email arriving to the order sitting in the ERP. Pick the number that would make the owner of the process say that's the point, and write it down with how you'll take it.

Pick one. With three measures, when one rises and another falls, the conversation turns to which one counts. With one, the conversation is about whether it moved. If a second number matters, make it a guardrail: time to first reply is the measure, and the share of replies a person had to rewrite is the number that must not get worse.

Take the reading before the change

This is the step most projects skip, and it's the one that makes the result provable. Before the system exists, take the measure the way you'll take it afterwards. If it's hours a week, ask the people doing the work to keep a tally for two or three weeks. If it's response time, pull the last couple of months from the ticketing tool or the shared inbox. If it's cost per invoice, divide the hours by the count.

The reading doesn't have to be precise. It has to be honest and repeatable. A rough tally kept by the team beats a precise figure nobody can reproduce. Write down how it was taken, so the comparison later isn't an argument about method.

What to count on each side

On the return side

• Hours the system took on. The time your people spent on the steps the system now runs, at what that time costs you. Then say what the hours went to instead, because a saving only counts if the time was used.
• Errors removed. Re-keyed data, missed follow-ups, invoices paid twice. Count the ones you can see in your records, at what each one cost to put right.
• Work that wasn't possible before. Every quote followed up, every order entered the same day it arrived. This is often the largest return and the hardest to count, so tie it to a number someone already tracks.
• The hire you didn't make. If the team handled more work without adding a person, that's a return, and it's the easiest one to explain to a CFO.

On the cost side

• The build, whatever it cost.
• Running costs: the services the system calls, the monitoring, and the person who maintains it. What decides the cost of an AI project? explains what drives each of these.
• Your team's time: describing the process, testing the cases and reviewing the output after launch. It's real and it's usually left out.

Take a system that removes fifteen hours of work a week but needs an hour of review every working day. Its return is a third smaller than the headline suggests. Count the review time, then work to bring it down as the team's trust grows.

A worked example

Take a hypothetical distributor of about four hundred people, where two people in finance type supplier invoices into the accounting system and chase the ones that don't match an order. The measure is hours a week on invoice handling. For three weeks before the build, both keep a tally at the end of each day. That gives a weekly figure and, divided by the number of invoices, a cost per invoice. Both are written down with the method.

After launch, the system reads each invoice, matches it to the order in the ERP and posts the ones that agree. The rest go to the finance controller. The same two people keep the same tally for the first month, now counting time spent on exceptions and on checking the system's work. The weekly figure drops, and the cost per invoice with it. The hours that came back went to chasing overdue customer payments, which the team had never had time for, and that work has its own number: days sales outstanding, which the controller already reports.

The report fits on one page: hours a week before and after, cost per invoice before and after, review time, running cost, and a line on what the hours went to. Nobody has to take anyone's word for it, because the before figure was taken the same way as the after.

Report on a rhythm

One reading after launch tells you about one week. Take the measure every month and put it next to the reading from before. The first month is usually noisy while the team adjusts. By the third, the trend is clear, and the trend is the result you report.

Keep the report to a page and give it a named owner. Producing it is part of operating the system, alongside watching the runs and fixing what changes. If the report takes longer to put together than the work it describes, automate the report too.

When the number doesn't move

Sometimes the measure stays flat. That tells you something, and there are three usual reasons. Most of the time was in the exceptions, and the system only handles the routine. The team kept doing the manual step alongside the system because they didn't trust it yet. Or the measure was never what the process was slow at.

Each has its own fix. If the time was in the exceptions, the next piece of work handles the most common one. If the team kept the manual step, set a date it stops and show them where the exceptions go; getting your team to use AI covers that. If the measure was wrong, pick the one that moved and take its reading now as a new baseline. A flat number read in the first month can save a project. The same number found after a year of nobody looking usually ends it.

What to do this week

1. For the process you're considering, write down the one measure and how you'd take it.
2. Start the reading now: begin the tally, or pull the report from the system.
3. List the costs you'd expect on both sides, including your team's time.
4. Decide how often you'll report and who will read it.

Get the next article when it's published.