After seeing a few articles on SaaS usage-based pricing, I felt that every solution, even the B2B solutions I had been working with during the last decade, should be priced on a “per drink” basis. It didn’t matter if your drink of choice is red, blue, green, or white: you should be willing to be paid upon consumption. However, after spending more time thinking about reasons why usage-based is best, I felt I needed to present a more balanced - and feasible - approach.
The bar at the Cala di Volpe resort, Sardinia, Italy: pick what you want and pay by the drink.
Haven't we seen this before?
I’ll start by making the case for migrating from per-user-per-month (pupm) SaaS pricing to usage-based pricing. All transitions meet resistance, and I’ve seen something similar before. In pre-SaaS times, enterprises were buying a software package (do you still have the actual boxes around?) that had a defined set of functionality, say, whatever came with release 13.3.5. After months or years of customization and configuration, business users at companies were finally able to use the solution. The software provider was cashing in an 18% maintenance fee, until one day the industry overall decided to ask for 21+%. All the while, the world around the customer had been changing, priorities had shifted, some business users and stakeholders had moved on while others joined. What had seemed the best solution had become sub-optimal or even obsolete: naturally, the company would start investing more months to investigate, negotiate, and upgrade to the next software product version, or to implement a different solution altogether.
The software package model entailed success stories, but most projects ended up between partial success and partial failures, with the software product coming short of expectations. The delta between what was expected when purchased and what was delivered in production was relevant. Most failures were not widely exposed, neither by the software provider, nor by the customer. The customer team that had selected the solution in the first place was usually committed to make it work, having sunk monetary and emotional cost in the project success. On the other hand, the software vendor was busy working on their major (yearly) and minor releases, cranking on an inflow of feature requests, with a big time lag between a release GA and its customer adoption.
Such customer projects were complex and fraught with issues. Consultants like me were constantly defining approaches and methodologies (and yes, best practices, too), leveraging the learnings from past projects to make new projects go as smooth as possible. At some point everyone recognized that an approach to “plain vanilla” implementations was superior to one where enterprises were trying to fit their current processes as the blueprint for customizing the software. The message was: “stop trying to do what you do today, use the system the way it’s intended to be used!”.
I‘ve been digressing a bit, however this is one more example of history repeating itself, where patterns seen in the past manifest again. Fast forward to today: true SaaS is supposed to be instantly activated and available for use. However, when it comes to B2B solutions, setting them up usually requires configuration, from configuring the master data hierarchy to import data, to workflows, to core solution functionality. While good solutions offer powerful self-service capabilities, many times customers require or at least benefit from the support of the vendor’s Customer Success team.
Evolving SaaS solutions: history repeats itself
Even SaaS configurability has its limits: at any point in time, the SaaS solution only has a determined set of functionality, and determining what features to add next remains, even in today’s Agile world, an exercise fraught with sub-optimal, short-term decisions. Short-term thinking is a reason why vendors don’t grow beyond a certain size: some find product-market fit, but then stop actively searching for new ways of adding value by evolving and expanding their offerings. They therefore fail to enhance the solution so that customers can evolve the process the solution was enabling in the first place.
The key to evolving a solution to better fit both existing and new customer segments is to look beyond the natural incremental improvements that the first customers originate. It’s easy to pick the top ranked incremental improvements, plus add new “must have” requests that prospects require. True innovation, strategic changes that open new customer segments, support new processes, or radically improve the current solution are hard. There will always be new escalations that seem more urgent than any effort requiring prolonged investment and harder, deeper thinking.
Also, some customer prospects require commitment from vendors that a new set of functionality be added in short order before they sign the contract. While some requests cover industry-wide requirements, experience also shows that these same customers many times don’t even leverage this functionality that was deemed “must have”, because after using the solution their processes change, and their priorities too. Why instead not adopting the solution as “plain vanilla” as possible? This is no different than what was happening in the packaged software world when customers requested customs or configs to fit their current processes.
Evolving SaaS solutions pricing
How do we get to a better place in today’s SaaS times? What if we transition to a model where vendors charge by usage, or “by the drink”? Let me wear my Product Manager hat for a minute and make the case for it. Among the many advantages of usage-based pricing, the most fundamental one is that it creates a deeper symbiosis between vendor and customers. Things work well for everybody when the customer finds value in the vendor solution. This value is reflected in the number of business users, the volume of business flowing through, and the solution stickiness. Usage combines such dimensions and becomes the universal measure: when customers users flock and repeatedly leverage the solution to generate value, they invite/involve their colleagues and partners, they become advocates, and the flywheel spins faster.
After all, both vendors and customers have a common objective: quickly determine what changes lead to the best results. While each could also follow a waterfall approach, with a customer spending a month or two to define a business yearly plan and then sticking to it, and the vendor defining requirements for a couple of months and then executing a yearly release, competition would likely kill them both.
Instead, they both need to measure and iterate, and therefore need a vendor solution that provides near real-time feedback to validate whether both the customer business process change and the vendor product improvement supporting it work. Quick iteration with A/B testing enables faster progress since assumptions can be quickly validated, and changes adopted or discarded. As a result, customers evolve business processes faster, while vendors converge toward the best solution to support these processes.
Generalizing more, usage-based can get you closer to your customers. You want to keep on working and improving what really makes your solution valuable to them. If you are content with growing the number of users on your platform and care less about whether those users are actively using it, then you may not realize you have a problem until they churn. Since we’re talking about B2B solutions, users are not aimlessly clicking on the next video clip, they are using your solution to get their job done. And getting their job done faster and better is more important than being counted as users so that vendors can charge a per user per month fee. Ultimately, usage-based can also make vendor’s life easier, since it has an ingrained upselling mechanism.
The Product Management case for usage-based pricing
As a product manager (remember my hat!) this is nirvana: product decisions are based on what generates the most value for all customers and for my solution. I need to increase usage, expand the number of customers, of people at customers using the solution, and how much they use it. Sure, I need to avoid adding clicks to just increase usage, since in B2B (contrary to social media, pardon the lame joke) users despise every extra click, but in general increasing usage is good.
The above argumentations to support pure usage-based pricing seemed to make sense, and I was ready to define a matrix of customer KPIs mapped to vendor KPIs. But then I took my product management hat off, and had to admit that pushing usage pricing as “the” way to charge customers is simplistic and there are some fundamental considerations to keep in mind.
The case against usage-based pricing
There are some objections I’ve heard from vendors, which in one way or another could make most B2B vendors “special” and immune from adopting usage-based pricing. Let’s go through them to either dismantle or accept them.
One is vendor Sales efficiency. Most Sales teams operate with incentives linked to a big one-time revenue event, such as signing a one or three year contract. Moving to usage-based pricing is usually seen as transitioning Sales teams from hunters to farmers. This is by no means a new argument, in fact it’s the same we’ve heard when we transitioned from packaged software to SaaS, yet isn’t this transition easier than that one?
Profitability is also to be taken into account when transitioning to usage-based. Some B2B solutions take time and effort to set up. Vendors will invest considerable effort, not only in Sales but also in Customer Success, to make customers productive on their solution. Customer churn can then become even more disastrous if such investments are not recouped over the life of a contract. However, this risk is minimized if the vendor is focused on increasing usage by increasing the number of users and their adoption of the solution. If users love the solution and they use it they will stick around, no need for a 3-year contract with a fixed number of seats.
Keys to success: linking vendor KPIs with customer KPIs
To avoid measuring the wrong KPI so that usage-based pricing works we need to align the vendor KPIs with the customer KPIs. Ideally you may think they are exactly the same, yet in reality they are not. Vendors need to measure KPI that are linked to how much revenue their solution generates, while customers measure how many contracts they can revise in a day, and how much money they get from a rebate with the new solution compared to last year. I’d be very happy if customers would be willing to set up revenue-sharing agreements, where I just get a percent of the incremental revenue, but I have yet to find a customer signing a contract that includes that KPI.
We can link the vendor usage KPIs to the customer KPIs, and in theory everything would work fine. A new vendor-customer contract can be set up with aligned KPIs, and the product and customer processes would then improve in lockstep.
At the most basic level, “usage” needs to be reframed to avoid focusing on vanity measures that makes the vendor feel good but don’t relate to success. We need to start from the OMTM (Only Metric That Matters) for your business. The universal one, and least for a for-profit company, is revenue growth, but what KPI that you can track today will translate in revenue? If you are a B2B SaaS company, it could be:
Net Adds, new subscribers minus churned
Revenue per Customer
Customer Acquisition Cost (CAC)
Churn
If we find a way to link Revenue per Customer to usage, then everything works. The issue is that revenue must be linked to the value generated for the customer, otherwise the vendor is leaving money on the table and becomes unable to evolve the solution as fast as the customer requires. There are B2B solutions that have a limited number of users, yet that generate a lot of value for the customer. Also, there are solutions that business users use every day, such as CRM, and others that are used less frequently, maybe a lot at the end of the quarter, yet more sporadically in between.
We can then think about ways of pricing usage so that it reflects value, but we are fundamentally trying to find a formula that includes usage as a parameter to calculate customer value.
A practical - yet solid - approach to SaaS pricing
Isn’t it then better to just determine value-based pricing? I think so, and while it’s not easy, I’ll provide some examples of how we can approximate value pricing for B2B solutions.
Pricing should combine the best of both worlds: a base and a “usage-based” variable portion. The base should be proportional to the value for the company. The most common way to do that us to link it to customer’s revenue: the bigger the company, the more the solution should impact in terms of efficiency and value. A slightly better way, when possible, is to just consider the monetary value of the transactions the solution is enabling, such as invoices, rebates, contracts, quotes, or POS (Point of Sale) data. I’m saying “slightly” because these measures are directly or indirectly related to company revenue, and while the formula that links them to revenue will change based on industry and company type, the final result is not that drastically different. For vendors, revenue is a more stable determinant of what to charge than not transactions, which will be low at the beginning to then grow over time. Therefore, the base could just be determined based on customer revenue tiers.
Variability and growth can better be accommodated by a “usage based”, or “transaction-based” portion of the SaaS subscription. As the value of rebates, contracts, or the amount of data/traffic moving through the solution grows, so does the SaaS subscription rate. This may not necessarily be linked to a single variable. Consider a solution that allows you cleansing and enriching partner data such as POS data. Here, complexity, support cost, and value in that case are driven by both the number of partners and the volume of data. Therefore, the vendor should charge by using a matrix with these two dimensions, with on one axis number of partners tiers, and on the other the other total transactions tiers, or using a formula that combines both. As a vendor you want this calculation to be automated, hence you want your CRM, CPQ, and/or other solution you use to price and bill to support what you choose. In my experience, trying to fit matrixes in CRM/CPQ solutions is hard!
Should you evolve your SaaS pricing?
Sticking to per-user per-month (pupm) fixed contract pricing for SaaS may seem easier, and pure usage-based pricing may not work well for many B2B SaaS solutions. However, vendors should strive to set up pricing aligned with both their KPI and with their customers’ KPIs. Doing so will boost the right behavior across the company and translate into better solutions, more innovation, and more satisfied, active, and strategically aligned customers.