How to Measure ROI from AI Implementation: A Realistic Framework

In the press and at conferences, you periodically hear claims like this: some company implemented AI and saved or earned colossal amounts — anywhere from tens of percent to multiple-fold growth. I've read claims like this many times, but I have never once seen anyone show how exactly that number was calculated.

I've been implementing AI and developing complex, high-load IT systems for about 25 years, and I know that claims like this deserve careful scrutiny. Here's why.

When I see a number like that, the question that immediately comes to mind is: did they account for infrastructure? How much will you pay Amazon, Google, or Microsoft for cloud per month, or how much will your own servers cost? How much will model training cost? How much data will that require, and how much time and money will go into preparing that data the right way?

I have never once seen things like this included in the calculations, and yet this is a significant part of the cost of implementation.

Implementing AI and getting ROI are not the same thing. There is no direct link between these two events unless someone has calculated everything in advance and factored all the critically important components into the project's economics.

The AI ROI calculation itself comes down to three specific numbers: how much the process costs right now, what its real improvement potential is, and how much it will cost to develop, implement, and operate the solution. Without any one of the three, this isn't a forecast - it's a lottery.

The AI ROI calculation rests on three numbers. If even one is missing, it's already fantasy.

The first number is how much the process costs right now. The second is what its real improvement potential is, without optimistic assumptions. The third is how much implementation will cost.

Let's take a very simple, illustrative example. Say some all-inclusive hotel chain has 100 hotels in its network, and each hotel throws away, say, 70 kilograms of food per day that guests didn't eat—and that's a very optimistic estimate.

And this figure is still not exact, because it must also include the cost of food waste disposal and the energy spent on preparing the discarded dishes. Only after that data is added do we arrive at the first number with precision.

The next step is to understand the true potential to reduce those losses. The point is not to assume that “we will optimize everything," but to identify what can actually be controlled in all-inclusive hotel restaurants and how those losses might be reduced. Should the analysis account for guest demographics? Track which dishes are ordered most often? Survey guests at check-in? Measure how much is discarded and use that data to optimize the menu? There may be many possible approaches, and in some cases the right answer will be a combination of several, while in others it will be a focused bet on one.

Only then can you move on to calculating the third number. At that stage, you need at least a high-level understanding of how the system will be structured, along with a rough estimate of infrastructure costs.

The ROI calculators I encounter most often begin by asking what industry a business operates in, perhaps request a few figures, and then produce opaque, industry-wide benchmarks—usually scraped from the internet by an LLM, with at best a few calculations layered on top. Not a single question about the specifics of the business, not a single request for the metrics that actually matter. Just averaged data, pulled out of thin air, so to speak. That is not a reliable basis for forecasting.

The unit economics of a premium restaurant, a fast-food chain, and a delivery-only dark kitchen are fundamentally different. In practice, nearly everything differs: cost structure, production intensity, food cost, payroll. And each format has its own bottleneck: for one, the volume of waste; for another, the speed of production and order processing.

The conclusion is straightforward. The potential ROI from investing in AI solutions can only be calculated with real precision after a deep, business-specific analysis grounded in each company’s own indicators. And for the most accurate estimate, the right approach is to build a prototype of the chosen solution, measure its results, and then decide how to move forward—refining the numbers before full-scale implementation.

The most common mistake in ROI calculations is misjudging the cost of implementation.

Companies treat this superficially: they estimate roughly the cost of development itself and an approximate infrastructure cost, but factor in only superficially — or not at all — things like model training, data preparation, staff training, scaling the system across multiple locations (where applicable), and the time needed to roll out the system.

The second common mistake: being overly optimistic about the potential for improvement, especially when there hasn't been a prototyping stage to test the ideas and measure real-world numbers.

Many people look at the task with excessive optimism, and then are equally surprised when the numbers turn out to be several times more modest in practice.

Very often the projected figures diverge sharply from practice, and before spending money on development and implementation, the correct approach is to run deep calculations and modeling, develop prototypes of several solution variants, run testing and data collection, run the analysis and modeling again, and only after that make decisions about allocating significant budgets for development and implementation. In large companies with many locations, as in the example of all-inclusive hotel restaurants, the cost of implementing, maintaining, and operating various solutions can become a significant expense line, directly affecting the solution's payback and economic efficiency. There are other expense items that companies systematically omit from the ROI calculation—more on those separately.

Even a correct calculation doesn't guarantee the numbers will hold up after launch. On paper, you're calculating the process as it looks before anyone has actually gone through it. But as soon as the system is rolled out in practice, things surface that weren't visible at the calculation stage: process changes, retraining the team, who deploys the solution on-site, and how it's deployed.

It's not a matter of the quality of the calculation. It's that some of the variables can only be known in practice. And every case in business is unique, so success on dozens of other projects tells you nothing about how a new one will go. Nobody knows in advance how a team will actually integrate a new process into their work, how long retraining will take, what will go wrong during rollout, and what adjustments will be needed during operation. All of this only shows up after launch.

The payback of an AI implementation—or of implementing any new IT system—can never be expressed as a single number, and that's not a sign of incompetence. Behind it lie real uncertainties: there are too many unknowns and variables in the equation, and they change over time.

Today, a material costs one price; in two months, it's up 50%, or three times as expensive. We calculated the savings at raw material price X. If the price changes, all the calculations look different too. For example, we learned to save on raw materials, and then the material became 20% more expensive, so the savings became even more significant. If, on the other hand, it got cheaper, it might turn out that the implementation cost wasn't worth it. The same goes for new expenses. For example, the average market pay for the staff involved in the process increases, and the savings no longer seem as compelling.

That's exactly why payback is always a range — a low, medium, and high scenario. Not a single number that a vendor neatly presents on a slide.

If a calculator or a vendor gives you exactly one number, that's a clear signal of a lack of data behind the calculation.

You need to get the first number: how much the process costs right now. Most often, a company already has this; it's just scattered across different reports.

Second, you need to assess the potential for improvement. Assess it honestly and without inflating it, based on what can realistically be changed in the process — not on wishes.

Third, the cost of implementation at the start can only be estimated approximately, but even a high-level estimate of the system architecture, the equipment and servers needed, model training, and staff already provides a reasonably accurate figure.

If a company doesn't have precise data on the current cost of the process, that's not a reason to stop. Gathering that data is the first step, and it can be done in parallel with developing a prototype: a small pilot on a limited part of the process shows whether the idea itself works, even before the full economics have been calculated. From there, run the next round of calculations and modeling based on the prototype.

We specifically designed our ROI calculator so that it doesn't calculate or invent numbers on its own, but takes real data, supplements it with information using an LLM, and then performs a calculation as close as possible to the specific business.

Payback from AI implementation doesn't happen on its own. ROI comes down to three numbers: how much the process costs right now, what its real improvement potential is, and how much implementation will cost. Without one of the three, it's not an ROI calculation — it's a guess. What's more, the most accurate calculations can only be obtained after developing a prototype of the solution, collecting real data, and refining the calculations.

Calculate your three numbers. If you don't have the data for that yet, start with a small pilot on one part of the process - it will show whether the idea itself works, even before ROI has been fully calculated.