The not-so-simple transition to Usage-Based Pricing (UBP) for enterprises

Usage-based pricing (UBP) charges customers solely for the services they use. If anything, it might very well be a stark departure from the rigid subscriptions and seat counts. However, there is no singular approach to it.
On this page

Andreessen Horowitz puts it aptly in a blog.

“Just because usage-based pricing has worked for other companies, it doesn’t necessarily mean it’ll work for yours. Our rule of thumb — Usage-based pricing generally works best for SaaS products whose end-user is other software, while subscription-based models tend to work best for SaaS products with human end users.”

Usage-based pricing (UBP) is elegant in its simplicity. 

It charges customers solely for the services they use. If anything, it might very well be a stark departure from the rigid subscriptions and seat counts. However, there is no singular approach to it. 

Companies are neither going the usage way fully, nor ditching it entirely either. The sweet spot turns out to be hybrid — traditional subscriptions, with an additional component of usage-based pricing.

The roots for Usage-based Pricing (UBP) were, more or less, pioneered by the likes of Microsoft Azure and Amazon Web Services (AWS). But today, it’s everywhere.

As a concept, it has gained popularity, and interest over the past decade but it is rapidly picking up momentum only in the last 3 to 5 years.

UBP, not so universal

It has all the more popularity because of the exponential value it offers to both the buyers and sellers, and it is a curious subject to address because usage-based pricing (UBP) is never one-size fits all. 

Here are some examples how —

  • SendGrid, for example, has a monthly subscription fee for the customers, with a maximum cap on the number of emails that can be sent in a month. If a customer exceeded this number, there would be an overage fee which is billed in the next month’s invoice. This way, no customer would be blocked from using the software after a point. But if anything, as the companies grew, they would only start sending more emails on a recurring basis, which also meant — their usage would grow.

  • Hubspot is another example, but with a very different pricing model. It has a subscription fee for its marketing product but also a different fee altogether for the number of contacts being used. The contacts here are the real value-addition to these customers, which would also grow based on more consumption and more usage. The lever for Hubspot is to be able to charge its customers, also on the real value they are able to create for customers.

  • Algolia and Twilio follow a different pattern — a pay-as-you-go pricing model, but also self-serve for their customers. For every search request and every SMS message you send, there is a charge. As they would go up-market, and usage increases for large-scale customers, annual contracts would now kick in, with a fixed allotment at a specific rate. Suddenly, revenues become all the more predictable here.

Transition to usage-based pricing

AppSmith, for example, was convinced that the traditional subscription-based pricing models in SaaS were not serving the best interest of the customers. Usage-based pricing, on the other hand, stood as an approach that is far more ethical and just.

AppSmith helps developers build internal applications like support tools, dashboards, and asset management systems. Last year, the company announced the introduction of usage-based pricing for all of its customers.

The Business plan was now accessible at $0.40 for each user per hour, starting with a monthly quota of 100 hours. Beyond this allowance, there was no need to fret over unexpected costs — but costs are capped at $20 per user per month once the initial allowance is exceeded.

While this blog outlines the announcement in full, there are a few lessons to be learned on how the company did it so very gracefully. For one, AppSmith maintained transparency, and the team communicated exactly why it made all the more sense for them to switch to usage-based pricing.

“We wanted our pricing model to guarantee the ongoing viability of our freely available, open-source Appsmith platform by sharing in the value gained by our Business users without adding financial hurdles to adoption. To realize this, we undertook a thorough consultation with both our OSS and Business users to find out what would work best. We then clearly communicated to our community what we were implementing and how, as well as how it would lead to long-term benefits for the project.”

The blog goes on to talk about the benefits of this transition, how the company was tracking usage, and how the entire transition allowed for newer use-cases to occur.

Pricing is tricky. It is all the more nuanced and layered by its own right, that it compels any company to tread it very carefully. Here are some best practices to keep in mind, whether you add a component of usage-based pricing (UBP) or fully switch to it:

  • Transparency and trust — Reinforce your commitment to transparency and fairness, emphasizing that the move to usage-based pricing is in the best interest of both the customer and the company over the long term.

  • Feedback mechanisms — Solicit feedback. Actively seek out customer feedback throughout the transition process to identify concerns, confusion, or areas where additional support is needed. Be prepared to make adjustments to your usage-based pricing model or allow for a transition plan, based on customer feedback to better meet their needs.

  • Customer segmentation — Evaluate and identify different customer segments based on their usage patterns, preferences, and the potential impact of usage-based pricing (UBP) on their costs. Once this is in place, develop tailored communication campaigns and transition plans for each segment, while recognizing that one size does not fit all.

  • Grandfathering options — Customer success plays a major role here while you temporarily grandfather existing customers into their current pricing plan for a defined period. The idea is to be able to offer them a sense of security, and safety and also time to adjust to the new changes. For those customers who are willing to switch to usage-based pricing (UBP) earlier, it is better to offer incentives like discounts, additional features, or higher usage limits at no extra cost.

  • Financial cushions — Some temporary price caps can be implemented for existing customers to ease into the new pricing model without facing a sudden spike in costs. To support the same, you might want to provide tools that help your customers monitor and control their usage. It goes a long way when you make proactive efforts to ensure that they do not suddenly experience shocks in their bills.

  • Assurance — Offer satisfaction guarantees or an option to revert to their previous plan within a certain period if the usage-based pricing model doesn’t suit their needs. Allow your existing customers to try out UBP, in tandem with their current plan, to see which works better for them without any financial commitment.

  • Educational Support — Conduct educational workshops, tutorials, and webinars to guide customers through the usage-based pricing model, showcasing how to manage and optimize their usage. Offer personalized consultations to help customers understand the impact of the transition on their specific situation and how to get the most value out of UBP.

Usage-based pricing has become increasingly popular among many companies, allowing them to align costs directly with usage levels. Zenskar simplifies usage-based pricing by offering a flexible billing architecture that effortlessly supports various pricing models and manages usage data without requiring complex engineering efforts.

Revolutionize your pricing strategy and drive growth with Zenskar's innovative billing solution.

To explore how Zenskar can help streamline your billing processes and implement a scalable system, book a demo with us today.

Never miss new content
Subscribe to keep up with the latest strategic finance content.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Explore related blogs