How to Calculate ROI on an AI Integration Before You Commit Budget

Most AI ROI estimates fall apart for a boring reason: someone multiplied hours saved by hourly rate, ignored everything else, and got a number that felt exciting enough to greenlight a budget. That number is usually wrong, not because the math is hard, but because three or four real costs and one optimistic assumption never made it into the spreadsheet. This is the methodology behind our AI ROI Calculator: what actually goes into each input, and where the estimate typically breaks.

The basic formula, and why it undersells the real question

The standard ROI formula is simple: (net return from the investment minus cost of the investment) divided by cost of the investment, expressed as a percentage. Payback period is even simpler: implementation cost divided by net monthly savings. Neither formula is where the disagreement happens. The disagreement happens in what you plug into 'net return' and 'cost', and that's where most back-of-envelope numbers quietly go wrong before the formula is even applied.

Step 1: Quantify hours saved honestly, not theoretically

Start with the current process: how many hours per week does a task actually take, measured, not estimated from memory. Then ask what percentage of that task an AI integration will realistically remove, not what it removes in a vendor demo. A feature that drafts invoice line items but still needs a human to check and approve each one might save 40 to 60% of the time, not 100%, because verification, exception handling, and edge cases don't disappear. Use the lower end of your range for the initial estimate. It's easier to be pleasantly surprised later than to defend an inflated number to whoever approved the budget.

Step 2: Choose a realistic hourly cost baseline

The hourly cost input should be the fully loaded cost of the time being freed up, not just a salary divided by working hours. Include payroll taxes and benefits where relevant, and be honest about what the freed-up time is actually worth. If saved hours get reabsorbed into other low-value busywork rather than higher-value output, the real financial return is lower than the headline hours-saved number implies. This is one of the more common inflation points in AI ROI pitches: hours saved are real, but their dollar value depends entirely on what replaces them.

Step 3: Estimate implementation cost, all of it

Implementation cost isn't just a development quote. It includes integration with existing systems (CRM, ERP, internal tools), any data cleanup needed before the AI feature can work reliably, testing against real edge cases, and staff time spent in requirements and review meetings. If you're still at the stage of not knowing what a build should cost, our AI Cost Estimator gives realistic ranges by scope tier before you request a formal quote.

Step 4: Don't forget ongoing maintenance cost

This is the input most estimates skip entirely, and it's usually the one that changes the payback period the most. AI features drift: the model's behavior shifts as underlying data changes, prompts need adjusting, and something will eventually need fixing after go-live. Budget a recurring monthly or annual maintenance figure and subtract it from your annual savings before calculating payback, not after. We've written separately about what maintaining an AI feature actually looks like eighteen months after launch, and it's worth reading before you finalize a maintenance line item, because the real cost tends to show up later than most estimates assume.

Step 5: Calculate payback period and 3-year return

Once you have all four inputs, hours saved, hourly cost, implementation cost, and maintenance cost, the calculation is straightforward. Here's a worked example using conservative, realistic assumptions rather than optimistic ones.

A business estimates that an AI feature will realistically save 10 hours per week across a team (already adjusted down from a theoretical 20 hours, accounting for adoption ramp-up and exception handling). The fully loaded hourly cost is €30. Annual gross savings: 10 hours x 52 weeks x €30 = €15,600. Implementation cost is €20,000. Ongoing maintenance is €250 per month, or €3,000 per year. Net annual savings after maintenance: €15,600 minus €3,000 = €12,600.

Payback period: €20,000 divided by (€12,600 / 12) = roughly 19 months. Three-year return: net savings over three years (€12,600 x 3 = €37,800) minus the initial implementation cost (€20,000) = €17,800 net return, or roughly 89% ROI over three years. That's a defensible project. If maintenance had been left out of the calculation, the payback period would have looked like 15 months instead of 19, a meaningfully rosier picture built on an omission, not an error in the formula.

The three mistakes that make most back-of-envelope numbers wrong

• Uncounted maintenance. As shown above, leaving out ongoing cost doesn't just shave a few months off the payback period, it changes whether the project clears a sensible threshold at all. Always subtract maintenance from annual savings before calculating payback, not as an afterthought.
• Optimistic adoption rates. Estimating that a team will use a new AI feature for 100% of eligible tasks from week one is rarely realistic. People fall back on old habits, some tasks have exceptions the feature can't handle, and training takes time. Model adoption at 60 to 70% for the first few months and adjust upward once you have real usage data, rather than baking full adoption into the initial projection.
• One-time savings mistaken for recurring savings. Some AI benefits are genuinely one-off, clearing a backlog, correcting a one-time data problem, and shouldn't be annualized as if they repeat every year. Separate the two categories clearly: recurring operational savings compound over the years in your 3-year calculation, one-time gains don't and shouldn't be double-counted.

A related, less mechanical mistake worth naming: treating 'hours saved' as the only metric that matters. As PwC's analysis of AI ROI points out, ROI estimated at a single point in time, before accounting for how benefits shift as usage and confidence grow, tends to be shakier than it looks. Treat your first ROI estimate as a starting hypothesis to revisit after three to six months of real usage data, not a final number.

Where accuracy risk enters the calculation

Not every AI use case carries the same risk of the savings not materializing as planned. A feature that drafts an internal summary for a human to review has a very different error tolerance than one that makes an automated decision affecting a customer or a financial record. If the feature is likely to produce occasional wrong or fabricated outputs, some of your 'hours saved' will be spent instead on catching and correcting those errors, which eats into the net savings side of the calculation. We've mapped out how that risk varies by use case in more detail in our piece on hallucination risk profiles, which is worth reading alongside this framework if the feature you're evaluating touches customer-facing output or financial data.

When the math says no

Sometimes a careful ROI calculation should conclude that the project isn't worth it yet, at least not at the scope originally proposed. A payback period stretching well past two years, a task with too much variability to reliably automate, or savings that depend on unrealistic adoption rates are all legitimate reasons to narrow the scope, wait for cleaner data, or pick a different task entirely. That's a useful outcome, not a failed exercise: it's cheaper to find out on a spreadsheet than after six months of development. If the numbers do work, our AI Integrations team can help fit-check the use case and pilot it against real tasks before committing to a full build.