Define what the customer is buying first, then decide on the billing unit. If the customer is purchasing ongoing access rights, per-seat pricing can be used; if costs vary with task volume, usage-based pricing is appropriate; outcome-based pricing is only feasible when results can be clearly verified by both parties. When results and costs are both unstable in the early stage, subscriptions with quotas or base fees plus overage charges are usually easier to use to control pilot boundaries.
This article discusses product billing design. The comparison table and calculations are recommendations from this site; all amounts are hypothetical examples; specific supplier rules shall be subject to their current documents and contracts. Information verification date: 2026-10-11.
1. What problems do the three models each solve
Per-seat
Applicable conditions: Value comes from continuous personal use, and there is a certain relationship between the number of users and value
Benefits: Easy for customers to budget, and bills are easy to explain
Issues to bear: A small number of heavy users may consume large amounts of costs; after account sharing or staff reduction, value becomes disconnected from headcount
Usage-based
Applicable conditions: The number of times, minutes, or processing volume can be metered, and costs vary accordingly
Benefits: It is relatively easy to make revenue cover variable costs
Issues to bear: Customers do not like paying for failed attempts, and they also worry about out-of-control bills
Outcome-based
Applicable conditions: Results are observable and attributable, and both parties agree on completion conditions
Benefits: Billing is closer to the value perceived by customers
Issues to bear: Result disputes, delayed confirmation, and manual rework will all affect gross margin
This is not a maturity ladder that must be traversed from left to right. An assistant for continuous collaboration with writers, and an agent that completes customer service tickets Agent, may be suited to different models in the long term.
2. "Outcome-based" is first and foremost a definition
Do not just write "charge per resolved issue". Clarify at least the following six items:
1. Billing object: Is it a conversation session, a ticket, an appointment, or an order?
2. Completion condition: Is it generating a reply, user confirmation, or a status change in the downstream system?
3. Confirmation time: Is it confirmed on the spot, or after an observation period?
4. Reopening rule: If the same issue recurs, will the fee be reversed or merged?
5. Human involvement: If a human reviews or ultimately takes over, is it still billable?
6. Deduplication and disputes: How are repeated requests counted, and how can customers view evidence and file appeals?
A real-world reminder comes from Intercom. Fin's official documentation divides "outcomes" into multiple types, among which the billing rules for configured completed process handoffs differ from those for ordinary escalations to humans. Therefore, "charging per outcome" cannot be simply translated as "charging only when there is completely no human intervention". This shows that billing events require item-by-item reading of definitions, and does not prove that this model is suitable for all businesses. Fin's official outcome definition (https://www.intercom.com/help/en/articles/8205718-fin-ai-agent-outcomes )
3. Calculate the cost per billing unit first
Assume 1,000 tasks are accepted in a month, of which 800 reach the contractually agreed billable outcome. The total cost of models, tools, and operation is 600 yuan, review and rework cost 400 yuan, and the allocated monthly operation and maintenance cost is 200 yuan.
- Total delivery cost: 600 + 400 + 200 = 1,200 yuan.
- Cost per billable outcome: 1,200 ÷ 800 = 1.50 yuan.
- If 3 yuan is charged per outcome, revenue is 2,400 yuan, leaving 1,200 yuan after deducting the above costs.
This balance does not deduct customer acquisition costs, taxes, payment processing fees, and unallocated R&D expenses, so it cannot be called the company's net profit. If billable outcomes drop to 400 while total costs remain temporarily unchanged, the unit cost will rise to 3 yuan, and the original unit price will no longer leave a margin.
The most easily overlooked point here is that failed tasks also cost money, and manual rework also costs money. You cannot directly infer from "a single model call costs 0.1 yuan" that "selling each outcome for 1 yuan is very profitable".
4. A replicable billing plan card
What the customer buys
Example: After-sales document organization Agent: Organize verifiable after-sales document packages from incoming messages
Billing unit
Example: After-sales document organization Agent: One document package that passes the agreed field checks
Non-billable situations
Example: After-sales document organization Agent: Duplicate requests, system failures, key fields that cannot be verified
Human involvement boundary
Example: After-sales document organization Agent: Whether manual review is included shall be separately agreed; free unlimited rework cannot be assumed by default
Usage control
Example: After-sales document organization Agent: Monthly budget, alerts before overage, pausable tasks
Billing evidence
Example: After-sales document organization Agent: Task ID, completion time, result link, fee breakdown
Dispute handling
Example: After-sales document organization Agent: Agreed conditions for reopening and refund/deduction within the observation period
Cost review
Example: After-sales document organization Agent: Check success rate, human minutes, and cost per outcome every week
The services and rules in the table are design examples, not launched products or contract templates. Before actually publishing prices, they need to be jointly confirmed by the personnel responsible for commercial operations and delivery.
5. How to reduce pricing rework in the early stage
When customer needs are clear but costs are unclear, first run a pilot with a limited task scope and quota to collect full delivery costs. Customers know "how much they can try", and you also have the opportunity to identify high-cost anomalies.
If results take several months to verify, such as final sales closures, directly charging per closed deal will bring attribution, sales cycles, and customer execution capabilities into the bill. You can first charge for verifiable intermediate deliverables, but name them truthfully; do not package "finding leads" as "bringing revenue".
If fixed monthly fees are very popular, you should still clarify quotas and overage rules. "Unlimited use" will cause individual long tasks, tool loops, or multi-person shared accounts to change the cost structure.
Frequently asked questions
Is charging per token the fairest? It is suitable for scenarios where customers understand and control underlying usage. When business users care more about tasks and results, fees need to be converted into units they can budget for, and how failures and retries are counted must be explained.
Is outcome-based pricing necessarily more expensive and more profitable? Not necessarily. The supplier bears more failure and rework costs; it can only hold true when results are stable and pricing covers the full delivery cost.
Sources and further reading
- Intercom: Fin AI Agent outcomes (https://www.intercom.com/help/en/articles/8205718-fin-ai-agent-outcomes ), used to illustrate the difference between outcome definitions and handoff billing; its customer growth figures are not cited.
- This site: Discussion on enterprise AI implementation and pricing (https://signaltobuild.com/knowledge/kb-1184fa393da5ec2af8a93c7bd4618dcb ), for further comparison of different views from interviews.
- AI Product Practice Special Topic (https://signaltobuild.com/topics/ai-products ) · Subscribe to site updates (https://signaltobuild.com/subscribe )