Multi-axis Pricing: a key tool for increasing SaaS revenue

Scalable pricing is a powerful tool to grow revenue in a SaaS or software business. It allows you to capture more of the revenue that your customers are willing to pay, without putting off smaller customers that are not able to pay high prices. It also provides a great way to continue to grow revenue from your existing customers. This post looks at how to create scalable pricing using multiple pricing axes, and discusses the different types of axes that can be used.


Many SaaS startups begin life with one product that has a simple pricing model. They might have initially only one version of the product to keep their lives simple, and use a single flat price for that version. To make that product as attractive as possible to a wide range of potential customers, it is not uncommon to see the founders set the price low, so price sensitive users are not put off. This is a smart strategy, as in the early days it is far more important to get lots of customers, than to it is to optimize profitability per customer.

However as time progresses, they may hear comments like:

  • “I would have been happy paying far more for your product as it provides such great value to me”
  • “I didn’t consider your product as it was too cheap, and didn’t look like a credible option to handle our more advanced needs”
  • “I only needed a subset of your functionality, and your product was too expensive”

These comments indicate that there are a variety of different user types in the market, with differing levels of value they can extract from use of your product, and as a result, differing willingness to pay. All of the above point to the limitations of a simple pricing scheme.

Let’s look at these to items separately:

Value extracted from use of the product

Here are some examples of how different customers can get differing levels of value from your product:

  • They are a larger company, and many more employees are using the product
  • They are using fewer, or more, of the features in the product
  • They have a greater number of items that are being processed by your software.
    • e.g. if it is email marketing software, they may have a very large mailing list
    • or if it is a backup service, they may have a very large dataset that they are backing up
    • etc.

Emotional Willingness to Pay

There is a very significant difference in the willingness to pay amongst various customer types. Car manufacturers have known this for a long time, and usually include a highly profitable model at the top of their range that appeals to the non-price conscious buyer, who likes to feel that they have bought the very best.  Take a look at the Mercedes Benz S-Class as an example: The base model S550 starts at $94k, but for those that aren’t price sensitive, they sell an S600 version for $160k, or an S65 AMG version for $211k.




The main difference is a slightly bigger engine. But if you look at the profit margins for these models, the margins increase greatly for the higher end models.

What’s important to recognize here is the mentality of the customer. In the business world of software buyers, the emotional thinking is slightly different. The driving emotions that can make them want/expect to pay a higher price are:

  • Their problems are so important to them that they are looking to make sure they have taken the best possible steps to address them
  • They want a serious commitment on behalf of their suppliers.
  • They have a status need to own the best

Those buyers will not feel comfortable buying a “cheap” solution.

Scalable pricing is the answer

The solution to this is to introduce pricing that scales up or down. If designed correctly, the pricing should scale down to allow you to capture the smallest/cheapest customers that are still profitable, up to the largest customers that are willing pay a great deal.

To architect scalable pricing, we will use one or more axes. Let’s take a look at some common axes for scaling pricing:

1. Product features

A very common way to differentiate pricing is to package up different versions of the sofware with more functionality available at a higher price:



2.  Number of Users

The theory here is pretty simple: as more people use the product, the customer derives more value.




3.  Depth of usage

By “depth of usage”, I mean some an indicator like the size of database used, the number of people on an email marketing list, the amount of storage used, etc. These all indicate that the customer is getting greater value from the product, and therefore is likely to be willing to pay more.



Other Axes that I have seen used

Some other examples of factors that can be used to scale pricing include:

  • Number of Websites created
  • Number of Servers/Virtual Machines (not applicable to SaaS)
  • Quality of Support
    • Response time – i.e. 2 hours versus 24 hours
    • Email support versus phone support
    • Number of support incidents
    • Dedicated support representatives
  • Number of sites where the software is installed
  • Number of named support contacts

Automatically increasing revenue from existing customers

As a SaaS business grows larger, it starts to accumulate a large customer base. An important factor to look for in selecting a pricing axis is to look for ways to automatically get more and more revenue from that customer base. A good example of this is pricing around storage usage. Companies find it hard to throw things away, and the amount of things that they want to store keeps increasing. As a result storage growth in a typical company is around 60% per annum. If you can tie your pricing to something like storage where there will continue to be annual growth, you have an excellent way to grow your business without having to do any more selling.

How many Pricing Axes is optimal?

If you are going to build a low cost sales model, it will be useful to have a very simple pricing model that the customer can immediately understand. I would argue that this means no more than 3 pricing axes, and perhaps 2 is the optimal.  (I’d be interested to see what readers think, so please add your comments to this blog post on this topic.)

Cross-sell Axes

Another very important way that one can sell more into an existing customer base is to cross-sell them. By cross-selling, I mean selling them on an additional product or service. For a SaaS business, there are a few interesting ways one can do this:

  • Buy or build additional products that are closely related to existing products
  • Sell add-on modules that integrate nicely with the existing product
  • Create an AppStore, and sell third party products, taking a cut of the profits
  • Create a services marketplace where you connect partners that provide services offerings around your products and take a cut of the transaction fees
  • Look for other fees that are created around the usage of your product (e.g. payment transaction fees in eCommerce, advertising revenue, etc.), and ask yourself if it is possible for you to extract a portion of that revenue.

These ideas are important as they essentially allows you to go beyond the two or three axis pricing that we thought was optimal in the section above.

The beauty of all of these ideas is that they provide more and more value to your customers, and wherever you are able to this, you can increase customer satisfaction and loyalty, as well as getting paid more.

Getting to Negative Revenue Churn

All SaaS businesses will see some level of ‘customer churn’. i.e. you will lose some customers. However if one looks at ‘revenue churn’, which is the amount of revenue coming out of the installed base of customers, it is possible to get negative revenue churn. The way to do this is get enough additional revenue from the customers that stay with you to more than offset the loss of revenue from the customers that have churned.


The key to achieving this is additional pricing axes, as described above.

How this relates to Freemium Business Models

This topic is very relevant to entrepreneurs who are thinking about using Freemium business models. To make the Freemium model work well, you need to achieve two things:

  1. Design something that you can give away free that still has very high value to the customer.
  2. Design an upgrade from that initial product that is also extremely compelling. Compelling enough to get a significant portion of your free user base to pay.

If your free product is not valuable enough, it will not get adoption. And it most certainly won’t get viral adoption, which is the one of the most powerful things that can happen when you give things away for free. (For more on virality, see this blog post: The Science behind Viral Marketing.)

Step 2 is all about finding a way to introduce a pricing axis that scales from free to paying.

Open Source Software – Scalable Pricing is key

One of the toughest challenges at JBoss was finding a way to get customers who had downloaded a completely free Open Source product to pay. This was one of the key elements that helped drive revenue growth at JBoss. That story is described here: Lessons from Leaders: How JBoss did it

Value-based Pricing

You might have noticed how I have tried to link pricing to the value that a customer derives from using the product. I believe this is a key concept, and one that is sometimes forgotten.

As the CEO of my own startups, I used to spend a lot of time in front of customers selling. As any salesperson will tell you, one of the hard parts of the sales job is justifying to the customer why they should pay you so much money. I found myself wanting to be able to answer that question with ease and comfort. And the only way that I could do that, was to make sure that my pricing was clearly aligned with the value that the customer would derive from using my product.

Once you have come up with a pricing scheme, test it against this simple question:  How comfortable will you feel when talking to your customer about your price versus the value you generate?


If you are running a SaaS busines (or any other kind of software business), it pays to spend some time thinking about your pricing axes. This represents one of the very powerful levers that are available to you to grow your business.  (I am surprised by how often I find this has been ignored.)

As always, I would love to hear your feedback as to how this has applied in your own businesses. This is also very valuable for other readers. So please add your views below.

Share and Enjoy


  • David Skok

    Hi Kosta, most companies I deal with charge by the hour for customizations, and don’t discount that. The reasons to discount would be if you facing tough market conditions and need to win business. As a company gets more established, those reasons tend to go away. Then companies are faced with the issue of how to make those services profitable. Most are able to charge a good rate, even as high as $250 per hour, as there is high value to the services.

  • Kosta Kontos

    Hi David

    Thanks for the prompt reply. I enjoy how you add value to your blog by encouraging conversation like so.

    Yes indeed, we currently discount our hourly billing rate for customisations solely in order to win business – but this is driven by our desire to grow our brand (as opposed to poor market conditions). I look forward to our being established one day (and thus billing market-related rates).

    With regards to these customisations, in light of the fact that we’re billing for our time / their implementation, how should we justify our maintaining ownership of the IP / source code? The reason I ask is that I envisage a client questioning us as to why they’re required to pay for customisations when they don’t end up owning the actual software.

    A couple of justifications I can think of are a) our clients are paying for the functionality, not the source code (and our proprietary framework enables us to deliver functionality much faster than a programmer developing the same functionality from scratch), and b) were we to expose an API, our clients could hire someone else to implement customisations instead.

    What are your thoughts on ownership of paid-for customisations?

    And when these client-specific customisations are really useful (and would benefit the rest of our clients), how should we SaaS vendors approach the opportunity to refactor such paid-for customisations into our shared / multi-tenant codebase (and thus providing it to our other clients at no extra cost to them)?

  • David Skok


    It is very common for companies to keep ownership of any custom work that they have done, so long as it is made clear with the customer up front. It is also very common for them to use those custom developments as the basis for future features that are made available to all other customers. I haven’t personally been involved in selling that kind of contract, so can’t help tell you how it is done. My gut tells me that the right thing to do here is to be clear with customers about what you are going to do upfront. Perhaps tell them that you have your own roadmap, that is prioritized according to broader market needs, and what they are requesting is not on that roadmap. You are happy to do that development for them, but it has to be paid in order to justify the resources.
    It might also be appropriate to give them some kind of reward later on if you do use one of the features they paid to have developed. That reward doesn’t have to be financial, but just a way of recognizing the help they provided.

  • Bill Corrigan

    Good posting.  I am interested in hearing / seeing how people differentiate SaaS offerings by the quality of support.  Would customers opt for a Premium offering if it had the same functionality as the Free but only differentiated by the level of Support?  I imagine Support would be important for any Enterprise-class product, where customers are running their business on it and would be interested in hearing other people’s thoughts.

  • Gil Sadis

    David, I agree, though we see a lot of our customers preferring this kind of pricing where they pay us only if they sell. It might be because we’re selling to SMEs but it shows that there are cases where customers prefer to pay this way.
    BTW, our business is helping SaaS companies with their pricing and we like to think we’re disrupting the software pricing world by providing companies the ability to price their software based on their users’ value.
    Anyway, this is a great post and I really like your writing.

  • whatman

    Wow, I used to do this kind of work on behalf of a former employer, and this is 110% spot on and accurate. Great comment

  • Sandy Brown

    Long-term, simply by definition, costs determined by value-based charges usually are constantly greater or comparable to the prices produced from cost-based charges (if we were looking at lower, it might show that the actual benefit understood because of the client is leaner versus costs connected with making the great as well as a income perimeter, and thus organizations would long term not necessarily be curious to generate as well as offer in that will price).
    Value-based charges will be predicated when a comprehension connected with client benefit. Inside business-to-consumer promotes, dealers ought to fully grasp this effect his or her services or products possess on end user electric. Inside business-to-business environment, organizations must know exactly how his or her featuring aids clients, which is other corporations, become more profitable.

    But I am recommending Curation Software-YOUR #1 Content Curation and Traffic Assistant Tool! as CurationSoft has a very nice interface and it’s easy to see that it’s going to become a must have for curation in order to save time finding the relevant content as well as developing the set or posts, and the commentary.

  • Sevak

    Hi David,

    I have been reading your blog for some time and have used a lot of ideas for our SaaS business. I was looking for some pricing discussion on your blog and found this. Do you happen to have any pricing models, maybe some excel samples that you might be willing to share?

    I am also curious if and how one may be able to find the price elasticity of demand in a SaaS product. I am assuming changing your prices often just to find the elasticity of demand would be a futile exercise and send the wrong message to your customers. Any thoughts?


  • David Skok

    Unfortunately I don’t have any models or Excel samples to share. However a visit to some of the leading SaaS companies pricing pages will likely give you a ton of good ideas.
    Regarding how to figure out the elasticity of demand, most of the companies that I work start with customer interviews, and purposely use lower pricing in the early days to make sure that price is not a major factor affecting initial traction. Then when they have decent traction, they start adding in more powerful features and raising prices. Depending on customer reaction, they get the signals they need to figure out the elasticity of demand.

  • Omar Mohout

    Tx for the excellent overview David.

    Good inspiration for the pricing for startups book:

  • Etienne Garbugli

    Great post – really useful model. I referred to David’s ideas in the book Lean B2B: Build Products Businesses Want (