How Do You Calculate ROI on an AI Agent Before Greenlighting the Project?

Quick answer

Before a single line of code is written, estimate ROI with three numbers you can actually defend: the fully-loaded cost of the task today (hours × cost per hour × volume), the realistic automation rate (what fraction of that task the agent will actually handle without human correction, not the optimistic 100%), and the build-plus-run cost (development, plus ongoing model/infra/monitoring cost). ROI is the value freed up by automating that realistic fraction, minus build-plus-run cost, expressed as a payback period. Not a percentage that sounds impressive on a slide.

Why pre-project ROI estimates fail before they start

Most AI project business cases fail for one of two reasons: they use an unrealistic automation rate (assuming the agent handles 100% of a task when a defensible estimate is 60-80% for a first version), or they only count build cost and forget run cost (model calls, monitoring, human review time for edge cases), which is an ongoing expense, not a one-time project cost. A credible pre-project estimate has to survive someone in finance asking "what if it only automates 60%, not 90%" without the whole case collapsing.

The four inputs to a defensible estimate

1. Fully-loaded cost of the task today. Not just salary: include the time cost of the people currently doing the task, at a realistic hourly rate, across the actual volume it happens (per day, week, or month). This is usually the easiest number to get right and the one teams most often lowball by ignoring overhead.

2. Realistic automation rate, not the best case. Estimate what fraction of instances the agent will handle end-to-end without a human correcting it, based on how repetitive and well-defined the task is. A highly structured, low-variance task might realistically hit 80-90% automation for a first version; a task with lots of judgment calls might realistically land at 40-60%. Build the estimate around the conservative number: it's the one you'll actually be held to.

3. Build cost. Development time, integration work, and evaluation/testing: this is the number most AI project estimates already include, and it's covered in depth in our AI agent cost breakdown.

4. Run cost. Model API calls at your expected volume, infrastructure, monitoring, and the ongoing human time spent reviewing edge cases or correcting mistakes: this is the number most first-time AI project estimates miss entirely, and it's the one that turns a good ROI story into a mediocre one if ignored.

The formula

Monthly value freed up = (task hours today × automation rate) × cost per hour Monthly cost = amortized build cost over your planning horizon + run cost Payback period = build cost ÷ (monthly value freed up − monthly run cost)

A project that pays back in 3-6 months at a conservative automation rate is a strong case. A project that only pays back if you assume 95% automation and ignore run cost isn't a bad idea necessarily. It's an unvalidated one, and it should say so honestly rather than presenting an inflated number.

What to do with the estimate once you have it

Use it to set the bar for what "success" means before the project starts, not after. Pick the automation rate and payback period you're estimating, and treat those as the actual success criteria the launched agent gets measured against. This is the direct link between this pre-project estimate and post-launch measurement: our ROI measurement post covers tracking the metrics that prove (or disprove) the estimate once the agent is live. A pre-project estimate that never gets checked against reality isn't a business case, it's a guess with a spreadsheet attached.

The mistake that undermines trust in AI project estimates generally

The fastest way to lose credibility for future AI proposals is presenting an inflated pre-project ROI estimate that the launched system doesn't hit. Conservative, explicit assumptions that turn out to be beatable build more organizational trust (and more budget for the next project) than an optimistic estimate that quietly misses.

FAQ

What if we don't have good data on the task's current cost? Estimate it: time a sample of the task, ask the people doing it how long it typically takes, and be explicit that it's an estimate. An honest estimate with stated assumptions is more useful and more defensible than waiting for perfect data that may never come.

Should we include the cost of managing the AI project itself? Yes: project management and stakeholder time is a real cost, usually amortized into the build-cost side, and leaving it out is one of the more common ways pre-project estimates undercount true cost.

How conservative should the automation rate assumption be? Conservative enough that you'd still consider the project worth doing if it undershoots: if the business case only works at the optimistic end of your estimate, that's a signal the project needs a narrower scope, not a more optimistic number.

Does this change for an AI feature we're building, versus one we're buying? The framework is the same either way. The inputs (task cost, automation rate, build cost, run cost) just get sourced from your own estimate for an in-house build, or from a vendor's proposal plus your own sanity-check for a bought solution.

Accelate builds the pre-project ROI model alongside the technical scope for every engagement. So the business case and the build plan are the same document, not two disconnected ones.