Most leadership teams can answer "are we using AI?" in about ten seconds. Ask "is it working?" and the room goes quiet, or worse, someone reads out an adoption percentage as if it answered the question. It didn't. Adoption tells you how many people opened the tool. It says nothing about whether the business is better off.
That gap is not a minor measurement gripe. It's the reason MIT's 2025 State of AI in Business research found 95% of organizations getting effectively zero measurable return on their generative AI spend, and only 5% of custom enterprise AI tools ever reaching production at all. It's the reason BCG's own research put the number of companies still unable to show tangible AI value at 74%. Unfortunately, these numbers are the norm that most companies experience.
The fix is picking the right question for the right initiative, building a baseline before you touch anything, and giving each department its own small set of numbers that mean something to the people running that function. That's what this piece walks through, with formulas and worked examples you can lift directly into a spreadsheet.
The instinct in most finance functions is to apply one hurdle rate to every AI request that lands on a desk. That instinct is where measurement breaks down first. A copilot that shaves twenty minutes off email drafting and a from-scratch agentic workflow that eliminates a manual reconciliation step are not the same kind of investment, and judging them by the same yardstick guarantees one of them looks like a failure no matter what happened.
Gartner's research on generative AI value sorts AI investment into three business cases, each with its own currency of return. The framework is useful precisely because it stops leadership from treating a productivity nudge and a structural bet as interchangeable line items.
The practical implication: before you measure anything, label it. A tool that saves individual employees time belongs in the Defend column and should be judged on employee capability and retention, instead of a spreadsheet ROI. A rebuilt process belongs in Extend and needs a real financial return within a reasonable window. A genuine bet on a new capability belongs in Upend and should be funded and measured like the venture bet it is, not killed in month four for not yet paying for itself.
The single most common way AI ROI gets overstated is an incomplete denominator. Teams count the software license and the API bill, call that the investment, and divide the (often generous) benefit estimate by that number. The result looks great and is wrong. Here is how you can calculate your Total Cost of Ownership (TCO):
That last item, the temporary productivity dip while a team adjusts to a new way of working, is often called the AI J-curve, and it's worth planning for rather than being surprised by. We cover how to map the workflow itself, which is the step that surfaces most of these hidden costs before you commit budget, in how to map your business workflows before you automate them with AI.
A useful discipline here, borrowed from how BCG's research describes the gap between AI leaders and everyone else, is the 10-20-70 rule: roughly 10% of the effort in a successful AI initiative goes to the algorithm itself, 20% to data and infrastructure, and 70% to the people and process work around it. Companies that allocate budget that way, rather than spending most of it on the model and treating change management as an afterthought, saw 1.5 times higher revenue growth and 1.6 times greater shareholder returns over three years in BCG's dataset. If your AI budget is 70% technology and 10% change management, you have the ratio backwards, and your ROI math will eventually catch up with you.
Once the cost side is honest, the benefit side needs a model that fits the use case rather than the generic "hours saved" estimate applied everywhere. A few approaches cover most situations:
None of these replace the fully-loaded TCO from the previous section. Think of TCO as the denominator that's always running in the background, and pick one of the models above to build the numerator for each specific initiative.
The frameworks above set the ground rules. What follows is the starting metric set for the six functions where AI spend is currently concentrated. None of these lists is exhaustive. Pick two or three, get a real baseline on them, and add more once those are trustworthy.
Average handle time is the wrong headline metric now, because it rewards speed even if the underlying issue isn't fixed. Two better ones:
Resolution durability: the share of AI-handled conversations that stay closed for seven to ten days without the customer reopening the same issue. A high "resolved" rate paired with a high reopen rate is a system closing tickets without solving the underlying problems.
Cost per resolution, split by channel: what it costs the business per AI-resolved conversation versus per human-escalated one, so leadership sees the real blended unit economics rather than a single average that hides the mix.
This is the function where the gap between how people feel and what the telemetry shows is widest, and best documented. In GitHub and Accenture's joint enterprise study, developers using Copilot accepted roughly 30% of suggestions, and that acceptance translated into an 8.69% increase in pull request volume and, notably, a 15% increase in the pull request merge rate and an 84% increase in successful builds. Merge rate and build success are the numbers that matter, because they show the extra output wasn't lower-quality churn.
Track Change Failure Rate (the share of production deployments that require a rollback or hotfix) alongside any velocity metric. If deployment frequency rises but CFR rises with it, you're not measuring productivity, you're measuring a debt you'll pay later. Google's DORA team built a public ROI of AI-assisted software development calculator specifically so engineering leaders can stress-test their own assumptions about the adjustment period and failure-rate impact before presenting a number to the CFO, rather than assuming the rosiest case.
Marketing Efficiency Ratio (MER), total revenue attributable to AI-assisted channels divided by total spend on those channels, is the number CFOs look at, and it's harder to game than channel-level ROAS because it can't be inflated by shifting spend between channels. See HubSpot's explainer for the full calculation.
For anything involving personalization or recommendation, hold back a randomized 10% of the audience from the AI-driven treatment. The difference between that group and everyone else is close to the actual incremental effect, isolated from seasonality and market movement that would otherwise get credited to the model.
Better AI-assisted candidate matching shows up first in reduced early turnover, and turnover is expensive: HR research commonly puts the fully-loaded cost of replacing an employee at roughly half to twice their annual salary, depending on seniority. Track first-year attrition for AI-assisted hires against your historical baseline rather than screening cost alone, since a cheaper screen that produces worse matches is a net loss dressed up as a win.
Also worth knowing before you trust any adoption survey: Wharton's Ethan Mollick has documented what he calls "secret cyborgs", employees who get real value from AI tools and don't tell their managers, often out of concern it will look like cheating or invite a headcount conversation. If your self-reported adoption number looks low, that's a reason to look at system-level usage logs before concluding people aren't using the tools.
Accounts payable is one of the cleanest places to benchmark, because Ardent Partners' 2024 State of ePayables research gives a real external baseline: the average organization spends $9.40 and about 9.2 days processing a single invoice manually. If your AI-assisted AP process isn't meaningfully below both numbers, you have a baseline to compare against and a target for what "meaningfully better" should look like.
In compliance and fraud monitoring, machine-learning transaction monitoring has been shown to cut false-positive alert volumes substantially, which matters less for the raw percentage and more for what it frees up: analyst hours redirected from chasing noise to reviewing the alerts that are worth their time.
Touchless processing rate: the share of a physical or digital operational step completed without manual intervention, tracked per process rather than as a single company-wide figure, since a blended number hides which processes are working.
Unplanned downtime, tracked before and after predictive maintenance deployment against a full seasonal cycle, not a thirty-day snapshot that happens to land during a quiet period.
Measurement only works if it's built into the rollout from day one, not bolted on after someone asks for a number. A ninety-day structure keeps that honest without turning into a permanent audit project.
The first thirty days are for recording the current unit cost, cycle time, and error rate of the process you're about to touch, over a full business cycle rather than a convenient week. This is also when you pick which measurement approach from the table above fits the initiative and label it Defend, Extend, or Upend, so nobody applies the wrong yardstick six months later.
The next thirty days are the pilot. Track adoption, but treat it as an early signal, not the final scorecard. This is where the J-curve shows up, so expect a temporary dip in output or quality and don't panic when it happens, panic when it doesn't recover.
The final thirty days are the comparison against the baseline you recorded, not an estimate. Whatever capacity gets freed up needs an explicit next destination, more volume, higher-value work, or a deliberate decision to reduce headcount growth, because reclaimed time that has nowhere to go quietly evaporates and the ROI evaporates with it. If you want a structured way to check whether your organization is ready to run this cycle well before you start, our AI readiness checklist is a reasonable place to start, and if you want to see how the major public maturity models compare before picking one to benchmark against, we broke down 17 AI maturity frameworks side by side.
Where to start
Every metric in this piece assumes you already know where AI sits in your operating model and where it doesn't. If you're not sure yet, the AI Operating System Scorecard gives you that starting baseline in under fifteen minutes.
Take the AI Operating System Scorecard →
There isn't one that works for every case, which is the point of this piece. What matters more than any specific metric is labeling the initiative correctly first, a productivity tool (Defend), a redesigned process (Extend), or a genuine new bet (Upend), because that label determines which metric is even the right one to look at.
Long enough to get past the J-curve, which for most process-level ("Extend") initiatives means at least one full quarter after the pilot ends, not the pilot period itself. Judging a rebuilt process in its first thirty days almost always catches it at its temporary low point.
Both, but they answer different questions. Department-level metrics tell you whether a specific initiative is working and should keep or lose funding. A single company-wide number is useful for board reporting, but only if it's built by rolling up honestly-measured department numbers rather than estimated top-down, which is how most inflated AI ROI claims get made in the first place.
The AI Operating System Scorecard is a diagnostic tool that measures whether your business is structurally built to make AI compound, across nine dimensions including how decisions get made, how clearly your processes are defined and how your team is using and integrating AI.
The output is a clear view of where your biggest leverage gaps are and where to focus first.
One practical AI operating-system insight bi-weekly.
No fluff, no spam.
© 2026 AV Ventures Limited trading as Orbflo | All Rights Reserved
