AI ROI Starts Before the Pilot: How to Track Value from Intake to the 90-Day Review

1. Define the return before funding the use case

An AI use case needs a measurement plan before it needs a pilot. The sponsor should be able to explain which outcome will change, how the team will measure it, and what would justify the next investment.

Recent ROI headlines make that discipline more important. SAP and Oxford Economics' July 2026 research surveyed 2,600 business leaders across 13 countries and found expectations of 21% AI ROI this year, rising to 38% in two years. Those are expectations in a vendor-sponsored survey, not audited returns. They offer context for executive ambition, not a return benchmark for a local business case.

A practical tracking method starts with two stages. Initial intake documents the problem, the current workflow, and the desired outcome. Solution definition brings business and IT together to specify the proposed change, costs, assumptions, and measures.

The record should follow the use case after launch. A forecast becomes useful once someone compares it with actuals and explains the gap. An intake estimate is a starting hypothesis, not a result — filling out a form doesn't mean the benefit actually showed up.

2. Measure the workflow before changing it

Start with a defined unit of work: a support interaction, invoice, document review or another identifiable transaction. Record volume, seasonal peaks, active labor, waiting time, errors, rework, backlog and current outside spend.

Active effort and elapsed time answer different questions. A document might take twenty minutes to prepare and three days to approve. Faster preparation frees up labor, but turnaround barely moves if the approval queue sits untouched.

Map the proposed workflow against the current one. Mark which steps get assisted, automated, removed or left alone. That's how you find out whether the investment actually hits the bottleneck.

Initial intake can run on estimates. Before you evaluate the pilot, though, strengthen those estimates with an observation window, a sample, a data source and an owner. These baseline details are recommended additions to a basic metric table. Include the complex cases and exceptions — don't just time the easiest work.

Older research shows why local measurement matters. The 2023 NBER working-paper version of Generative AI at Work studied a staggered rollout among 5,179 customer-support agents and found a 14% average increase in issues resolved per hour, with larger gains among novice and lower-skilled workers. That's operational productivity in one setting — not a financial ROI estimate, and not a promised gain for your team.

Choose the comparison before launch. Randomized deployment, or a staged rollout with credible comparison groups, can strengthen attribution. If you're stuck with simple before-and-after measurement, document the changes in demand, staffing and case complexity that could explain the result.

3. Separate cash return from capacity released

Time saved multiplied by a loaded labor rate gives you a capacity-value estimate. It does not demonstrate that spending fell. A team can use freed hours well while payroll remains unchanged.

Keep benefit categories separate: reduced cash spending, documented future cost avoidance, incremental contribution margin, capacity redeployed, and service or quality improvements. Avoided hiring needs a credible demand and staffing plan. Extra revenue needs attribution and the cost of serving it.

For a stated period:

Financial ROI = (attributable monetized benefits − full incremental costs) ÷ full incremental costs.

Agree on recognition rules and cost treatment with finance. Keep a cash-flow view distinct from an economic view that values internal effort and redeployed capacity.

Here's a hypothetical example. All numbers below are invented, not organizational results.

A team handles 1,000 eligible cases monthly. It attempts 80% with AI. Comparable active labor falls from 20 to 12 minutes per attempted case, including review, corrections and fallback, with quality maintained.

Capacity released is 1,000 × 80% × 8 ÷ 60: 106.7 hours per month. At a hypothetical $60 loaded hourly rate, that's a $6,400 monthly capacity-value proxy.

Now assume finance verifies $2,500 monthly contractor spending avoided because of that capacity. Total incremental operating cost is $1,500 monthly, with $12,000 of one-time build and change costs.

Assuming twelve full months at those levels, without an adoption ramp:

• Recognized benefits: $2,500 × 12 = $30,000.
• Year-one costs: $12,000 + ($1,500 × 12) = $30,000.
• Year-one financial ROI: 0%.
• Simple undiscounted payback: $12,000 ÷ ($2,500 − $1,500) = 12 months.

Don't add the $6,400 capacity proxy to the contractor savings — that counts the same underlying improvement twice. A real forecast needs ramp time built in, plus evidence that the spending was actually avoidable, not just theoretically avoidable.

The capacity gain can still matter. It might support better service or absorb demand. But without evidence of monetary realization, report those outcomes and their costs. Don't invent a financial payback to justify what was really an operational win.

4. Include the cost of keeping the solution useful

Start by splitting one-time costs from recurring ones. Internal build effort, platform consumption, licenses, infrastructure, and support give you a starting point. Translate hours into dollars using a stated rate before totaling them, and flag which amounts are actual cash spend versus allocated internal effort — these get treated very differently in a budget review.

Then go back through the delivery plan for anything the cost estimate missed: data cleanup, integration, business testing, security and legal review, training, parallel operations, ongoing evaluation. These show up eventually. Better to account for them now.

Human review and exception handling cut both ways — they affect productivity and cost simultaneously. Account for them once, consistently. If review time has already reduced your measured labor saving, don't charge that same labor again as a separate penalty. That's double-counting.

Scrutinize your operating assumptions directly. Record eligible volume, expected adoption, calls or tokens per case, retries, support requirements. And allocate shared platform costs transparently — multiple use cases claiming the same benefit while the full expense sits somewhere else is how budgets quietly stop making sense.

Model changes, retesting, eventual migration or retirement — include these where applicable. The cost estimate should reflect these obligations even when the license quote omits them.

Run the low, base, and high cases side by side. Lower adoption can shrink variable consumption while fixed costs stay exactly where they were. Higher volume might improve utilization, but it also pushes up review demand. Neither direction is free.

Keep year-one economics separate from a mature monthly run rate. And for a material multiyear commitment, finance should run discounted cash flows rather than adding future benefits at face value.

5. Measure adoption and quality alongside speed

Availability is a weak adoption measure. Track eligible work, AI-attempted work, accepted output, repeat use, overrides and downstream defects. Specify the denominator: acceptance among attempted cases differs from adoption across all eligible cases.

Measure net effort across the workflow, including prompting, review, correction, failed attempts and fallback. Agree on a quality threshold before comparing speed. A faster step that transfers rework to another team may leave total labor unchanged.

METR's July 2025 randomized study illustrates why impressions need checking. Sixteen experienced open-source developers completed 246 tasks on familiar repositories. AI-allowed tasks took 19% longer, although participants subsequently believed AI had made them faster. The finding concerns that population, those tasks and early-2025 tools; it is not a verdict on current coding assistants.

The follow-up matters. In February 2026, METR explained that its newer experiment produced an unreliable signal of current productivity. Participant and task selection, along with difficulties measuring concurrent agent work, complicated interpretation. The authors believed developers were likely benefiting more than before, but described their data as weak evidence for the size of that change.

Keep measuring as tools and work practices change. A baseline, a quality measure and a credible comparison are more useful than confidence alone. Update the evaluation method when the workflow changes enough that the old measure stops describing the work.

6. Make the 90-day review a decision about continued investment

The two-stage template approach considered here already provides a sponsor accountable for outcomes, metric owners and a reporting cadence, a quality measure, adoption planning, and a 90-day review of actual performance and run costs. That review ends with a call to continue, expand, modify or retire.

But those provisions describe a measurement process. They're not evidence that anyone actually realized savings.

One recommended addition is a benefit register that links baseline, forecast, actual, variance and explanation to a named owner and decision date. Finance validation of monetary claims is another addition worth making explicitly — don't assume a general intake process already covers it.

Split the work clearly. The sponsor owns changes to the business process and benefit realization. Operations maintains workflow measures. IT supplies system telemetry and operating costs. Finance checks monetary conversion, attribution and double counting.

The review should explain a missed target, not just flag it. Low adoption, a changed case mix, extra review effort, weaker-than-expected output — these call for different responses, and conflating them wastes the review. Keep the original forecast next to the revised assumptions. Overwrite it and the organization loses the ability to learn from its own estimates.

Ninety days is a decision checkpoint, not a universal payback deadline. Report costs incurred and benefits observed through that date. Label anything annualized as a projection, especially where demand is seasonal or adoption is still climbing.

Additional 30- and 60-day checks can catch problems before the formal review arrives. A six-month follow-up can test benefits that take longer to show up. Both are refinements worth adding. Neither is a reason to delay the next accountable decision.

7. Fund the next phase against evidence

At the next funding discussion, the sponsor should bring a concise record: the intended outcome, the baseline and source, the benefit category, full costs, adoption and quality results, the accountable owner, and the next decision date.

Make the financial claim traceable. A reviewer should be able to move from hours released to the specific spending avoided or margin created, without relying on an unexplained conversion factor. Capacity that has not produced a cash benefit should remain visible in its own category.

Some investments deserve funding for better service, resilience or a necessary control. State that rationale and measure the relevant outcome. A fabricated positive ROI makes the decision less informed.

A pilot can also buy information. A bounded experiment might establish whether people will adopt the workflow or whether quality survives difficult cases. Define the uncertainty it must resolve and limit the spending accordingly. Useful pilot learning does not, by itself, prove production economics.

Expand when observed outcomes and operating readiness support the next investment. Modify when a specific adoption, quality or cost constraint has a credible remedy. Retire when the benefit hypothesis no longer holds. Continue at current scope when more evidence is worth its cost, with a time limit and a clear next test.

The 90-day review should end with that choice, an owner and a funding consequence. The case for the next phase rests on what the team can now demonstrate.