I posted a little while ago about different pricing strategies for SaaS businesses. Briefly my view was that principally SaaS vendors should keep their SaaS pricing simple. After that Sinclair wrote an excellent post over on his blog that elicited some really useful comments. one of the comments came from Yves who basically said that, while a “pay for what you use” approach towards SaaS pricing may be best at a conceptual level in practice it has several shortcomings;

  • It makes it very difficult for potential users to perform comparisons with other offerings
  • It tends to be quite complex to calculate total cost – possibly creating a barrier to uptake

What Yves came up with however is absolutely the best solution. In his words;

So, I have abandoned the idea of applying the per use model to the pricing for now but not completely. My plan is to reintroduce it but not in the pricing page of the application but as a service to my customers. If I discover that certain customers could pay less changing their pricing model to a per use model, I will propose them the switch. It will makes less money at the end, but the benefit of having your users satisfied is priceless.

Yves should be congratulated – in my mind this solution is by far the best result and should really build a loyal following. It includes the best of both worlds in that it;

  • Allows users to make a very quick cost analysis and therefore competitor comparison and ultimately a buying decision
  • It allows users at the outset to see further options which could possibly reduce the costs even further (but not increase them – a ratchet clause working the right way for a change!)
  • It gives the vendor a reasonable degree of certainty around recurring revenue
  • It allows for easy and obvious modularisation – a theme which I believe we’ll see more and more of in the future
Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

  • Thank you for this Ben.

    I would also add that, just as said by Coghead’s CEO here : http://blogs.zdnet.com/SAAS/?p=559, it will fit whit the needs of certain customers to have the comfort of a packaged pricing too if they want it.

  • Another thing to consider is your goals, especially in the stage where you need converts to learn and evangelise your product.

    If you’re creating a project collaboration service like BaseCamp, you want *people* to collaborate. So restricting the number of users (by charging per-user) makes no sense – either people will be left out of the projects, or people will ‘cheat’ and merge user accounts together to stay under “the limit”, which means they don’t get the best out of the product. And people have thoughts like “if I left David out, we’d stay under 15 users and don’t have to pay another $100 – he’s not on many projects anyway…”. Charging per-project (as they do) means that BaseCamp can be at its full potential for a small team, and grow to cover different areas, with pricing going up as it becomes more valued.

    CRM apps like Salesforce.com/Highrise are different. We have 12 salespeople, lets get 12 accounts. If you charged per-client or per-opportunity or per-contact, you’re encouraging people to leave contacts out of the CRM to avoid paying more: immediately making it less useful.

  • Well stated Rob. Excellent points.

    You need to understand the goal of your product, and what drives its adoption. You also need to understand the goals of your business at the given time. If you place any barrier in the way of a user realizing the benefits of your solution, you risk them not finding it valuable enough to continue using it. Initial adoption and success during the implementation period is critical.

    Yves approach is beautiful. If you have the ability to meter and bill based on usage, and you tell your customers that would benefit that they can save money by switching, you’ll most likely gain the difference back in the long run. You’ll also have created a bonafide promoter of your company/product.

    I think we need some shakeup in the pricing models for SaaS apps. I’ve not seen too many really creative pricing models lately.

    So, as Yves

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.