How to Calculate AI ROI: Why Time Saved Is Not Money Saved

The distinction is not anti-productivity. Task-level studies show that AI can reduce time and sometimes improve quality in specific settings. One field study reported a 13.8% increase in customer issues resolved per hour, while a preregistered writing experiment found less time and higher quality on bounded professional tasks. Those are meaningful operational results. Neither study says the employer removed 13.8% of payroll. Productivity evidence belongs in the performance input; financial capture still has to be demonstrated.

Use the Automation Economics Calculator to run the complete model, and read the published AEM-1.0 methodology for every equation and control.

Suppose a salaried employee saves five hours each week. Payroll is unchanged on Friday. The company may gain faster response, lower backlog, better work, or more resilience. Those outcomes can be valuable. But if demand, staffing, overtime, contractors, and output are also unchanged, no direct financial value has yet been captured. Calling the loaded value of those hours “savings” silently assumes the conclusion.

Loaded cost is still the correct resource input: wages alone omit employer-paid benefits and other compensation. Current BLS data explicitly separates wages and benefits. The error is not using a loaded rate. The error is treating every freed loaded-cost hour as cash that left the income statement.

• A salaried hour made available is capacity until a staffing, spend, throughput, or quality outcome changes.
• A backlog reduction is an operational result; value it only if its consequence is observable.
• Faster output is not automatically revenue; use incremental contribution and show the demand path.
• A theoretical avoided hire is not a benefit unless the hire was genuinely required and its timing is documented.
• The same hour cannot reduce overtime, avoid a hire, and produce new contribution at the same time.

The license or token bill is one line. A decision-ready AI ROI calculation also prices implementation, integration, data preparation, security, enablement, migration, human review, exception handling, correction, monitoring, model or prompt changes, vendor management, and recovery from failure. NIST's risk framework likewise calls for expected benefits and costs against appropriate benchmarks, measures of uncertainty, pre-deployment testing, and continuing measurement.

Consider an illustrative case-review operation with 20,000 cases a year. The current workflow takes 15 minutes per case, has a 5% rework rate with 20 minutes per correction, uses 300 fixed annual hours, and carries a $60 loaded hourly cost. The proposed system attempts 75% of cases, succeeds on 90% of attempts, adds five human minutes to every failed attempt, sends 30% of successful outputs to a four-minute review, leaves a 2% residual error rate with 15 minutes of rework, and uses 300 fixed oversight hours. Every number below is an input to the worked example, not a benchmark.

The automation clearly removes work. It creates more than three thousand hours of annual capacity. Yet the investment result depends on what the operation can actually do with those hours.

Each steady-state row reconciles as captured capacity value plus the separately modeled $3,900 quality value minus $58,750 of recurring technology cost. The quality benefit does not consume capacity; implementation, delay, ramp, and discounting explain why the 36-month NPV is not the annual result multiplied by three.

The first row is not a declaration that unused capacity has no value. It says direct cash value has not been demonstrated. Management can still choose the project for service, resilience, speed, quality, or strategic reasons. The approval memo should name that reason instead of relabeling resource capacity as payroll savings.

The final row is not permission to invent an avoided hire. Finance should require a dated capacity forecast, the role and cost that would otherwise be added, the month it would begin, and evidence that the automated workflow can absorb the projected demand. If the hire was never going to happen, its value is zero.

Simple ROI divides net undiscounted benefit by incremental cost. It is easy to communicate and easy to manipulate through the horizon. NPV is harder to flatter: implementation lands early, benefits begin after go-live, ramp delays full performance, and future cash is discounted. Payback answers a different question—when cumulative cash flow recovers the investment. Use all three, label the horizon, and do not compare projects with mismatched timing.

• Test automation coverage and straight-through success. Failed attempts often return the original work plus failure overhead.
• Test review rate and minutes. Review is paid work and can become the new bottleneck.
• Test residual error and consequence, not only average accuracy.
• Test implementation cost, delay, ramp, recurring technology, and volume.
• Test the capture mechanism itself. If a modest capture change reverses NPV, confidence should be moderate even when the base case is positive.

1. Baseline by workflow segment: volume, normal time, fixed work, rework, errors, exceptions, queue time, and non-labor failure consequence.
2. Proposed-system performance: attempted share, straight-through completion, review rate and minutes, fallback work, residual error, and oversight.
3. Adoption and ramp: eligible users, active use, workflow penetration, time to competence, and unsupported workarounds.
4. Complete cost: implementation, integration, security, licenses, tokens, compute, connected software, training, maintenance, monitoring, and switching.
5. Capture ledger: overtime removed, contractor invoice reduced, staffing action, avoided-hire counterfactual, or incremental contribution—with a named owner for each.
6. Financial result: monthly cash flow, NPV, simple and discounted payback, ROI, sensitivity, and the conditions that would stop the project.

Measure a representative production period, not a showcase. Segment routine work from consequential exceptions. Compare against the human baseline at the same quality and reliability threshold. Continue monitoring after launch because adoption, inputs, models, and business rules change.

This discipline changes other buying decisions. An AI receptionist can create coverage without replacing a full role. Microsoft 365 Copilot can save user time without generating seat-level cash. In both cases, the correct question is the same: what changed after the capacity appeared?

These are generalized assumptions. Model your workflow in the Automation Economics Calculator, review the complete Software Second methodology, or run the analysis against your company.