SaaS Pricing Models (part 2)
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!
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:
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…