How to Calculate AI ROI Without Made-Up Numbers: A Practical Guide

How to Calculate AI ROI Without Made-Up Numbers: A Practical Guide

To calculate AI ROI, first measure the current process (volume, hours, rework and hourly cost), then list the real costs of building, running and maintaining the solution, and write down the assumptions that connect the two. The result only means something if you defined, before the pilot, what counts as a gain and how it will be observed. Without that, ROI is an attractive projection, not a basis for a decision.

Key takeaways

• Start from a measurement of the current process, not from the tool's promise. Without a baseline there is no gain, only opinion.
• Separate what was measured, what was estimated and what is an assumption. Every assumption needs an owner and a way to be tested.
• Costs go beyond the license or model usage: they include setup, human review, monitoring, maintenance and your own team's time.
• Define what counts as a gain before the pilot. Freed-up hours only become a financial gain if they are redirected or if they avoid a hire or a cost.
• The pilot exists to confirm or overturn the estimate, and the decision to expand, adjust or stop should be agreed from the start.

Why most AI ROI calculations do not hold up

The typical calculation in a sales presentation multiplies a number of supposedly saved hours by an hourly cost and subtracts the price of the tool. The problem is not the arithmetic, it is where the numbers come from. Time per task usually comes from memory or a generic average, and the savings come from an ideal case in which the AI is always right and nobody needs to check its work.

Three failures show up again and again. The first is having no baseline: nobody measured how much the process consumes today, so any result after the pilot looks like an improvement. The second is counting only the visible cost and ignoring review, error correction and maintenance. The third is treating freed-up hours as money saved, when the team still has the same payroll and the same headcount.

An honest estimate accepts being less impressive. It says: with these measurements, these costs and these assumptions, the expected result falls in this range, and the pilot will show whether the assumptions hold. That is what lets you decide calmly.

What to measure in the current process before talking about AI

Pick one specific workflow, not the whole company. Order status inquiries, request triage, proposal generation and record updates are examples of workflows with a clear start and end. A vague goal like improving sales produces no useful measurement.

For the chosen workflow, collect the following over a representative period:

• Volume: how many cases come in per week or per month, including seasonal swings.
• Time per case: actual working time, not the elapsed time between request and reply. Measure by sampling, with a stopwatch or a simple log, and note the spread between easy and hard cases.
• Who does it: the role and the hourly cost of the person doing the work, including payroll charges according to your finance team's method.
• Rework: how many cases come back, get corrected or trigger a complaint.
• Waiting bottlenecks: where the customer or the process sits idle because nobody has answered.
• Cases that require judgment: the ones that should never be automated without human approval.

If the company uses a CRM, a helpdesk or WhatsApp Business itself, some of this data already exists in reports. When it does not, a spreadsheet filled in for a few weeks does the job. When you measure people's work, explain the goal and measure the process, not the individual. For more on this, see how to measure AI productivity on your team without turning it into surveillance.

Which costs belong in the calculation

AI cost comes in layers, and forgetting one of them is the most common way to inflate ROI. List all of them, even those without a defined value yet, and mark which are quotes, which are estimates and which are unknown.

• Discovery and design: the time to map the process, set limits and write escalation rules.
• Implementation: development, integrations with your systems, channel setup such as the official WhatsApp API, and testing.
• Recurring use: model consumption, which depends on tokens, plus infrastructure, messaging and platform licenses.
• Human review: the time of the people who check answers, approve sensitive actions and handle exceptions. This cost exists even when the workflow runs well.
• Monitoring and maintenance: watching logs, adjusting instructions, updating the knowledge base and reacting to changes in the model or the channel.
• Compliance: LGPD analysis, defining a legal basis, a data retention policy and, where relevant, legal review.
• Cost of error: what a wrong answer costs in rework, refunds or lost trust.

When you compare against the human or outsourced alternative, apply the same cost criteria on both sides. The article on outsourced customer support vs AI and how to compare the real cost explains how to avoid comparing apples to oranges. The idea of unit cost, described on the FinOps Foundation's unit economics page, helps here: instead of looking at total spend, calculate the cost per resolved case and compare it with the cost per case in the current process.

What to count as a gain (and what to leave out)

Defining the gain before the pilot is the most important decision in the calculation, because it stops the result from being interpreted afterward to suit whoever is presenting it. Sort the possible gains into categories and choose which ones apply to this project.

• Avoided cost: a hire that was no longer needed, overtime that did not happen, an outsourcing contract that was reduced. This is the most solid gain because it shows up in cash.
• Redirected capacity: freed-up hours that the team now spends on higher-value work. Count them only if you name the activity and someone is accountable for it. Otherwise it is just idle time.
• Preserved or generated revenue: leads answered faster, quotes sent that previously slipped away. This requires an assumption about conversion, which must be measured in the pilot, never taken for granted.
• Quality and risk: fewer typing errors, fewer forgotten follow-ups, fewer complaints. Worth recording, but convert it to money only if you have a measured cost of error.
• Intangible benefits: team satisfaction, standardization, a history of decisions. List them separately and do not add them to financial ROI.

Leave out anything that cannot be verified. If nobody can say how you would know it happened, it does not go in the calculation. That one rule removes most inflated estimates.

How to build the formula with explicit assumptions

The structure is simple. The discipline is in writing down where each variable comes from.

• Monthly gain = workflow volume x share resolved without human intervention x average time per case x hourly cost, plus any other gains accepted in your definition.
• Monthly cost = recurring use + human review + monitoring and maintenance + the monthly share of the implementation investment.
• ROI for the period = (accumulated gain minus accumulated cost) divided by accumulated cost.

The weakest variable is the share resolved without human intervention, because it depends on the real quality of the agent. Treat it as the central assumption. Use a conservative, an expected and an optimistic scenario, and check whether the decision changes between them. If the project only pays off in the optimistic scenario, the risk is high.

Illustrative scenario (no real figures): a distributor receives many order status questions on WhatsApp. Measurement shows a monthly volume V, an average time T per inquiry and an hourly cost C. The assumption is that the agent resolves a share P of the inquiries by checking the order system and hands the rest to a person. Each handed-off inquiry still costs review time R. The gross gain is V x P x T x C, and from it you subtract the review cost and the recurring cost. If P fell by half, would the numbers still work? Asking that question before the pilot is worth more than the final number.

If the gain depends on the team using the freed-up time for another task, write down which task and who follows up on it. In businesses with recurring support, as the article on AI customer support and what to automate shows, the automatable share is usually clear for status and scheduling questions and smaller for complaints and negotiations.

Step by step: estimate before the pilot and decide after it

Use this sequence as a working checklist.

• Choose a single workflow with a start, an end and an owner.
• Measure the baseline: volume, time per case, rework and hourly cost, by sampling and with the spread recorded.
• Define what counts as a gain and what stays out, and put it in writing.
• List all costs, marking quote, estimate and unknown.
• Write the assumptions (resolved share, error rate, review time) and assign an owner to each one.
• Calculate three scenarios and identify in which one the project stops being worth it.
• Agree before the pilot on the decision criteria: which result leads to expanding, which to adjusting and which to stopping.
• Run the pilot with a record of every case, so you can compare what was measured with what was estimated.

This checklist follows the same method Juan Carlo uses in his work: map the process and the current baseline, limit the agent's data and actions, pilot one real workflow with logs and an agreed success metric, and hand the operation over to the team, then decide whether the project expands, adjusts or ends. If you want the full method, read how Juan Carlo works with companies.

During the pilot, quality has to be measured alongside time. An agent that answers fast and gets things wrong produces no gain. Anthropic's guidance on evaluating agents and the NIST AI risk management framework help define test cases, acceptance criteria and responsibilities. Record decisions, errors and escalations in logs, because they are what supports the final calculation. If the pilot contradicted an assumption, that is not a failure: it is the information the estimate existed to produce.

Frequently asked questions

How long does it take to measure the baseline? It depends on the workflow's volume and seasonality, but what matters is covering a period that represents normal routine, including peak days. In many cases a few weeks of simple logging is enough for a first estimate, which the pilot then refines.

Can I calculate ROI if the company has no data on the process? You can, but the result will only be an assumption and should be presented that way. The best first step is a short period of manual measurement, which on its own often reveals bottlenecks and rework nobody could see.

Do saved hours count as a financial gain? Only when they turn into avoided cost or into capacity used for a defined activity. If the freed-up time changes nothing in hiring, outsourcing, overtime or output, it is an operational benefit, useful, but it should not be added to the financial return.

What if the pilot's ROI comes in lower than estimated? Compare variable by variable: the resolved share, the review time and the actual volume show where the calculation diverged. From there, the decision is to adjust the scope, improve the agent or stop, according to the criteria agreed before the pilot. Stopping early, with the costs known, is also a legitimate result.

Sources

• FinOps Foundation: unit economics
• NIST AI Risk Management Framework
• Anthropic: Demystifying evals for AI agents