How to Measure the Business Value of AI

When a business uses AI in customer support, software development, sales, or document handling, faster work does not guarantee a better financial result. Employees may spend saved time checking answers or fixing errors. The business saves cash only when it reduces spending. It gains value from extra capacity when employees use saved time productively.

Compare business outcomes with what would have happened without AI, then subtract the full cost of producing those outcomes. This comparison is called attribution: deciding whether AI caused the change rather than another factor. The approach below shows how to choose useful measures, make a fair comparison, and separate cash savings from estimates of the value of extra capacity.

Measure outcomes at the right level

AI results appear at several levels. A task measure, such as minutes to draft a response, shows how one activity changed. A workflow measure tracks the full path to completion. That path includes review and corrections, as well as handoffs and exceptions. A business outcome measures what the company ultimately cares about. Examples include customer satisfaction and sales, along with operating costs and reliable delivery.

Track all three when they apply. For example, a support operation might measure response-drafting time, issues resolved per paid hour, and repeat contacts. If employees draft faster but resolve no more issues and customers contact support again, the task improved while the business result did not.

Choose measures before a rollout. For software development, accepted changes and defects tell more than the number of lines of code generated. For document handling, count correctly completed cases and downstream corrections, not just the time to produce a first draft. Usage measures, such as licenses assigned or prompts submitted, describe adoption but do not establish value.

Compare AI with a credible alternative

A before-and-after comparison alone cannot show that AI caused a change. Demand and staffing might explain the result. So might seasonality or a separate process change. Before introducing AI, record work volume and quality, along with costs. Also note differences among users or case types. These results form the baseline for comparison.

When practical, randomly assign comparable workers, cases, or locations to use AI or continue the existing approach. Keep the measurement period and outcome definitions consistent. If a business cannot randomize access, it can roll out the tool in stages and compare early and later adopters. That comparison depends on the groups having similar trends before the rollout, so state the assumption and avoid presenting the result as certain proof.

Also track whether people actually used the tool. Measuring the effect of offering access answers a different question from measuring the effect on people who use it. Record changes to the model, instructions, connected data, or review rules during the test, because those changes can alter results.

Count the full workflow

Measure the time and labor required from the start of a task to an acceptable result. Include preparation, prompting, review, correction, escalation, and later work that depends on the result. A tool that produces a draft quickly can still lengthen the workflow if an employee must check every claim or repair frequent errors.

Measure quality as well as speed and volume. Depending on the work, track whether the result passes review the first time, how much rework it needs, repeat customer contacts, defects, incidents, or cases that need human review. Set a clear acceptance standard before the test so the business does not count incomplete or inaccurate output as completed work.

Research shows why task suitability matters. In an experiment with 758 consultants, AI users completed more tasks and worked faster on tasks within the tested model’s capabilities. On a task outside that boundary, they were less likely to produce a correct answer, according to the consulting-task experiment. In a separate trial, experienced open-source developers took longer on tasks when using the early-2025 AI tools studied by METR. Neither result predicts every business’s performance. Together, they show why a speed measure needs a quality check and a defined work context.

Translate operational gains into financial value

Start with incremental net value, meaning the benefits attributable to AI minus the additional costs of achieving them. A common summary is:

ROI = (attributable benefits − total costs) ÷ total costs

ROI, or return on investment, expresses net benefits relative to costs. The result is only as sound as its assumptions. Report observed financial savings separately from operational gains and forecasts.

Saved time represents capacity. It becomes a cash saving when the business actually reduces an expense, such as overtime or contractor spending. Employees create capacity value by using the freed time for more work, faster service, or another defined priority. If the business cannot show how it used the time, it should not report the full value as realized savings.

Include the complete cost of operating the AI-supported workflow. That means more than subscription fees: account for integration and data preparation, as well as training. Include review and correction, oversight, and security and privacy work. Also count monitoring, maintenance, and remediation when something goes wrong. A pilot with low software costs can still require substantial human labor.

For example, a business testing AI-assisted support could compare resolved issues per paid hour and repeat contacts with a control group. It could also compare customer feedback between the groups. It could then calculate any reduction in overtime separately from additional capacity used to handle more cases. The customer-support study found a 14% average increase in issues resolved per hour among 5,179 agents at one company, with larger estimated gains for novice and lower-skilled workers. That operational result does not establish the same gain elsewhere or prove that another company would reduce costs.

Expect results to vary

Business value depends on the task, users, tool, and surrounding workflow. A field study of online retail applications reported sales effects ranging from 0% to 16.3%, depending on the application and its added contribution to existing practices, according to research from Columbia Business School. Those results show that even within one platform, different uses produced different outcomes.

Company-wide effects can also look modest even when a targeted task improves. In a survey of nearly 6,000 executives across four countries, 69% reported that their firms used AI, while 89% reported no labor-productivity impact over the preceding three years. The NBER survey report reflects executive reports, not audited financial results or a causal experiment. It still highlights a useful distinction: adoption is an input, while measurable business impact is an outcome.

Report results by task and user group, not only as a company-wide average. A tool might help newer employees while adding little for experienced specialists, or improve routine cases while increasing exception work. A single average can hide both the people who benefit and the people who absorb extra review or correction.

Recheck value after launch

A test before launch estimates how AI performs under test conditions. Continued measurement shows whether the value lasts as staff adopt the tool, demand changes, and the workflow evolves. Compare results over meaningful operating periods, and document changes to the model, process, and review rules so readers can interpret shifts.

Set an owner for the measures and the operating costs. That owner should review output quality, exception rates, customer outcomes, usage, and ongoing labor alongside the financial calculation. The NIST AI Risk Management Framework recommends testing before launch and monitoring performance afterward. It also recommends documenting the measures, uncertainties, and limits on how far the results apply.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com