.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.
The Founders Ultimate Guide to Usage Based Pricing Metrics How Do You Choose What to Measure
Usage-based pricing looks simple from a distance. Pick a unit, count it, multiply by a rate, and let revenue rise with adoption. In practice, the unit becomes one of the most consequential product decisions a founder makes. It affects what sales can promise, what finance can forecast, how customers budget, and whether expansion feels like earned value or an unpleasant surprise.
The stakes have increased. Traditional SaaS products can often bill for users because a person remains the center of the work. Data platforms, communications products, and AI agents have changed the equation. A customer may gain value from a gigabyte processed, a marketing contact reached, an action completed, or a support case resolved. The meter must reflect that difference without making the bill impossible to understand.
Monetizely's position is clear: choose one primary usage metric that rises when the customer receives more of the value they came to buy, remains predictable enough for an annual budget, and can be measured and defended without argument. Usage is not the strategy. The metric is.
The meter earns trust when it grows with the customer's own success
A useful metric connects a customer’s growing business to your growing revenue. Datadog does not charge infrastructure customers by the number of people logging into the product. It charges for monitored infrastructure, containers, data ingested, and other units that rise as an engineering environment becomes larger and more complex. Snowflake charges for compute, storage, and data transfer because those units reflect actual use of a cloud data platform.
The contrast matters. A seat is a sound meter when every additional user receives meaningful value and adds meaningful work. A token is a poor customer-facing meter when buyers want “faster contract review,” not a lesson in model inference. Founders should resist the temptation to charge for the easiest technical event to record.
The public pricing pages of mature software companies show the pattern. Each company chooses a unit buyers can recognize in the work they already manage.
Exhibit 1. Established B2B software companies charge for the business object closest to the work
| Company | Public pricing structure, checked September 7, 2026 | What the meter follows | Founder lesson |
|---|---|---|---|
| Datadog | Infrastructure Pro is listed at $15 per infrastructure host per month on annual billing; other products use units such as ingested GB, indexed spans, events, and LLM spans. (datadoghq.com) | The systems and data an engineering team chooses to observe | One product can use several meters when each module creates a distinct type of value. |
| Snowflake | Customers pay for compute credits, storage, and data transfer; Cortex Agents are billed in AI Credits per million tokens processed. (docs.snowflake.com) | The cloud resources and AI processing consumed | Resource usage works when customers already expect to manage a usage budget. |
| HubSpot | Marketing Hub combines platform access, seats, and tiers of marketing contacts. The official catalog lists Starter from $20 per seat per month and additional contact charges above included tiers. (legal.hubspot.com) | The reachable audience that marketers can actively engage | Charge for the customer object that expands campaign reach, not every record stored in a database. |
| Salesforce Agentforce | Public pricing includes $500 per 100,000 Flex Credits, $2 per conversation, and a $5 per user per month Agentforce User License. (salesforce.com) | Actions, conversations, or employee access, depending on the deployment | An AI product may need a different meter for employee assistance than for customer-facing automation. |
The common thread is not “usage pricing.” It is the decision to make the bill move with a recognizable form of customer progress.
Founders often start with a question such as, “Should we charge per token, per task, or per seat?” That sequence is backward. Before choosing a meter, a company must decide what it wants pricing to accomplish and whom it intends to serve.
Monetizely’s 5-Step Pricing Framework puts that order into practice. As described in Monetizing Agentic AI, the framework begins with goals and segmentation, then moves to packaging, pricing metric, price points, and operationalization. The sequence matters because a metric cannot rescue a package built for the wrong buyer, and a rate cannot rescue a meter that customers reject.
The five steps answer five different questions:
- Goals and segmentation: What must pricing achieve now, and which buyers have meaningfully different needs?
- Packaging: Which features, services, and commercial terms belong together for each segment?
- Pricing metric: What single unit best tracks the value delivered by each package?
- Price points: What rate captures fair value while supporting the company’s growth and margin goals?
- Operationalization: Can product telemetry, contracts, billing, finance, sales, and customer success run the model consistently?
A founder building an AI support product provides a simple example. The company may want fast adoption in mid-market ecommerce, not maximum margin from Fortune 100 accounts. Its package may include integrations, workflow controls, and human escalation. Only then should the team decide whether to charge per conversation, per action, or per resolved case.
The following questions turn the framework into a practical screen before the company debates price.
Exhibit 2. A candidate metric should clear five tests before it reaches a price discussion
| Test | Question founders should ask | Strong signal | Warning sign |
|---|---|---|---|
| Value link | Does more usage mean the customer gets more of what they bought? | More resolved cases reduce support workload. | More tokens rise because prompts became inefficient. |
| Buyer forecast | Can a budget owner estimate next quarter’s spend using data they already have? | The customer knows its monthly active contacts or cloud hosts. | The customer cannot predict model calls or tool retries. |
| Customer control | Can the buyer influence the unit through normal operating decisions? | A team can decide which marketing contacts to engage. | A vendor’s internal architecture changes the bill. |
| Economic protection | Does the unit rise with the cost of serving unusually heavy use? | Larger data volumes create more compute and storage cost. | A fixed seat absorbs unlimited inference cost. |
| Auditability | Can both parties see the same count and resolve disputes quickly? | A completed transaction has a timestamp and record ID. | “Business value created” requires subjective judgment. |
A metric that fails two of these tests should not move to price research. The team should either choose another unit or change the product and package so the intended unit becomes credible.
Many companies confuse flexibility with clarity. They add seats, credits, tasks, requests, storage limits, feature gates, and surprise overages to the same offer. Buyers then struggle to answer a basic procurement question: what will we actually pay over three years?
A product can have more than one charge, but it should have one primary meter. That meter tells the buyer what expansion means. A fixed platform fee can sit underneath it when the customer receives ongoing value from access, security, integrations, or governance. A cost-based allowance can limit exposure during an early AI rollout. Neither should hide the primary logic of the deal.
HubSpot offers a useful example. Its Marketing Hub pricing separates access from the pool of marketing contacts a customer can actively target. The company does not bill for every CRM record in the same way because not every stored record produces marketing value.
A clean architecture usually falls into one of four patterns.
Exhibit 3. The product’s role in the customer workflow should determine the primary meter
| Product role | Best primary meter | Supporting charge, if needed | Example |
|---|---|---|---|
| Daily workbench for a named professional | Active or named user | Usage allowance for unusually expensive AI features | An AI coding assistant used by developers |
| Platform that processes customer-owned volume | Data, messages, events, or transactions | Minimum commitment | Snowflake compute and storage; Datadog telemetry |
| System that expands a managed business object | Active customer, contact, property, or account | Seats for administrators | HubSpot marketing contacts |
| Agent that completes a defined business result | Verified output or outcome | Platform fee for integrations and controls | Resolved support cases or qualified meetings |
The table points to a disciplined rule: use seats for access to human work, usage for customer-controlled volume, and outcomes only when the product can prove that outcome without dispute.
Engineering teams naturally see technical events. They can measure API calls, tokens, workflow runs, model requests, and GPU seconds with precision. Buyers rarely organize budgets around those units.
A customer does not buy an AI sales agent to consume 40 million tokens. The customer buys more qualified pipeline. A legal team does not want 200,000 document chunks processed. It wants contracts reviewed with lower outside-counsel spend and faster turnaround.
The gap between cost and value explains why raw technical meters often belong in the background. They are essential for margin control, especially where inference costs can spike. Yet a meter that only tracks vendor cost turns every model change into a potential customer dispute. If a new model uses twice as many tokens to produce the same answer, the vendor’s architecture has changed while the buyer’s value has not.
Founders should treat cost data as a guardrail in the rate card and package design, not automatically as the unit shown on the order form. Snowflake can charge in credits because its customers already understand compute consumption as a managed operating resource. The same logic will not automatically transfer to a workflow application that uses AI behind the scenes.
Three conditions justify exposing a technical metric to the buyer:
- The buyer already manages the unit as part of its operating budget, such as cloud compute, data retention, or messaging volume.
- The buyer can directly control the unit through ordinary product decisions, such as choosing retention length or processing more records.
- The unit remains stable even when the vendor changes models, routing logic, or system design.
Without all three, technical usage belongs in internal dashboards and margin models, not at the center of customer pricing.
AI agents make the choice harder because a seat can remain familiar long after it stops reflecting the work performed. Monetizely’s Agentic Monetization Spectrum, or AMS, provides a direct way to judge that shift. It scores an agent on three dimensions: zero-human ability, meaning how much work the agent completes without a person; operational domain, meaning whether it handles one task, one workflow, or work across functions; and output/cost ratio, meaning how much customer value rises relative to compute cost. As autonomy, scope, and value relative to cost increase, the strongest meter moves from user access toward output or outcome.
The AMS does not make outcome pricing fashionable by default. It identifies when it is commercially justified.
Exhibit 4. AMS scores show why different AI products need different primary meters
| Product or archetype | Zero-human ability | Operational domain | Output/cost ratio | Primary meter indicated |
|---|---|---|---|---|
| Cursor-style coding assistant | Medium | Medium | Inflecting | Per developer seat, with sensible AI-use limits |
| Devin-style autonomous coding agent | Large | Medium | Inflecting to exponential | Work unit or usage-based agent capacity |
| Enterprise legal assistant modeled on Harvey AI | Medium | Large | Exponential | Per lawyer seat remains workable because legal procurement budgets by lawyer, with usage tiers for heavy deployment |
| Sierra-style customer-service agent | Large | Large | Exponential | Verified resolution or another defined business outcome |
Cursor’s public packaging has historically separated individual, team, and enterprise needs through administration, security, and support rather than by sharply rationing core coding capability. That supports a per-seat anchor because a developer remains central to quality control and adoption.
Sierra-style support automation sits at the other end of the spectrum. When an agent resolves a customer issue without human intervention, the buyer can count the result, compare it with ticket cost, and see whether quality holds. A resolution meter becomes credible only if the contract defines resolution, attribution, exclusions, fraud controls, and the treatment of reopened cases.
Salesforce’s Agentforce pricing reflects this range. The company offers user licensing, per-action Flex Credits, and per-conversation pricing, rather than forcing every deployment into one model. The lesson for founders is not to copy three options. It is to recognize that internal employee assistance, workflow execution, and customer-facing service can create value through different units.
Outcome pricing works only when the buyer can see the result in the same system
Outcome pricing earns attention because it sounds aligned. Both vendor and customer benefit when the customer gets a result. Alignment alone is not enough.
The outcome must be observable, attributable, timely, and valuable. “Qualified meeting booked” may work if the CRM records the meeting, the account meets agreed criteria, and the customer cannot quietly redefine qualification after the fact. “Revenue influenced” is usually too distant and too contestable for a primary meter.
A support agent provides a cleaner case. Consider an AI agent priced at $2 per verified resolution, where the customer estimates that a resolved ticket avoids $8 of human support cost.
Exhibit 5. A resolution meter scales with customer value across different operating conditions
| Monthly scenario | Customer conversations | Resolution rate | Verified resolutions | Customer labor value at $8 per resolution | Vendor revenue at $2 per resolution |
|---|---|---|---|---|---|
| Early deployment | 20,000 | 30% | 6,000 | $48,000 | $12,000 |
| Established deployment | 20,000 | 70% | 14,000 | $112,000 | $28,000 |
| Expanded deployment | 40,000 | 70% | 28,000 | $224,000 | $56,000 |
The model preserves a visible customer surplus in all three cases and allows the vendor to earn more when the agent actually delivers more verified work.
A per-conversation meter would be easier to count, but it would charge the same for a failed exchange and a successful resolution. A flat seat price would be simpler, but it would disconnect vendor revenue from a deployment that doubles in volume and proven impact. The resolution is therefore the right primary meter for this product, while a platform fee can pay for integrations, administration, security, and ongoing availability.
A pricing metric is also an operational promise. Once a sales representative puts “per resolution” on an order form, the company needs a shared definition of resolution across product data, invoices, customer success reviews, and renewal negotiations.
That work is larger than most founders expect. Monetizely’s guidance on operationalizing agentic pricing notes that implementation requires metering, entitlement control, usage rating, credit tracking where relevant, and invoices customers can understand. The operational build can require three to five times the effort of choosing the pricing structure itself.
Before launch, founders should make sure the meter can answer these questions:
- What event starts the count, and what event completes it?
- Which system is the source of truth when product logs and customer systems disagree?
- Which events are excluded, reversed, credited, or capped?
- How quickly can the customer see usage and forecast the next invoice?
- Who owns a disputed count, and what evidence settles it?
A buyer will accept variable spend when the company gives that buyer control, visibility, and a defensible record. Without those elements, even a well-aligned meter becomes a renewal risk.
Monetizely’s position is not that every company should move to usage, nor that every AI product should charge for outcomes. Founders should choose a primary meter that expresses the product’s actual role in the customer’s work.
For a developer assistant, that may be the developer seat. For a data platform, it may be compute, data, or events. For a marketing platform, it may be engaged contacts. For an autonomous support agent with clear proof of work, it should be verified resolutions.
The discipline lies in committing to the unit before debating discount bands, token allowances, or a clever credit name. Customers can tolerate a price they consider high when the logic is clear and the value is visible. They rarely tolerate a bill they cannot explain.
Set a non-negotiable rule for new offers: every package must name one primary meter in the first page of the order form and explain, in one sentence, why that unit rises with customer value.
Build the annual operating plan around meter behavior: model revenue under low, expected, and high customer adoption, then compare those paths with support, infrastructure, and sales-capacity needs.
Make expansion a product event, not a billing surprise: place usage forecasts, alerts, and upgrade paths inside the workflow where the customer manages the relevant business object.
Treat metric changes as migrations, not pricing edits: decide in advance who will be grandfathered, which customers must opt in, and what evidence will show that the new meter is better.
Review the primary meter when the product changes role: a copilot that becomes an autonomous agent may outgrow per-seat pricing, but only after customer proof, operational data, and contract definitions are ready.
Footnotes
- Monetizing Agentic AI: https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- Datadog, official pricing list and billing documentation. (datadoghq.com)
- Snowflake, official pricing and AI pricing documentation. (docs.snowflake.com)
- HubSpot, Product and Services Catalog. (legal.hubspot.com)
- Salesforce, Agentforce Pricing. (salesforce.com)