What You Charge For: Access, Attempts, and Success
For an AI SaaS provider, the first serious pricing choice is not whether the invoice should look familiar. It is whether the provider is charging for access, for an attempt to perform a task, or for a result that the customer accepts as successful. This chapter focuses on the difference between conversation-based pricing and outcome-based pricing so the reader can see how each contract allocates performance risk and handles buyers whose value and task difficulty are partly hidden.
The distinction matters because an AI service does not face one uniform customer or one uniform task. One customer may use the service for routine requests that succeed often. Another may bring rare, difficult cases that are highly valuable when solved but frequently require human intervention. If both customers are charged under the same success-contingent rule, the provider is not simply rewarding performance. The provider is also making a bet about information it cannot fully observe.
An Attempt Is Not a Success
The paper Pricing AI as a Service formalizes two ways to make that bet. Conversation-based pricing, or CBP, charges a fixed fee per invocation. An invocation is an attempt to use the AI service: a request is submitted, the system processes it, and the contract charges whether or not the desired result is ultimately produced. Outcome-based pricing, or OBP, charges only upon success. The provider receives payment when the service meets the contract’s definition of a successful outcome, rather than merely when it has consumed resources or returned a response.
These are not just two ways to display the same price. They place different events at the center of the transaction. CBP makes the attempt the billable unit. OBP makes the verified result the billable unit. A customer that values budget predictability may prefer to know the cost of initiating work. A customer that distrusts paying for failed attempts may prefer to transfer more performance risk to the provider. The provider must decide whether the added appeal of success-contingent payment is worth accepting more uncertainty about revenue.
Consider an AI service used to handle customer requests. Under CBP, the provider charges when the service takes on a request. If the request is unresolved and passes to a human agent, the provider has still performed a billable invocation, although the customer may incur additional internal costs. Under OBP, the provider is paid only if the request meets the agreed success condition. The customer has stronger protection against paying for an unsuccessful event, but the provider now bears more of the consequences of difficult requests, ambiguous outcomes, and disputes over whether the service actually solved the problem.
That does not mean CBP ignores quality or that OBP measures value perfectly. A fixed fee can be paired with service levels, credits, monitoring, or renewal decisions. A success fee can be distorted by a narrow definition of success, delayed verification, or outcomes that depend on the customer’s own actions. The contract’s primary payment event simply makes some risks more explicit than others.
The following sequence captures the difference without implying that either design is universally superior:
The human fallback is not an optional detail in this picture. If an AI service returns an answer that a person must inspect, repair, or replace, the customer’s cost continues after the service’s payment event. A contract may therefore be favorable at the provider boundary and unfavorable at the workflow boundary. The reverse can also happen: a service may fail on some individual requests but still reduce the total burden on a well-organized human team.
The economic comparison must keep its denominator straight. CBP asks how much revenue an invocation produces. OBP asks how much revenue a successful outcome produces and how often that outcome occurs. Neither number alone reveals profit. For a provider, expected revenue from a success-contingent contract depends on the payment per success multiplied by the probability of success for the relevant customer and task mix. For a customer, expected cost includes not only the payment but also the work that remains when the AI does not finish the task.
Hidden Types Turn Payment into Screening
The informational problem becomes clearer when buyers differ in ways the provider cannot directly observe. The SSRN paper models private information about valuation and task difficulty. Valuation describes how much a buyer benefits from the service. Task difficulty affects the AI service’s probability of success. These are separate dimensions: a buyer may care greatly about an outcome while submitting tasks that are unusually hard for the AI to complete.
In a simple binary-type model, the paper reports that CBP reduces to a standard screening problem. In plain terms, the provider is trying to offer terms that cause different buyer types to select arrangements appropriate to their willingness to pay. Because the charge is attached to the invocation, the payment rule does not itself multiply the buyer’s private type by an unobserved success event. The provider still faces incomplete information, but the contract’s main informational task is comparatively familiar.
OBP adds another layer. The amount the provider receives depends on success, and success depends on the type of task the buyer brings. A buyer’s willingness to pay and the AI’s probability of success can therefore interact inside the payment rule. The provider is not only screening how much the buyer values the service; it is also indirectly screening how likely the buyer is to generate a payable outcome. This is why the paper describes OBP as a two-dimensional screening problem in the binary-type model.
A useful way to think about the difference is to imagine two buyers who are equally willing to pay for a successful result. The first uses the service for routine requests that succeed frequently. The second uses it for difficult cases that often require escalation. Under a fixed invocation fee, the provider receives payment for taking on both streams of work. Under a success fee, the second buyer can be attractive only if the price per success compensates for the lower success frequency and for the provider’s cost of handling attempts that do not pay.
The customer may also behave differently under the two contracts. A success-contingent price can make experimentation less painful because the customer does not pay the headline fee when the service fails. But it can encourage disputes about what qualifies as success, or lead the customer to submit tasks whose value is high but whose difficulty is poorly matched to the system. A fixed fee may encourage broader use because each invocation has a known price, while also exposing the customer to the cost of unsuccessful attempts. These are incentive effects, not merely accounting preferences.
The paper’s abstract describes a “virtual type” interpretation for OBP: value is adjusted by success probabilities when the provider evaluates the buyer’s effective economic type. The useful intuition is that willingness to pay cannot be read separately from the chance of producing a payable success. A high valuation does not automatically make a buyer profitable for the provider. The success probability changes the value that the contract can realistically capture.
This is also why a high per-success price can be misleading. Suppose, purely as an illustration, that an AI provider receives $100 whenever a request is judged successful. If the service succeeds on nine out of ten comparable attempts, the payment generates about $90 of expected gross revenue per attempt. If it succeeds on one out of ten, the same headline price generates about $10 per attempt. After inference, support, verification, and escalation costs, the second stream may be unprofitable even though the price attached to a success looks high.
The danger is not limited to the provider’s margin. If a customer knows that difficult work is unlikely to succeed but pays only on success, the contract can make the AI service look cheap while shifting unresolved work into a human queue. A provider that responds by raising the success price may then make routine customers subsidize or abandon the difficult segment. The contract’s apparent fairness at the moment of payment can conceal a selection problem across the customer base.
The Contract Does Not Pick a Winner by Itself
The abstract reports a sharp but conditional comparison. OBP outperforms CBP when per-success value—value normalized by the probability of success—is aligned with success probability across buyer segments. In the reported alignment, buyers willing to pay more per success are also those for whom success occurs sufficiently often. The provider’s price is then connected to a stream of outcomes that is both valuable and reasonably likely to materialize.
When that alignment fails, the paper reports that CBP dominates. A buyer can accept a high price per success while generating low, or even negative, expected profit for the provider because the buyer’s tasks fail too frequently. In that setting, an outcome label does not solve the information problem. It can intensify it by making the provider’s payment depend on exactly the uncertainty the provider has difficulty predicting.
The distinction is important for the phrase “pay for performance.” Performance-based payment is attractive when the outcome is observable, attributable to the service, and related to the customer type in a way that supports the provider’s economics. It is less attractive when success depends on a downstream human team, when the customer controls part of the process, or when difficult tasks are systematically more valuable but less likely to succeed. The contract should be judged by those relationships, not by the positive connotations of the word “outcome.”
The paper also reports an asymmetric robustness result for its model: CBP guarantees at least half of second-best revenue, while OBP can be arbitrarily poor in the worst case. This is a theoretical robustness statement under the paper’s assumptions, not a claim that every subscription or invocation plan will beat every outcome contract in practice. Its practical importance is that downside is not symmetric. A success-contingent contract can look efficient in a favorable customer mix and become fragile when hidden task difficulty or success probabilities change.
That asymmetry gives the provider and customer different reasons to be cautious. A provider should not set a success price from successful cases alone; it needs to understand the frequency and cost of unsuccessful attempts. A customer should not assume that payment on success eliminates operating risk; the customer may still supply the human labor, delay, data, and judgment needed to turn an AI output into a usable result. Both parties need a definition of success that can be observed without pretending that all downstream value is generated by the AI.
So CBP is not the “bad” option and OBP is not the “honest” one. CBP buys predictability at the level of an attempt. OBP buys stronger linkage to a realized result, but at the cost of more exposure to hidden types, measurement disputes, and low-probability success. A hybrid design may combine a predictable access or invocation charge with outcome-linked credits or bonuses, but the available evidence does not establish one universal hybrid formula. Any such design still has to answer who verifies the outcome, who handles failures, and how the human fallback affects the economics.
The remaining question is where the alignment condition comes from in an operating system. The SSRN abstract points to a customer-service queue in which unresolved requests are escalated to people and reports that the relationship between AI capability and human service rate changes which contract performs better. That is the point at which pricing leaves the invoice and enters the workflow: the service is valuable only in relation to the work that follows its attempt.