Outcome-Based Pricing: How It Works

The metering layer, the data model, and the audit trail all get harder when the billing trigger moves from activity to results. Outcome-based pricing charges only when a defined result is delivered, like a resolved ticket, an approved transaction, or a cancellation saved.

This article covers what outcome-based pricing is, how it differs from other pricing models, what it demands from the infrastructure underneath, and where teams typically underestimate the complexity. 

What is outcome-based pricing?

Outcome-based pricing is a model where customers pay only when a defined business outcome is delivered. 

The price is not tied to access, seats, or raw usage. Instead, it is tied to a result like a resolved support ticket, a fraud-free transaction approved, or a cancellation saved.

This is different from consumption-based pricing, which charges for activity regardless of whether that activity delivered value. Outcome-based pricing charges for the result of that activity.

The distinction matters at the infrastructure level because the system has to know the difference between an event and an outcome. Tracking API calls is straightforward. Tracking whether a customer's issue was resolved, without human intervention, within a defined window, requires a more precise data model.

How outcome-based pricing works

Outcome-based pricing follows a 4-step flow: the product captures an event, the system evaluates it against a predefined outcome definition, the confirmed outcome is recorded in a ledger, and billing is triggered.

1. Event capture

The product emits an event every time a relevant action occurs.

• For a support tool, that might be a ticket interaction.
• For a fraud detection platform, it might be a transaction evaluation.

The event has to be captured in real time with enough granularity to evaluate later: who triggered it, when, and under what conditions.

2. Outcome evaluation

The system evaluates the event against a predefined outcome definition.

Did the ticket close without human escalation within the defined window? Did the transaction pass without a chargeback?

The definition has to be precise enough for the system to evaluate it consistently, and it has to be versioned so it stays auditable across contract periods.

3. Outcome recording

Confirmed outcomes are written to a ledger. Each record ties back to the underlying events so finance can trace every billed outcome to the product activity that triggered it.

This is what makes revenue recognition and dispute resolution possible.

4. Billing trigger

Once an outcome is confirmed and recorded, it flows to the billing system. Depending on the model, billing happens per outcome, at the end of a cycle, or when a contracted threshold is reached.

The engineering challenge is that all four steps have to stay in sync. Event capture that works at low volume starts dropping events under burst traffic. Outcome definitions that are clear in a contract become ambiguous at the data layer. Ledgers that seem sufficient early on cannot support ASC 606 traceability at scale.

How outcome-based pricing compares to other models

Seat-based pricing dropped from 21% to 15% of SaaS companies in 12 months, according to Growth Unhinged's 2025 State of B2B Monetization report. According to the 2026 report, hybrid pricing jumped from 25% to 37% of respondents in 12 months. The change is driven by AI: when one agent can replace 10 users, seat-based revenue erodes as the product gets better.

The three dominant models in SaaS today sit on a spectrum:

1. Seat-based pricing. Fixed cost per user. Predictable revenue, but decoupled from the value customers receive. Engineering overhead is low: provision a seat, revoke it, done.
2. Usage-based pricing. Variable cost tied to consumption: API calls, tokens, compute. Requires metering infrastructure but does not require the system to interpret whether consumption delivered value.
3. Outcome-based pricing. Variable cost tied to results. Requires metering plus outcome attribution, enforcement logic tied to defined success criteria, and an audit trail that finance and customers can verify.

Each step up the stack adds infrastructure complexity.

Real examples of outcome-based pricing in production

Intercom

Intercom charges per resolved ticket through Fin, its AI agent. The outcome is defined as a ticket closed without human escalation. If Fin fails to resolve the ticket, there’s no charge.

That constraint has aligned Intercom's engineering roadmap directly with resolution rates: improving the metric improves revenue. Fin has grown from $1M to $100M+ ARR, powered by a $0.99 outcome-based pricing model that charges only for successful resolutions.

The infrastructure implication is significant. Every ticket interaction has to be tracked, the resolution criteria evaluated at the data layer, and the outcome recorded in a way that is auditable.

The pricing model only works if the metering layer can distinguish a genuine resolution from an unresolved interaction that was incorrectly marked closed.

Zendesk

Zendesk’s own positioning highlights a core challenge with outcome-based pricing: defining what “resolution” actually means. They note that definitions vary widely across vendors, with some counting conversations that end, escalate, or time out as successful outcomes.

To address this, Zendesk introduced stricter criteria, including validation layers and a 72-hour window to avoid double-counting or premature resolution.

The takeaway is not that outcome-based pricing fails, but that it depends heavily on precise, enforceable definitions. Without that, what looks like success in dashboards may not reflect real customer outcomes.

This is why many AI-native products stop short of true outcome-based pricing. Tools like Cursor use credit-based models instead, where usage is metered across actions rather than tied to a validated outcome. Moving from usage to outcomes introduces a harder problem: defining, verifying, and auditing what “success” actually means in the system.

The outcome definition problem

Zendesk’s challenges point to a common failure: the outcome is not defined in a way the system can evaluate.

For engineering, this starts at the data layer. The system needs a definition built from events it can observe and verify, not labels it cannot interpret.

“Ticket resolved” is not enough. A usable definition ties to conditions the system can check, such as no follow-up within a time window or no escalation during the interaction.

If any part of the definition depends on data that is not captured, the outcome cannot be enforced. That is where disputes come from.

Teams run into this when they define outcomes in business terms first, then try to map them to the data they have. The more reliable approach is the reverse: define outcomes using existing events, then validate that those events represent the intended result.

What outcome-based pricing requires from engineering

Outcome-based pricing requires systems that capture events at the right granularity, apply consistent outcome definitions, and enforce access based on those outcomes in real time. It also requires an auditable event log that ties every outcome directly to billing and revenue recognition.

1. Event capture at the right granularity

The metering layer has to track not just that something happened, but what happened, when, and for which customer. If the outcome is a resolved support ticket, the system needs to know when the ticket opened, what interactions occurred, and whether it closed without human escalation.

2. Outcome definition enforcement

The criteria for what counts as an outcome have to be defined centrally and applied consistently. The rule that decides whether a ticket counts as resolved has to live in one place in the stack and execute reliably at scale, instead of being reimplemented in every service that reports usage.

3. Entitlement enforcement tied to outcomes

Access controls may need to reflect outcome status. A customer who has consumed their contracted number of outcomes may need to be handled differently from one who has not. That requires the entitlements layer to read outcome data in real time.

4. Auditable records for billing and revenue recognition

Every outcome event has to be traceable from the product to the invoice. Revenue recognition under ASC 606 requires SaaS companies to determine whether fees can be recognized as outcomes occur or must be estimated and recognized over the contract term. That determination depends on the granularity of the event log.

Metering infrastructure for outcome-based pricing

Usage-based pricing requires a metering layer. Outcome-based pricing requires that metering layer to do more: capture events at higher granularity, apply outcome logic against those events, and produce records that are auditable under revenue recognition requirements.

The minimum viable metering stack for outcome-based pricing includes:

Real-time event ingestion

Events must be captured as they happen. Batch processing introduces lag, which makes outcome attribution unreliable, especially for time-bound definitions.

Idempotent event handling

Usage pipelines are at-least-once by design. Each event needs a unique identifier, and processing must be idempotent so duplicate events do not result in duplicate charges.

Outcome evaluation logic

The system needs a layer that reads event streams and evaluates them against outcome criteria. This logic must be versioned and auditable, since definitions can change across contract periods.

Ledger-level traceability

Every recorded outcome must be traceable back to the underlying events. This is required for revenue recognition, customer verification, and dispute resolution.

Outcome data carries contract context that some organizations cannot send outside their own infrastructure. A self-hosted enforcement layer keeps that data within the VPC, resolves checks locally, and removes any dependency on external uptime from the outcome evaluation path.

Building this in-house means stitching together event pipelines, evaluation logic, and billing integrations, often across multiple services. That’s where most teams start to see fragmentation.

One way teams avoid that fragmentation is by separating outcome logic from application code entirely. Stigg sits between the product and billing, keeping metering and entitlement enforcement in one layer so outcome definitions do not drift across services as the system evolves.

The product catalog defines what outcomes are tracked, usage events stream in real time, and entitlement enforcement applies against those records. Billing systems like Stripe or Zuora handle invoicing downstream.

Billing systems track what happened and generate invoices. Stigg decides what is allowed before it happens. That separation is what keeps outcome enforcement consistent across services without it becoming a billing problem.

Revenue recognition in outcome-based pricing

Outcome-based pricing changes what the data layer has to capture. The system needs to know not just that an outcome occurred, but when, under what conditions, and whether it meets the criteria defined in the contract. That granularity is what finance needs to determine how revenue is recognized under ASC 606.

The core question is whether the company is selling access to a platform or delivering specific outcomes. That distinction determines when revenue can be recognized.

How revenue recognition differs

What this means for engineering

Engineering systems have to support finance decisions. The data layer must capture enough detail to determine how revenue should be recognized.

At minimum, the system needs:

• Granular event logging so each outcome is tied to specific actions
• Precise timestamps to determine when an outcome occurred
• Traceability between events, outcomes, and invoices

Where teams run into problems

Teams often treat:

• Event logging as a backend concern
• Revenue recognition as a finance concern

That separation breaks down quickly. If the system cannot provide auditable, structured data, finance cannot recognize revenue correctly, and engineering ends up rebuilding the data model after the fact.

Entitlement enforcement in outcome-based pricing systems

In an outcome-based model, entitlements define how many outcomes a customer is allowed and what happens when that limit is reached.

For example, a customer might contract for 1,000 resolved tickets per month. The system has to track confirmed outcomes, update the remaining balance, and enforce limits in real time so the product can respond before the threshold is exceeded.

This behaves like a credit system. Each confirmed outcome draws down a balance the system evaluates on every event. A counter that decrements isn't enough. AI products running outcome-based models need a credit layer that handles multiple balance types, burn order, and expiry correctly.

At the limit, enforcement determines the behavior:

• Block further outcomes (hard limit)
• Allow overage beyond the contract (soft limit)
• Trigger a top-up or upgrade flow

When this logic lives in application code, outcome limits become tightly coupled to plan definitions and hard to change without a deployment. Keeping entitlement enforcement in a dedicated layer means outcome thresholds, add-on overrides, and promotional grants resolve deterministically at runtime.

Packaging changes like adjusting outcome thresholds or updating plan limits go through configuration. Structural changes like introducing a new outcome definition still require engineering work, but the enforcement layer remains the source of truth that downstream systems follow.

Where in-house systems break

Most teams start by building outcome tracking inside the application layer. A function fires when an outcome occurs, increments a counter, and passes data to billing. That works early on, but it breaks as soon as the system has to handle change.

The pressure shows up when:

• Outcome definitions evolve across contract periods
• Customers dispute whether an event qualifies
• Finance needs to trace invoices back to specific events
• Multiple products introduce different outcome logic

Each of these is a data modeling problem, not just an implementation detail. When this logic lives in application code, it becomes harder to audit, change, and keep consistent across systems.

Over time, small decisions compound into a system that is tightly coupled, difficult to modify, and fragile under scale.

At enterprise scale, outcome evaluation isn't a single check against a single balance. It runs across nested org hierarchies, multiple concurrent sessions, and product lines with different outcome definitions.

That volume requires local state resolution, or the enforcement layer becomes the bottleneck before it becomes unreliable.

Build vs. buy for outcome-based pricing infrastructure

Building in-house works under specific conditions, but it starts to break as things get more complex.

In-house systems are viable when:

• Outcome definitions are simple
• Event volume is low
• Audit requirements are minimal

Complexity increases quickly when:

• Definitions become nuanced
• Event volume grows
• Finance requires granular traceability (e.g., ASC 606)

At that point, teams are no longer building features. They are maintaining the infrastructure.

A dedicated entitlements and metering layer handles:

• Event ingestion
• Outcome evaluation
• Entitlement enforcement
• Ledger-level traceability

The trade-off is upfront integration versus long-term system complexity. Miro estimated that building and maintaining its monetization infrastructure in-house would have consumed 5,000 engineering hours.

Moving to a dedicated layer gave Miro a hybrid seat and usage model with enforcement, resets, and visibility across the stack in under six weeks. When the infrastructure is designed for change, outcome definitions move through configuration instead of code.

Outcome-based pricing only works if the system does

Outcome-based pricing rarely fails at the model layer. It fails when the system cannot tell the difference between an event and an outcome, or when enforcement logic drifts across services until nobody owns it.

Stigg is the usage runtime for AI products. Entitlements, credits, usage limits, and spend governance run synchronously in the request path before compute is consumed. 

For teams building this before the audit request arrives:

• Outcome thresholds, add-on overrides, and promotional grants resolve from a single entitlement layer, so enforcement stays consistent as contract terms evolve
• Cache misses fall back to Stigg's Edge API at ~100ms, fast enough that outcome evaluation never becomes the bottleneck
• Every outcome deduction writes an immutable ledger event with full attribution back to the product activity that triggered it
• BYOC Sidecar runs inside your own VPC, keeping enforcement live during upstream interruptions with no external dependency
• Outcome definitions and packaging thresholds update through the product catalog without a deployment

If the event model, outcome definitions, and audit trail are already on the engineering roadmap, the infrastructure decision is already being made. Explore how Stigg’s infrastructure handles that layer without rebuilding it from scratch.

FAQs

1. What is outcome-based pricing?

Outcome-based pricing is a model where customers pay only when a defined result is delivered, such as a resolved ticket or approved transaction. The system must verify that the outcome actually occurred before billing.

2. What is the difference between outcome-based pricing and usage-based pricing?

The main difference between outcome-based pricing and usage-based pricing is that usage-based pricing charges for activity, while outcome-based pricing charges only when a defined result is achieved.

3. What infrastructure does outcome-based pricing require?

Outcome-based pricing requires real-time event tracking, outcome evaluation logic, and an auditable ledger. These systems ensure each billed outcome is validated, enforced, and traceable.

4. How does outcome-based pricing affect revenue recognition?

Outcome-based pricing affects revenue recognition by tying it to when outcomes are delivered. This requires granular event data to determine when revenue can be recognized under ASC 606.

5. What is the difference between outcome-based pricing and value-based pricing?

The main difference between outcome-based pricing and value-based pricing is that value-based pricing reflects perceived value, while outcome-based pricing charges only when a measurable result is delivered.