After many years on the marketplace, the benefits of SaaS – especially when compared to owning everything yourself – are obvious and well known: Flexibility to “dial” capacity up or down as needed, pay-as-you-go pricing, access to high economies of scale with low investment… However, SaaS pricing modes often lacks two things that we all had when we “owned” all of our own resources (people, servers, on-premise licenses, etc.): predictability and control.
Back then it was easy to figure out what our budgets would be for the next year. Our starting budgets were based on existing payroll (for IT and software staff) and capital resources. We could easily decide (usually once per year) if we wanted to increase or decrease this by X%. Once we did this, it limited how much we could possible spend. The big challenge was prioritizing this budget across what turned out to always be too many projects. (Usually, the time required to build and ramp up systems kept this in check.)
Now things are different. Because we can buy SaaS-based services quickly and easy we can do more in less time and with far less work. However, this can lead to traps where we become “victims of our own success.” The SaaS-based online program we launch could get so much traffic that our costs quickly beyond grow beyond our budget. The easy access to storage could lead our teams to store too much, burning through money.
This problem is bad enough with commodity items (usually serviced with IaaS, Infrastructure-as-a-Service and PaaS, Platforms-as-a-Service). It can become “unmanageable” with complex portfolios of activity that do not easy fall into easy-to-size units (marketing and advertising campaigns, clinical trials, public sector programs, etc.) In these cases, SaaS creates a predictability problem for “both sides of the table”: customers cannot easily predict and control what their budgets will be while vendors cannot easily predict revenue recognition (affecting their ability to control business expansion).
SaaS vendors need to find viable solutions to this conundrum balancing SaaS’ flexibility with the basic need to budget and control costs. Here are four options:
The Fixed Price Model
Under this model, the price of the SaaS product is fixed, regardless of usage volume. A first blush, this can easy to budget (great for customers). However, it can kill TCO for vendors (the first time a customer wildly exceeds planned volume). Guarding against this leaves vendors two choices: raise prices (to guard against – leading to reduced demand) or KYFC “keeping your fingers crossed” (potentially risky).
This model is good in places where variability is low (e.g., sales force automation – one sales person can only generate so many contacts in a given month).
The On Retainer Model
This model draws from the ‘Old World’ of having lawyers and accountants – people who can perform a wide range of services – on retainer. It is somewhat tailored on a case-by-case basis, looking at expected volume across a wide portfolio of work and flattening this out into constant quarterly or monthly payments, adjusted by periodic reconciliation (based on actual vs. planned usage). This balances customer and vendor risk – and predictability with flexibility. However, it is complicated.
This model is good in places where usage is subject to “external factors” (e.g., portfolio-based business models like architecture, legal, research, campaign management, etc.)
The Credit Model
This model draws ultimately from the postal service (e.g., stamps). Customers budget for and buy X usage credits per quarter. Each use of SaaS consumes these until their budget runs to zero. They can distribute these credits for use internally however they desire. This “caps” costs but can leave businesses “in a lurch” if credits run out faster than expected.
This model is good for discretionary business applications (e.g., recreation/reward allowances and advertising click-thru’s)
The Tax Model
This model adds a standard overhead “tax” to a recurring operation. It is most well known in the credit card payments industry but has applications in many other “commodity” transactions. It is predictable. However, it requires high volume to avoid high taxation rates per transaction.
This model works best in places where the cost of the transaction is low vs. the value of the item transacted (e.g., eCommerce, HR payroll software).
None of these are ideal for all circumstance. However, each balances the benefits of SaaS’ flexibility with the “old fashioned” business need of predictability and control for specific business scenarios.
Disclaimer: I have been both a SaaS buyer and seller, using all of the models above – and many more that I would avoid like the plague. See my background for more information.
Note: If you liked this, you may be interested in Nine (Ten) Software Pricing Models Evaluated