SaaS Pricing Models (part 1)

There has been a lot of discussion of how a SaaS offering is priced. Different vendors use different pricing models. To the untrained eye it may seem that they don’t know what they’re doing. But, obviously, this is not the case. Vendors have thought a lot before applying “this” or “that” Pricing Model and you can rest assured that they’ve also done their competition research.

Today, we shall explore the different Pricing Models of SaaS (we shall focus on SaaS; what you are about to read does not necessarily apply to PaaS, IaaS or other forms of “aaS”). We shall also try to approach an answer on why similar pricing models of similar applications can diverge so much from each other.

Pricing per user, per month: This is a very common practice that reflects the fact that the criticality of the application on the Business functions is proportional to the number of users that are using it. It is attractive to the Buyer because it is very clear to him what is going to pay on “day one” and what in the next “days”. Finally, this model is very helpful for seasonal businesses, when they need to periodically increase/decrease their user count. This is very close to Microsoft’s philosophy “pay as you go”.

Pricing per user, per month, per module: This is a model very similar to the previous one with the sole difference that the Vendor requests you to acknowledge that using more features of the application means that the application becomes more business-critical for you and therefore you should pay more. In addition, “more functions” means more data storage, more technical administration tasks for the vendor and increased maintenance requirements to the vendor by you. And this has a direct impact on your costs.
This model is also clear to the buyer but in some cases it may indicate that the supplier is trying to gain more money with each simple “click” that the buyer is doing (“So, now that Mary was also granted access to the CRM module, you have to pay me $5 more, per month”). This could be a possible drawback in Eastern-thinking countries or cultures such as Greece, India etc. Also, if you try to follow the user authorities “to the letter” in order to be 100% accurate, this could lead to an administration nightmare. For this reason, when this model is applied, a clause in the Services Contract could read something like “reevaluation of the user rights will be done every 6 months. If significant changes are found, then the monthly fee will be re-negotiated”.

Pricing per month, per module: This is a simplified model where the vendor assumes that the number of users will not significantly change and is charging for a standard fee per month (and possibly per module). What is implied here is that the application, by definition, cannot be used by a large number of people; perhaps because it is outside the mission-critical definitions of the Enterprise.
A perfect example of this model could be an HR system: It is typically used by a small number of employees (or “given number” if you prefer) and they are doing trivial tasks. It doesn’t matter if the Enterprise has 30 or 150 employees. The system will be used by, say, 3 people (the HR dept.).
But look at this: If the Enterprise suddenly decides to apply “self-services” in the HR sector, then the number of users will suddenly explode from 3 to 150. Then, this pricing model may not be suitable any more…

Pricing per GB: This is a model suitable for cases where the application does not offer “tons” of functionality, but requires lots of disk space. Imagine a Document Management application for higher executives of the company. The number of users is, by definition, small and not likely to increase. But the volume of the data hosted in that application is very large, because it includes multi-page contracts, scanned images etc.

We shall explore more Pricing models in our next episode. Stay tuned!