AI Automation ROI: The Only Three Numbers That Matter

Everyone has an ROI slide. Nobody has a baseline.

Ask a vendor for AI automation ROI and you'll get a calculator with a suspiciously smooth slider. Ask a buyer six months after deployment and you'll often get a shrug: "it feels faster?" Both failures have the same root, nobody measured the before.

ROI isn't a projection problem. It's a measurement discipline, and it needs exactly three numbers.

Number one: the baseline burn

Before anything is built, count the process as it exists: items per month × minutes per item × loaded hourly cost. Not the optimistic version, follow a real invoice, a real order, a real ticket through a real week, including the interruptions and the chase-ups.

This number does two jobs. It tells you whether to automate at all, the working thresholds: 60+ hours a month typically pays back within 6–12 months; under 20 hours, don't build custom. And it's the denominator every later claim gets checked against. No baseline, no ROI, just vibes with a dashboard.

Number two: the zero-touch rate

After deployment, resist the vanity metrics ("AI handled 10,000 documents!") and track one thing: the share of items completed with no human involvement. The zero-touch rate is unfakeable, an item either needed a person or it didn't, and its trend is the health of the whole system. Rising means the validation rules and exception queue are learning; flat means the automation stopped improving; falling means something upstream changed and nobody noticed.

Pair it with where the touched items go: a review queue where a person spends five seconds approving a pre-filled record is still a massive win over three minutes of keying. Count recovered minutes, not just untouched items.

Number three: payback months

Now the division everyone skips the honest version of:

Payback months = total setup cost ÷ (monthly burn recovered − monthly running cost)

The trick is what goes in each term. Setup includes your team's workshop and testing hours, and the integration surprises, legacy systems are where budgets go to grow. Running cost is not the LLM bill (that's cents per document, tens of euros for a thousand); it's hosting, monitoring and the humans reviewing the exception queue. And "burn recovered" is measured, not projected: baseline minus what the process costs now.

Run the formula quarterly. An automation that paid back in month eight and keeps compounding is a different conversation with your CFO than a slide from before the project.

What the three numbers won't capture

Some value resists the formula and deserves a sentence, not a spreadsheet: errors that stopped happening, the after-hours orders that used to walk away, the invoices chased on day one instead of day 45, the key person who's no longer the only one who knows the process. Real, but keep it out of the payback math, mixing it in is how vendor calculators lie.

The takeaway

Measure the burn before, the zero-touch rate after, and the payback months honestly, everything else is decoration. Set the zero-touch threshold in writing before the pilot starts, that single habit is most of what separates pilots that reach production from the 80% that don't. First step of every engagement we run is the baseline; bring a process and we'll count it with you.

For nonprofits the arithmetic is different but the logic is the same: the constraint is a small team carrying the admin of an organisation twice its size, and the payback shows up in hours returned rather than headcount avoided.