There are a bunch of new* ways of selling software these days. SaaS (Software as a Service) has been in the consumer space for a while, and is making significant inroads into the enterprise software space today. If you’re considering purchasing or using software, you should understand what SaaS means and how it is different from the software products of the past.*
*Note: None of these are truly new ideas – time-shares on mainframes, “dumb” terminals (like the IBM 3270, aka “green screen”) remote / shared storage have been around since the 70’s. Application Service Providers (ASP) were big (big flops) in the 1990s. But people have short memories, so “new” is how too many people think about SaaS today.
From The Customer’s Point of View
If you’re selling software as a service, you hopefully don’t need a Foundation Series introduction to SaaS. If you’re considering purchasing software as a service, then maybe you do. This article is not an article about the challenges of product management for a SaaS product, nor is it about multi-tenant architectures and other SaaS implementation details.
This article looks to simply compare, from the customer’s point of view, software purchased as a service versus software purchased as a product.
Software as a Service?
Software as a service, is an interesting name. It implies that instead of purchasing the software, you are purchasing a service – and that service is the ability to use the software. You are also (usually) purchasing a hosting and infrastructure service. The SaaS provider will maintain the hardware, perform upgrades, backup your data (sometimes), and otherwise perform all of the “keep the lights on” services and activities required to keep the software running.
Imagine a typical, 1990’s style software purchase. You buy a source code control system. You set up a server somewhere, and install the software. You have ongoing support costs – providing power to the server, keeping the server cool, applying security and operating system updates to the server. You have costs associating with administering the hardware. You also, when you get updates to the software, and when you purchase upgrades to the software, have to spend money (labor costs) to update the software.
You also carry the risk of a botched upgrade. And you carry the risk of a hardware failure causing downtime, or causing you to lose data. You also have to bear the costs of security – do you allow your people to access the software (on the server) from other computers on your network? Do you allow them to access the software when they are not on the network (travelling, working from home, etc)? You have to invest in designing and maintaining a secure system – to prevent your competitors from stealing – or even worse – destroying your data.
Now imagine that you’re outsourcing all of the “keep the lights on” activities above. You pay an IT services firm to manage the hardware and the software for you, including the security model – and you just use it. That’s one of the benefits of purchasing software as a service. To really grasp the economics of SaaS you have to contrast it with the economics of software license purchases.
Widespread Misunderstanding
There is a widespread misunderstanding about purchasing software. In the last section, we used the word “purchase” but that isn’t actually correct. You don’t purchase a copy of the software – you purchase a license to use the software (with restrictions). You probably have heard the phrase “site license”, which means that you are purchasing the right for everyone in your building (or company) to use the software. Sometimes software is sold in terms of “numbers of seats” – the number of people that are licensed to use the software at any one time. You could have 100 engineers, who all share ten seats (single-seat licenses) of analysis software. Since each engineer only spends about 5% of their time using the software, they can easily share licenses. At any given time, five engineers (on average) will need to use the software. With a license for ten simultaneous users, each engineer is likely to be able to use the software whenever they desire.
The point of these examples is to point out that even when you think (or say) you are purchasing software, you aren’t.
Now that we have that behind us, the idea of purchasing a service is not as different from purchasing a license. In neither case are you purchasing software. In both situations, you are purchasing the right to use the software.
Economics of Software Licensing
There are an infinite number of creative ways to purchase a software license. The most common situation is that you purchase a license, and then later purchase upgrades.
An obvious example is Microsoft Office (productivity software). Microsoft releases a new version of Office every couple of years. If you own the previous version, you can purchase an upgrade for less than the cost of buying the software for the first time. You are not required to purchase an upgrade, but you may want to. If the people you work with all upgrade, you may want to upgrade too – so that you can use the documents that they create. Microsoft does a good job of providing free utilities to read documents from the newer versions, and allowing people with newer versions to create documents that can be used by people with older versions. Microsoft, therefore, gives you a choice. They rely on market forces to create the pressure to upgrade, but you never have to upgrade.
Intuit, makers of Quickbooks (small business accounting software), is a little pushier. They release a new version of the software every year. And you can continue to use your old version. Unless, however, you use one of the services that they also sell. Intuit sells services that integrate with Quickbooks. And at least with some releases, when a new version of Quickbooks comes out, they will stop supporting the integration of those services with older versions of Quickbooks. If you need those services, you must upgrade.
When companies sell software (licenses), they usually sell a version of the software, and then make updates to that software with some frequency, from daily to annually. Companies also manage those updates as two distinct types of updates – major and minor. Minor updates are usually free, and major updates usually require you to purchase an upgrade. Minor updates might be bug fixes, or features that were intended to be in the major release, but were delayed. Or they might just be the introduction of capabilities with “small” value to their customers. A lot of software will automatically notify you, download the update, and install it for you. That’s great service. Major updates are usually more significant – they introduce capabilities that have “large” value to their customers, or are intended to make the product appealing to additional markets.
To understand the economics of software license purchases, you have to look at both the value over time and the costs over time of purchasing a software license.
To keep this simple, we’ll assume the model described above – minor updates happen frequently and are free, and major updates require the purchase of an upgrade to the latest version of the software. We’ll also assume that every new update introduces something valuable to you as a customer.
Starting with the value model for the software, from the software company’s perspective:
The axes represent increasing value (up) versus the passage of time (to the right). Time starts when you purchase a license to use the software. You’re immediately getting value. As minor updates are made (and minor releases are made – sharing the updates with customers), the value gets marginally higher. Whenever a major release (a major update) is made, the value curve jumps up dramatically. This represents the introduction of new, valuable capabilities.
As each new customer purchases a license to the latest version of the software, the company gets more revenue. As each existing customer purchases upgrades to their existing software, the company gets more revenue. A company makes money from finding new customers and from keeping existing customers. Companies make more (per purchase) from finding new customers than from getting existing customers to upgrade. Until a product builds a large base of existing customers, the company’s financial focus will be on finding new customers. Satisfying existing customers is at risk of becoming a secondary priority, purely based on economics. And yes, this is an incomplete picture, there are indeed other factors. But it is absolutely an influence.
Software License Benefits
We started this article with a promise to look at this from a customer’s perspective. If the model above represents how a software company views its products, here’s how a customer would view the same thing. Remember – in our example, we have a perfect product manager – every update has the same perceived value to customers as it does to the company. This chart shows the same value-model, but overlays your purchasing behavior as a customer.
As a customer, you make an initial purchase (the left-most callout), and then get free incremental increases in value from each minor release. You also purchase an upgrade to the latest version of the software as soon as it is available. You then start getting incremental value from the minor updates to that version of the software. The older version does not keep getting updates, so if you don’t purchase the upgrade, you don’t get the benefits of the latest minor releases. A second major release happens, but you don’t purchase it for a short while. Then a minor release is made, with a fix to an annoying bug that really bothers you. So you purchase another upgrade.
The value to you looks like the following:
The green area represents the value you get*. Notice that you did not get the value of the last major release until you actually purchased it. You also did not get the incremental value of minor releases that happened after that release. Once you did purchase the upgrade, you immediately got the benefits of all the minor releases. You got “back in the game.”
*The value is often a function of how much you use the software (enabling the benefit), and as such, it is a function of time. The more you use it, the more value you get. So showing this as an area is informative.
Software License Costs
Your costs over time are also important.
The obvious costs are the checks you write to the software company to pay for the software and for the major upgrades. The chart above can be a little misleading – we are depicting “one time costs” that add up over time. Showing this as a stair-step area instead of a series of spikes will make sense in a moment. The key thing to appreciate is that once you make a purchase, your license purchasing costs do not go up again until you make another purchase.
At the start of the article, we identified several “cost of ownership” costs – supporting the software and hardware, for example. It is critical that you keep those costs in mind when evaluating software license purchases. These costs are ongoing costs – the more you use the software, the more the costs add up.
There are also training costs – the cost of lost productivity as people learn to use the software and adapt to changes in the software.
When you combine these, you get a model for the total cost of purchasing a software license over time. The jargon term for this is Total Cost of Ownership (TCO).
As you can see, “purchasing” software one time actually has a continuously increasing total cost of ownership. Different types of software will have different relative costs for infrastructure support, training expense, and license fees. But generally, training expenses are much lower than the other costs of ownership.
SaaS – A Simple Definition
Software as a service is usually provided as follows:
- A company creates a software product and hosts that product on multiple servers. The company manages the hardware and software – and realizes the cost of that management.
- Customers subscribe to the service – getting the right to use the software, for as long as they continue to pay the recurring subscription fees.
- The company makes both major and minor updates to the software, and the customers automatically get those updates as part of their subscription.
There are many examples, some obvious ones are Salesforce.com, Kadient’s inciteKnowledge, and 37signals’ Basecamp.
SaaS Economics
Software as a service is purchased with the same mechanics as subscribing to a magazine or cable television or satelite radio. You pay a recurring fee for the right to use the software, just as you pay a recurring fee for the right to watch cable television. You might even get a discount for purchasing a longer-term subscription and paying up front. When you want to stop using the service, you stop paying the fee.
The model for creating value with SaaS products is the same as with licensed software.
The graph looks the same as the first one in this article, because it is the same graph. Where things change slightly is in the value model from the perspective of the customer.
There is a single trigger to the realization of value – starting the subscription. You automatically get the minor and major updates “for free” by continuing to pay the subscription fee.
SaaS Costs Are Different
Where software as a service differs from the purchase of a license to use software is on the cost side.
The training costs associated with using software have nothing to do with the mechanism for payment, so those costs are the same. The cost of subscribing to the service (blue cross-hatched region) is new, and goes up over time. It is also typically higher than the training costs. Note that there are no “large purchase” spikes in the costs – because you never purchase a license. And there are no infrastructure costs, because the company that provides the service realizes those costs.
The idea is that this approach is more cost-effective when it comes to infrastructure costs, so the company can pass on those savings to you.
Comparing the two cost models side by side is the way to really see the difference:
Both models have costs that increase over time. For many technical reasons, the SaaS architecture is more efficient and has lower costs for the software company – which tends to result in lower costs for the customers. This is not always the end result, but it is directionally correct.
Another interesting factor to consider is the financial pressure on the SaaS provider. Where a software licensing model creates pressure to prioritize finding new customers, a SaaS model creates pressure to keep existing customers. SaaS providers get the same revenue from a new customer as from an existing customer, instead of the “new vs. upgrade” dynamic seen with software licensing models. It is always cheaper to keep an existing customer than to find a new one. The net result – financial pressure to retain existing customers. This can drive a different behavior, more like that of a retail sales model, where keeping your existing customers is critical.
Conclusion
The SaaS model ultimately provides the same type of products as a software licensing model. But with a better economic model – one that is lower in cost to me, and one that is structurally inclined to keep getting better for me with every new release.
Personally, I really like the idea of purchasing from a company that is financially motivated to keep me happy, not one who’s pressured to find another customer as soon as I’ve written my check.
The best companies try to reinvent themselves and improve their products continuously. Over time, the best companies will move to SaaS models, which align their financials with their objectives.
Check out the index of the Foundation Series posts for other introductory articles.
Excellent article Scott. I’ve linked it from my blog. One area that you didn’t mention is that for most Enterprise-level apps (the Oracle’s, SAPs, etc) or anything w/ site licensing, there is a yearly “maintenance fee,” which in some cases is ~20% of the cost of the license. That fee is required to keep the license supported. So in some ways the pricing is SaaS-y if you amortize the maint fee (at least in the companies I was a part of, maintenance fees were paid from OpEx not CapEx).
To me the customer choice is rent vs. buy. There are some other psychological issues at play w/ SaaS like data lock-in and the fact that people don’t generally like pay-as-you-go; they’d rather pay flat fees even if they come out behind. Also you can continue to use your purchased license as long as you need it w/o add’l cost, vs. the SaaS product that you lose access to when you stop paying.
Scott – nice article! Very cool charts :) A couple points to add.
Another reason that many companies look at SaaS is the fact that they don’t want to invest in a large internal IT group – they don’t consider that to be a core competence. In other words, even if the costs were identical, there are benefits that some firms can realize by not having to deal with a big IT staff.
On the SaaS side of the equation there are potential hidden costs to watch for. The SaaS industry is still maturing, which means that not everyone around today will be here tomorrow. Firms can run into very large problems if their SaaS vendor suddenly goes out of business, or makes a big change to their subscription rates, etc… Firms considering SaaS should definitely do their due diligence before signing a deal.
Paul, thanks very much for the comments and the article. I saw your article before I saw the comments here, and opened up the page to make sure I included a link to your article, SaaS Foundations. It is also linked in the trackback (comment #2), but I wanted to call it out again, since we may get some mainstream readers for this article who aren’t as familiar with blogs and trackbacks. From looking at the real-time stats this morning (thanks, Woopra!), we are definitely getting a higher share of first time readers coming in for this article.
Wow – I completely forgot the maintenance arrangement. I lived in that world for 8 years (working for an ERP software vendor), and the 15% to 20% annual fees were indeed a source of revenue. Unfortunately, I’ve seen that revenue stream have an order of magnitude smaller impact on product management than did the “find new customers” stream. Perhaps I was subliminally discounting it as something that “doesn’t affect behavior.” Great addition, and I should definitely include it in any future discussions of the topic.
Also – the rent vs. buy analogy is ok, and is the one I “grew up with.” To vamp on Brad’s comment, the “equity” you build up in a ‘buying’ scenario is the risk-mitigation of being able to assure access to the software in the future. You may still have a financial liability, but you can assure that the application does not “go away.”
Brad, thanks for the compliment and the great additions. I’d say welcome to Tyner Blain, but I know you’ve been reading here for a long time. I just can’t remember if this is your first comment – either way, thanks!
Excellent point about the risk-mitigation element. An interesting business might be a SaaS-data-escrow service. I’ve worked with a couple customers on large ERP software (licensing) deals, who demanded successfully that the source code for the software they were licensing was escrowed with a third party – should the vendor become insolvent. While escrowing the server-side SaaS software does not make sense, an escrowing of the data with a third party provider does seem pretty compelling. SaaS vendors could provide it as a value-added service to customers who value it.
Does anyone know of a company that provides that service? Surely I didn’t just invent it in a comment on a blog. :) And if no one is doing it yet, and you’re interested in working with me to create it, send me an email. We’ll talk.
Roger Cauvin has also added an article to his blog extending this one, and summarizing some key value props. Thanks Roger! Go check it out (Roger’s article).
Nice intro, Scott!
Risk and business continuity issues deserve more emphasis, I feel. The customer or end-user may not feel there’s much difference between software on their PC, software on in-house servers, software on remote (outsourced) servers and software as a service (although they may detect different performance characteristics). The same applies to data. But as soon as something goes wrong, the differences become apparent. And if you care about your software not working, your business continuity planning had better have taken the different risk profile into account.
These days, many businesses are operationally dependent on their applications software, just as they have long been operationally dependent on their bankers. If whole lines of business depend on software that might, conceivably, disappear without warning, that’s a novel type of risk to mitigate. Most businesses assume that their bankers won’t just stop working, even if they are overwhelmed by some financial crisis (another bank will step in; the “banking system” will keep the wheels turning). If you outsource sofware service provision to a single supplier, you need to consider the risk of your supplier failing, but you’ll generally conclude that the risks are reduced rather than increased, since the supplier has more robust risk-mitigation than you do yourself. But if you effectively outsource each software component separately, as a service, it’s easy to lose sight of the risks and lose control over their mitigation.
Scott,
I like your ideas and as someone who sells SaaS, I would add a couple things.
1. Business people have bought my product as opposed to IT teams. SaaS address a disconnect between the concerns of IT departments and people working in the business.
2. SaaS doesn’t require a capital outlays, it come from operational budgets and is much easier from an accounting perspective. It doesn’t have long term contracts, which greatly benefits the buyer.
3. It keeps vendors and customers much closer. I would like to believe that we will develop configurable software, but for now, we have developed customized software. It benefits our customers, who fortunately for us are very large (10,000+ employees)
Are these some of the things you’ve seen?
Andy
AlanAJ, thanks very much for the great comments, and for being active here (for what, over a year now?)! The change in risk profile is definitely significant, and will need to be managed.
Anecdotally, the recent Gmail failure (where email is “mission critical” for me, and Gmail is Tyner Blain’s SaaS email provider) was pretty inconvenient for a few hours. But it came back – and while I had a loss of service, I did not experience any other costs (including time to focus on fixing it).
A few months ago, a small business client of ours lost their email. They managed their own exchange server, with outsourced IT services. They had to deal with hardware issues, software issues, and a few days of downtime. They “avoided risk” by managing their own application, but Tyner Blain avoided the risk of an expensive and protracted downtime by relying on a SaaS model.
Two different sides of the same coin.
I also have a client that migrated from a self-managed Lotus Notes / Domino email solution to outsourced support of that same infrastructure (which they were not happy with), and then to Gmail as their SaaS email provider.
Thanks again!
Hey Andy, thanks for the comment and welcome to Tyner Blain!
I’ve seen similar dynamics (vendor to business, bypassing IT) as well. I’ve also seen that with packaged software sales (into F500 companies), where the business feels that IT is not agile enough to enable the business to succeed. That introduces some interesting governance problems, and a bunch of “mini IT shops” within pockets of a corporation. Then the pendulum swings the other way, and the company goes back and forth between trying to be agile and trying to reduce ongoing costs.
SaaS presents an interesting opportunity to avoid that problem, although when you customize a SaaS product, you run into the same governance issues. One client I’ve worked with has a massive SaaS vendor, and all of the “customization activity” is managed through a global IT bureaucracy. The client realizes the TCO benefits, maintains some governance, and loses some of the agility that would otherwise be enabled by outsourcing a “best of breed” component of their infrastructure.
You do raise an interesting point about paying for SaaS as a recurring expense versus a capital outlay. I think it depends. I’m too rusty on my tax accounting to know what type of depreciation schedules a company can set up for a long-term SaaS contract, or if they even can. I also wonder if the company would have to track a SaaS vendor relationship as an ongoing liability (like property leases). So at the CFO level, I don’t really know which is better.
Most of the economic buyers I’ve worked with in the enterprise space can make recurring commitments (SaaS) of more significance than packaged-software ‘purchases’ due to the way their budgeting authority is granted. That does make it easier to penetrate an account with a viable solution.
I think you’re spot-on, pragmatically, about being closer to the customers. I don’t know of an enterprise IT team that manages itself as a profit-center instead of as a cost-center. A profit-centric IT group would, in addition to cost-management, would engage tightly with the business to uncover opportunities to improve the business. That IT team would probably be even better to work with (as a SaaS vendor) than working only with the business. Primarily because that IT team would be able to apply a global perspective in how the company can benefit from and integrate with your offering, where an individual business group would be narrow in scope. You could unlock more value for your customers when working with that magical IT team.
A company selling a new license has a high cost of sale. When they sell an upgrade, they have a low cost of sale. This motivates them to retain customers. It does not; however, motivate sales reps to retain customers.
In the TCO, the infrastructural multiple increases without regard to release cycles. The infrastructural multiple washes out ROI claims above 3%. Learning builds at the front of a release and falls at the back of the release. Learning cost extend beyond what shows up on the books. Many of the learning and support costs involve the salary contribution of workers who cannot for the moment be productive. That time represents money lost.
Not all companies selling licenses reduce the commissions on upgrades. When they don’t, they are failing to capture their increasing return. This usually results in higher prices.
Selling licenses and then selling SaaS subscriptions are both necessary over the life of the underlying technology. You sell license until you enter Moore’s late mainstream market, enter a recession, face price-based competition or commoditization, or enter a consumer market.
When you transition from product to service, start by moving license and subscription management–the business transaction functions–online first. Then, move some, but not all features online. Eventually, all your features will be online. Further, the UI for licensed software will be geek facing and feature bloated, while the UI for a SaaS application will remove the feature bloat, use intelligent defaults and other knowledge-based capabilities, and will face the non-geek. SaaS provides the power without necessitating the control that geeks don’t want to do without. This divide may have you maintaining your licensed product while serving your SaaS version.
Hey David, thanks for the comment! I just listened to a good podcast this morning by McKinsey about SaaS that touches on several of these dynamics. I can’t find a link to it online, but you can subscribe to the “McKinsey on High Tech” podcast in iTunes. The episode is “Software as a Service” from Aug 2008.
FWIW, I don’t think the 3% number you cited is universally applicable, although it could definitely apply in some domains.
You’re right that the cost of acquisition is higher for new customers than old customers, but after about 15 years of working with enterprise software companies and with dozens of enterprise software customers, I will tell you this. My perception is that an inordinately higher level of investment is made on new-customer acquisition than on revenue-generating upgrade sales. Many enterprise licensing arrangements include all minor (and occasionally a fixed number of major) upgrades in the initial sale.
I don’t see license sales and then SaaS as serial stages in the lifecycle of products based on a particular technology. I see them as orthogonal business models that can compete in the same market. Different financial considerations may drive companies in one direction or another, and for a given market segment / product space, may make one model incredibly ineffective at competing with the other. The Kindle sells “forever” use of the cellular modem + network as part of buying the product. Why don’t cell phones get sold the same way?
Also – great point about feature-bloat tendencies in licensed products. The McKinsey analyst found 50% to 80% of the features in licensed products were unused, while SaaS providers were able to measure usage more effectively and tailor their offering accordingly. Note that this is really more about online/offline applications, but there is definitely correlation (but not causality) between on/offline applications and SaaS/licensed products.