How to Calculate the ROI of an AI Agent Before You Build It

Most AI business cases begin with a suspiciously neat sentence:

This agent will save 20 people five hours per week, so it will save the company $500,000 per year.

The arithmetic may be correct. The conclusion usually is not.

Five hours returned to an employee does not automatically become five hours of payroll savings. A faster process does not automatically create more revenue. And a demo that completes a task once is not evidence that the system will handle the exceptions, adoption, maintenance, and review work that show up in production.

This is why many AI projects look excellent in a spreadsheet and disappointing six months after launch. The spreadsheet counted theoretical value and ignored the operating model required to capture it.

At Refound, we calculate AI agent ROI in two stages. First, we establish whether the workflow can produce measurable business value. Then we discount that value by what the company can realistically capture.

The result is not as exciting as multiplying everyone’s salary by 30%. It is far more useful. It gives leadership a business case they can defend, a pilot they can measure, and a clear reason to stop if the economics do not work.

Start With the Unit of Work

Do not begin with the agent. Begin with the work.

“Build a sales agent” is not a measurable project. Sales is a function containing prospect research, account qualification, meeting preparation, call follow-up, CRM updates, proposal creation, forecasting, and dozens of other tasks.

“Prepare a pre-call account brief” is a unit of work. It has a trigger, inputs, steps, an output, an owner, a frequency, and a current cost.

Before estimating ROI, write down these eight facts:

If you cannot describe the unit of work this clearly, you are not ready to calculate ROI. You are still describing an idea.

This is also why an operational AI audit starts with workflow mapping. You need a baseline before you can value a change.

The Five Sources of AI Agent Value

AI agent value usually comes from five places. A good business case includes the ones that apply and ignores the ones that do not.

1. Capacity returned

The agent reduces the amount of human time required to complete the work.

Use this formula:

Annual hours returned =
  annual task volume × (current minutes - future minutes) ÷ 60

Gross capacity value =
  annual hours returned × loaded hourly cost

Loaded hourly cost should include salary, benefits, payroll costs, and any overhead your finance team normally applies. Do not quietly use a consultant billing rate for an internal employee. That inflates the number.

The next step is the one most ROI models miss:

Realizable capacity value =
  gross capacity value × redeployment factor

The redeployment factor reflects how much of the returned time the business can turn into useful capacity.

• 20% to 40% when the time arrives in small, scattered fragments and nobody changes the employee’s workload.
• 50% to 70% when the workflow is frequent, the saved time appears in meaningful blocks, and the manager has a plan for it.
• 80% to 100% when the company can avoid a hire, reduce contractor spend, remove paid overtime, or increase production against a real backlog.

If an agent saves someone six minutes twice a week, the theoretical time is real but hard to capture. If it removes three hours of report preparation every Monday, the capacity is far easier to redeploy.

2. Additional throughput

Sometimes the company has more valuable work than the team can currently complete. The agent lets the same team process more leads, review more claims, publish more campaigns, or serve more customers.

Annual throughput value =
  additional completed units × contribution per unit

Use contribution, not revenue. If an additional customer produces $20,000 in revenue but costs $12,000 to serve, the contribution is $8,000.

You also need evidence that demand exists. “The team could produce twice as many proposals” has no value if there are not enough qualified opportunities to require them.

3. Cycle-time improvement

Speed creates value when timing changes an outcome.

A proposal delivered the same afternoon may close more often than one delivered eight days later. A customer issue identified in ten minutes may prevent a cancellation. A product team that synthesizes research in one day instead of three weeks can test an idea before a competitor launches.

Model this separately from capacity:

Annual cycle-time value =
  affected units × expected outcome improvement × contribution per outcome

Treat the outcome improvement as a hypothesis until a pilot proves it. If you assume that faster proposals will improve win rate by two percentage points, label that assumption and test it.

4. Quality and error reduction

Agents can improve consistency by applying the same checklist, policy, or evidence requirement every time.

Examples include:

• Fewer incorrect invoice classifications
• More complete CRM records
• Fewer missed contract clauses
• More consistent customer onboarding
• Fewer reports built from stale data

Annual quality value =
  errors avoided × average cost per error

Count the full cost of an error when you can support it: rework, credits, refunds, escalation time, lost margin, and regulatory exposure. Do not assign a dramatic number to “reputational risk” because it makes the model look impressive.

5. Risk reduction and option value

Some agents create value by making important work happen reliably. They monitor a control, detect anomalies, prepare an audit trail, or surface an issue before it grows.

Use expected value:

Expected annual risk value =
  reduction in incident probability × expected incident cost

If a failure has a 10% annual probability and an expected cost of $200,000, reducing that probability to 6% creates $8,000 in expected annual value, not $200,000.

Option value is harder to quantify. A shared agent infrastructure may make the next five workflows cheaper to build. That matters, but keep it outside the base case unless you have a specific follow-on plan. It belongs in the strategic rationale, not disguised as guaranteed year-one savings.

Calculate the Full Cost, Not the Prototype Cost

The first working demo is rarely the expensive part. Production is where the real cost appears.

Your estimate should include six cost categories.

Discovery and process design

Someone must map the current workflow, define the target workflow, collect examples, document exceptions, and agree on what the agent may do.

This cost exists even when you buy a product instead of building one. Configuration without process design is how companies automate a bad workflow.

Build and configuration

This includes application development, prompts, skills, orchestration, user interface work, and any vendor implementation fees.

Data and integration work

The agent needs access to the right systems and records. API work, identity, permissions, data cleaning, document ingestion, and migration often cost more than the model itself.

Model and infrastructure costs

Include model usage, hosting, storage, observability, browser automation, third-party APIs, and vendor licenses.

Model cost per task should be based on a representative sample, not the cheapest successful run. Complex cases use more tokens, more tool calls, and more retries.

Human review and exception handling

An agent that reduces a six-hour task to a one-hour review saves five hours, not six.

Include time spent reviewing outputs, handling exceptions, resolving failures, and answering questions from users. Human oversight is part of the system, not an embarrassing temporary cost to hide from the spreadsheet.

Maintenance and change management

Processes change. APIs break. Policies get updated. Models behave differently. Employees need training. Someone must own the workflow after launch.

For a meaningful agent, budget for ongoing monitoring, maintenance, evaluation, and user support. An agent without an owner is a pilot with a delayed expiration date.

Your first-year cost is therefore:

Year-one cost =
  discovery
  + implementation
  + integration
  + first-year infrastructure
  + first-year human review
  + first-year maintenance and training

Separate one-time costs from annual operating costs. Leadership needs to see both payback and steady-state economics.

Risk-Adjust the Benefits

A workflow can be economically attractive and still fail in practice.

We apply three discounts to expected benefit:

1. Technical reliability: Can the agent complete the task accurately across normal cases and known exceptions?
2. Adoption: Will the people responsible for the workflow actually use it?
3. Value capture: Will the business change workloads, capacity, or decisions enough to capture the benefit?

Risk-adjusted annual benefit =
  gross annual benefit
  × technical reliability
  × adoption rate
  × value-capture rate

Suppose an agent has $200,000 of theoretical annual benefit. You expect 90% technical reliability, 80% adoption, and 70% value capture.

$200,000 × 0.90 × 0.80 × 0.70 = $100,800

This can feel harsh. That is the point. A conservative model gives you room to be pleasantly surprised. An optimistic model gives you a future budget meeting where everyone argues about why the savings never appeared.

Do not multiply discounts blindly when they overlap. If your redeployment factor already accounts for value capture, do not discount capacity a second time. The model should be conservative, not incoherent.

A Worked Example: Proposal Preparation

Consider a hypothetical professional-services firm producing 200 proposals per year.

The current workflow takes six hours per proposal. A proposed agent would assemble discovery notes, retrieve approved scope language, select relevant case studies, calculate pricing from the current rate card, and prepare a first draft. A consultant would review and finalize it in two hours.

Baseline assumptions

Capacity value

Hours returned = 200 × (6 - 2) = 800 hours

Gross capacity value = 800 × $90 = $72,000

Realizable capacity value = $72,000 × 70% = $50,400

Cycle-time value

The firm believes same-day proposals can move win rate from 20% to 22%. That must be tested, so it remains a labeled hypothesis.

Additional wins = 200 × (22% - 20%) = 4

Cycle-time value = 4 × $25,000 = $100,000

Total expected annual benefit

Capacity value                     $50,400
Cycle-time value                  $100,000
Quality and rework value           $15,000
                                  --------
Expected annual benefit           $165,400

Cost estimate

ROI and payback

Year-one ROI =
  (year-one benefit - year-one cost) ÷ year-one cost

Year-one ROI =
  ($165,400 - $91,000) ÷ $91,000 = 81.8%

Monthly net benefit after launch =
  ($165,400 - $32,000) ÷ 12 = $11,117

Payback on one-time investment =
  $59,000 ÷ $11,117 = 5.3 months after launch

The model is attractive, but the $100,000 cycle-time benefit is still a hypothesis. The firm should approve the project with a pilot gate: if proposal turnaround improves but win rate does not, the steady-state case falls back to capacity and quality value.

That still may justify the system. The decision should be based on the downside case, not only the most flattering one.

Build Three Cases

Never present one number. Build three versions.

If the downside case is catastrophic, shrink the first phase. If the base case depends on five unproven assumptions, run a pilot before approving a full build. If the upside case requires organizational changes nobody owns, remove it.

Set the Pilot Metrics Before Development

The best time to define success is before anyone falls in love with the prototype.

For each workflow, establish:

• Current task volume
• Current human time per task
• Current cycle time
• Current error or rework rate
• Current business outcome, where relevant
• Target agent completion rate
• Target review time
• Maximum acceptable error rate
• Expected adoption rate
• A stop, revise, and expand threshold

For the proposal example:

Expand:
  80%+ of proposals use the workflow
  median preparation time falls below 2.5 hours
  factual correction rate stays below 5%
  zero unapproved pricing changes

Revise:
  adoption is 50% to 79%
  review time remains above 3 hours
  recurring errors cluster around fixable inputs

Stop:
  adoption remains below 50% after training
  material pricing or scope errors exceed the agreed threshold
  downside-case payback exceeds 24 months

These gates turn ROI from a sales promise into an operating discipline.

Common AI ROI Mistakes

Counting all saved time as cash

Returned capacity only becomes financial value when the organization uses it. Name what people will do with the time: handle more accounts, remove a backlog, improve service levels, avoid a hire, or stop paying overtime.

Double-counting the same benefit

If more throughput already creates more contribution, do not also count every saved hour as separate value unless the hours truly get redeployed elsewhere.

Valuing the entire workflow when the agent handles one step

An agent that drafts a report does not eliminate the research, review, approval, and distribution around it. Model the new end-to-end workflow.

Ignoring exceptions

The common cases create the demo. The exceptions create the cost. Sample real work and identify how often the happy path breaks.

Hiding human review

Review is not failure. Unmeasured review is failure. Design it, time it, and include it in the economics.

Assuming adoption

If the agent creates work in a new interface, requires people to change habits, or threatens how a team defines its value, adoption will not happen because the output is technically good.

If adoption is the constraint, use the practical AI rollout playbook to design leadership ownership, champions, training, and feedback into the implementation.

Using model cost as total cost

Tokens are often the smallest line item. Process design, integration, evaluation, ownership, and change management determine whether the system works.

The One-Page AI Agent Business Case

Before approving a build, leadership should be able to review one page containing:

1. Workflow: The exact unit of work and current owner.
2. Baseline: Volume, time, cycle time, quality, and current outcome.
3. Target state: What the agent does and what the human still owns.
4. Benefit: Capacity, throughput, speed, quality, and risk, without double-counting.
5. Cost: One-time and recurring, including review and maintenance.
6. Assumptions: Every unproven input labeled clearly.
7. Cases: Downside, base, and upside.
8. Pilot: Metrics, duration, owner, and sample size.
9. Guardrails: Permissions, review rules, and escalation paths.
10. Decision gates: Stop, revise, and expand thresholds.

If the business case cannot fit on one page, the project is probably still too broad.

ROI Is a Design Constraint

ROI should not be calculated once at the beginning and revisited in a slide after launch. It should shape the system.

If review cost is too high, narrow the agent’s scope. If adoption is weak, move the output into the tool people already use. If integration cost overwhelms the benefit, choose a workflow with better data access. If the value depends on revenue lift you cannot observe, select a pilot where cycle time or capacity can be measured directly.

The useful question is not “Can we build an AI agent for this?”

You almost certainly can.

The useful question is whether the redesigned operating model creates enough measurable value to justify building, operating, and managing it.

That is the difference between an AI demo and an AI investment.

If you need to identify the right workflows, establish defensible baselines, and rank opportunities by impact and effort, our AI Audit produces exactly that roadmap. You can also use the 12-point workflow readiness assessment before you start putting numbers into a business case.