How to Calculate AI ROI Before You Build: A Worked Example

A pilot gets approved when someone multiplies hours saved by a salary. That number is wrong the same way every time. It counts time saved as money saved. It prices the model at demo volume. It assumes the system never makes a mistake.

The model below replaces that number with one you can run on your own figures. One worked example runs through all of it. Every figure in that example is illustrative. Swap in your own volumes, rates and quotes before you decide anything.

Three questions before you open a spreadsheet

Answer these first. If one of them fails, you do not need the rest of the model.

1. Does this workflow need AI at all? AI models are good at messy inputs: rambling emails, scanned contracts, phone calls. They are slow, costly and unpredictable at strict rules. Run three tests on the workflow:

• ▸Input: Is the data structured (a web form, a fixed file format) or unstructured (free text, PDFs, audio)?
• ▸Logic: Can every decision be written as if/then? "Balance below zero, suspend the account" is a rule. "Customer sounds ready to cancel, route to retention" is a judgment.
• ▸Output: Does the system need to read, summarize or extract from noise?

If the input is structured and the logic is if/then, build a normal integration or an automation workflow. It will be cheaper to run and easier to maintain. Our n8n vs custom agents guide covers where that line sits.

2. Do the costs survive production volume? A demo runs ten times. Production runs ten thousand times, with retries and growing context. The cost section below shows how to price that properly.

3. What does one wrong answer cost? A bad internal meeting summary is an annoyance. A customer-facing agent that invents a refund policy is a direct loss and a legal question. You need a number, or at least a ceiling, for this before you build.

Value: the realization factor most cases skip

Time saved is not money saved. Say an AI system cuts a compliance report from four hours to one. The spreadsheet says you saved three hours at $60, so $180 per report. That holds only if you cut paid hours or fill them with work that earns money. Otherwise you have a less stressed employee and the same payroll.

So discount the saved time by how much of it reaches your P&L.

Gross value = task volume × hours saved per task × fully loaded hourly rate × realization factor

The realization factor is the share of saved time that turns into money. It is the single most important input in the model.

• ▸Close to 100%: a contact center where shorter handling time lets you staff fewer seats at the same volume.
• ▸Partial: salaried knowledge workers who move to a real backlog of revenue work. Most internal cases sit here. Use a conservative assumption and defend it.
• ▸Possibly negative: a firm that bills by the hour. Faster work means fewer billable hours, unless you change how you price.

Cost: what the system costs to run

Running cost has two parts that people treat as one. The first is inference, meaning what you pay the model provider per use. The second is everything around it: hosting, monitoring, maintenance and human review.

Model providers charge per token, roughly a fragment of a word. Input (what you send) and output (what it writes back) are priced separately.

Monthly inference = volume × [(input tokens × input price) + (output tokens × output price)] × pass multiplier

The pass multiplier is where demo costs and production costs split. A production system rarely reads a document once. One step plans what to look for. Another extracts it. A checking step compares the extraction against the source. If the check fails, the system retries, and each retry carries the previous attempt and its error notes.

Context grows with every loop. A 13,000-token contract read three times, with corrections attached, can consume about 45,000 input tokens rather than 13,000. Model the pass count you expect in production, not the one you saw in the demo. The arithmetic for how retries and context growth multiply the per-pass cost is its own post. What sets the build price is the other half of the budget.

Two levers bring this down. Route simple items to a smaller, cheaper model and send only hard cases to a frontier model. Also, cut the context you send on each pass. Both are engineering decisions, so ask your builder how they will handle them.

Errors: price the human fallback

No AI system is right every time. Design for the misses and pay for them in the model.

Error cost = volume × fallback rate × hours to fix × hourly rate

The fallback rate is the share of items the system routes to a person. That happens because confidence is low or because a check failed. Fixing an AI miss is often slower than you expect. The reviewer has to work out what the system got wrong before correcting it. Where to put that approval step is its own design problem, covered in our LangGraph production patterns.

If the output reaches a customer, the cost of a miss is not just review time. It includes refunds, complaints and regulatory exposure. Put a check on the output itself, not only instructions in the prompt. For inbound customer email, Verel Coordinator does this. It routes work under your rules, runs a compliance gate on anything customer-facing, and logs every decision.

Then budget for maintenance. Providers retire model versions on a published schedule; Anthropic's deprecation page lists a retirement date for each one. A setup that works today can get worse after a forced migration. You need monitoring that catches drift, plus engineering hours to fix it. Budget a monthly figure for this. Leaving it out is the most common way a positive business case turns negative in its second year.

The worked example

A procurement team reviews 200 vendor contracts a month. Each takes two hours at a fully loaded $100 an hour. All figures below are illustrative.

Value. The theoretical saving is 200 × 2 × $100 = $40,000 a month. The team is salaried and has a partial backlog, so we assume a 30% realization factor. Bankable value is $12,000 a month.

Inference. Assume a long contract is about 100,000 input tokens and the report is 1,000 output tokens. Take illustrative frontier-tier prices of $3 per million input tokens and $15 per million output tokens. Check your provider's current pricing page, such as OpenAI's. One pass costs $0.30 + $0.015 = $0.315. At 200 contracts that is $63 a month. With five passes per contract it becomes $315. Add search storage, hosting and monitoring, and call it $500.

Errors. 15% of contracts (30) go to a reviewer, at one hour each. That is $3,000 a month.

Build and upkeep. Assume a $35,000 build, spread over 12 months ($2,917), plus $1,500 a month for maintenance and monitoring.

Payback is $35,000 ÷ $7,000 = 5 months. From then on, the system adds about $7,000 a month in operating margin.

Notice what inference costs: about 4% of the realized value. The case does not depend on the model price. It depends on two assumptions, so test both.

Sensitivity: where the case breaks

Halve the realization factor and a five-month payback becomes three years. Double the fallback rate and payback nearly doubles. Those are the two numbers to stress-test with your team, and the two a vendor's demo will never show you.

The pattern holds beyond contracts. The math usually works on high-volume, repeatable work with clear pass/fail criteria and expensive human time. It usually fails on open-ended judgment work, where fallback rates stay high and errors are costly. An internal chatbot with no workflow attached tends to show a negative return by line three. Better to find that out in a spreadsheet than six months into a pilot. Our post on why POCs fail in production lists the engineering gaps behind those stalled projects.

Frequently asked questions

Q: What payback period should we target? Aim to pay back inside 12 months. Models and provider APIs change often, and a long payback means you may need a migration before you break even. If your realistic payback is beyond 18 months, narrow the scope to the busiest, most repeatable part of the workflow and rerun the numbers.

Q: Do open-weight models like Qwen or Llama improve the return over paid APIs? It depends on volume. Paid APIs charge per token, so cost rises with use. Self-hosted models cost roughly the same each month whether the hardware is busy or idle. At high, steady volume, self-hosting can lower unit cost. At low volume, the API is almost always cheaper. Compare your projected monthly API bill with the full cost of hosting and operating the servers.

Q: How do data residency rules affect the ROI model? They change the cost lines, so model them explicitly. Saudi Arabia's Personal Data Protection Law, administered by SDAIA, restricts transferring personal data outside the Kingdom. In the UAE, Federal Law No. 2 of 2019 on ICT in health fields restricts storing health data outside the country; the UAE government's data protection page lists both instruments. Either can rule out a provider endpoint hosted abroad. Price the in-region or private alternative as its own infrastructure line, and run the PDPL checklist for AI deployments before you sign.

This week

Take the two numbers a vendor demo never shows, realization factor and fallback rate, and run the sensitivity table with your own values this week.