A reader recently wrote to ask for advice about a product which started as a SaaS offering, but for which the technology and customer needs are pointing in another direction:
[…] As we evolved this product we started working more with directory services and really needed to move the app inside the corporate network for optimum functionality. We are just undergoing our first pilot of this product launched in this manner […] I really want to stay with a SaaS model but this is clearly a product. It installs on their gear, they maintain the systems etc. Have you heard of any precedent that would allow a product like this to be sold as a service? […] $x/desktop/year kind of thing. However, most software comes with a perpetual right to use license and I’m not sure if it’s fair to me or my customer to sell them a product they install but that is licensed on more of a subscription basis. […]
First and most importantly, this reader has a very good product: a pilot project (with a real customer, I assume) who wants to pay for and use the software at hand. In this situation, the obvious advice is to figure out how your customers want to pay you, and let them pay you. That’s not very informative, though.
To get a handle on the situation here, consider the appeal of SaaS. In my experiences as both as customer an seller of software-service offerings, the key benefits of the SaaS model are:
- Recurring revenue for the vendor, which facilitates a stable and growing business that makes payroll every time.
- Reduced risk for the customer, who can stop using the service when the need arises (either because it does not work well, or because they no longer need it) with much less abandoned investment compared to an up-front on-premise installation
- Better alignment of the vendor and customer interests
Based on need for your software to operate behind the firewall, it appears that that bulk of potential customers at this time (2009) indeed will prefer to install the software in house. It is technically feasible to implement SaaS in such a way that it authenticates (or federates) with existing internal software, but thus far that is not a popular way to go, particularly from a security point of view.
The question then, is how to get at least a portion of the benefits of SaaS, with on-premise installed software. This turns out to be fairly easy:
- Sell the software as a “subscription”. It is fairly common to sell software with subscription pricing, with a perpetual right-to-use bundled in. Offer your product in a bundle something like this:
- The software itself, including perpetual right to use it (but with the caveats below)
- Installation assistance
- Support
- Upgrades
- Bug fixes
- Priced at $X per user per year
If you set the pricing so that year 1 is the same price as years 2..N, you have something very close to SaaS in, in terms of your customer relationship (though not in terms of the deployment architecture, of course). If you set the pricing so that years 2..N cost 10-20% of year 1, you have the traditionat purchase-then-maintenance enterprise software pricing model.
What if the customers pays for year 1, then stops paying but keep using?
This is a possibility, but is may not be a problem in practice. Enterprise products tends to require support and upgrades to keep working smoothly in their real-world environments (ongoing streams of business and technical changes), and enterprise customers who rely on such a product, generally value an ongoing relationship with the vendor. Some customers will use-but-not-keep-paying, but even then you can think of it as price discrimination, in that it provides a way for customers who need more value (ongoing support and updates) to get it at higher cost, while customer unwilling to pay for the ongoing subscription have a way to pay you for a lesser offering (just the first year, then they are on their own) at a lower cost (i.e. just pay for the first year).
