The art and science of SaaS pricing: True usage-based pricing

In part 2 of this series, we explored scalable unit-based pricing and highlighted a few of the common pitfalls and lessons the industry has learned. In this final article, we will delve deeper into the ultimate alignment with customer value: true usage-based pricing.

Irrespective of how advanced you get with the choice of your unit, the pricing fundamentally still boils down to a flat (within the unit limits) subscription fee — unless you go all the way to true usage-based “transaction pricing.” With transaction pricing, you simply defines a rate per unit and then assess and invoice monthly in arrears based on actual usage. In B2B SaaS, usage-based pricing is more the exception than the rule and is usually employed in combination with a subscription, such that the usage-based revenue typically makes up only 25-50% of total recurring software revenue.

Usage-based pricing can be incredibly powerful, particularly in cases where the SaaS solution handles the flow of money, and the transaction fees can be imbedded — or sometimes buried — in the flow of money. Examples are obviously B2B payments for goods and services, either on the buy side (e.g. expense management, purchase-to-pay, supply chain finance, freight audit and payment) or the sell side (e.g. ecommerce platforms and other solutions that touch revenue and AR).

In such cases the SaaS usage fees can be extracted from (revenue) or tagged onto (expenses) the business’ flow of money and are thus often seen as “cost of doing business,” as part of COGS. And that can be incredibly lucrative for the SaaS vendor and usually allows a far higher share of value than a simple subscription ever would.

Subscriptions are seen as OpEx spend, an IT budget line item that receives initial and often annual scrutiny, particularly as the solution’s value proposition over time comes to be seen as status quo. I have personally witnessed cases where large enterprise customers balked at a six-figure annual subscription but happily allowed a very healthy seven-figure usage fee to be embedded in the payments flow. As OpEx it was a show-stopper. In COGS it was a rounding error.

But before you get overly excited, there is a soft underbelly of usage-based pricing. In fact, I would recommend that the majority of B2B SaaS companies steer well clear of usage-based pricing unless they do handle the flow of money and can “tag-on” their fees. As a standalone fee, invoiced monthly in arrears and collected directly from the SaaS customer, it is problematic and, in most cases, not worth the headache. Here is why:

  • It is difficult to predict for both the customer (budget) and the SaaS vendor (revenue) and triggers a lot of pushback from IT buyers to “please flatten it into a subscription.”
  • It causes cash flow delays as you can only invoice monthly in arrears. You can experiment with asking for some pre-pays to smooth cashflow, but in most cases that’s a non-starter.
  • It typically causes a revenue delay as usage does scale up slowly with rollout and adoption, delaying revenue considerably compared to a subscription.
  • Often that rollout becomes a whole second, multi-year sales cycle. First your sales team sells the customer on buying and deploying. Then your customer success team sells the users and trading partners (think of a P2P solution) on actually using it. Only then and gradually do you realize revenue and cash.
  • In many cases this model represents the worst of both worlds: Customers like the usage-based model while their use is still small and ramping up, making you wait for revenue while they have little skin in the game. But once the solution catches on and volume really grows, they will push you very hard toward an all-in “enterprise deal” that’s big but a flat subscription, depriving you of the upside.
  • You will need a much more robust billing infrastructure to produce but also defend your invoices. I remember all too well the frequent requests from F&A, triggered by customer disputes, asking the R&D team to take their eyes off the innovation ball to produce more detailed “billing reports” to defend usage-based invoices.
  • Seasonality and economic cycles drive variability and can precipitously shrink revenue month over month and, if you focus on certain verticals, induce a nasty seasonality in your own revenue (e.g. retail).
  • And last, but by no means least: Incentive structures can be a real struggle around usage-based pricing. Do you want to pay sales commissions on signature or go-live on the expected volume but before any revenue? Or wait until volume transpires after rollout, possibly months and even years later? How long are your account executives willing to wait? What if they leave — or you are looking to terminate one? What if you find they spend all their time shepherding the rollout (and their commission) of that large deal they sold last year rather than selling the next? I have seen a lot of different models around this, trying to strike the best balance and being fair to all parties. None of them was perfect, and all of them were complex and risky.

As you can see, there are significant obstacles to usage-based pricing models for B2B SaaS companies. When it fits, it is powerful. But don’t force it where it doesn’t belong.

In summary, the right pricing strategy for B2B SaaS companies is incredibly important — and too often overlooked or poorly designed. Thoroughly understand your various customer segments and how they ascribe value to your offering. Find a scaling unit most closely aligned to that value and use it to establish a tiered subscription model that still is easy enough to administer. And with a reasonable amount of effort and attention to it, you should enjoy significant positive impact on annual contract value, growth, and retention.

Andy Stinnes is Venture Partner at Cloud Apps Capital Partners.

VentureBeat

  • up-to-date information on the subjects of interest to you,
  • our newsletters
  • gated thought-leader content and discounted access to our prized events, such as Transform
  • networking features, and more.

Source: Read Full Article