A CEO measures return on AI the same way as any other investment: what an outcome costs now, against what it cost before and what it is worth. For AI that means one unit above all, cost per successful outcome: the full cost of an AI workflow divided by the runs that met a quality bar, such as a ticket resolved without a human or a code change merged. Adoption tells you whether people use the system; margin and cycle time tell you, a quarter later, whether it paid. A monthly board report should carry all three, in that order, with the same lines every month.
Most AI reports start from spend because spend is the easiest number to get. Spend is an input. On its own it cannot say whether a rising bill means waste or a feature customers love.
Why spend and adoption are not return
Two common reports fail the same way. A spend report shows the provider bill rising 40% and invites a cut. An adoption report shows 80% of staff using an assistant and invites a celebration. Neither says what the money bought.
The FinOps Foundation describes how AI unit economics should mature: it "often starts with cost per token and expands toward outcome oriented measures," giving cost per assist, cost per agent action and cost per case deflected as examples1. Its Tokenomics paper defines the outcome measure precisely: cost per successful outcome is the "total cost of a multi-step process, counting only the runs whose output clears the quality floor for that workload," and "failed and discarded runs are cost, not completions"2.
That last sentence is the one leaders miss. A model with half the per-token rate that fails twice as often costs the same per finished task and costs more in rework. The detailed method is in cost per successful task; this guide is about what to put in front of a leadership team.
The metrics, in one table
| Metric | How it is computed | Leading or lagging | Who owns the number |
|---|---|---|---|
| Active use | People or customers who used the AI feature this month ÷ those who could | Leading | Product |
| Cost per successful outcome | Total workflow cost ÷ runs that met the quality bar | Leading | Engineering + finance |
| Cost per resolved ticket | AI cost of support conversations ÷ tickets closed without a human and not reopened | Leading | Support |
| Success rate | Runs that met the bar ÷ all runs | Leading | Engineering |
| AI cost of goods per customer | Provider usage attributed to a customer ÷ that customer's revenue | Lagging | Finance |
| Gross margin change | Margin on AI-using customers or products against a baseline | Lagging | Finance |
| Cycle time or handling time | Time from request to outcome, before and after | Lagging | Function owner |
| Unattributed or unpriced spend | Usage that cannot be tied to a workflow or has no known rate ÷ total | Hygiene | Platform team |
Three definitions decide whether this table can be trusted:
- The quality bar. Write it down per workflow before launch: a ticket counts as resolved if it was closed without a human and not reopened within seven days; a code change counts if it merged and was not reverted within 30 days. Without a written bar, success rates drift upward.
- Full cost. Provider usage, AI tool subscriptions and the platform around them, plus the people who build, review and correct the output. Report them as separate lines, and add them only when computing cost per outcome.
- The baseline. What the same outcome cost before: a human-handled ticket, a change shipped without the tool. Without one, cost per outcome is a number with nothing to compare it to.
Cost per resolved ticket, worked through
Two things in this example matter more than the totals. First, the denominator is resolved tickets, not conversations: if the resolution rate falls from 30% to 20%, the cost per resolved ticket rises by half with no change in the bill. Second, the provider usage is often the smallest line. A board that only sees the $1,720 sees the wrong problem.
Margin impact of AI features
For a company that sells software with AI inside it, AI usage is cost of goods sold. The question a CFO asks is what share of each customer's revenue it consumes, and how that share behaves as usage grows.
Report the distribution, not only the average: median and 90th-percentile AI cost per customer, and the number of customers above a threshold you choose. The decisions this supports are concrete: usage limits per customer, a higher plan for heavy users, a lower-cost model for the bulk of requests, or caching for a shared prefix. The pricing side is covered in AI feature unit economics.
Adoption versus value
Adoption is a leading indicator: if nobody uses a feature, it cannot return anything. It becomes harmful when it is the target. Teams asked to raise "weekly active AI users" find ways to raise it.
Pair every adoption metric with the value metric it should move:
| Adoption metric | Value metric it should move | Warning sign |
|---|---|---|
| Agents handling support conversations | Cost per resolved ticket, reopen rate | Resolution rate flat while conversations grow |
| Developers with a coding-agent seat | Lead time to production, change failure rate | Seat use rises, lead time unchanged after a quarter |
| Sales staff using an email assistant | Reply rate, time per qualified meeting | Messages sent rise, replies do not |
| Customers using an in-product AI feature | Retention or expansion of those customers | Usage concentrated in a few accounts with rising cost of goods |
Coding tools: seats, usage and what to measure
Coding agents are the AI spend line that grows fastest in many engineering budgets, and they can be bought two ways. Per seat: ChatGPT Business, which includes Codex, is listed at $20 per user per month billed annually and $25 billed monthly4. Per token: Codex with an API key is billed at API rates, and OpenAI warns that API token prices are separate from subscription usage and should not be used to estimate included tasks4. For Claude Code on API billing, Anthropic reports that across enterprise deployments the average is around $13 per developer per active day and $150 to $250 per developer per month, with 90% of users below $30 per active day5. Anthropic recommends starting with a pilot group to set your own baseline5.
These are cost figures, not returns. Measure value with numbers engineering leadership already uses: changes merged, lead time from first commit to production, change failure rate and incidents after release, each compared with the same team's previous quarter. Lines of code and prompts per day are activity and easy to inflate. Anthropic's own dashboards report accepted lines per member5; treat that as a usage signal, not a productivity measure. The cost mechanics are covered in coding agent costs for teams.
The monthly AI report to the board
A board does not need a dashboard. It needs the same short table every month, each line with a target and one sentence explaining any movement. A template:
| Line | This month | Last month | Target | What explains the change |
|---|---|---|---|---|
| Estimated provider usage (all AI workflows) | ||||
| AI tool and platform subscriptions | ||||
| Share of usage attributed to a workflow and priced | ≥ 95% | |||
| Top workflow: cost per successful outcome | ||||
| Top workflow: success rate | ||||
| Second workflow: cost per successful outcome | ||||
| AI cost of goods as % of revenue (median, p90 customer) | ||||
| Lagging outcome (handling time, lead time or margin) | ||||
| Incidents: provider outages, model retirements, spend limits hit | ||||
| Decisions needed from the board |
Rules that keep it honest:
- Label estimates as estimates. Usage cost computed from tokens and rates is an estimate of what your providers will bill. Reconcile it with the invoices monthly and state the gap.
- Never sum unlike things silently. Provider usage, subscriptions and staff time are separate lines. A combined "AI cost" is for the cost-per-outcome calculation only.
- Report the denominator. Every cost per outcome shows how many outcomes it was divided by.
- Show unpriced and unattributed spend. A workflow you cannot see is the one that surprises you.
- Same lines every month. A metric that disappears from the report is a finding.
The operational version of this report, with weekly and monthly cadences and alerting, is in the AI spend report leadership actually reads.
Common ways the numbers mislead
- Counting outputs, not outcomes. Drafts generated, conversations handled and code suggested are activity.
- No counterfactual. If ticket volume fell for a seasonal reason, the assistant did not cause it. Compare against a baseline period or a control group where you can.
- Ignoring rework. Human time spent correcting AI output belongs in the cost of the outcome.
- List rates when you pay negotiated ones. If your contract carries different rates, estimates at list rates overstate or understate cost.
- Treating one month as a trend. Model, prompt and traffic changes move unit cost; look at three months before acting on a direction.
Measuring cost per outcome with INFRO
INFRO is a control plane between your applications and the AI provider accounts you already hold; your providers bill you directly, and every amount INFRO shows is an estimate of that provider cost, never including INFRO's own subscription. It covers the cost side of this report and leaves the value side to you.
Cost per run by workflow and customer. Tag requests with metadata.workflow and metadata.trace_id and INFRO treats each pair as a run. Unit economics returns, per workflow, feature, end customer or cost center, the requests, runs, total estimated cost, cost per request and the median and 90th-percentile cost per run, with the unpriced share beside every row. Join that with your own success record on the run id to get cost per successful outcome.
Rates and reconciliation. Negotiated rates entered per model replace list rates in the estimate, and reconciliation compares estimates daily with the cost reported by OpenAI's and Anthropic's own cost APIs. Both are on every plan.
The leadership view. The console's Summary shows the budget cycle's estimated spend against budget and its projection, with four status lights, and a monthly report is emailed on the 2nd and kept as a page for any past month. See Summary and reports.
What INFRO does not do: it does not see whether an answer was correct, whether a ticket stayed closed or whether a change merged, and it does not see traffic that goes straight to a provider or seat-based tools such as ChatGPT Business. Those numbers come from your own systems.