.png)
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.
Service -
New Pricing Metrics
Choose the metric your revenuescales on
The pricing metric is the unit your entire revenue model multiplies from. Monetizely has implemented usage-based pricing (UBP) end to end at small and large companies, and we start from an honest assessment: UBP aligns price with customer value, and it is not a universal solution. The engagement validates whether a new metric fits your context, then designs the metric, tariff structure, packages, and price points.
Last reviewed September 2026 · Strategy, migration, and operational readiness in one engagement
The decision
A new metric rewires thewhole company
Usage-based pricing can align revenue with the value customers get. It also changes sales compensation, revenue forecasting, profit-and-loss reporting, and even how the company is valued. The first step is validating that a new metric fits your customer segments, usage patterns, costs, and operations, before any design work starts.
When the assessment supports the change, the design questions follow in order: which usage metric customers find fair and you can operationalize, whether the tariff is one-part, two-part, or three-part (a platform fee plus committed units plus overage rates), how packages wrap the metric, and where the price points land. Each is tested with buyers before launch.
What decides it
Three tests every metric must pass
A pricing metric has to work for the buyer, for your economics, and for your systems at the same time. Candidates that fail any one of the three fail in production.
- Fairness to the buyer
Customers accept metrics they can predict and control. Metrics that feel like a meter running create usage anxiety and stall adoption. - Economics for you
The metric decides whether heavy users are your best accounts or your worst. Margin has to survive the top decile of usage. - Operability
A metric your systems cannot meter, quote, and bill accurately cannot ship, whatever the strategy deck says.
The rubric
The seven-factor metric evaluation
Every candidate metric is scored against the same seven questions, split between customer needs and business needs.
- Risk perception Do buyers see the metric as a sure bet or a gamble?
- Mental anchors Are customers used to buying this category a certain way?
- Value alignment Do winning customers and growing revenue move together?
- Consumption pattern How does usage actually translate into revenue?
- Cost pattern How do serving costs scale with consumption?
- Competitive action What are competitors doing on pricing, and does it constrain you?
- Implementability Can the metric be metered, quoted, and billed by your systems?
The model is designed against value, customer risk, margin and operational feasibility at the same time.
Scope & workstreams
Every engagement runs the assessment and design core; market testing is added when rates and structures should meet real buyers before launch. Every workstream ships with a goal and a concrete deliverable.
One core track, one modular one
WorkstreamGoalYou get
Metric strategy
CORE · EVERY ENGAGEMENTAssessment before design, and design before rates.
1.
Readiness assessment
Segment readiness, product usage patterns, cost implications, and operational feasibility, evaluated before design starts.
An honest answer on whether UBP fits your context
A go, no-go, or hybrid recommendation with reasons
2.
Segment & usage review
Customer behavior, usage patterns, and value perceptions across the base.
Know how each segment actually consumes
Segments mapped to consumption and value perception
3.
Metric & tariff selection
Candidates scored on the seven-factor rubric; tariff structure chosen across one-part, two-part, and three-part designs.
A metric buyers accept and systems can run
A metric decision and tariff structure
4.
Package design
Flexible usage tiers shaped in cross-functional workshops with product and marketing.
Packages that wrap the metric cleanly
Package architecture with usage tiers
5.
Price point hypotheses
Empirical analysis, competitive comparison, and strategy goals.
Rate hypotheses ready for the market
Price points per tier and segment
Market testing
MODULARAdded when rates and structures should be validated before launch.
6.
Pilots & research
Pilot pricing with select customers or survey cohorts, using Van Westendorp, MaxDiff, conjoint, and in-person methods.
Validated rates and structures before the switch
Actionable insight that refines the model on evidence
The deeper implementation layer can extend into detailed CPQ, billing, metering and pricing-systems work throughmonetization engineering.
How it works
Three steps, from assessment to a tested model
Assessment before design, and design before rates. The order protects you from operationalizing a metric the company cannot run.
OutputReadiness read
Assess
Segment readiness, usage patterns, cost implications, and operational feasibility produce a clear recommendation before any design work.
OutputMetric & rate design
Design
Seven-factor scoring picks the metric, the tariff structure is chosen, and packages and price points are built in cross-functional workshops.
OutputValidated model
Test
Pilots with select customers or survey cohorts validate the rates and structures, and the model is refined on real feedback.
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 calculate COGS (Cost of Goods Sold) for an Agentic AI product?
+
COGS for Agentic AI products include LLM API inference costs, cloud compute infrastructure, data pipeline costs, and third-party service fees - and they are significantly higher and more variable than traditional SaaS COGS.
Traditional SaaS products typically run at 80%+ gross margins because hosting costs are minimal and don't scale linearly with usage. AI-first SaaS products operate at 30-50% gross margins - closer to services companies than software companies. This fundamentally changes how you need to think about pricing.
Here's how to break down Agentic AI COGS:
LLM inference costs are usually the largest line item. An AI agent chaining multiple LLM calls per task can rack up costs quickly. LLM API prices dropped approximately 80% between 2025 and 2026 alone - and models that were state-of-the-art in 2023 have seen price declines of roughly 1,000x. Using a frontier model like GPT-4o (now at $2.50 per million input tokens, down from $5.00 a year ago) for a customer service use case is dramatically cheaper than it was even 12 months ago. But switching to DeepSeek V3 at $0.28 per million input tokens or a hosted Llama 4 Maverick at $0.15 per million can reduce costs by another 10-15x. The model selection decision is now a first-order pricing decision, not just an engineering decision.
Compute and infrastructure costs include the GPU/CPU resources for running models (especially if self-hosted), vector database costs for RAG pipelines, and the orchestration layer that manages multi-step agent workflows.
Data costs cover training data acquisition, fine-tuning runs, embedding generation, and ongoing data pipeline maintenance. These are recurring, not one-time.
Compliance and risk costs are the often-overlooked "AI tax" - legal review for IP infringement risk, bias auditing, and regulatory compliance.
The critical exercise is calculating your cost-per-outcome (or cost-per-task) distribution - not just the average. Some agent interactions are cheap (simple lookups), others are expensive (complex multi-step reasoning chains). If you price at the average cost but 20% of your interactions cost 5x that average, those heavy interactions will destroy your margin. You need to model the tail of your cost distribution and build pricing guardrails - usage tiers, complexity caps, or premium rates for complex workflows - to protect against margin degradation.
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.
How does Agentic AI pricing differ from traditional Generative AI pricing?
+
Generative AI is typically priced by token consumption or flat per-user subscriptions. Agentic AI requires pricing based on completed tasks or business outcomes because agents execute autonomous, multi-step workflows - not single prompts.
The distinction matters because the economics are fundamentally different. A Generative AI product like ChatGPT processes a prompt and returns an output in one interaction. The cost is roughly proportional to tokens consumed. But an Agentic AI product - say, Intercom's Fin resolving a multi-step support case or Cognition's Devin autonomously executing a code migration across a massive codebase - may chain together dozens of LLM calls, API lookups, and decision branches to complete a single task. The cost per task is highly variable and often unpredictable.
This creates a few new pricing challenges that don't exist in traditional GenAI:
First, per-token pricing becomes tough to grok for the buyer. A customer may not care how many tokens their AI agent consumed to resolve a support ticket - they care that the ticket was resolved. The push will be more towards some sort of task-based pricing or outcome-based pricing.
Second, the value delivered per execution varies enormously. Some agent tasks are simple and cheap to run; others are complex and expensive. Your pricing metric needs to account for this cost variability while still feeling fair to the customer. The solution is usually a consumption-based metric tied to completed actions or outcomes - per resolution, per workflow completed, per transaction processed - with bundled tiers for cost predictability.
How long does it take to launch a usage-based pricing model?
+
A typical seat-to-usage transition takes 12 to 18 months from strategy lock to production launch when no single function owns the systems engineering layer.
New Relic announced its transition in July 2020 and completed rollout in late 2021 (16-18 months). Datadog and Snowflake ran similar timelines. With dedicated Monetization Engineering ownership, the timeline compresses to 6 to 9 months for the operational stack, plus a separate migration window of 12 to 18 months as existing seat-based customers move at renewal.
The biggest single accelerator is owning the specification layer early. Most stalls happen because pricing decisions get made before the systems can absorb them, and engineering loses 6 to 12 months arguing about what each system actually needs to do.