How Should You Charge for Your Software?
Many years ago, I was responsible for changing my company’s pricing model. The impetus for making a change was that the existing pricing model was having the unintended effect of increasing customers’ prices over time even if the value they were receiving stayed flat, which in turn led to boom and bust cycles of expansion and contraction (or cancellation).
Having been told by customers how they thought about value, I created a new usage-based pricing model. I was thorough in my analysis:
- If the new pricing model were applied to existing customers, how would their prices be affected? Many would decrease; some would increase or remain unchanged. Total revenue would be unaffected.
- Based on what we knew about how our competitors priced, how would we stack up if the new pricing model were applied to each of our last twenty sales opportunities? The results were positive.
- I worked closely with the top sales reps to iron out the specifics of the new pricing model. Did they feel good about it? Would it make their jobs easier? I received two thumbs up from each of them.
Twelve months after rolling out the new pricing model, the company’s average selling price had more than doubled and revenue retention had improved materially. Mission accomplished.
And yet, I knew that I’d made a mistake. Although the metrics were good, prospects and customers were struggling to understand how the pricing worked. Once it was explained to them, many didn’t know how much they should buy—or worse, confidently bought too much. Then came what should have been the final straw: an external trainer asking the sales team to explain the pricing model. It was ugly.
I count not taking immediate action to adjust the pricing model among my greatest professional regrets. I’d been so laser-focused on aligning price and value that I’d lost sight of other important factors. I hadn’t stopped to ask myself: What makes a pricing model good?
Here’s a framework I created to answer this question:
- It’s easy for buyers to understand. I learned the hard way that this is the most important consideration. There’s a reason per-user pricing is so common, although as Kyle Poyar’s excellent blog post on the subject makes clear, it isn’t the right model for all software.
- It’s easy to scope accurately. Assuming some form of commitment and/or prepayment is required, buyer and seller must be able to determine easily how much needs to be bought. A disadvantage of usage-based pricing is that it can be difficult to scope.
- It aligns price and value. Buyers want to receive good value for their money. Sellers should want exactly the same thing, because customers that are overpaying for the value they’re receiving will cancel. The reverse is also true: sellers should be compensated fairly.
- The driver is unlikely to decrease. Another advantage of per-user pricing is that most companies don’t reduce headcount over time. Similarly, once entered, most companies don’t pull out of international markets, or remove integrations. On the other hand, variable drivers that are project-based in nature can lead to lumpy revenue.
Even after creating a pricing model that fulfills the above criteria, you may realize that all isn’t as straightforward as it seems. For example, while Salesforce charges the same for every user, an increasing number of SaaS companies split users into paid and unpaid, e.g., quota-carrying reps require a paid seat but managers and sales ops get free seats. Is this the beginning of a shift to usage-based pricing, a permanent middle ground, or a temporary blip? My instinct tells me it’s the latter, but time will tell.
You’ll likely need to make similar decisions about your pricing model. My advice is to keep it simple. For example, if you choose per-user pricing, include a free seat for the admin during negotiation, if asked, rather than have a policy of admin seats always being free.
By applying this framework you can avoid your pricing model getting between you and winning deals.
