The common SaaS per-user, per-month subscription revenue model is rapidly evolving.
From time to time I feel I must remind everyone – buyers, sellers, pundits, commentators, & analysts – that SaaS is not a pricing model or pricing strategy. From the vendor side, Software-as-a-Service (SaaS) is a unique Software Business Architecture where service is the focus over the technology. From the consumer side, SaaS is on-demand functionality that solves business problems, putting the focus more on the “service” aspect than the “software” SaaS might displace.
So, the notion that if you have a web-based, multi-tenant software product you must adhere to the same pricing tactics employed by every other vendor has come and gone. Just as SaaS vendors have created some amazingly sophisticated products that are a far cry from the simple web-based CRUD apps put out five years ago – not just because the technology has improved but the expectations of the market have matured and evolved as well – the pricing strategies employed by the vendors have evolved as well. And this is a great thing!
The impetus of this post came from an article on ZDNet by Larry Dignan the other day titled “SaaS pricing evolves: Should we be worried?” In that article Dignan discusses changes in SaaS pricing, especially around the “open secret” that some companies are signing multi-year contracts with SaaS vendors which prompts him to ask the question “Is this really SaaS pricing as initially conceived?“
As should be very obvious, SaaS itself has matured since the term was coined back in 2004 and now represents every functional area legacy software did. SaaS has moved beyond the small vertical, niche or departmental apps or less “mission critical” horizontal products – Salesforce.com, YouSendIt, Yammer for example. In 2010 you can run your entire business in the cloud with real SaaS products including wide-band horizontal products that a few years ago pundits questioned whether they were a fit for pure-play, multi-tenant SaaS.
These include such “not fit for SaaS” products as: Human Capital Management (HCM) from Workday and Enterprise Resource Planning (ERP) from Plex to Material Requirements Planning (MRP) from Rootstock or Supply Chain Management (SCM) from SPS Commerce. So as the complexity of what is available as SaaS and the requirements around the solutions (customization, on-boarding, training, etc.) evolve, it only makes sense that the pricing must evolve, too.
But it isn’t just the increased complexity of the products that has caused an evolution in SaaS pricing. SaaS vendors now realize that they are bringing value to a market specific to their product, and the problems it solves, and they need to be aligned with the customers in that market. This means they should not worry about what Salesforce.com is doing if they aren’t a CRM product and aren’t competing with SFDC.
Not all understand this yet – we work with clients to change their thinking on this every day – but savvy SaaS vendors are realizing that they are still competing with legacy software vendors, they might compete with other SaaS vendors, and even more important – they compete with the status quo – whatever that might be; an Excel spreadsheet, a clip board, or a home-grown software solution.
I think the crux of Dignan’s question is that the evolution of SaaS pricing has steered further and further away from “utility” pricing or this idea of only paying for what you use in the truest sense (paying in arrears, being billed by small usage metrics, etc.). The reality is that “utility pricing” has only seemingly come to fruition at the Infrastructure-as-a-Service (IaaS) portion of “cloud computing.” Amazon’s EC2 product in their Web Services line is a perfect analogy for utility-style computing.
With EC2, you spin up a compute instance (virtual machine), it does some work, and when it is done it spins down – like a toaster where the power company only charges you for the kWh used while making breakfast. Except that even Amazon has long-running charges for storing your VM image on S3, persisting data between sessions, etc. But you still only pay for what you use. Predictable recurring revenue that grows over time (increases CLV) is still the goal, even for “utility computing” companies like Amazon.
But sorry, SaaS is not utility computing – though because it is not a pricing strategy itself if that is aligned with your market, you could certainly price that way. It is critical to understand why SaaS is not a “utility.” This list is not complete, but just remember that a great deal of the value derived from SaaS happens outside of direct use of the product. Whether that is continuous improvement to the software itself, constant vigilance by the vendor to ensure business rules are up to date (tax laws, industry requirements, etc.), infrastructure upgrades, support systems, backups, etc.
These are elements that you as an end-customer would have had to support in the past. But now, you do not. Even more important are the Network Effects – the fact that a system becomes more valuable to everyone as more users join. From improving the user experience, to populating the system with actionable information not available to users of legacy software, SaaS is different and that is relevant to everyone, from the vendor to the end-customer.
So yes, SaaS Pricing has evolved – and will continue to evolve – and this is a great thing. It means SaaS is entering new markets with new value propositions and also indicates an increasing level of maturity among the vendors. For those who were only interested in SaaS because of the promise of “utility computing,” sorry to disappoint. But for those who understand the incredible value that SaaS can bring to the end-customer, the notion of better alignment in pricing to those customers means a greater adoption rate for SaaS and less barriers to acceptance by the customers.
Let’s Grow Your SaaS Company
For immediate consultation and advice on effective growth strategies and tactics for your SaaS company, schedule a 60-minute meeting with me via Clarity. If you feel a more involved engagement is required for me to help you, email me with the specifics of your situation (as much detail as you’re comfortable giving) and we’ll setup a meeting to work through the particulars.