What Does Real AI Agent ROI Look Like, Beyond The Vendor Case Study?

Last Updated: 30 October 2026

Real AI agent ROI looks like fewer hours per unit of work with an error rate you can defend. Not agent counts, not hours saved across a company, not a percentage improvement in a cycle. One workflow, one unit, one baseline, measured before and after. That is the only comparison that survives a board meeting.

The market is full of numbers that cannot be compared. UBS said in its third quarter results that employees are using more than 12,700 personal AI agents in their daily work, as PYMNTS reported. ElevenLabs says its internal agents save 1,200 hours a month across sales, support and engineering, according to Techgenyz. Procol says its agents cut manufacturing procurement cycles by 75%, as reported by Express Computer.

Each of those is interesting. None of them tells you what your business will get. One counts agents, which measures adoption. One counts hours, which measures effort but not output. One counts cycle time, which measures speed but not quality. This post covers what to baseline, how to build a calculation you can defend, which costs get left out, and how to present the result to a board that has heard too many demos.

What does real AI agent ROI look like?

It looks like a before and after on a single process, expressed in units the business already tracks. For an accounts team that is invoices processed per person per day. For a support team it is tickets resolved without escalation. For a sales team it is quotes issued per week. The metric has to exist before the agent arrives, or the comparison is a story rather than a measurement.

Four numbers make a complete picture: volume, handling time per item, error or rework rate, and end-to-end cycle time. Volume tells you whether the saving is material. Handling time tells you where the labour goes. Error rate tells you whether the agent is creating work downstream. Cycle time tells you whether the customer notices a difference.

Most vendor case studies report one of those four and imply the rest. That is why a 75% cycle time reduction can sit next to a 1,200 hour saving and a 12,700 agent rollout without any of them being comparable. They are measuring different things in different businesses with different baselines, and in most cases the baseline was never published.

Why are vendor case studies so hard to compare?

Because the unit of measurement is chosen after the result, not before it. A vendor that improved cycle time reports cycle time. A vendor that reduced headcount reports hours. A vendor that sold a lot of seats reports seats. Each is true, and each is selected because it is the most flattering true number available.

Take the UBS figure. More than 12,700 agents in daily use is an adoption statistic, and adoption is genuinely hard to achieve at a bank. It says nothing about hours saved, error rates or cost per transaction. It is a signal that the tooling is usable, which matters, but it is not a return.

The ElevenLabs figure is closer to a return, because hours are a cost. But hours saved across three functions is an aggregate, and aggregates hide distribution. If 80% of the saving comes from one function, the number tells you where to look, not what to expect. It also does not say whether the hours were redeployed or removed, which is the difference between a cost saving and a capacity gain.

The Procol figure is a cycle time claim, and cycle time is the easiest metric to improve and the hardest to monetise. A procurement cycle that finishes 75% faster only creates value if the business does something with the time, such as negotiating earlier or reducing stock holding. Faster for its own sake is a process improvement, not a return.

None of this means the vendors are wrong. It means the numbers are not transferable. The useful question is not "what did they get" but "what did they measure, and can I measure the same thing here".

What should you baseline before you automate?

Baseline the workflow for two weeks before an agent touches it. Two weeks is long enough to catch the weekly rhythm and short enough that people do not game it. Record volume per day, handling time per item, rework rate and cycle time. If the process is already measured, use the existing data, but check that the definitions match what you are about to change.

The handling time definition matters more than people expect. If the team's time recording includes waiting for a manager's approval, you will attribute approval delay to the agent's work and overstate the saving. Measure touch time and cycle time separately, because an agent usually compresses touch time and leaves approvals untouched.

Rework is the number most pilots ignore. An agent that drafts 70% of items but creates a 15% rework rate has not saved 70% of the effort. It has moved effort from doing to correcting, which is slower per item and worse for morale. Track rework from day one, or the saving will look better in month one than it does in month six.

Write the baseline down and get it signed by the person who owns the process. That signature is what makes the post-implementation comparison credible. Without it, the pilot's sponsor and the finance team will disagree about what changed, and the business case dies in a meeting about definitions.

What does a defensible calculation look like?

Here is one, using a mid-sized accounts-payable team. The team processes 1,200 invoices a month at an average of 8 minutes of touch time each. That is 9,600 minutes, or 160 hours a month. Assume the agent drafts 70% of invoices correctly on the first pass, so a person checks each one for a minute. The other 30% are handled as they are today.

The arithmetic: 840 invoices at one minute is 840 minutes, or 14 hours. The remaining 360 at 8 minutes is 2,880 minutes, or 48 hours. Total touch time becomes 62 hours instead of 160, a saving of 98 hours a month. That is our arithmetic on an illustrative process, not a vendor claim, and it is the shape of calculation a finance team can check line by line.

Notice what the calculation does not do. It does not claim the team shrinks by 61%. It claims 98 hours a month of capacity, which the business can redeploy, absorb into growth or, if volume is falling, remove. Those are three different financial outcomes from the same operational saving, and the choice belongs to the business, not the vendor.

It also does not include the cost side yet. The agent needs oversight, an integration to the invoice system, an evaluation set and someone who owns it. Those costs are recurring, and leaving them out is how a pilot looks profitable for one quarter and then quietly stops being reported.

Which costs do teams leave out?

Four, and all of them recur. The first is oversight: someone has to review exceptions, check the eval set and decide when the agent's behaviour has drifted. Budget half a day a week for a single workflow, and more if the agent touches money. The second is integration: the agent needs access to the invoice system, the purchase order system and the payment batch, and those connections break when any of them is upgraded.

The third is evaluation. An eval set of fifty real cases takes a day to build and an hour a month to maintain, and it is the only thing that tells you whether a model upgrade helped or hurt. Teams that skip it end up tuning prompts by vibes, which is expensive in a way that never appears on an invoice.

The fourth is drift. Models change, data changes, and the business changes its own rules. An agent that was 70% accurate in March is not automatically 70% accurate in September. Without a monthly check against the eval set, you will discover the drift through an error, not a dashboard.

Add those up honestly and a workflow that looked like a 98 hour saving may be a 70 hour saving after oversight and maintenance. That is still a good return. It is just a smaller one, and it is the one you should put in front of a board.

How long before an agent pays back?

Longer than the pilot suggests, and the curve is predictable. Month one is usually the best month, because the easy items dominate and the team is paying attention. Months two and three are when the exception rate settles and the oversight cost shows up. Month four onwards is the steady state, and that is the number to use in a business case.

A reasonable planning assumption is that steady-state accuracy is a few points below pilot accuracy, oversight is higher than planned, and integration work is a one-off that takes longer than the vendor estimates. None of those assumptions require pessimism. They require a business case that survives being wrong by 20%.

The payback period itself depends on whether you are counting capacity or cash. If the saved hours are redeployed into growth, the payback is an opportunity cost and hard to prove. If the saved hours remove a contractor or defer a hire, the payback is cash and easy to prove. Be explicit about which one you are claiming, because a board will ask.

What does this mean for an Australian mid-market buyer?

Australian mid-market businesses usually have two constraints that shape the maths. The first is that labour is expensive, so an hour saved is worth more than in many other markets, which makes automation economics better than they look on a vendor's global slide. The second is that teams are small, so the oversight cost is proportionally larger, because the same person who owns the process also owns the agent.

That second point is the one to plan for. A 20-person finance team cannot absorb half a day a week of agent oversight without taking it from somewhere. Either the agent is reliable enough that oversight is genuinely light, or the business needs to fund a part-time owner. Both are legitimate. Pretending oversight is free is not.

There is also a data custody angle that affects cost. If the agent runs locally, the marginal cost per invoice is effectively zero and the data stays in the building. If it runs on a per-token API, cost scales with volume, and a busy month costs more than a quiet one. For a workflow with predictable volume, either model works. For one with spiky volume, the fixed local cost is easier to budget.

How do you present it to a board?

One page, four numbers and a decision. The four numbers are baseline hours, post-automation hours, steady-state error rate and the recurring cost of ownership. The decision is whether to scale, hold or stop. Anything else on the page is context, and context is what people argue about when the numbers are weak.

Put the unit of work at the top. "We process 1,200 invoices a month at 8 minutes each" is a sentence a board can follow. "We deployed 40 agents" is not. The first invites a question about throughput. The second invites a question about what an agent is.

Then state the assumption you are least sure about, explicitly. If the straight-through rate is the risk, say so and show the sensitivity: at 50% instead of 70%, the saving is 62 hours instead of 98. A business case that shows its own downside is more credible than one that only shows the upside, and it survives the first month of real data.

If you want help building the baseline and the calculation for a real workflow, our post on designing an agent around a real pipeline covers the scoping side. If you have a process you suspect is worth automating and want the numbers tested before you commit, talk to us.

Frequently asked questions

What is a realistic ROI for an AI agent?

It depends on the workflow, but a defensible case starts with a measured baseline. In our accounts-payable example, a 70% straight-through rate reduced 160 hours of monthly touch time to 62. After oversight and maintenance, the realistic saving was closer to 70 hours a month.

Why are vendor case studies unreliable?

Because the unit of measurement is chosen after the result. Agent counts measure adoption, hours measure effort and cycle time measures speed. None of them are comparable across businesses, and the baseline is rarely published.

What should I measure before deploying an agent?

Volume per day, touch time per item, rework rate and end-to-end cycle time, measured for two weeks before the agent arrives and signed off by the process owner. Measure touch time and cycle time separately, because agents compress touch time but leave approvals untouched.

What costs do AI agent business cases usually miss?

Oversight and exception handling, integration maintenance, an evaluation set and model drift. Each is recurring, and together they can reduce a headline saving by 20% to 30%. A business case that includes them is more credible and more likely to survive month four.

How long does an AI agent take to pay back?

Month one is usually the best month because easy items dominate. The steady state arrives around month four, once exception rates and oversight costs settle. Plan for steady-state accuracy a few points below pilot accuracy and oversight higher than planned.