Measuring AI by Work, Usage, and Outcomes
A short guide on how to price AI products by usage, work delivered, and outcomes.
Puneet Anand
Seat pricing still lives! But it assumes that more users means more value. That was true when software was something people operated by hand.
An AI agent can finish more work independently with fewer people, and every request it makes adds compute cost, so a seat count now tracks neither the value a customer receives nor the cost of serving them.
Most AI companies have not responded by jumping to outcome pricing. They have added usage charges on top of a subscription and kept going.
We typically see a combination of the following layers:
Most products combine two or more of these with a base subscription.
-
Usage
Tokens, API calls, minutes, or credits. The customer pays whether or not the work succeeded. Commonly seen for APIs and infrastructure, where cost scales with consumption and the customer is close enough to the system to predict their own spend.
It is the easiest to meter because it requires no judgment about what happened. It is also the least connected to what the customer came for.
-
Work unit
For example, a document produced, a contract reviewed, or a questionnaire completed. Payment depends on the work finishing, not on how well it went. For document workflows, a fee per completed task is easier for a buyer to reason about than a token count they have no way to estimate.
A unit generally won't map to a single model call or a single session, and most products have more than one kind of trackable units.
-
Outcome
For example, a support ticket that stayed closed, a legal contract accepted without a rewrite, or a disputed invoice collected. Payment depends on a result, which is usually known some time after the work finished. For support agents, verified resolutions can work alongside a work unit charge for the cases that did not resolve, so the effort spent on them is not invisible.
This layer needs a waiting period and reproducible evidence behind each charge.
-
Share of value
A percentage of money recovered or generated. For recovery products, a share of what was recovered fits how those buyers already purchase, so the pricing model needs less explaining than the product does.
It depends entirely on attribution.
-
Seats and bundled access
For copilots, the value is real but hard to attribute to any one task, and forcing a unit definition onto it produces numbers nobody trusts.
Seat pricing has not disappeared as SaaS bears predicted! It is a weaker proxy than they used to be, and for some products they are still the most honest one available.
What companies are doing
Kyle Poyar and Metronome’s 2026 survey found that 37% of software and AI companies used hybrid pricing, while 5% named outcome pricing as their primary model.
Outcome pricing is attracting a lot more interest in the AI landscape but it is business or use-case specific to implement and there can be multiple edge cases that need handling.
A vendor has to agree with the customer on what counts as success, then show it happened, every month, for every unit of work.
That requires accurate reporting and attribution to be trusted for pricing by your customers.
Start by defining the unit of work
Is a model call a unit of work? Is a session?
In most products the unit is something a customer recognizes as value like one questionnaire, one claim, one vendor assessment, and it may or not fit into a single session.
A questionnaire might be drafted on Monday, accepted on Thursday by a different person, and touched by three separate AI calls along the way.
Measuring sessions tells you about usage patterns. It does not tell you how many questionnaires got done.
On the other hand, one session might deliver multiple work units.
Two more points on this:
One event may not be enough to capture delivered value A submitted answer might mean the AI drafted it, or it might mean someone wrote it by hand and the AI didn’t contribute to it.
But if you consider a simple sequence: the AI draft was created, and then the answer was submitted, that helps you measure the AI was used to deliver value.
A product usually has multiple kinds of billable work. A support platform gets a ticket deflected before a human saw it, or a ticket resolved by an agent with AI assistance, and a refund processed end to end are three different pieces of work, likely worth different amounts, and finished in different ways.
Most of this can start without new instrumentation. The events and the AI traces are usually recorded; they are just sitting in a warehouse, user interface, and an AI observability tool that do not know about each other. The new work is matching the records that belong to the same piece of finished work.
That matching is most of what we work on: connecting user events to the AI traces that produced them, and then turning finished units of work into numbers that can be relied on in an invoice.
Work unit vs. a successful work unit (= outcome)
A completed unit of work can be called successful if it achieves something of high value.
Success could be defined as specific criteria on finished work. For instance, an AI agent resolving a case is much more useful than surfacing the right policy.
Success could be decided later than when the work is done, and possibly by someone else in a workflow.
For example, the questionnaire is submitted on Thursday; whether it was accepted with few edits shows up over the following week, in a different system, from a reviewer who was not the person the AI was helping.
Some success criteria are absences. “No override within seven days” and “the ticket was not reopened” cannot be observed at the moment work finishes. They require waiting out a defined period and then declaring that nothing happened.
Success criteria could also live in the semantics of the AI agent traces or outputs. Checking off with a rule isn’t applicable here.
Whether an AI draft actually answered the question asked, or an AI summary dropped the one clause that mattered, lives in the meaning of what the AI produced, so it needs semantic evaluation with extremely high calibration.
Short summary
Start with a base fee and metered usage. Add outcome pricing where success is clear, attributable, and verifiable without argument.
Charge for the work customers value. Keep measuring what that work costs you, and keep the evidence for both.
Happy pricing!
Announcing DataFramer: AI Workflow Intelligence
Three roles, one question: is our AI actually working? DataFramer is the AI Workflow Intelligence Platform built to answer it.
Puneet Anand How DataFramer Measures Whether an AI Answer Is Right
In production there's no answer key. Here's how we calibrate LLM judges to your experts' definition of correct, and keep them honest.
Puneet Anand Confidently Wrong AI Is a Business Problem
The dangerous AI mistakes aren't the obvious ones. They're fluent, confident, and wrong, and the business pays before engineering ever knows.
Puneet Anand Get started
Start improving your business outcomes.
Understand how AI is affecting your users and business. Make every AI workflow more accurate, more used, and more valuable.