.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
Pricing strategy now fails at thesystems layer
AI, agentic workflows, and consumption pricing have turned monetization from an administrative task into a systems engineering problem. CPQ, metering, billing, entitlements, and revenue recognition now have to evolve together.
In the seat-based SaaS era, pricing could live in spreadsheets and billing could be configured after the commercial decision. Under consumption and AI-native pricing, every customer interaction can generate real cost, pricing metrics change more frequently, and the product runtime itself becomes part of the revenue system.
The biggest failure point is the gap between the pricing decision and the systems that operationalize it. No single function owns that end-to-end path, which is why launches stall, revenue leaks, and engineering teams end up rebuilding pricing logic repeatedly.
The framework
The Monetization Stack
Every modern monetization system depends on four interlocking layers. In a usage-based or hybrid model, the gaps between them are where launch stalls and revenue leakage occur.
- Entitlement & access control
Defines what a customer is allowed to use and enforces limits such as token caps, model tiers, concurrent-agent limits, and context-window thresholds. - Metering
Captures billable usage events across tokens, model type, compute time, tool calls, and outcome events without dropping or double-counting revenue. - CPQ
Translates commercial constructs such as platform fees, commits, discounted units, and overages into contracts that the product and billing systems can actually execute. - Billing & revenue recognition
Turns usage events into invoice line items and applies the accounting logic for committed use, overages, breakage, true-ups, and ASC 606 revenue recognition.
Why this matters
Four failure modes explain why the systems layer matters
The cost of an under-specified monetization stack shows up in delayed launches, missed revenue, customer bill shock, and implementation rework.
- 12–18 month launch stalls Pricing decisions can sit for more than a year when nobody owns the specification and systems-engineering layer between strategy and production.
- 2–5% ARR leakage Mis-metered events, missed overages, incorrect prorations, and reconciliation gaps can silently reduce realized revenue.
- Bill shock Poor entitlement, notification, and usage-control design can create unexpected charges, renewal friction, and overage disputes.
- 40–50% implementation overruns CPQ and billing programs frequently expand beyond initial time and cost estimates when scope, integrations, and vendor dependencies are discovered late.
The model is designed against value, customer risk, margin and operational feasibility at the same time.
Scope & workstreams
The engagement moves from diagnosing the stack, to specifying what every system must do, to coordinating implementation and launch.
Three disciplines, from architecture to go-live
WorkstreamGoalYou get
Architecture Review
SYSTEM DESIGNDefine what the monetization stack needs to become before implementation begins.
1.
Current-state architecture & gap analysis
Map CPQ, metering, billing, ERP, and entitlement systems, including integration seams, vendor dependencies, and technical debt.
Know exactly where the current stack will break under the target pricing model
Current-state architecture map and gap analysis
2.
Target-state architecture & build-vs-buy
Define the target system boundaries, vendor roles, integration sequence, and build-versus-buy decisions.
Create an architecture the organization can implement
Target-state architecture, vendor matrix, and critical path
Product Management
SPECIFICATIONTranslate commercial requirements into implementation-ready product and system specifications.
3.
Metering & event specification
Define billable events, event schemas, attribution rules, idempotency requirements, and reconciliation logic.
Make every revenue-bearing event measurable and auditable
Event schema and metering specification
4.
CPQ & billing workflow design
Specify commits, overages, top-ups, true-ups, pricing approvals, billing flows, and the rules that connect contracts to runtime usage.
Turn pricing constructs into executable commercial workflows
CPQ workflow PRDs and billing-flow specifications
5.
Entitlements, accounting & customer policies
Define entitlement enforcement, ASC 606 treatment, customer notifications, dispute handling, and contract language for new pricing constructs.
Make the model operable across product, finance, and customer experience
Entitlement, revenue-recognition, notification, and policy specifications
Project Management
EXECUTIONCoordinate vendors, systems integrators, internal teams, testing, and launch against one implementation plan.
6.
Program governance & implementation control
Run the master plan, critical path, risk register, decision log, change control, and vendor/SI coordination.
Keep implementation decisions and dependencies under one owner
Master project plan, status cadence, risk register, and decision log
7.
Go-live readiness & cutover
Coordinate UAT, launch readiness, cutover planning, Deal Desk readiness, and sales enablement.
Make the new pricing model shippable and operational on launch day
Go-live checklist, cutover runbook, and enablement framework
The deeper implementation layer can extend into detailed CPQ, billing, metering and pricing-systems work throughmonetization engineering.
How it works
Three phases, from architecture to production launch
Architecture, specification, and execution overlap so systems decisions are made early enough to avoid downstream rework.
OutputTarget-state architecture
Architecture Review
Map the current CPQ, metering, billing, ERP, and entitlement stack; identify gaps; define the target architecture and vendor decisions.
OutputImplementation-ready specifications
Diagnose & design
Write the PRDs, event schemas, billing flows, entitlement rules, ASC 606 treatment, customer policies, and acceptance criteria that vendors and engineering teams build against.
OutputProduction go-live
Execution
Coordinate the master implementation plan, vendors and SIs, UAT, risk management, cutover, sales enablement, and launch readiness.
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.
How do you transition existing SaaS customers to an Agentic AI pricing model?
+
Transitioning existing customers to a new pricing model requires a phased rollout with grandfathering provisions, separate price books for new versus existing customers, and a realistic timeline - typically 12-18 months for the full migration.
This is one of the hardest problems in SaaS pricing, and most companies dramatically underestimate the complexity and overhead involved. Changing the pricing model for existing customers isn't just a billing update - it touches contracts, sales compensation, financial reporting, customer success workflows, and your renewal engine.
Here's how to approach it:
First, run separate price books. New customers go on the new Agentic AI pricing model from day one. Existing customers stay on their current model until their renewal window. This avoids the disruption of forcing changes mid-contract and gives you time to build operational muscle on the new model with new customers before migrating your installed base.
Second, design your grandfathering strategy. Not every customer needs to move at the same time or to the same model. Segment your existing base by risk: Which customers would benefit from the new model (and are therefore easy transitions)? Which customers would see higher costs (and need careful handling)? Which are high-churn-risk regardless? Start the migration with customers who will see clear value from the new model - they become internal case studies and references.
Third, plan for the conversation. Every customer migration requires a human conversation - this isn't something you announce via email blast. Your CSMs and AEs need to explain why the change is happening, demonstrate how the new model aligns with the customer's success, and provide a clear cost comparison. Some customers will need price protection periods (6-12 months at their current rate) to ease the transition.
Fourth, accept the overhead cost. Customer migrations consume CS and sales bandwidth. You'll need dedicated resources to manage the transition, handle billing disputes, and update contracts. Factor this into your timeline and resource planning.
The companies that fail at this try to do it too fast. They announce a "sunset date" for the old model, push everyone onto the new pricing, and lose 15-20% of their base to churn. The companies that succeed treat it as a 12-18 month program with dedicated ownership, clear communication, and enough flexibility to accommodate customers who need more time.
Other consultants sound the same, how are you different?
+
None of the other premier consultants have actually implemented complex pricing within companies like Twilio and Zoom. This requires operational systems understanding, not just strategy.
In addition, other consultants often "over egg the pudding", they know customers will buy approaches as long as they look/feel scientific, yet we have multiple customers who have spent more >$100k each on conjoint analysis which did not help them at all. We are careful with where we ask you to spend your money.
Should we price our AI agents based on tokens, tasks, or outcomes?
+
Each pricing metric carries distinct tradeoffs across implementation complexity, value alignment, and margin potential. The right choice depends on your product's maturity, your ability to instrument usage, and how clearly you can tie consumption to customer value.
Here's how each option breaks down:
Token-based pricing
Pros: Tokens are the easiest metric to meter and map directly to your underlying compute costs, giving you tight cost control and margin visibility from day one. For developer-facing API products (like OpenAI's API), tokens are intuitive - developers understand them and can optimize around them.
Cons: Tokens have no natural connection to business value. No customer measures their success in tokens consumed, which makes pricing conversations difficult with non-technical buyers. Token pricing can also create usage anxiety - customers start rationing interactions, which suppresses adoption and can increase churn over time.
Task-based pricing (per workflow executed, per document processed, per query handled)
Pros: Tasks strike a practical balance between measurability and value alignment. They're understandable to buyers, reasonably easy to instrument, and tend to correlate with the value customers receive. The key is selecting a task metric that is (a) simple to define, (b) easy for the customer to track and forecast, and (c) proportional to the value they receive. n8n, for example, charges per workflow execution - one run counts as a single execution regardless of how many nodes it includes - making "usage" easy to define and the charge against each usage event simple to understand.
Cons: Not all tasks deliver equal value, which means you may leave money on the table on high-value workflows while overcharging on low-value ones. Defining the task boundary can also get tricky as agent capabilities grow more complex - a single "task" might involve multiple subtasks with very different cost profiles.
Outcome-based pricing (per issue resolved, per qualified lead, per successful transaction)
Pros: Outcomes deliver the strongest value alignment and can support the highest margins, since you're charging for the result the customer actually cares about. This model also creates a powerful sales narrative - you're sharing risk with the customer and only getting paid when they see value. Intercom chose $0.99 per resolution for its Fin AI Agent, which resonates strongly with buyers because the charge maps directly to a support ticket deflected.
Cons: Outcome pricing introduces real operational risks. Defining outcomes is harder than it sounds - who determines "resolved"? What happens when some outcomes cost you 10x more to deliver than others? Intercom faces ongoing challenges around defining when a conversation is truly "resolved" versus merely abandoned - and at high volume, a 50% resolution rate on 10,000 monthly conversations means $4,950 in variable costs that scale directly with automation performance. Salesforce discovered similar friction when its $2-per-conversation Agentforce pricing confused customers about what counted as a "conversation," forcing a pivot to action-based Flex Credits within months of launch.
Our recommendation: For most Agentic AI products, task-based pricing offers the strongest starting point - it balances measurability with value alignment while keeping operational complexity manageable. Where possible, select task metrics that approximate outcomes, and build the instrumentation to move toward true outcome-based pricing as you accumulate data on cost patterns and customer definitions of success. Token-based pricing can work well for developer-facing or infrastructure-layer products, but is rarely the right primary metric for business application pricing. Whichever metric you choose, it must be simple to understand, easy to track, tied to value, predictable - and it must cover your costs.
What are the margin risks of offering a flat-rate subscription for AI agents?
+
A flat-rate subscription for AI agents creates direct margin risk because your costs scale with usage while your revenue stays fixed - heavy users can push individual accounts into negative gross margin territory.
This isn't theoretical. Sam Altman publicly acknowledged that OpenAI was losing money on heavy users of the $200/month ChatGPT Pro subscription because inference costs exceeded the subscription revenue. Cognition's Devin faced the same problem from the opposite direction - at $500/month flat for its autonomous coding agent, the price was too high for light users and potentially margin-destructive for heavy users chaining dozens of complex multi-step workflows.
They ultimately abandoned flat-rate entirely, moving to $2-$2.25 per Agent Compute Unit on a pay-as-you-go basis. And that's for products with relatively predictable per-query costs.
For Agentic AI products, where a single autonomous workflow can chain 10-50 LLM calls plus API lookups plus orchestration compute, the cost variance per "use" is dramatically higher.
The specific risks include:
Margin degradation from power users. In a flat-rate model, your most engaged customers - the ones getting the most value - are your least profitable. This inverts the fundamental SaaS dynamic where your best customers should also be your most valuable.
Unpredictable COGS forecasting. With AI agents, the cost of serving each customer depends on their specific use case, complexity of tasks, and volume. You can't forecast COGS accurately if usage patterns vary wildly.
No natural expansion revenue. Flat-rate pricing eliminates the upsell trigger. There's no signal that tells you when a customer has outgrown their plan and should upgrade.
The guardrails to mitigate these risks: Introduce usage tiers within your flat-rate plans (e.g., up to 1,000 agent actions/month at the base tier). Add overage pricing beyond the bundled allocation. Set rate limits or throttling for extremely heavy usage. Implement the three-part tariff model - platform fee plus bundled usage plus overage - which gives customers subscription-like predictability while protecting your margins. This is how most successful AI products are structured today, from ElevenLabs to Intercom's Fin to Salesforce's Agentforce Flex Credits.