.png)
.jpg)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
The problem
The seat is becoming a strategicconstraint
AI is absorbing seat-based workflows while consumption fragments across UI, API, MCP, and custom integrations. The result is a widening gap between the number of users you charge for and the value your product actually delivers.
Per-seat pricing is no longer only a packaging decision. It can constrain how the business grows when value separates from headcount.
The transition is also unusually risky because the pricing model and the operating model have to change together. Moving to consumption affects customer segmentation, packaging, metric selection, unit economics, willingness to pay, sales compensation, CPQ, billing, metering, revenue recognition, and migration.
The customers most exposed are often shelfware accounts and light users on heavy bundles. That means cannibalization modeling and migration design need to happen before the rate card is locked.
The framework
The Consumption Transition Spectrum
The CTS evaluates your business across three dimensions and uses the result to determine the right pricing architecture, migration design, and operational sequencing.
- Value-Headcount Decoupling Test
How far customer value has separated from the number of seats being purchased. Low decoupling supports seats or hybrid pricing; high decoupling makes consumption more viable. - Consumption Surface Distribution
Where consumption occurs. A concentrated product surface can support a surface-specific metric, while UI + API + MCP + integrations may require a unified consumption currency. - Cannibalization Exposure
How much existing ARR could decline under a consumption model. High exposure increases the need for platform fees, renewal-only migration, and grandfathering.
Why this matters
Most consumption transitions fail in predictable places
The pricing decision is only one part of the transition. Revenue protection, operational readiness, and migration sequencing determine whether the model survives contact with the installed base.
- Structural pressure AI and multi-surface consumption weaken the relationship between seats and customer value.
- Operational stalls A rate card can be approved long before CPQ, metering, billing and compensation are able to support it.
- Revenue leakage Metering gaps, reconciliation errors and uncontrolled bill shock can erase part of the upside of the transition.
- Cannibalization Shelfware accounts and light users on heavy bundles can pay materially less when the seat construct disappears.
Scope & workstreams
The workstreams run in sequence and are tailored to the company’s Consumption Transition Spectrum profile.
Six workstreams, from segmentation to operationalization
WorkstreamGoalYou get
Pricing strategy
Core · every engagementSegment, package, metric and economics decisions are made before the operating build is specified.
1.23
Strategic customer segment review
Segment the installed base by consumption readiness, value drivers and cannibalization exposure; identify which cohorts should migrate first.
Know where the transition can expand revenue and where it can destroy it
Segment readiness map with migration sequencing
2
Hybrid Package Architecture and Design
Design platform-plus-consumption tiers, unified token currencies where appropriate, capability-to-segment mapping, and committed-usage bundles with rollover and overage rules.
Build a commercial architecture that protects predictability while allowing consumption to scale.
Defensible packaging architecture with token-currency specification.
3
Price Metric Selection via the CTS
Evaluate token, transaction, outcome, and hybrid metrics against value-headcount decoupling, consumption surfaces, cannibalization exposure, margin, and predictability.
Choose a metric that works for customers, economics, and the operating model.
Pricing metric selection with rationale and unit-economics validation.
1.
Unit Economics and Migration Modeling
Model cohort revenue protection, cannibalization scenarios, cost to serve, and margin floors.
Know the ARR and margin consequences before migrating customers.
Revenue and margin model with sensitivity analysis across migration paths.
5
Data-Driven Price Point Selection
Run willingness-to-pay research, competitive benchmarking, platform-fee design, committed-token bundle pricing, and overage-rate setting.
Set rates on evidence rather than internal intuition or competitor copying.
Defensible rate card with research backing.
Operational transformation
Launch layerThe pricing model is translated into the rules, systems and customer migration mechanics required to ship it.
6
Market Testing and Operationalization
Run a pilot cohort and design sales compensation, CPQ rules, billing flows, ASC 606 treatment, migration mechanics, and sales enablement.
Make the pricing model launchable by the actual organization.
Launch-ready pricing with the supporting operational stack.
The deeper implementation layer can extend into detailed CPQ, billing, metering and pricing-systems work throughmonetization engineering.
How it works
Three phases, from diagnostic to launch
Strategy and operational readiness progress together so the pricing model does not get stranded between approval and production.
OutputCTS profile & architecture
Diagnose & design
Current-state diagnostic, segmentation, cannibalization analysis, package architecture, metric selection and unit-economics modeling.
OutputValidated rate card
Research & Pilot
Willingness-to-pay research, competitive benchmarking, platform-fee and usage-rate setting, followed by a structured pilot cohort.
Operationalize & LaunchLaunch-ready transition
Output
Sales compensation, CPQ, billing, metering, revenue recognition, migration sequencing, enablement, vendor coordination, and go-live planning.
The team
Operators first, consultants second
Team background28+ years of combined pricing and monetization leadership at Twilio, Zoom, DocuSign, LinkedIn, and Squarespace. We have run pricing as operators and as consultants, and we understand both the commercial decision and the systems needed to operationalize it.
Co-founder & CEO
Ajit Ghuman
Author ofPrice to Scaleand co-author ofMonetizing Agentic AI. Led pricing as an operator through the perpetual-to-SaaS and seat-to-usage shifts.
Meet the team →
Co-founder · COO/CTO
Akhil Gupta
Co-author ofMonetizing Agentic AI. Leads monetization engineering across metering, billing, CPQ and pricing-systems architecture.
Monetization engineering →FAQ
Seat-to-usage pricing, answered
Condensed from our research and client work. This static block can later be replaced with the existing FAQ multi-reference list in the CMS template.
What is Monetization Engineering?
+
Monetization Engineering is the systematic discipline of building and operating the infrastructure that translates product usage into revenue, while remaining flexible enough to support rapid pricing evolution.
It is not billing engineering, although it includes it. It is not pricing strategy, although it operationalizes it. It is not RevOps or financial operations. It is the connective tissue across CPQ, metering, billing, entitlements, and revenue recognition that no single function owns. The discipline emerged because traditional billing tools and RevOps teams cannot handle the complexity of consumption-based or AI-native pricing, and pricing metrics now change every 6 to 18 months in modern software companies.
How is Monetization Engineering different from billing engineering, pricing strategy, or RevOps?
+
Monetization Engineering spans all three but is owned by none of them.
Pricing strategy decides what to charge for; it does not implement systems. RevOps runs the deal motion in CRM-scale data; it cannot operate machine-scale event pipelines. Billing engineering builds invoice generation; it does not own pricing logic, entitlements, or CPQ. Monetization Engineering is the architecture, specification, and execution layer that connects all four into a working system. It is the only discipline that owns the end-to-end path from product event to GAAP-recognized revenue.
Why can’t existing billing vendors solve usage-based pricing on their own?
+
Modern monetization is an architecture problem, not a tool problem. The vendor landscape is fragmented by design.
Metronome powers OpenAI and Anthropic billing but does not handle ASC 606 revenue recognition rules in NetSuite. Orb’s RevGraph separates instrumentation from pricing logic but does not own CPQ or contract management. Salesforce CPQ generates quotes but has no mechanism to push contract limits into the product runtime to enforce entitlements. Stigg owns entitlements but not metering or invoicing. Lago is open-source and flexible but requires engineering to deploy and operate.
You buy components, not a finished system. Buying high-quality materials does not produce a well-designed building. The integration, specification, and orchestration work is what most companies underestimate.
Why can’t RevOps own monetization for AI products?
+
RevOps owns the deal motion in CRM-scale data. AI monetization operates on machine-scale event streams. The gap is structural, not skill-based.
Three reasons RevOps cannot own this alone:
Scale mismatch. RevOps tools (Salesforce, HubSpot, Gainsight) operate on hundreds of contracts and thousands of leads. AI monetization operates on millions of tokens and billions of events. You cannot push high-velocity inference logs into Salesforce without serious performance and reliability issues.
Low-code ceiling. RevOps teams excel at Zapier, Workato, and Salesforce Flow. Mission-critical AI billing requires idempotent, fault-tolerant code. Drag-and-drop workflows are too brittle for revenue-grade ledgers.
Source-of-truth shift. In traditional SaaS, the source of truth was the contract in the CRM. In AI SaaS, the source of truth is the infrastructure where usage occurs. RevOps typically lacks access to and deep familiarity with that environment.