SaaS Pricing Models (part 2)

In this post we shall continue with the discussion on several Pricing Methods of SaaS that started in the previous one. Here we go:

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, let’s 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 Customer’s 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 shouldn’t forget the “one time costs” that most vendors require: Upon activation of the enterprise on the SaaS environment (or the official 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 customer’s “space” in the Cloud. It may also cover additional services such as initial load of the existing data from the customer’s 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.

In the next post we shall take these methods for granted and explore why similar Pricing Models for similar Applications can diverge so much from each other. How can a vendor charge you for X dollars per user and another charge you for 2*X ? Stay tuned…