This article examines commercial pricing structures. Part 4 of the Verified Work Series examines the underlying unit economics.
- AI is changing software from a place where people perform work into a system that can perform part of the work itself.
- That makes the number of users a less complete measure of value.
- The practical response is not necessarily pure outcome-based pricing. It is to define the work, verify the result, separate completion from human handoff, and then choose a commercial model that reflects value, cost, and risk.
AI is separating software value from human access
For most of the software-as-a-service era, pricing by the seat was logical.
A company paid for each employee who could log in because the software gave people a place to perform their own work.
A CRM stored customer information, but a salesperson entered and interpreted it. An accounting system organized financial records, but an employee reviewed and reconciled them. A help-desk platform routed tickets, but a support representative resolved them.
The software provided access, structure, and productivity. The human still performed the work.
AI begins to change that relationship.
When an AI-enabled workflow extracts invoice data, compares it with a purchase order, identifies a discrepancy, prepares an accounting entry, and routes an exception to the correct reviewer, the customer is no longer buying only access to a tool.
The customer is buying some portion of the work itself.
That does not mean seat pricing will disappear. It means that headcount is becoming a less complete proxy for the value software delivers.
Menlo Ventures estimates that enterprises spent approximately $37 billion on generative AI in 2025, compared with a revised $11.5 billion estimate for 2024 under its current methodology. It estimates that approximately $19 billion—slightly more than half—went to the application layer. These are Menlo's market estimates, based on a survey of roughly 500 US enterprise decision-makers combined with a bottom-up market model; they are not audited totals for the entire market.
The important point is not only that businesses are spending more on AI.
More spending is reaching applications that research, draft, classify, reconcile, respond, and execute—not only infrastructure or software that employees operate manually.
As AI performs more work directly, the natural commercial question changes from How many people need access? to:
What work was completed, at what quality, and with what evidence?
The unit of value is evolving
A simplified view of the shift is:
Software license
Pay to install and own the tool.
Per-user seat
Pay for each person with access.
Usage or output
Pay for consumption or units produced.
Verified operational outcome
Pay in relation to work completed, verified in the real business system.
This is not a universal sequence that every product must follow.
Seat pricing remains useful when value scales with the number of active users. Usage pricing remains useful when consumption is measurable and closely connected to cost. Output pricing can work when a unit of production is clear.
Outcome-linked pricing becomes more credible when the result is specific, attributable, quality-adjusted, time-bounded, and independently verifiable.
AI application companies are already experimenting with per-seat, per-workflow, consumption-based, and per-outcome models. A 2026 analysis from Andreessen Horowitz also noted the tension between customers wanting pricing tied to performance and still needing budget predictability.
The future is unlikely to be one universal pricing model. It will be a closer connection between the commercial unit and the work actually delivered.
Three different questions are often treated as one
"Outcome-based pricing" is frequently used as a broad label. In practice, three separate questions need to be answered.
| Question | What it means | Example |
|---|---|---|
| What creates business value? | The operational result the customer wants | An invoice is accurately validated and posted |
| How is the result measured? | The evidence showing whether the result occurred | The final record exists in the accounting system and passed required checks |
| How is the service priced? | The commercial agreement between customer and provider | Fixed fee, managed-service fee, usage fee, outcome-linked fee, or a combination |
These questions are connected, but they are not interchangeable.
A company can measure success through verified outcomes while charging a fixed implementation fee and an ongoing managed-service fee.
A company can charge per document or transaction without confirming that the document or transaction produced the intended business result. That is usage- or volume-based pricing, not necessarily outcome-based pricing.
The central distinction is:
Measuring value through outcomes does not require pricing exclusively by outcomes.
A commercial arrangement may reasonably include payment for workflow analysis and implementation; system integrations; ongoing monitoring and maintenance; model and tool consumption; human review and exception management; and a component linked to verified results.
The pricing model should reflect both the value delivered to the customer and the real cost and risk involved in delivering it.
An output is not always an outcome
AI makes visible activity easy to produce. It can create a document, classify a record, draft a response, or call an API.
Those actions may be useful. They do not necessarily mean the business process is complete.
| AI activity or output | More meaningful business outcome |
|---|---|
| Drafted a customer response | The issue was resolved under defined service criteria |
| Extracted fields from an invoice | A valid record was accurately posted to the accounting system |
| Generated a weekly report | The report used current authoritative data and reached the intended recipients |
| Researched a prospective customer | The lead met defined qualification criteria and supporting evidence was recorded |
| Prepared a refund | The authorized refund was issued correctly and reflected in the relevant systems |
| Reported task completion | The intended final business state was independently confirmed |
A useful outcome needs more than a count. It should be:
- Specific. Both parties understand exactly what qualifies.
- Observable. The result can be confirmed, preferably in an authoritative system of record.
- Quality-adjusted. Errors, policy violations, and downstream rework are not rewarded.
- Sufficiently attributable. The provider is not credited or penalized for events outside the system's reasonable control.
- Time-bounded. The result can be confirmed within a defined verification period.
- Resistant to gaming. Maximizing the commercial metric does not damage the underlying business process.
For example, "hours saved" may be useful as an estimate of value, but it should be based on an observed baseline and measured human effort—not simply on an AI-generated estimate of how long the work might have taken.
A correct handoff is valuable—but it is not a completed outcome
Reliable AI workflows do not complete every case autonomously.
Suppose an AI system compares an invoice with a purchase order and finds a tax discrepancy. It stops the payment, preserves the evidence, and sends a structured review package to the finance manager.
The system behaved correctly. But the invoice has not yet been processed.
These two facts should not be collapsed into one metric.
| Workflow result | Business process completed? | Correct control decision? |
|---|---|---|
| Verified completion | Yes | Yes |
| Appropriate human handoff | No | Yes |
| Human-resolved handoff | Yes, after review | Yes |
| False completion | No | No |
| Missed escalation | No | No |
An appropriate handoff may prevent a costly error and preserve substantial business value. It should be measured and recognized.
But it should not automatically be reported—or billed—as though the original business outcome had already been completed.
A commercial agreement can assign different treatment to verified automated completions; cases correctly prepared for review; cases jointly resolved by AI and a person; unsuccessful attempts; avoidable errors; and rework caused by incorrect processing.
Those definitions should be agreed before deployment, not negotiated after the billing period ends.
Why pure outcome-based pricing is difficult
The appeal is straightforward: The customer pays when value is delivered.
The implementation is more complicated.
1. The provider may not control the entire outcome
An AI system may qualify a sales lead, but it does not control whether the prospect buys. It may prepare a valid invoice package, but it does not control whether a customer pays on time. It may produce a recommendation, but it does not control whether a manager acts on it.
The farther the pricing metric is from the work the system directly controls, the greater the risk of disagreement over attribution.
A practical metric is often a proximal operational outcome: a result that creates value, can be materially influenced by the system, and can be independently verified.
Examples include a correctly posted invoice; a complete compliance package; a qualified case ready for human review; a validated customer record; or a report delivered with confirmed data and recipients.
2. Volume can hide poor quality
A provider paid for every "resolved" support case may have an incentive to close cases too early. A provider paid for every processed document may increase throughput while creating corrections for downstream employees.
An outcome definition should therefore include quality conditions such as accuracy; required approvals; absence of duplicate processing; acceptable rework; reopened-case windows; policy compliance; and confirmation in the final system of record.
Otherwise, the pricing model rewards visible activity rather than useful work.
3. Cases are not equally difficult
One invoice may be standard and complete. Another may involve several currencies, missing documents, tax discrepancies, or conflicting supplier records.
Charging the same amount for each case may create unpredictable margins or encourage a provider to favor easier cases.
Possible responses include defined case classes; complexity bands; explicit exclusions; separate pricing for exceptions; minimum volume commitments; or different commercial treatment for human-assisted resolution.
4. Outcomes can change after they are recorded
A support case may be reopened. An accounting entry may be reversed. A report initially accepted may later fail a compliance review.
A contract therefore needs a verification window; a rule for reopened or reversed outcomes; a correction process; a dispute process; and an identified authoritative system.
5. Costs and attribution can be difficult to predict
AI services incur variable costs from model usage, retrieval, tools, infrastructure, monitoring, and human review.
Outcome-only pricing may require the provider to absorb those costs even when completion depends on external data, customer action, or third-party systems.
A 2025 a16z study based on conversations with more than two dozen enterprise buyers and a survey of 100 CIOs across 15 industries found that buyers' concerns about outcome-based pricing included unclear outcome definitions, unpredictable costs, and attribution. The report said most surveyed CIOs still preferred usage-based pricing for AI applications.
That does not show that outcome-linked pricing cannot work. It shows why definitions, telemetry, attribution, and predictability must come before the pricing promise.
Hybrid pricing is often the practical bridge
Bain reviewed more than 30 established SaaS vendors introducing generative AI capabilities, excluding AI-native vendors.
It found that roughly 35% had increased or adjusted per-seat pricing while bundling AI features, while approximately 65% had introduced a hybrid model that added an AI-related meter—such as usage or feature access—to seat-based pricing.
None of the vendors in that sample had fully moved to AI usage- or outcome-based pricing. Bain described hybrid pricing as the dominant interim strategy and emphasized the need for telemetry, billing capabilities, commercial readiness, and customer predictability.
A hybrid structure can separate different types of value and cost.
| Commercial component | What it may cover |
|---|---|
| Implementation fee | Workflow analysis, integration, configuration, testing, and deployment |
| Base platform or managed-service fee | Availability, monitoring, maintenance, policy updates, support, and governance |
| Usage or volume fee | Documents, cases, workflows, tool calls, or other variable workload |
| Outcome-linked component | Verified completions or another agreed operational result |
| Performance adjustment | Shared upside or downside relative to an agreed baseline or service level |
Not every engagement needs every component.
The purpose is not to make pricing more complicated. It is to avoid asking one metric to represent several different things.
Implementation work should not be disguised as an outcome fee. Variable operating costs should not be ignored. Customers should not pay an outcome premium for results that cannot be verified. And providers should not accept responsibility for business events they cannot reasonably control.
Define the completion contract before the price
Before choosing a commercial meter, the parties should define the workflow itself.
A practical completion contract should specify:
| Contract element | Question |
|---|---|
| Unit of work | What is one case, transaction, document, or workflow? |
| Target state | What must be true in the real business system for completion? |
| Quality conditions | Which checks, approvals, and policy requirements apply? |
| Authoritative evidence | Which system or receipt confirms the result? |
| Attribution boundary | Which parts are controlled by the provider, customer, or third party? |
| Verification window | How long must the result remain valid before it qualifies? |
| Exception classes | Which cases require human judgment or separate treatment? |
| Correction rule | What happens if an outcome is reversed or found to be incorrect? |
| Commercial treatment | How are completion, handoff, failure, and rework billed? |
Pricing should follow the completion definition. It should not substitute for it.
Begin with one measurable workflow
This approach is easiest to test where operational pain is visible and decision-making involves fewer layers.
Where internal capacity for workflow design, integrations, AI evaluation, and ongoing monitoring is limited, scope discipline becomes especially important.
The starting question should not be: Which AI pricing model should we adopt?
It should be:
Which bounded workflow produces a result we can define, observe, and verify?
Possible starting points include reconciling a defined class of invoices; assembling a recurring operations report; processing standard customer-service requests; checking document completeness; preparing routine approvals; or updating records under clearly defined rules.
Before choosing the commercial unit, establish:
- the current volume and human effort;
- the target business state;
- the required quality and policy conditions;
- the evidence needed to confirm completion;
- the cases requiring human judgment;
- the expected cost of exceptions and review; and
- the process for corrections and disputes.
A pilot can then show whether the most appropriate commercial unit is a seat; a workflow; a case; a document; an action; a verified completion; or a combination.
What Nova Epitome means by "measured by outcomes"
At Nova Epitome, measuring by outcomes does not mean that every engagement must use a pure contingency or success-fee model.
It means that project success should not be defined only by whether a model was connected; whether a demonstration worked; how many users received access; how many tokens were consumed; how many drafts were generated; or how many tasks the AI attempted.
The more meaningful question is whether the intended operational state was achieved and verified.
That requires a measurable definition of completion; bounded permissions; evidence from the relevant systems; independent confirmation where appropriate; separate treatment of exceptions and human handoffs; monitoring for false completion and rework; and commercial terms that reflect the actual workflow.
We measure engagement success through verified operational outcomes. Commercial terms may combine implementation scope, usage, managed support, and outcome-linked components.
This protects both sides.
The customer receives a clearer account of what the system actually delivered. The provider is not forced to accept responsibility for outcomes outside the workflow's control. And both parties have a stronger basis for improving the system over time.
The future is not one universal AI pricing model
Seat pricing will continue to make sense for many kinds of software. Usage pricing will remain appropriate when consumption is measurable and connected to cost. Output pricing can work when a production unit is clear.
Outcome-linked pricing becomes more credible when the result is specific, observable, attributable, quality-adjusted, time-bounded, and independently verifiable.
The direction is not simply seats are disappearing. It is:
Software value and pricing are moving closer to the work performed and the value actually delivered.
For buyers, that changes the opening question.
Instead of asking How many people need access?, businesses can increasingly ask:
What work should the system complete, how will we know it was completed correctly, and how should the value and risk be shared?
That is a more difficult commercial conversation. It is also a more honest one.
Related reading
The Verified Work Series examines the reliability side of this argument: Part 1 — why finishing the work is the hardest part, Part 2 — what tamper-evident records can and cannot prove, and Part 3 — when AI should stop and hand control to a person. Part 4 — The Economics of Verified Work examines the cost model that should be measured before selecting a commercial pricing structure.
References
- Menlo Ventures, 2025: The State of Generative AI in the Enterprise — market estimates based on a survey of roughly 500 US enterprise decision-makers combined with a bottom-up market model.
- Bain & Company, Per-Seat Software Pricing Isn't Dead, but New Models Are Gaining Steam — pricing-model analysis of more than 30 established SaaS vendors.
- Andreessen Horowitz, How 100 Enterprise CIOs Are Building and Buying Gen AI in 2025 — survey of 100 CIOs across 15 industries plus enterprise-buyer interviews.
- Andreessen Horowitz, Surviving AI Price Wars Without Destroying Your Business — analysis of seat, workflow, consumption, and outcome pricing units and predictability.