The AI Pricing Stack: Usage, Outcome, and Hybrid Models

TL;DR

• AI products need a pricing stack (multiple models layered together), not a single pricing model, because different value delivery mechanisms require different capture mechanisms
• Three pricing primitives: usage-based (charge for consumption), outcome-based (charge for results), and platform-based (charge for access and configuration), each with distinct advantages and failure modes
• The winning model for most AI products is a hybrid: platform fee for the floor, outcome-based metering for the upside, and usage-based guardrails to prevent margin erosion

---

I wrote previously about why per-seat pricing dies in the agentic era. The cannibalisation paradox is clear: better AI means fewer human users, which means fewer seats, which means less revenue. If your pricing is tied to logins, your AI roadmap is engineering your own churn.

But "don't use per-seat pricing" isn't a pricing strategy. It's the absence of one. The question every AI product leader faces is: what do you replace it with?

The answer isn't a single alternative model. It's a stack. Different layers of value require different pricing mechanisms, and the companies that get this right will have a structural margin advantage over those that don't.

I've implemented pricing restructures at Cotality (driving material ARR growth through tiered pricing) and built billing infrastructure from scratch at OpenChair (Stripe Billing, Connect, and Terminal). The patterns that work aren't theoretical. They're operational.

The three pricing primitives

Every AI product pricing model is built from three primitives. Understanding each one, its mechanics, its advantages, and its failure modes, is the foundation.

Primitive 1: Usage-based pricing

Mechanism: Charge for consumption of a resource. API calls, tokens processed, compute hours, storage consumed.

Advantages: Revenue scales linearly with customer value. Heavy users pay more. Light users pay less. Aligns the customer's cost with their consumption. No wasted spend on unused capacity.

Failure modes:

The customer doesn't understand what they're paying for. Tokens, API calls, compute hours: these are infrastructure abstractions. They mean nothing to a salon owner or a property agent. Pricing on infrastructure units forces your customer to understand your cost structure, which is backwards. You should understand their value structure.

Usage-based pricing punishes you for efficiency. If you optimise your prompts to use fewer tokens, your revenue drops. If you implement prompt caching that reduces inference cost by 90%, your per-request revenue drops with it. Your engineering team's best work directly reduces your top line. That's a broken incentive.

Revenue volatility. Usage fluctuates with seasonality, business cycles, and customer behaviour. Finance teams hate unpredictable revenue. Investors discount it. The CFO will ask why revenue dropped 15% in January, and the answer ("customers used less AI during the holiday period") isn't satisfying.

Best for: Developer tools, APIs, and infrastructure products where the buyer is technical and understands consumption metrics. Bad for end-user products where the buyer is a business owner or operator.

Primitive 2: Outcome-based pricing

Mechanism: Charge for results. Tickets resolved, contracts reviewed, invoices processed, appointments booked, leads qualified.

Advantages: Perfect alignment with customer value. The customer pays for what they actually want (resolved tickets, booked appointments), not for the machinery that produces it. This makes the value proposition self-evident: "We resolve tickets for $2 each. Your current cost is $7.50 each. You save 73%." No ambiguity.

Revenue grows with customer success. As the customer routes more work through the AI (because it's good enough to handle more), revenue increases. The AI getting better directly increases revenue. The incentive alignment is elegant.

Failure modes:

Defining the outcome is harder than it sounds. What counts as a "resolved ticket"? If the AI responds but the customer replies again, is that one resolution or two? If the AI routes to a human who resolves it, does the AI get credit? Every edge case in outcome definition becomes a billing dispute.

Attribution complexity. When the AI assists a human rather than replacing them, who gets credit for the outcome? If the AI drafts a property description that the agent edits, is that an AI outcome (billable) or a human outcome (not billable)? The assist model is valuable but hard to price on outcomes.

Customer risk aversion. Outcome-based pricing transfers risk from the vendor to the customer. If the AI resolves 500 tickets, the customer pays for 500. If it resolves 5,000, the customer pays for 5,000. That's a variable expense that the customer can't fully predict. Some customers prefer the predictability of a flat fee even if it costs more on average.

Best for: Products where the AI performs a complete, measurable task that replaces human labour. Support resolution, document processing, data extraction, scheduling.

Primitive 3: Platform-based pricing

Mechanism: Charge for access to the platform, its configuration capabilities, integrations, and the human-facing interface. Flat monthly or annual fee.

Advantages: Predictable revenue. Predictable cost for the customer. Simple to sell, simple to bill, simple to forecast. Finance teams love it. Sales teams can quota on it.

Failure modes:

Doesn't capture the value of AI improvements. If you ship 10 new AI features and the platform fee stays the same, your customer gets more value but you don't capture any of it. Over time, the gap between value delivered and value captured widens.

No expansion revenue without price increases. The only way to grow revenue from an existing customer is to raise the platform fee (friction) or sell more seats (the old model, which we're trying to escape). There's no organic growth mechanism tied to the customer using the product more.

Subsidises heavy users at the expense of light users. A customer running 10,000 AI tasks per month pays the same as a customer running 100. The heavy user is massively undercharged. The light user is slightly overcharged. Neither is optimal.

Best for: The baseline layer that covers infrastructure, configuration, and human-facing features. Not as the sole pricing mechanism for AI-heavy products.

The hybrid stack

No single primitive works alone for an AI product. The winning model layers them.

Layer 1: Platform fee (the floor)

A flat monthly fee that covers the platform itself: the dashboard, configuration, integrations, user management, support. This is the predictable revenue baseline.

The platform fee should be priced to cover your non-AI infrastructure costs with healthy margin. It's the price of admission, not the price of value. Think of it as: "What would this product cost if the AI features didn't exist?" That's your platform fee.

At Cotality, the tiered pricing restructure separated platform access from value-add capabilities. The base tier covered the core platform. Higher tiers unlocked additional capabilities and usage allowances. This structure drove material ARR growth because it aligned price tiers with value tiers, not just seat counts.

Layer 2: Outcome-based metering (the upside)

Metered charges for the work the AI completes. Framed in the customer's language, not yours.

Structure this as an inclusion plus overage model: "Your plan includes 500 AI-booked appointments per month. Additional appointments are $1.50 each." The inclusion normalises AI usage (every customer tries it). The overage captures expansion revenue as adoption grows.

The inclusion amount should be set to cover 60% to 70% of expected usage for the median customer in each tier. This means most customers occasionally exceed the inclusion (triggering expansion revenue) without feeling penalised for normal use.

Layer 3: Usage-based guardrails (the protection)

Usage-based pricing isn't the primary revenue mechanism, but it serves as a margin protection layer. Set hard or soft limits on resource-intensive operations that could blow out your inference costs.

For example: "Includes 100 AI voice receptionist minutes per month. Additional minutes at $0.15 each." The customer understands minutes. You've capped your exposure to high-consumption outliers. The heavy user pays more for the higher infrastructure cost they create.

This layer exists to prevent the scenario where a single customer's usage pattern destroys your unit economics. Without it, one customer running 50,000 AI queries a day (instead of the expected 500) would quietly eat your margin.

Pricing the confidence threshold

Here's where AI pricing gets genuinely novel.

I wrote about the spot-check architecture: routing high-confidence AI outputs directly and only auditing low-confidence outputs with a more expensive model. The confidence threshold is a dial you can turn. Higher threshold means more outputs get audited. More audit means higher quality. Higher quality means higher cost.

This creates a natural product tier structure:

Standard tier: 85% confidence threshold. Most outputs pass through unaudited. Lower cost. Suitable for tasks where occasional errors are acceptable and humans review outputs.

Professional tier: 92% confidence threshold. More outputs get audited. Higher quality. Higher cost. Suitable for tasks where errors have moderate business impact.

Enterprise tier: 97% confidence threshold. Nearly all uncertain outputs get audited. Highest quality. Highest cost. Suitable for regulated environments where errors have significant consequences.

The customer isn't choosing a "quality setting." They're choosing a risk tolerance. And they're paying proportionally to the infrastructure cost of delivering that tolerance.

This is pricing differentiation built on architectural reality, not on arbitrary feature gating. The standard tier customer and the enterprise tier customer have access to the same AI features. The difference is how many outputs get the expensive audit layer. That's a real cost difference that justifies a real price difference.

The transition playbook

If you're currently on per-seat pricing, you can't flip to a hybrid stack overnight. The transition has to be commercially smooth.

Phase 1: Instrument. Before changing any prices, add metering to your AI features. Track work units (tasks completed, documents processed, whatever your outcome metric is). Track usage (API calls, inference cost, storage). Build the dashboard. You need 2 to 3 months of data before you can model the hybrid pricing.

Phase 2: Model. Using the metered data, model what each customer would pay under the hybrid stack. Find the crossover point: at what usage level does the hybrid model cost more or less than the current per-seat model? For most customers, the hybrid model should cost 10% to 20% less at current usage (incentivising adoption) while creating expansion revenue potential at higher usage.

Phase 3: Offer. Present the hybrid model as an option at renewal. Frame it as a cost saving: "Based on your usage, you'd save X% under our new pricing. Plus, you'd pay only for additional AI work that creates additional value." When the math favours the customer, adoption follows. Don't force the transition. Let the economics sell it.

Phase 4: Default. Once 40% to 50% of customers have opted into the hybrid model, make it the default for new customers. Legacy per-seat pricing remains available but isn't promoted.

Phase 5: Sunset. Once 80%+ of customers are on the hybrid stack, sunset per-seat pricing for new customers. Existing per-seat customers can stay until renewal but see the comparison dashboard showing what they'd pay under hybrid.

This phased approach protects ARR, gives finance predictable transition timing, and lets your sales team adapt their compensation model gradually.

The pricing test

Here's how to test whether your AI pricing stack is sound:

1. Does the customer understand what they're paying for? If the answer requires explaining tokens, inference, or API calls, start over.
2. Does the customer pay more when they get more value? If usage doubles but revenue doesn't change, you're leaving money on the table.
3. Does improving the AI increase or decrease your revenue? If the answer is "decrease," your pricing penalises your own product improvements.
4. Can your finance team forecast next quarter's revenue within 15%? If the answer is "no," you need more platform fee and less variable pricing.
5. Is there a natural expansion path that doesn't require a sales conversation? If growth requires a salesperson to upsell, you've built a sales-dependent model.

A pricing stack that passes all five tests aligns your incentives with your customer's incentives, captures value proportional to delivery, and creates organic expansion revenue. That's the model that wins in the AI era.

---

Frequently Asked Questions

How do you handle free trials under outcome-based pricing?

Include a generous AI allowance in the trial. "14-day trial includes 200 AI-booked appointments." The customer experiences the outcome (booked appointments without phone tag) and the transition to paid is a continuation of value they've already seen, not a leap of faith. Metered trials convert better than time-limited trials for AI products because the customer has concrete usage data to justify the spend.

What about enterprise customers who demand flat-rate pricing?

Offer a committed-use model: "Pay $X/month for up to Y outcomes. Unused outcomes don't roll over. Overages at $Z each." This gives the enterprise customer the predictable spend they want while giving you committed revenue. Set the committed level at 80% of expected usage. The customer slightly overpays relative to pure usage-based pricing, but they get the budget predictability they value. You get revenue certainty.

How do you prevent pricing complexity from hurting sales velocity?

Keep the customer-facing pricing simple. "Starter: $X/month, includes Y. Professional: $X/month, includes Y. Enterprise: custom." The hybrid mechanics (platform fee + outcome metering + usage guardrails) live behind the tier structure, not in front of it. The customer sees a tier comparison table. The billing system handles the metering. Pricing complexity should be invisible to the buyer and visible only to the billing infrastructure.