Calculating the return on investment of an AI project, before and after

Why calculate before you start

AI projects are often decided on an impression. A successful demo, a competitor making announcements, an overloaded team asking for help. These signals are real, but they do not tell you whether the project will return more than it costs. Calculating the return on investment settles that question before a budget is committed, and checks after go-live that the answer held.

The calculation is not sophisticated. It mostly demands honesty on two points AI projects tend to gloss over: the costs that continue after delivery, and the human time still needed once the tool is in place. This article sets out the method we follow, item by item, with a numerical illustration presented as such. For an example applied to a sales team, our article on the sales FDE versus RevOps already walks through a full calculation, so we do not repeat it here.

Ask the right question before counting

An ROI calculation answers a specific decision. Before opening a spreadsheet, write the decision in one sentence: "should we automate drafting replies to written customer requests?", "should we build a tool that sorts supporting documents for accounting?". A vague question produces a vague calculation, because nobody knows which costs and gains to include.

Then state the alternative. The project is always compared with something: changing nothing, hiring, configuring an existing tool, or using an off-the-shelf connector. The ROI of an AI project only makes sense against that alternative. If a simple setting in your current software solves half the problem, that setting is the benchmark, and the AI project has to beat it.

Full costs, item by item

Most estimates only include the build cost. It is the most visible, and often not the heaviest over time. We count four families of cost.

Build

This covers scoping, design, development, integration with existing tools and testing. Integration is the most underestimated item: plugging into a clean API is quick, plugging into manual exports or data scattered across several applications is real work. Our article on what an AI agent costs in production details these items and the questions to ask before pricing.

Add your own teams' time. The people who explain their work, supply examples, test early versions and validate the rules are not doing something else meanwhile. That internal time is a real cost, even though it appears on no invoice.

Operations

A tool in production has to be hosted, monitored, backed up and updated. The software it depends on evolves, language models are replaced by new versions, business rules change. Plan a recurring maintenance budget, even a modest one, rather than discovering this item at the first incident.

Consumption

Every call to a language model is billed on usage. At Anthropic, for instance, the published price list bills per million tokens, with one rate for the text sent to the model and another for the text it produces, output being the more expensive. The same list states that batch processing, for tasks that do not need an immediate answer, halves the token price, and that caching repeated instructions sharply reduces the cost of subsequent reads. These technical choices change the bill for the same project. Consumption cost is therefore calculated per operation, then multiplied by the expected volume, including the case where volume doubles.

Uncontrolled consumption is in fact one of the ten risks listed by OWASP for applications built on language models. A spending cap and per-operation tracking are part of the project, just like the code. Our CADRE framework for managing AI costs describes how to organise that tracking.

Human review time

This is the item almost every calculation forgets, and the one that most often sinks a project on paper. It deserves its own section.

Review time, the forgotten cost

An AI tool almost never makes a task fully automatic. It prepares, proposes, sorts or summarises, and a person reviews before the result goes out. That review takes time, and the time must be deducted from the gain. A draft reply that needs as many corrections as writing it yourself returns nothing.

Three questions help estimate this item. What share of cases does the tool handle correctly with no edits? How long does reviewing a correct case take, and correcting a flawed one? What share of cases can the tool not handle at all, sending them back to the manual process?

On top of that comes supervision: regularly reviewing a sample of outputs, spotting drift, updating the instructions when the business changes. This work is recurring, and it falls to someone who knows the business well, whose time is therefore valuable.

Some tasks require systematic review, whatever the tool's success rate. Anything that commits the company, a price, a lead time, a contractual reference, must be calculated by the system from your data and checked, never produced freely by the model. We explain why in why an AI agent must never quote a price. That check has a cost, and it gets counted.

Gains to count, and how to express them

The gains from an AI project fall into four families. They are not all measured with the same precision, and that is normal. What matters is stating, for each one, how it is measured.

Time returned

This is the most common gain and the easiest to measure: time spent on a task before, minus time spent after, review included. It is valued at the loaded hourly cost of the people concerned. One caveat matters: that time only has value if it is redeployed. If freed time is assigned to nothing, the gain stays theoretical. Write down what it will be used for: handling more requests, cutting overtime, absorbing growth without hiring, spending more time on complex cases.

Errors avoided

A re-entry avoided is also a typo avoided. An automatic consistency check is an incorrect invoice that never goes out. This gain is measured by counting errors before and after, then estimating what one error costs: time to fix it, a credit note, an unhappy customer. When that unit cost is hard to establish, keep at least the number of errors as an indicator.

Shorter lead times

Answering a request faster, sending a proposal the same day, closing an accounting month earlier. These gains are measured as the duration between two dated events, for instance between receiving a request and sending the reply. Their financial value is indirect, but it can be discussed with the business: does a faster reply change the conversion rate, satisfaction, cash flow?

Revenue

Some projects create revenue: more requests handled, follow-ups that no longer slip, a new service for customers. It is the most attractive gain and the hardest to attribute, because other factors affect sales at the same time. Present it separately, with caution, and never base the decision on it alone.

Measure before: the baseline

Without a starting measurement, no ROI can be verified. The baseline describes the current situation with recorded figures, not estimates from memory.

• Volume. How often does the task occur per day, week, month? Your tools' logs, the mailbox or the management software often provide this figure.
• Unit time. How long does one occurrence take? Time a real sample, separating simple cases from complex ones. Self-reported estimates are almost always wrong, in one direction or the other.
• Quality. How many errors, reworks, complaints? Pick an indicator you will be able to record the same way afterwards.
• Lead times. How long from start to finish of the process? Record it from dates stored in your tools.

This measurement happens on the ground, alongside the people doing the work. It is exactly what an engineer does in FDE as a service during the observation phase: watching the real steps, timing them, and producing a baseline the team recognises as accurate.

A numerical illustration, to be read as a hypothesis

The figures below are assumptions made to illustrate the method. They describe no client and no measured result. Every organisation replaces them with its own baseline.

Take a team that receives written customer requests. Assumptions: one thousand requests a month, twelve minutes of handling per request today. Current time is therefore twelve thousand minutes, or two hundred hours a month.

An AI tool drafts a reply from the customer history and the knowledge base. Assumptions after go-live: the tool handles eighty-five percent of requests, and each of these needs four minutes of review and adjustment. The remaining fifteen percent are too specific and go back to the manual process, at twelve minutes each. Supervision, sample review and instruction updates, takes six hours a month.

That gives eight hundred and fifty requests at four minutes, or three thousand four hundred minutes, plus one hundred and fifty requests at twelve minutes, or one thousand eight hundred minutes. Total: five thousand two hundred minutes, about eighty-seven hours, plus the six hours of supervision. Time after go-live is about ninety-three hours a month. The gain is about one hundred and seven hours a month.

Now redo the calculation without review or supervision, as many quick estimates do: only the one hundred and fifty manual requests would remain, thirty hours, and the displayed gain would be one hundred and seventy hours. The gap between the two calculations is considerable. It comes entirely from the human time the tool does not remove.

To express this in money, multiply the hours gained by your loaded hourly cost. Subtract the monthly cost of operations and consumption. The result is the net monthly gain. Divide the build cost by that net gain to get the payback period. If the net gain is small or negative, the project is not justified by time returned, and it must find its justification elsewhere: errors avoided, lead times, revenue, or nowhere.

Measure after, with the same method

Once the tool is live, repeat exactly the same measurements: same indicator, same recording method, same scope. If you timed a sample of requests before, time a comparable sample after. If you counted errors from credit notes issued, count them the same way. Changing method between the two measurements makes the comparison useless.

Allow an adjustment period before the final measurement. In the first weeks, users discover the tool, distrust its proposals and check everything twice. Measuring too early underestimates the gain. Measuring once, over an unusually quiet or busy period, also skews the result.

Finally, compare actual to estimate, item by item. Is the share of handled cases as expected? Does review take the expected time? Does consumption follow volume? That gap is the most useful information in the project: it shows which assumption was too optimistic and where to act. It is also why we build in batches, measuring each batch before starting the next, as described in our automation method.

Also set, from the start, a cautious scenario and a stopping criterion. Redo the calculation with a lower share of handled cases and longer review: if the project stays profitable, the decision is solid. And if the gain measured after the adjustment period stays below the threshold you chose, the tool is fixed or withdrawn.

Traps that distort the calculation

• Counting time saved without review. The illustration above shows the size of the error.
• Forgetting consumption when the tool succeeds. A well-liked tool gets used more than planned. Calculate the cost per operation and see what it becomes if volume rises.
• Adding gains that overlap. An error avoided also saves the time to correct it. Do not count that time twice, in time returned and in errors avoided.
• Valuing time that will not be redeployed. Minutes scattered across everyone's day do not always turn into useful capacity.
• Extrapolating from a prototype. A prototype works on chosen cases. In production the hard cases arrive and the success rate drops. Our article on production prerequisites for a business POC details what changes between the two.
• Ignoring data quality. If input data is incomplete, the tool produces results that need rework, and the gain melts away. Upfront data and integration work is sometimes the real first project.
• Changing the measurement method along the way. A self-reported before and a timed after cannot be compared.

Where to start

Choose a frequent, measurable and tedious task whose volume and unit time you can record right now. Write down the decision and the alternative. Record the baseline on a real sample. You will then have what you need to judge any proposal, ours included.

If you want to do this work with us, our AI diagnostic starts with that measurement: it identifies the tasks where a tool genuinely returns time, works out the full costs with you, and hands you a calculation you can verify after go-live.

Sources

• Anthropic, Claude API pricing (input and output tokens, batch processing, prompt caching)
• OWASP, Top 10 for LLM Applications (2025), including LLM10 Unbounded Consumption

Frequently asked questions

Can you calculate ROI before knowing the project cost?

Partly, yes. The baseline and the estimated gain can be calculated without knowing the build cost. You then get the maximum amount it is reasonable to invest, which helps you judge the proposals you receive.

Should time saved be valued at gross salary or loaded cost?

At loaded cost, meaning what an hour really costs the company. Your payroll team or accountant can give you that figure per profile. Keep the same hourly cost for the before and after measurements.

What if teams refuse to be timed?

Explain that the measurement is about the task, never the person, and that results will not be used to assess anyone. Tool logs often provide much of the volume and lead-time data without a stopwatch. Involving a team representative in the recording also helps it be accepted.

Can a project that does not pay off in time saved still be worth it?

Yes, if another gain clearly justifies it: a regulatory obligation better met, costly errors avoided, a decisive customer lead time. That must then be written down explicitly, and that gain measured with the same rigour.

Who should own the calculation internally?

Ideally the person who will be responsible for the process after go-live, with support from finance for hourly costs. The provider can prepare the calculation, but the company has to validate the assumptions and record the measurement afterwards.