.png)
In my last blog post I explained the origins of Metronome. Now I want to do a couple deeper dives on issues people face with billing and pricing, especially for usage-based models. Today I’m focusing on how usage-based pricing (UBP) models almost inevitably become complex and what issues they creates for internal teams.
The tl;dr
- UBP offers a huge array of pricing levers, getting the right mix is important but inherently complex
- There are many ways of understanding value in UBP, therefore you need to offer customers choice in how to pay for that value
- UBP pricing strategies can differ significantly depending on segment and GTM motion
Problem 1: Too many levers to pull
One of the primary challenges in rolling out usage-based pricing is simply the sheer number of levers you need to manage. Each product feature, tier, and customer segment brings its own set of considerations. Take a look at a pricing page like PlanetScale’s. This is a simple pricing page. But when you break it down, each pricing dimension has its own variables—compute units, storage tiers, and transfer limits. The combinatorics for pricing in UBP can easily reach into the thousands or even millions of combinations.
Each of these combinations has varying margin, latency requirements, and up-time guarantees. This means each brings different value to the table and requires different pricing. How do you track that level of complexity? How do you roll that out to customers in a clearly and concise way? How do you make sure that any combination of these variables is priced in a way that serves your customers and your margins?
Problem 2: Customers need payment model options
Another key challenge in usage-based pricing is that customers expect flexibility in how they can pay. Different customers often have vastly different use cases for the same product. Let’s look at AWS as an example. The use cases range widely, and so do expectations for the product and the pricing. Consider someone building an app on the side. They probably just wants to swipe a credit card and pay as they go. They don’t want to interact with anyone to sign up, and they are not concerned about up time. Conversely, someone using AWS for a production workload has very different needs. A customer with this use case needs consistent up time and likely has a CFO who needs predictable AWS spend. They will probably go with a prepaid model with overages. They might have specific roll-over rules for unused resources, access to volume discounts, or long-term commitment schedules. Finally, consider a customer using AWS for an internal tool. They likely just need to keep to a budget with rate limiting and no overages.
Why is this important? Because even though your product might be the same—say, a cloud database—the workload and value perception differ greatly. For one customer, your database might be the backbone of their state security system, whereas another might use it to store cat photos. The underlying tech is the same, but the risk, value, and performance guarantees are completely different. AWS supports all these pricing models because they understand that their customers need customized pricing that reflects their specific use case.
Problem 3: Different go-to-market motions need different pricing models
As your business evolves, so do your pricing needs. In the early stages, your company might rely on a product-led growth (PLG) model, where customers self-serve through a credit card checkout flow. As your business matures, you may add a sales-led growth (SLG) motion with sales teams driving enterprise deals. Eventually, you might expand into reseller and partner channels, which bring their own pricing and packaging needs.
Each of these go-to-market motions demands a different approach to pricing and payment. For PLG, credit card payments are standard. Customers expect to pay for whatever they’ve used at the end of the month. They may have prepaid commitments for specific products if they're power-users. For SLG you still have credit card payments, but you have customers who prefer invoices, and you probably have to figure out how you want to sell through marketplaces, which have their own set of pricing rules. Customers probably want to pay up front with a prepaid commitment. You want to get ahead of them paying for overages by upselling your product first. You may also give them credits to promote value discovery outside of their core use cases. With resellers, you’re now managing reseller invoices, revenue splits, and more complex deals. You also need to simplify your offering because you have limited control over how it’s presented to the customer. Stacking this on top of the complexities from Problem 1 and Problem 2, and you’re dealing with infinite combinatorics.
Conclusion: The path forward
The challenges outlined here aren’t insurmountable, but they require a strong foundational infrastructure and a deep understanding of your customers' needs. Usage-based pricing is powerful because it aligns customer value with costs, but it’s also rife with complexity. Without the right tools and strategy, businesses often find themselves bogged down by the details, missing out on the full potential of this pricing model.
By recognizing the number of levers, understanding the demand for packaging flexibility, and being prepared for different go-to-market strategies, you can set yourself up for success. Embrace the complexity, but ensure you have the right systems and processes in place to manage it effectively.
