BY: LUBOR PTACEK, VP of PRODUCT MARKETING, ZUORA
The scale of a deployment is an important factor for how SaaS companies price their products, the most common way of measuring scale being the number of users. But what happens when software doesn’t naturally scale by the number of users? It turns out, this is a common problem.
For context, the modern SaaS company typically prices its product under three main considerations:
- Packaging: This is the way to package the functionality into products and assign each product a relative value. There are several different models used here, including the product suite, good-better-best, core plus add-ons, etc.
- Usage: This is a way to control the cost for each customer by providing a varying volume of usage at a price. For example, you may provide each customer with a certain amount of storage with their default price and charge them extra if they use more storage.
- Scale: This is a way to ensure that your price varies with the size of the deployment. That is usually done easily by counting the number of users.
The user number is a popular metric for scale because it is easy to understand and forecast, and it scales with the value that your customers perceive. Take one of the popular SaaS applications, for example, such as Slack, Dropbox, or Docusign. You’ll agree that deployment for 5 users should cost less than a deployment for 500 users, even if the functionality of both deployments is identical. It just makes sense – the value and price scale by the number of users. But what do you do when your software doesn’t have any users? How do you ensure that a small deployment costs less than a large one?
This, by the way, is not just a problem for B2B software. After all, Slack, Dropbox, and DocuSign all sell to consumers as well as to businesses. You will encounter this issue with software sold to businesses as much as software sold to consumers. The scale is also not the same as usage. Take backup software as an example. The usage might be related to the number of times someone retrieves data from backup storage while the scale is best measured by the amount of data stored. Even if there is no usage, you will need to charge your customers for the stored data – because it costs you a lot of money to store it.
There is, predictably, not a single answer to the problem and many companies are very creative and charge by the number of transactions, the number of records under management, number of API calls, number of business processes, amount of revenue/money under management, number of assets (i.e. vehicles), etc. A few important considerations for those embarking on a strategic pricing journey:
- Make sure your pricing reflects the value of your software. Your customers should clearly understand how they realize more value if they purchase more units of your software.
- Make it easy to forecast. Coming up with a sophisticated formula based on a lot of detailed metrics may sound like a very accurate way to determine the price but it will be difficult to quote if you can’t estimate how many units a customer needs.
- Don’t force your customers to make the wrong choices. Don’t design your pricing in a way that would encourage or even force your customers to do the wrong thing. For example, if you charge by the number of processes, you may not want your customers to create very complex and inefficient processes. If your unit is the number of invoices, neither you nor the customers will be happy if they feel compelled to switch from monthly to quarterly billing because of your pricing model.
- Encourage the adoption of your software. This is perhaps the most difficult piece of advice to follow but you want your customers to use your software more, not less, and your pricing shouldn’t be preventing them from doing so. This is as much a question for product design as it is a question of pricing. Of course, part of the pricing design is driven by perceived value as customers will adopt more willingly if they see more value. But adoption can be also encouraged by letting customers get creative with new types of use cases. Often, you will find that your customers are “abusing” your software by doing things that you have never expected – but that’s usually a great way to drive more adoption.
- Make sure you can meter and bill based on your pricing metrics. No matter what your pricing metric is, you need to be able to meter the units and make the measure visible to your customers. Ultimately, you also need a billing system that gives your customers the flexibility to design any billing model they need – one that processes the bills accurately every billing period.
There are many companies with cloud software that doesn’t logically scale with a number of users. Still, that software has to have pricing that works for both the buyer and the seller. And while there may not be a simple answer for all of the different software types out there, there are ways to get it right, pricing in a way that helps your company grow and become profitable.