News and analysis
AI product pricing: connecting price, usage and delivery cost
Choose an AI product pricing metric, account for heavy usage, test contribution margins and give customers a bill they can understand and verify.
An AI service can charge per user, processed document, credit bundle or achieved outcome. Naming a plan does not answer the central question: does the business model hold when customers use the product intensively? A fixed subscription may be convenient for buyers and unprofitable for sellers, while charging for every request may be technically clear and commercially confusing.
In its August 25, 2026 framework, Chargebee proposes connecting pricing to measurable outcomes, usage variation and cost behaviour. This is a billing vendor’s methodology, not proof that a particular structure will increase your profits. Your own product needs evidence about its customers and workload.
Define a unit the buyer recognises
Start with a useful action. An illustrative service might prepare a document record for an accounting system. A buyer may understand a processed document better than a million tokens. But “processed” needs a definition: was the file uploaded, did the model return an answer, or did the record pass an agreed check?
If you charge for an outcome, specify how it is established and how disputes work. If you charge for usage, explain which actions consume the allowance. A rerun caused by your own technical failure should not quietly appear to be another useful result. Whether it is billable is a commercial decision that needs to be stated in the product’s rules.
In its May 20, 2026 description of Fin pricing, Intercom distinguishes the pricing model from the metric: the overall structure and the specific unit of value. The company describes an outcome as a successfully handled service query. That is an example of its product choice; applying the same definition to document processing requires separate validation.
Calculate the cost of the complete action
Model-provider charges are one component of delivery cost. A document workflow may also require recognition, storage, retrieval, retries and human time for difficult cases. If checking is necessary before a result can be delivered, its cost belongs to that result even when a different budget pays for it.
Collect operation records containing task type, customer plan, workflow version, consumption and outcome. Do not retain document contents solely for financial analytics if technical identifiers and aggregates are sufficient. Shared resources in a custom API provide useful context for linking records: the published architecture explains consistent entities but does not establish a particular AI billing system.
Separate development experiments from customer-serving costs. Still include fixed expenses in the business model: low variable costs do not by themselves make the company profitable. The allocation of infrastructure and operational costs should be understandable to the financial owner.
Check heavy customers, not just averages
Averages hide long documents, difficult cases and frequent reruns. Compare typical usage with the upper part of the distribution. Then establish why usage differs: does a customer receive more value, or is the system spending resources on unsuccessful attempts?
Here is a hypothetical calculation, not an observation about an actual product. A plan costs 100 currency units per month, and processing a document has a variable cost of 0.20. At 100 documents, 80 remains before other costs. At 600 documents, variable costs reach 120. This simple model does not determine the correct price, but it shows why unlimited usage needs testing against intensive customers.
Consider an included allowance, clearly priced overages, restrictions on expensive workflows or several service levels. Limits should be visible before they are exhausted. Exceptions for a large customer need their own calculation: a discount and expanded allowance may both reduce margins. In customer product design, plans affect interfaces, warnings and administrator permissions, not just the pricing page.
Connect experiments to behaviour and margin
Interviews help reveal what customers consider valuable. They do not prove that a purchase will occur at a stated price. Fin explicitly describes willingness-to-pay findings as intent, then combines them with models of usage, discounting and commercial constraints.
For your own experiment, specify the segment, offer, observation period and decision criteria in advance. Measure offer acceptance, actual payment, continued usage and delivery margin. Do not declare success solely because revenue rises if the new group consumes substantially more resources or needs extra manual assistance.
First test one limited AI workflow with result evaluation. It provides a basis for measuring useful actions and expenses. You can then assess a bundle of workflows: a single credit unit should not conceal incomparable costs without an understandable conversion rule.
Make the invoice reproducible
Customers need the period, billable events, allowance used and overage price. The team needs the plan version, effective date and rounding rule. If terms change partway through a period, the system should explain which operations use the old version. This is easier to verify before the customer base grows.
A model catalogue and rate history address a related question: how much execution cost at the provider at a particular time. They do not automatically set customer prices. Delivery cost and selling price have different rules and should meet in the calculation while retaining their own histories.
Before launching a plan, reconcile payment and accounting records. Check duplicate events, cancellations, adjustments and failed payments. Otherwise, a sound pricing model can still produce a disputed invoice. The result should be more than a new number: it should establish a verifiable relationship between customer value, resource consumption and commercial terms.