SaaS Pricing

Standard way to price SaaS is to charge $X per user per month, but usage varies significantly and a fixed price may not truly reflect costs.

Yesterday I came across an interesting tweet. Basically Zapier is changing the way it charges its customers.

The tweeter has gone on to generalise this to say that current SaaS pricing (typically per user per month) is broken, and that people are going to move to pay per usage.

Now, as we are building something that will be sold as SaaS, this is a problem that we need to solve - on how to price. And I can think of arguments on both sides.

The slippery slope of cross-subsidy

When you keep your pricing too simple, you inherently cross-subsidise one set of users at the expense of another. I might be charging a fixed price per license per month. Now, all these users may not be using the product to the same extent - the power user might be “getting 100 insights a month” while a more ordinary user might be getting “5 insights a month”.

And in this situation, you actually price the product assuming an “average user”. Over a period of time, what will happen is that people who are being charged less will not find value in the product and churn out, and now your average cost per user goes up, which means you need to jack up the price, leading to another wave of exit. And so on.

Keeping things simple

On the other hand, there is the issue of “metering” and complications. There is a famous story about why all within-country postage costs the same - the cost of determining how much to charge used to be significantly more than the actual cost of transporting the mail.

And so in postage (but not in courier), as a matter of practice, you cross-subsidise long-distance letters with intra-city letters. The latter costs far less to serve but you are charging the same for all mails.

One reason why the per-user per-month everything-is-bundled-in pricing appeals for SaaS is the absolute simplicity of the pricing. The user knows exactly what the bill is going to be. There is no mental cost associated with usage - with pay per use, you are sometimes overoptimising on whether to use something at all, since there is an incremental cost involved.

Even with tiered pricing (which is one simple form of price discrimination), there is the additional mental cost to the user who might expend mental bandwidth to keep tool usage within a certain limit, rather than spending it on actually using the tool and running the business. And that is suboptimal.

What we might do

It’s way too early days for us. We are yet to write a single line of code, and so haven’t yet started thinking about price structures and stuff. And we can clearly see different kinds of users for what we are planning to build - from some who might use the product multiple times in a day, to some who seldom log in but subscribe to insights over email (where what we can track is limited).

I definitely want to discriminate, since my natural inclination is to have price broadly in line with cost, but am also aware of the cost of complexity.

Market price of risk

As an aside, in a financial derivatives sense, the cost of complexity is analogous to the market price of risk. Basically a certain payoff is worth more than an uncertain one. You would prefer me to pay you $100 guaranteed rather than toss a fair coin and pay you $200 iff it turns up heads.

The more the uncertain the payoff, the less attractive it is to you, and the less you will be willing to pay to accept the payoff. And, very very loosely speaking, this difference between expected payoff and what you are willing to pay to get it can be described as “market price of risk”.

Perplexity defines it as:

The market price of risk is a measure of the extra return or risk premium that investors demand to bear risk. It is often denoted by the symbol λ and is a key concept in the pricing of financial derivatives. In the context of the Black-Scholes model, it is represented by the term λ = µ - rσ, where µ is the expected return on the asset, r is the risk-free rate, and σ is the volatility of the asset

Now if you are a buyer of SaaS software, if I’ve priced it in some complicated manner, then what you might owe me at the end of the month is uncertain. And so if the average price is $D, you will perceive it to be much higher because of the uncertainty - putting it simply, you will remember the times when you’ve paid me well in excess of D, but forget when you paid less.

And so, there is a real cost to putting in a complicated usage-based pricing structure - unless of course the usage is something the customer absolutely doesn’t think about.

Now you think about this.