Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.
Outcome pricing sounds simple: the customer pays when the agent delivers value. The complication is deciding what counts as value. A conversation can end because the problem was solved, because the customer became frustrated, or because they went elsewhere. A handoff can be a useful outcome even though the original issue remains unresolved.
Support-agent pricing therefore begins with measurement design. The proposed framework here is a base fee plus clearly defined qualified outcomes, where appropriate. It is not a recommendation to copy any vendor's exact price or terminology. A customer must be able to understand, verify, and challenge the units on the invoice.
Read the definition, not just the price
The Intercom pricing page checked for this article describes Fin at US$0.99 per outcome and includes specified workflow handoffs within its outcome definition. That is a useful real-world example of why a billing unit should not automatically be described as a customer-confirmed resolution. Terms and prices can change, so verify the current page and quote before purchasing.
For your own service, define each event that can become billable. An explicit confirmation, a completed account action, a qualified handoff, and a period without further contact are different signals. Combining them into one metric may be commercially reasonable, but the customer needs to see the composition.
Avoid naming a metric more strongly than the evidence supports. If the system measures conversation closure, call it closure. If it verifies that a password reset succeeded, describe that action. Do not turn an inferred outcome into a claim of customer satisfaction.
Design the reopen rule
Suppose a customer asks how to activate a feature, receives instructions, and returns the next morning because the instructions did not work. Should that create two billable outcomes, one corrected outcome, or no charge? There is no universal answer, but there should be an agreed answer before deployment.
Choose a reopen window that fits the task. A shipping question may take days to reveal whether the answer was useful, while a simple account setting can be checked immediately. Define how related requests are linked without unnecessarily collecting more personal data.
Handle repeated questions within one conversation consistently. Customers should not pay more because an agent required several clarifications to understand an ordinary request. Conversely, a genuinely separate task may deserve its own unit if the contract makes that distinction clear and the event ledger can support it.
Keep billing and quality separate
A billable event is a commercial construct. Quality needs its own scorecard: factual correctness, policy compliance, repeat contact, complaint rate, escalation quality, and customer feedback. A service can generate many billable events while still delivering a poor experience.
Sample apparently successful conversations. Reviewers should inspect whether the answer addressed the actual problem and whether any promised action occurred. The linked evaluation guidance offers background for checking outcomes rather than trusting an agent's declaration of success.
Track denominator changes. If difficult tickets are excluded from automation, the remaining resolution rate may rise even though the overall support operation has not improved. Report eligible volume, attempted volume, and total incoming volume so the customer can interpret the result.
Prevent perverse incentives
Outcome pricing can encourage a provider to classify ambiguous conversations as complete, discourage human handoff, or split work into extra units. Good design reduces those incentives through clear definitions, transparent logs, and a dispute process.
Make necessary escalation commercially neutral where possible. A support agent should not conceal uncertainty because a human handoff reduces revenue. Reward correct routing when routing is the agreed service, and do not pretend it is the same as independently resolving the entire issue.
Exclude internal tests, duplicate deliveries, and provider-caused reruns from customer charges. If a failed integration creates repeated conversation records, deduplicate them by a stable task identifier. Billing logic should be inspectable code and data, not a model's subjective judgment about whether it was helpful.
Model a customer's bill before launch
Use representative historical volume to simulate the proposed invoice. Show the buyer how ordinary months, peak months, and unusual incident periods differ. Include platform fees, seats, channels, and human review where applicable rather than presenting a narrow unit price as the total cost.
An illustrative customer with 2,000 eligible tasks and a proposed US$0.80 task charge would face US$1,600 in usage charges before any base fee. If half the tasks are actually excluded or require a different workflow, the estimate changes. These figures illustrate invoice construction; they are not market pricing guidance.
Offer budget alerts and a defined behavior at the limit. Stopping all support without warning may be unacceptable, while silently allowing unlimited overage undermines trust. Options include routing to humans, pausing selected automation, or seeking approval for additional usage.
Make disputes easy to resolve
A customer should be able to trace an invoice unit to a task, timestamp, outcome type, and verification record without exposing sensitive content to unnecessary staff. Establish a review period and a credit process. A clear ledger is more valuable than arguing over a dashboard percentage.
Outcome pricing works when the event is observable, the provider influences it, and the customer believes the definition reflects value. Where those conditions are weak, a subscription or hybrid arrangement may be more honest and easier to operate.
Sources and evidence
Intercom pricing: Observed US$0.99 per outcome; definition includes specified handoffs, not only explicit customer-confirmed resolution. Pricing and outcome definitions can change; consult the current quote.
Demystifying evals for AI agents.
Research checked October 26, 2026. Business designs and illustrative calculations in this article are editorial proposals, not documented earnings or guarantees. Recheck current product terms before implementation.
Leave a Reply