It might be easy to default to pure consumption-based pricing. Total volume-based, nothing else. Use more, pay more. The appeal is obvious: it aligns cost to value, it lowers adoption barriers, and it scales naturally with the customer. According to Maxio's 2025 pricing trends report, 67% of SaaS companies now use some form of usage or consumption-based pricing, up from 52% in 2022. Metronome's State of UBP report found that 77% of the largest software companies have incorporated it in some way.
But "price on volume" is a starting position, not a complete strategy. The harder question is how your product, and the products on your roadmap, will create value relative to that volume. Not every feature you build will affect consumption the same way. Some will increase it. Some won't touch it. And some will actively reduce it.
How you handle each of those scenarios determines whether your pricing model stays coherent as your product evolves, or starts working against you.
When New Features Increase Consumption
Some features are built to drive more volume through the system. Integrations that connect to third-party platforms, workflow automations that trigger more events, distribution tools that expand reach. These features make the consumption meter spin faster.
When that's the case, the pricing logic is straightforward: package those features into your consumption-based model at no additional cost. The value is already captured in the increased volume.
Databricks is a good example here. They price on DBU (Databricks Unit) consumption, billed per second of compute usage. Their Partner Connect hub and Lakeflow Connect make it easy to ingest data from hundreds of sources, including Salesforce, PostgreSQL, SAP, and many others, and none of those integrations carry separate fees. But every new data source connected means more data flowing into the lakehouse, more ETL jobs running, more queries executing. More data to process means more DBUs consumed, and a higher bill. The integrations are volume accelerators, not separately monetized features.
The logic is clean. If the feature makes the meter run, let the meter do the monetization work.
When New Features Don't Affect Consumption
Not every feature drives more volume. SSO. Enterprise audit trails. HIPAA compliance. Role-based access controls. Custom data retention policies. These features deliver real value, but their value is decoupled from how much a customer uses the core product. A customer sending 100,000 API calls a month and a customer sending 10 million might both need HIPAA compliance equally, or not at all.
When features serve specific customer segments or use cases rather than driving consumption, bundling them into volume-based pricing leaves money on the table or, worse, forces every customer to subsidize capabilities they don't use.
Snowflake is a textbook case of getting this right. Their core pricing is consumption-based: you pay for compute credits, storage, and data transfer. But enterprise features like multi-cluster warehouses, 90-day time travel, column-level security, HIPAA compliance, customer-managed encryption keys, and private connectivity are not included at the base consumption rate. These capabilities are packaged into edition tiers (Standard, Enterprise, Business Critical, Virtual Private Snowflake), each carrying a progressively higher per-credit rate. A Standard credit on AWS runs around $2; Enterprise is approximately $3; Business Critical is around $4. The consumption mechanic stays the same across all tiers. What changes is the per-unit rate, reflecting the additional platform capabilities that specific customer segments require.
This is packaging discipline. The consumption model handles the "how much" question. The tier structure handles the "what do you need" question. They work together without either one distorting the other.
There are other packaging options for non-volume features too. Add-ons work when the feature serves a narrow enough segment that even tier-based inclusion would over-bundle it. Use-case-based packages work when clusters of features naturally align with distinct buyer profiles. The key is recognizing when the value of a feature is independent of volume and pricing it accordingly.
When New Features Reduce Consumption
This is the scenario that forces the hardest pricing conversations. You build a feature that makes your customers more efficient, and that efficiency shows up as lower consumption of the thing you charge for. AI is accelerating this dynamic across the industry.
Customer support is the most visible case right now. For years, platforms like Zendesk and Intercom priced on human agent seats. Then AI-powered automation started resolving customer inquiries without human involvement. Better automation means fewer tickets reaching human agents, which means fewer seats needed. The product is delivering more value while the pricing metric captures less of it.
The industry response has been to introduce new pricing meters. Zendesk launched outcome-based pricing in late 2024, billing per automated resolution at $1.50 (committed volume) or $2.00 (pay-as-you-go) on top of existing seat costs. Intercom introduced per-resolution billing for its Fin AI agent at $0.99 per resolution. HubSpot followed at $0.50 per resolution. In each case, the company recognized that the old meter (seats) was being cannibalized by the new capability (AI automation) and introduced a complementary meter to capture the value that automation creates.
The transition isn't seamless. Zendesk still charges seat fees alongside per-resolution fees, creating a layered cost structure that some customers find frustrating. Intercom charges per seat and per resolution, meaning customers pay for both the human infrastructure and the AI that reduces dependence on it. These are real tensions. But the alternative, holding onto seat-only pricing while your product actively reduces seat demand, is a slow revenue leak with no structural fix.
The pattern generalizes beyond support. Any per-seat product that introduces automation capabilities faces the same dynamic. If the new feature reduces demand for the thing you price on, you need a new or complementary meter that captures the value the feature creates. Not as a defensive move, but as a recognition that value has shifted and pricing should reflect where it landed.
Tying It Together
Consumption-based pricing is a strong foundation. But a foundation is not a building. As your product evolves, each new feature or capability falls into one of these three buckets, and the pricing response for each is different.
Features that drive more consumption belong inside the existing model. Features that deliver value independent of consumption need their own packaging. And features that reduce consumption signal that your pricing metric itself may need to evolve.
The companies doing consumption pricing well aren't the ones with the simplest models. They're the ones paying attention to how their product roadmap interacts with their pricing architecture, and adjusting deliberately rather than discovering the misalignment after it hits revenue.