Whether you're looking for an angel investor, a growth advisor, or just want to connect — I'm always open to great ideas.
Get in TouchComplete guide to implementing outcome-based pricing in SaaS. Covers attribution frameworks, pricing architecture, migration playbook, and real examples from Salesforce Agentforce, Intercom Fin, and Zendesk.
AI, startups & growth insights. No spam.
TL;DR: Per-seat pricing is collapsing under the weight of AI. When Klarna replaces 700 support agents with a single AI deployment, seat-based SaaS vendors lose 700 paying units overnight. Outcome-based pricing — charging for what customers actually get, not how many seats they provision — is the structural answer. This guide covers every layer: how to identify your value metric, how to construct metering infrastructure, how to restructure sales comp, how to manage revenue unpredictability, and how to migrate an existing customer base without a revolt. If you're building or re-pricing a B2B SaaS product in 2026, this is the playbook.
The per-seat model was a beautiful invention for its era. It scaled with headcount, it was easy to audit, easy to forecast, and easy to explain. Sales reps knew how to sell it. Finance teams knew how to budget it. CFOs could pull up a spreadsheet and say: 200 employees x $50/seat = $10,000/month. Done.
Then AI happened.
In February 2024, Klarna announced that its AI assistant — built on OpenAI — was handling the equivalent workload of 700 full-time customer service agents. The announcement was precise: the AI handled 2.3 million conversations in its first month, equaling two-thirds of Klarna's total chat volume. Resolution time dropped from 11 minutes to 2 minutes. Customer satisfaction was on par with human agents.
What does that mean for seat-based SaaS vendors who served those 700 agents? It means 700 seats evaporated. Overnight. Not because the company churned in the traditional sense — they didn't switch to a competitor. The underlying demand for human labor that justified those seats simply ceased to exist.
This is not a Klarna-specific story. It's a structural shift.
Crack 1: AI eliminates the unit of billing. Seat-based pricing is a proxy for human labor. One seat = one person doing work. AI agents don't consume seats — they do work. When an AI workflow automates tasks previously performed by 50 employees, those 50 seats disappear from vendor invoices regardless of how much value the software is creating. The software may be doing more work than before, but the billing mechanism can only go down.
Crack 2: Customers never liked it anyway. A 2023 OpenView Partners survey of enterprise software buyers found that 61% preferred pricing that tied cost to outcomes or value delivered rather than seats or licenses. Procurement teams have always viewed seat counts as adversarial — vendors trying to extract maximum revenue by counting heads. Outcome-based pricing flips this dynamic. You win when they win.
Crack 3: The incentive structure is inverted. Under seat-based pricing, a vendor has zero financial incentive to help customers use software more efficiently. If your customer finds a way to accomplish more with fewer people (through better processes, better tooling, or AI), your revenue shrinks. This is a perverse incentive structure. You are literally creating products where customer efficiency is a threat to your business model. Outcome-based models align these incentives: the more value you deliver, the more you earn.
Consider a recruiting SaaS product priced at $150/seat/month, typically licensed to recruiting teams of 10-15 people. An AI-powered recruiting automation layer can now do what previously required 10 recruiters — sourcing, screening, scheduling, follow-up. The company goes from 12 licenses to 3 (a hiring manager and two senior recruiters for final decisions). Revenue drops 75%.
If instead the pricing were outcome-based — say, $800 per successful hire — and the AI dramatically increases the number of hires the company can close, revenue grows as output grows. The vendor captures value proportional to value delivered.
Kyle Poyar at Growth Unhinged has been tracking this shift closely. His analysis of 2024 SaaS pricing surveys found that companies with AI-native products are disproportionately moving to consumption or outcome models, with 43% of new AI SaaS products launched in 2024 using non-seat-based pricing as their primary structure.
The transition is real, it's accelerating, and companies that cling to per-seat models into an AI-saturated market are on uncertain ground.
For more context on how AI is fundamentally reshaping seat-based pricing alternatives, the disruption patterns play out similarly across product categories.
"Outcome-based pricing" is an umbrella term covering several distinct structures. The right model depends on your product, the measurability of outcomes, customer sophistication, and your ability to absorb revenue variability. Here is the full taxonomy.
You charge only when a defined outcome occurs. No platform fee. No monthly minimum. Customer pays when they win.
Examples:
Best for: Products where the outcome is binary, easily audited, and high enough value to justify per-event pricing. Works well for outbound prospecting tools, collections software, recruiting platforms.
Pros: Maximum alignment. Customer bears zero risk. Easiest sales conversation. "You only pay us when you win."
Cons: Revenue is entirely variable. You may do enormous amounts of work and get paid nothing if your customer doesn't close. Susceptible to attribution disputes ("that lead was already in our pipeline"). Hard to establish investor confidence around.
Variants: Some pure outcome models include a time-based fee after a trial period to prevent indefinite free usage while the customer claims "no outcomes yet."
You define a metric that correlates with value delivered — not seats, but something closer to the actual work done — and charge per unit. This is sometimes called "usage-based" pricing, though the distinction matters: usage-based charges for consumption of infrastructure (API calls, compute hours); value-metric pricing charges for units of business value (messages sent, contracts analyzed, decisions made).
Examples:
Best for: Products where value delivery is clearly quantifiable and happens at consistent intervals. AI-native products fit well here because compute correlates with value delivery.
Pros: Scales naturally. Customers pay more as they get more value. No artificial ceiling. Captures growth automatically.
Cons: Harder to budget. Enterprise procurement teams often require caps or commitments. Can penalize power users who drive most of your value creation.
The most common enterprise structure: a base platform fee provides revenue predictability, while an outcome-linked component captures upside when things go especially well.
Example structure:
Best for: Enterprise deals where procurement needs a predictable line item but the vendor wants to participate in value upside. Particularly useful for post-Series B companies with investor pressure for ARR predictability.
Pros: Balances predictability and alignment. Easier to model. Platform fee establishes minimum revenue commitment.
Cons: Complexity in contract design. Two pricing variables to track and communicate. Outcome bonus can feel like a gotcha if not explained well upfront.
You take a percentage of incremental revenue your product helps the customer generate. Most aggressive alignment model. Used in e-commerce optimization, sales acceleration, and affiliate-adjacent contexts.
Examples:
Best for: Products with direct, measurable revenue attribution. Works well in e-commerce, fintech, and sales tooling.
Pros: Maximum alignment. Scales with customer success without any cap.
Cons: Requires airtight attribution methodology. Customer legal teams often push back on rev-share clauses. Can result in very high absolute payments when customers scale, creating exit pressure.
For implementation-heavy or consulting-adjacent SaaS, pricing is tied to reaching defined milestones rather than ongoing consumption. Common in implementation platforms, compliance tools, and integration platforms.
Example: $0 at contract signing → $20,000 at first deployment milestone → $30,000 at go-live → $5,000/quarter maintenance.
Best for: High-touch, multi-month deployments where value is delivered in phases.
For a deep dive into the full spectrum of usage-based pricing structures and how they compare in practice, the SaaS pricing literature has become rich with empirical case data.
The most common failure mode in outcome-based pricing isn't the billing system or the sales process — it's choosing the wrong value metric. The metric must be measurable, attributable, meaningful to the customer, and correlated with your own cost of delivery. Nail all four and you have a pricing model. Miss any one and you have a mess.
Step 1: Map what customers actually pay for.
Not features. Not capabilities. Outcomes. Ask: if the customer is in front of their CEO explaining why they renewed this software, what do they say?
"We renewed because it saved us 40 hours of manual reporting per month." "We kept it because it increased our email deliverability from 78% to 94%." "We expanded because it reduced customer churn by 2 points."
Those answers are your value metrics. Time saved, deliverability rate, churn reduction.
Conduct customer interviews specifically around this question. Don't ask "what features do you use?" Ask: "If you had to justify this to your CFO in one sentence, what would you say?"
Step 2: Separate leading indicators from lagging outcomes.
Lagging outcomes (revenue increase, churn reduction) are the real value, but they often have long attribution chains and months-long feedback loops. Leading indicators (emails sent, documents processed, decisions made) happen in real time and are cleaner to measure.
The best value metric sits between the two: something that is clearly upstream of the lagging outcome but trackable in real time. "Qualified leads generated" is better than "revenue closed" (lagging, long cycle, attribution noise) and better than "emails sent" (too upstream, no quality signal).
Step 3: Stress-test measurability.
For every candidate metric, ask: can we measure this with 100% accuracy, without relying on the customer's systems, and without disputes?
If measurement requires integrating with the customer's CRM, you have a dependency risk. If measurement relies on customer self-reporting, you have a trust gap. If it's something you control entirely — events logged in your platform, API calls made, records processed — you're on solid ground.
Step 4: Validate correlation between metric and your cost of delivery.
Your pricing metric should scale with your costs, not just with customer value. If your compute costs spike when the customer generates 10,000 outcomes, your pricing should capture that. If your metric can scale to 10x with near-zero marginal cost on your side, that's fine too — but price accordingly.
This is where many AI companies get into trouble. They charge per API call (correlates with compute) but customers think they're paying for outcomes. Or they charge per outcome but their compute costs are unpredictable and don't track with that metric.
Step 5: Run the competitive displacement test.
Ask: would a competitor steal our customer by offering to price on a different metric? If a competitor could charge per seat and look cheaper even though you deliver more value, that's a sign your metric is weak and you need better framing or a different metric entirely.
| Category | Strong Value Metrics | Weak Metrics to Avoid |
|---|---|---|
| Customer support AI | Tickets resolved, CSAT improvement | Sessions opened, agent logins |
| Sales automation | Meetings booked, pipeline created | Emails sent, contacts added |
| Data analytics | Reports generated, decisions logged | Dashboard views, queries run |
| Recruiting | Hires made, time-to-hire reduction | Candidates sourced, job posts |
| Legal / contract | Contracts reviewed, risk flags caught | Documents uploaded, pages read |
| Finance / accounting | Invoices processed, errors caught | Transactions logged, users |
The right column isn't inherently wrong — it's just that those metrics describe activity, not outcomes. Customers will always push back on activity pricing when they can argue the activity didn't lead to a result.
You cannot run an outcome-based pricing model on a spreadsheet and a handshake. The technical infrastructure required is meaningfully more complex than seat-based billing, but it has also become dramatically more accessible in the past two years. Here is the full stack.
Metering is the foundation. Every billable event must be captured, timestamped, attributed to a customer, and stored with enough context to be audited.
What you need:
Managed metering options:
Metering tells you what happened. Billing turns it into invoices.
Stripe Billing handles most early-stage outcome models well:
usage_type: metered on price objects for consumption billingbilling_scheme: tiered for volume discountsstripe.subscriptionItems.createUsageRecord() for pushing metered usageLimitations of Stripe for complex outcome models: Stripe billing was designed for subscriptions. Complex outcome models — multi-dimensional pricing, contract-level custom rates, minimum commits with true-ups — become painful in Stripe and require significant engineering workarounds.
At growth stage, purpose-built billing platforms handle this better:
Customers on outcome-based pricing have legitimate anxiety about runaway costs. The antidote is transparency. Create or integrate real-time usage dashboards that show:
This isn't optional. It's a trust mechanism. Customers who can see their usage in real time are dramatically less likely to dispute invoices or churn due to billing shock.
Outcome-based pricing will generate attribution disputes. Plan for them. Every invoice should be reconstructable from raw event logs. Create an internal tool (even a simple admin panel) that allows your Customer Success team to pull a complete audit trail for any customer for any billing period, showing every event that contributed to the invoice.
For models with attribution complexity (revenue share, lead quality measurement), consider third-party attribution verification or contractual clauses specifying attribution methodology.
Outcome-based pricing breaks most traditional SaaS sales compensation structures. If you don't redesign comp alongside pricing, your sales team will resist the new model or find ways to undermine it.
The problem with quota on TCV for outcome models: If a rep closes a deal that could generate anywhere from $60K to $200K ARR depending on customer adoption and outcomes, what does the rep get quota credit for? If you credit $60K (the minimum), reps are incentivized to sandbag. If you credit $200K (the potential), you're crediting revenue that may never materialize.
Recommended approach: Credit reps on committed ARR (platform fee + minimum commit) at close, with an expansion bonus at 6 and 12 months when actual usage is known. This creates a two-part comp event:
This structure requires that reps stay engaged post-close, which is a feature, not a bug. It breaks the handoff pattern where AEs pass deals to CS the moment the contract is signed.
Under seat-based pricing, CS metrics are typically: retention rate, NPS, and QBR attendance. These are activity metrics dressed up as outcome metrics.
Under outcome-based pricing, CS must own real outcomes:
CS teams on outcome models should be structured as value delivery partners, not account managers. Their job isn't to keep the customer happy — it's to ensure the customer achieves the outcomes that justify the bill. This is a fundamentally different skill set and often requires rethinking CS hiring profiles.
The most effective structure is a pod model: one AE and one CSM co-own the customer relationship from first meeting through year two. They share variable comp. When the customer succeeds and expands, both earn. When the customer doesn't hit outcomes and downgrades, both feel it.
This eliminates the adversarial dynamic that emerges when AEs oversell outcomes to close deals and then CSMs have to manage the expectation gap.
Define explicit handoff criteria: what must be true before a deal moves from AE-primary to CS-primary ownership? Typically: contract signed, implementation started, first admin user onboarded, success metrics documented.
The primary objection to outcome-based pricing from CFOs and investors is revenue unpredictability. If your revenue swings 40% month-to-month based on customer adoption patterns, you cannot construct a reliable financial model, and investors will apply a multiple discount to reflect that uncertainty.
Here is how to engineer predictability into an inherently variable model.
Every outcome-based contract should include a minimum annual commitment. This is the floor below which the customer cannot bill, regardless of how little they use the product.
How to size the minimum: The minimum should represent the value of the product at baseline adoption — typically 40-60% of the estimated ARR at full deployment. It should be large enough to cover your cost of serving the account and make the deal financially viable, but not so large that it creates sticker shock.
Contract language example: "Customer commits to a minimum annual spend of $48,000 (the 'Annual Minimum Commitment'). Actual billing will be the greater of (a) the Annual Minimum Commitment prorated monthly, or (b) actual metered usage in that month."
This gives you a revenue floor. From an accounting perspective, the minimum commit is recognizable as ARR.
A ratchet clause prevents customers from billing below a prior high-water mark. If a customer hit $15,000 in a peak month, a ratchet clause means their minimum the following month is $12,000 (80% of peak, for example), even if their usage fell.
Ratchets are common in enterprise software, legal retainers, and agency contracts. They protect against temporary usage dips that don't represent real value decline (seasonal lulls, team transitions, implementation pauses).
Important: Ratchet clauses create retention friction during genuine product dissatisfaction. Use them in contracts where you have high confidence in ongoing value delivery, not as a mechanism to lock in customers who aren't succeeding.
For customers with predictable seasonal variation (retail companies with Q4 peaks, tax software with April spikes), structure seasonal adjustments into the contract. Define expected high-water months and expected low months upfront, and set billing floor accordingly.
This prevents a situation where a retail company hits $50K in November, drops to $8K in January, and feels like they're being overbilled relative to current usage even though their annual spend is reasonable.
Outcome-based pricing creates a new churn risk vector: customers who hit outcomes but attribute them to their own team's work rather than your software. This is attribution churn — they stop paying because they don't believe the correlation they're paying for.
Mitigation:
Seat-based pricing pages are simple: three columns, three prices, a "most popular" badge on the middle tier. Outcome-based pricing pages require a fundamentally different design philosophy because the price is not a fixed number — it depends on how much value the customer gets.
When a prospect lands on your pricing page and can't see a number, anxiety spikes. "Why won't they just tell me the price?" is the immediate reaction. Your pricing page must answer this anxiety without lying ("prices start at $X") or oversimplifying ("it depends").
The most effective pricing page for outcome models is a calculator. Give the prospect inputs and show them estimated costs.
Example inputs for a recruiting SaaS:
Outputs:
The calculator does two things simultaneously: it personalizes the pricing estimate, and it forces the prospect to quantify their own situation — which primes them to see value in the number your calculator produces.
The calculator should connect to an ROI estimator. The ROI estimator shows the value case, not just the cost. Prospects on outcome-based pricing aren't just evaluating "how much does this cost?" They're evaluating "does the potential outcome justify the price?"
Make that evaluation easy. Show case study data. Show industry benchmarks. Show what similar-sized companies have achieved.
Headline: Lead with the outcome, not the mechanism. "Pay only for hires made" beats "Outcome-based recruiting software."
Sub-headline: Quantify the typical value. "Our customers average $3,200 in savings per hire compared to traditional ATS tools."
Pricing structure explained in plain language: Don't hide the model. Explain it directly: "You pay $850 per successful hire, with a $3,500/month platform minimum. Most customers hire 8-15 people per month."
FAQ section addressing the anxiety questions:
Case studies on the pricing page: Not on a separate page. On the pricing page itself, inline, showing real customers with real numbers. "Acme Corp hired 23 people last quarter using our platform, paying $19,550. Their previous cost for 23 hires was $41,000."
The hardest part of adopting outcome-based pricing isn't designing the model — it's migrating your existing customer base without triggering mass churn or a sales revolt.
Never force existing customers into a new pricing model. Grandfather them permanently, or grandfather them with a defined sunset.
Permanent grandfather: Existing customers keep current pricing forever. New customers go on the new model. This is the lowest-risk approach but creates a two-tier customer base that complicates CS, support, and feature prioritization.
Timed grandfather: Existing customers keep current pricing for 18-24 months, with clear advance notice of transition. This is the most common enterprise approach. It gives customers time to budget, negotiate, and plan.
Opted-in early migration: Offer existing customers an incentive to voluntarily migrate to the new model early. "Switch to our outcome-based model before January 1 and get a 20% lower success fee rate, grandfathered for 3 years." This lets you migrate your most sophisticated, value-confident customers first while keeping the reluctant ones on legacy pricing temporarily.
Don't flip to outcome pricing across your entire customer base simultaneously. Run a phased cohort rollout:
Cohort 1 (months 1-3): New logo customers only. All new contracts are on the new model. You develop operational muscle — billing, CS workflows, dispute resolution — without risking existing revenue.
Cohort 2 (months 4-9): Expansion contracts. When existing customers expand or renew, new scope is priced on the new model while their existing contracted volume stays on legacy pricing. This starts bridging existing customers toward the new model incrementally.
Cohort 3 (months 10-18): Full renewal migration for high-engagement customers. When contracts come up for renewal, CS has the conversation: "Here's what outcome-based pricing would have cost you over the last 12 months based on your actual usage. It would have been $X vs. the $Y you paid." If outcome-based is better for them, it's an easy upsell. If it's worse, you have a product or pricing design problem to fix.
Email for announcing the new model to existing customers:
Subject: How we're changing pricing for new customers (your account isn't affected)
"[First name], we're launching a new pricing model for customers who join after [date]. We're moving to outcome-based pricing — you only pay when [specific outcome]. For you as an existing customer, nothing changes. Your current pricing is locked in through at least [date]. I wanted to make sure you heard it from us directly before any public announcement. Happy to walk you through how the new model works if you're curious — some of our existing customers have actually asked to move over early."
For expansion conversations:
"As we expand your account to include [new use case], I want to walk you through a pricing option we have for this expansion. Based on your current usage patterns, outcome-based pricing for the expanded scope could save you [X%] vs. our standard rate. Here's how it works..."
"We can't budget for variable pricing." Answer: The minimum commit makes a predictable line item. Your budget exposure is capped at [minimum]. Above that, you only pay when you've already gotten value. Most finance teams appreciate that structure once they understand it.
"How do I know you won't inflate the outcome counts?" Answer: All metering data is available to you in real time via your dashboard. Every event is logged with a timestamp and event ID. You can audit any invoice at any time. We also offer a third-party verification option for customers above $X ARR.
"Our procurement process requires a fixed annual fee." Answer: We can structure the contract as a fixed annual commitment with a true-up at year end. You pay a fixed monthly amount; at 12 months, we reconcile against actual outcomes. If you used more, there's a true-up. If you used less, it rolls forward or is credited. Many enterprise customers prefer this structure.
Snowflake structured its entire growth story on consumption-based pricing. Instead of selling licenses, they charge per credit consumed (compute + storage). When customers use Snowflake to run more queries, process more data, and construct more pipelines, revenue grows automatically.
The result: Snowflake's net revenue retention (NRR) has consistently been above 130% — sometimes hitting 170% — because customers who start small and succeed naturally expand. They don't need an upsell call to buy more licenses. They just use the product more.
The critical design decision Snowflake made: credits are fungible. One credit can be used for any workload — compute, storage, data transfer — which removes friction from expansion. Customers don't have to decide in advance how they'll use the product. They just use it, and billing follows.
The Snowflake model also proves that consumption pricing can generate predictable revenue at scale. Their RPO (remaining performance obligation, which represents contracted future revenue) grew consistently even with variable consumption models, because large enterprise customers sign multi-year commit contracts.
Datadog charges on multiple consumption dimensions simultaneously: hosts monitored, custom metrics ingested, log volume, APM spans, synthetic tests run. Each has its own pricing. Customers pay only for what they instrument.
This multi-dimensional approach initially sounds complex, but it has a powerful effect: expansion is frictionless and customer-initiated. When an engineering team adds a new service, Datadog billing automatically captures it. No sales call required. No contract amendment. Revenue grows as the customer's infrastructure grows.
Datadog's NRR has consistently been 120-130%, and the company attributes a significant portion of this to their usage-based model that lets expansion happen without friction.
In 2023, Intercom made a significant pricing pivot: instead of charging per seat for customer support software, they moved to a model where AI-resolved conversations are priced differently than human-assisted ones. AI resolutions cost $0.99 each; human-assisted conversations are priced on a per-seat basis.
This was a direct response to the AI disruption threat. If Intercom kept per-seat pricing as AI handled more conversations, revenue would erode as companies needed fewer human agents. By pricing AI resolutions separately — at a price that reflects the value delivered (rapid resolution) rather than the cost of compute — Intercom repositioned itself to grow revenue as AI adoption grows.
The early results were promising: enterprise customers who deployed Intercom's AI saw their costs go up, not down, in absolute terms — because they were resolving dramatically more tickets at lower per-ticket cost, driving higher absolute spend. The pricing model succeeded because the value metric (resolved tickets) scales with usage, and usage scaled as AI got better.
Workiva, the financial reporting and compliance platform, has structured enterprise contracts around outcome metrics: time-to-close for financial reports, error rates in regulatory filings, audit findings reduction. Their pricing includes success components tied to measurable compliance outcomes.
This model works in compliance because outcomes are highly verifiable (external audits, regulatory filings have hard deadlines and documented results) and the consequence of failure is extreme (SEC filings, SOX compliance). Customers in this space have high willingness to pay for genuine outcome guarantees.
For context on how AI product pricing strategy connects to these structural shifts, the case studies illustrate that the winners are companies who redesigned pricing as a product decision, not just a sales process.
The hardest conversation about outcome-based pricing isn't with customers — it's with your board and investors. ARR is the north star metric for most SaaS investors, and outcome-based pricing complicates ARR in ways that can make your financials look worse on a spreadsheet even when the business is growing healthily.
The ARR problem: Traditional ARR is calculated on contracted recurring revenue — typically the annualized value of the customer's contract. With minimum commits, you can still calculate contracted ARR (the minimum). But actual consumption can be 1.2x to 3x the minimum, and that upside isn't captured in ARR.
Recommended metric framework for outcome-based companies:
Revenue forecasting for outcome-based businesses requires a cohort model rather than a simple seat count model.
Cohort model inputs:
The S-curve of consumption: Most customers don't hit full consumption immediately. They ramp up over 3-6 months as adoption grows. Model this ramp explicitly rather than assuming day-one full deployment. Your revenue forecast will be more accurate and your investor conversations will be grounded in actual observed behavior.
Scenario modeling: Run three scenarios — conservative (customers at 80% of committed minimum), base (customers at 130% of committed minimum, matching historical averages), and upside (customers at 200%, representing full platform deployment). Show investors all three with the assumptions behind each.
Board deck framing:
"We operate an outcome-based pricing model. Our contracted ARR is $X — this is our revenue floor, guaranteed by minimum commits in signed contracts. Our trailing 90-day consumption ARR is $Y, representing 1.4x our contracted ARR. Our consumption NRR is 138%, meaning existing customers are growing their usage by 38% annually."
The multiple question: Investors familiar with Snowflake, Datadog, and other consumption-based companies have learned to apply consumption NRR rather than seat retention as the key durability metric. If your consumption NRR is 120%+, you have a strong story regardless of the lower contracted ARR number.
The predictability story: Don't try to argue that consumption revenue is as predictable as contracted ARR — it isn't, and investors know it. Instead, tell the predictability story through: minimum commit coverage (what percentage of your Opex does contracted ARR cover?), cohort expansion curves (show that 6-month-old customers consistently expand), and customer concentration (no single customer exceeds X% of consumption ARR, limiting volatility).
Slide: Revenue Metrics
Slide: Cohort Expansion
Slide: Revenue Quality
The Zuora Subscription Economy Index offers benchmark data showing that subscription economy companies with high usage-elasticity in their pricing consistently outperform pure subscription models on NRR — useful data for investor context slides.
For companies still figuring out whether to monetize through freemium first or go straight to outcome pricing, the decision tree in monetization strategies offers a framework for sequencing these decisions by stage.
Designing an outcome-based pricing model is a multi-month initiative. Here is a compressed roadmap:
Days 1-30: Research and Design
Days 31-60: Infrastructure and Pilot
Days 61-90: Rollout and Communication
The transition to outcome-based pricing is not painless. You will lose some deals from buyers who cannot handle variable pricing. You will have billing disputes. You will have quarters where consumption comes in below minimums and the model feels expensive relative to seat-based alternatives.
But the companies that make this transition successfully — that construct pricing models genuinely aligned with customer success — end up with the most durable competitive advantages in SaaS: customers who can't churn because the software is proving value every billing period, expansion that happens automatically as customers succeed, and a sales motion centered on "you only pay when you win."
That's not just a better pricing model. It's a better business.
For additional reading on the structural shifts reshaping SaaS pricing, OpenView Partners' SaaS benchmarks and Kyle Poyar's Growth Unhinged newsletter are the most consistently rigorous sources in the market.
61% of enterprise buyers prefer outcome-based pricing. Per-seat doesn't work when AI replaces labor. Here's a product leader's guide to designing, implementing, and operationalizing outcome-aligned revenue models.
Complete playbook for migrating SaaS pricing to usage-based models. Covers metering infrastructure, hybrid pricing, revenue forecasting, and real migration timelines.
Seat-based pricing dropped from 21% to 15% adoption in 12 months. Here's why it's dying, what's replacing it, and how to migrate without a revenue cliff.