SaaS Pricing Models

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 dont know what theyre 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 theyve 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 Microsofts 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 likereevaluation 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 doesnt 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 1

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. Pricing per Transaction: This is an entirely different model. In this model, we are not counting users, time or modules. A business application is offered as a whole (in most cases a core-business-function type of application). The pricing is done on the basis of transactions done by any number of users in any time unit. Of course, then main thing here is to define what a transaction actually is. For example, in banking applications a transaction could be one complete loan application (of course, technically speaking, this is not ONE transaction, but business-wise it is). It could also be a cashier transaction from the bank teller. If this is an outsourced Credit Scoring function, then a transaction would be one score result (regardless of the number of loan co-applicants). Another example is this of an accounting application: A transaction could be one line on the General Ledger of the company or a complete journal entry. This model is very attractive for businesses that pull their earnings out of single transactions and therefore it looks logical to them to also link the IT costs to these transactions (this is the example of the bank that generates revenue out of loan interest). In that sense, the previous example of the accounting application, although clean and simple, does not look quite viable: The enterprise does not generate revenue from accounting transactions. Accounting Transactions are the mere result of some other business process. One more thing: In this model the vendor must be extra-cautious: he has to somehow measure expected volumes of transactions and come up with an offering that is neither too cheap nor too expensive. For example, if a bank gets 200 for loan expenses plus an average of 100 in interest (on the first installment only) and accepts 500 applications per month, that gives us: (200 + 100) * 500 = 150,000 per month. If the Vendor asked for 1 per transaction, then this would be classified as a bad deal for him! A logical number could be, say, 5 per loan, which is 2,500 per month. Now, lets see this example from the side of the customer: This number (2,500) is fair enough for a bank. But if you tried to get this amount of money from a, say, SMB for an ERP application, then you would be out of the door in the first 5 seconds! The flat-fee method: This is a very simple method that can be used for limited scope applications, which in addition, by definition, cannot have a large number of seats (=users) in the Enterprise. E.g. a Fixed Assets accounting module, where one data-entry user and one accounting supervisor are just enough. In that case, the vendor could offer a fixed cost per year. In the remote case that the two users become three, the vendor loses money, but the possibilities of that happening are small. And in any case, the vendor has gained a happy client, because he has offered a standard price clean and simple. Pay for success: In this method, the vendor becomes part of the business problem at hand. He will initially charge an amount of money for his SaaS application (lower than the industry standard, whatever this may be!) but he will expect to get more if the Customers business grows. Therefore, he wagers, so to speak, that his software will actually help the customer grow his business. This is not a very frequently met method, but being as aggressive as it is, I would bet that it would attract a lot of customers. Especially those who seek an IT strategy change as part of their overall business transformation. Apart from the periodical payments, we shouldnt forget the one time costs that most vendors require: Upon activation of the enterprise on the SaaS environment (or the official 2

signature of the Services Contract) the customer is expected to pay a start-up fee which covers the costs of the vendor for the time and effort taken to parameterize and activate the customers space in the Cloud. It may also cover additional services such as initial load of the existing data from the customers old system etc. There is one more thing to comment: Scaling. In most of the above models, the vendor will most often apply a scaling method, too. The more users are added in the system, the lower the unit cost will be, etc. This is a clear discount logic with which everybody wins: The vendor uses economies of scale to lower his costs and therefore his pricelist. The customer sees immediate benefit for his newly boarded users. Therefore, he receives incentive for boarding more and more users and thus automating his business more and more. And a final word on periodicity of payments: In many cases the per month periodicity is converted to larger time periods; say every semester, every six months etc. This is done in order to decrease administration effort for both parties (the supplier and the customer imagine being obliged to issue an invoice of $50 every month for every customer!). Also, the vendor can be paid in advance for the next period and this can lead to additional discounts for the Buyer. This leads to longer, stronger commitment and relationship between customer and vendor. You can clearly see that the discount workarounds or opportunities are large in number. Therefore, we can safely assume that there is a SaaS Pricing Method for everybody. Whether you customer want to focus on business results or user volume or stronger commitment and partnership with your vendor, you have a variety of options to get better deals. One can think and devise other pricing models that borrow elements from the above. E.g. I could also imagine a mixed model, based on per module and per GB. There is no end to what the Vendor can think of (and value). Therefore, for all you buyers out there, you can be sure that there actually is a pricing model that best suits your needs. Multitenant vs single tenant It is obvious that if you board a single-tenant solution, you will be provided with your own server (physical or virtual), your own database instance and your own application instance (executables or whatever this is). All of these require additional effort to support and maintain from the Vendors side. And this will obviously reflect on your costs. In addition, initial setup will require additional effort that simple does not exist in case of multi-tenant solutions. Level of application parameterization If the application supports extensive parameterization then this will cause additional effort on behalf of the Vendor (even if you wont be using some of the system features, they are still there and require proper parameterization). Moreover, extensive parameterization may provide more than one ways to tackle an issue. In that case, consulting services may be called-for. You can expect higher charges if you are buying a big system to cover small needs. Internal effort of uploading (usually perceived as trivial) data, such as customer file, warehouse codes etc. A common problem in these cases is that the Vendor already supports some kind of uploading mechanism, but chances are that the Customer will not provide the exact file format that the Vendor supports and/or there will be data purification issues (not known beforehand) and/or 3

the new SaaS system requires some information (data fields) that you simply didnt have in your previous system. This creates a nuisance for the Vendor (not to mention delays in the implementation!). And, as always, nuisance means money Number of modules and business functions that are covered You want to find a piece of software that does what exactly you are asking for. But it is possible that what you like best is larger in scope than your actual needs. This vendor has done a larger investment on that product than the guy next door. And this is going to affect the overall pricing. Of course, it is the vendors task to see you actual needs and come up with a logical charge. But logical is again a number range and not an absolute! It is your task, buyer, to balance what is offered to you versus what is being asked of you. Security features that are (or could be) installed This is a big discussion, but I think you get the point, right? The Security issue is (and will become even more) hot. In fact, it is one strong reason why some buyers reject the SaaS idea, to begin with. Lets just say that security can be physical (data center, firewalls etc.) and logical (software etc.). All these things cost money that the Vendor must spend in order buy and then maintain the entire infrastructure. SLA level This is another significant cost factor. The Buyer should be very careful on the Service Level that they will require. Do you really need 99.9% for, say, a back-office Accounting subsystem? Now, to distinguish between different Vendors, we must also remember that, depending on a number of factors, same Service Levels may have significant differences in terms for internal cost for the Vendor. Nationality of the Vendor The application is on the cloud but the programmers of the Vendors are residing somewhere! And they have a level of salaries, expenses etc. Therefore, the physical location of the Vendor can play a significant role in the overall cost of the solution. The phenomenon is more intense when the time comes for Professional Services or Customizations that are asked by the Customer and the Vendor is costing them (usually on a time-and-material basis) Different scaling perception Scaling usually exists, but volume-based discounts are perceived differently by each vendor. The scale can be 4,6,8% or 4, 10, 18%. Then, although two solutions start from a similar base price, they diverge significantly as volumes increase. This is a significant point of attention for big Customers. Periodicity of payments When increasing periods between payments, the cost of money saved by the vendor is different, depending on where the vendor is actually located. Local factors such as bank interest rates for business loans are obviously taken into account by each vendor, internally. In addition, certain periods may or may not be offered by a Vendor. E.g. a vendor might not want to engage in a monthly payment cycle, even if the customer requests so. 4

Customer support level and functions offered by the supplier The more open a Vendor is to Customers requests of any kind, the more expensive they tend to be. E.g. if a Vendor is open to any customization request, then he must have developed the mechanism to support this: hot-stand-by programmers and testers, very frequent upgrade cycles, complex release planning etc. These are the reasons why prices can be so different between SaaS vendors. And these are key aspects that Buyers should also examine when examining a SaaS offering. The Application itself does not represent 100% percent of the deal!

Tasos Christidis http://tchristidis.blogspot.gr/2010/03/saas-pricing-models-part-1.html