Much has been written about how software-as-a-service can lower a customer’s total cost of ownership (TCO) by eliminating the high up-front investment and ongoing maintenance costs of in-house software and hardware infrastructure. Most SaaS vendors deliver on this promise with a bargain basement subscription price, putting their faith in the miracle of multi-tenant architecture, and working to build enough volume to make the theory a reality. Meanwhile, they bleed cash.
Multi-tenant architecture simply is not enough. In fact, it can distract you from the real economic challenge of achieving economies-of-scale and driving out costs across the entire value chain. You’ve lowered TCO for your customer, now it’s time to think about lowering Total Cost of Service (TCS) for your business. TCS is the total cost of delivering your service to a customer, and if you expect to run a profitable, cash-positive business it can only happen if your lifetime customer value exceeds TCS.
Life Time Customer Value > Total Cost of Service
Total cost of service is the the mirror image of total cost of ownership. If you think of the value that your customer realizes from your product as resulting from the sum of all the work that you do (TCS) and all the work that your customer does (TCO) from raw idea through product delivery to realized benefit, then it becomes clear that creating a disruptive technology is really about taking costs out of the value chain, regardless of which side of the fence they sit on, because you pass your cost savings on to your customer in the form of lower prices.
The Mirror Image of Total Cost of Ownership : Total Cost of Service
In my recent series on SaaS Sales Tips, I suggest that the margin delivered by the sales operation, or the difference between revenue and fully loaded sales costs, is actually more important to the SaaS vendor than revenue alone. This tip is a special case of the more general objective of lowering TCS. SaaS vendors should look to drive costs out of the value chain and out of their operations across every function, not just through multi-tenant architecture.
SaaS vendors should lower TCS by driving costs out across the value chain
Every business activity should be examined for the potential to apply the following cost-eliminating techniques:
- Standardization
- Mass Customization
- Process Automation (internal and external leveraging the Internet)
- Customer Self-service
Standardization and mass customization are essential to a true multi-tenant SaaS product, but these concepts can be applied to achieve economies-of-scale across the entire value chain. For example, mass customization can be applied to customer acquisition through website personalization and automated nurturing programs that serve up content to prospects based on their history with your company, i.e., if the prospect spent 5 minutes on the widget page, then send that prospect an invite to watch a video on your widget capabilities. Or, apply Internet-based automation to your external support processes by offering a portal, knowledgebase, forums and online chat.
Customer self-service has the double benefit of automating tasks to drive out costs, but also shifting the cost back to the customer. This may sound like bad business, but the truth is that sometimes your customers would simply rather do things themselves, particularly if it means saving money. When was the last time you paid for full service at the gas station? I’m probably dating myself, because I honestly can’t remember the last time I pulled into a gas station that even offered full service. It used to be the standard, but it was eliminated by disruptive technologies for pumping and payment that eliminated and shifted costs within the value chain.
[…] when the SaaS business model scales to hundreds, thousands or even millions of customers. Lower total cost of ownership (TCO) in the SaaS business model arises from the combination of network automation and […]
The bottom line is what it is all about now. The SaaS model provides a company with the potential for savings in many different areas. I never really thought about our end of the equation. Thanks for your thoughts and the comments were helpful too.
[…] Why should this matter to SaaS experts and vendors? Two reasons. First, because most SaaS applications today exist as silos that only solve a piece of a customer’s puzzle. Second, because cloud computing enables new economies of scale through shared infrastructure that properly designed SaaS applications can leverage to further drive down total cost of service. […]
[…] A business model led by direct responsibility for service to end-users […]
Joel
Based on my discussion with a SaaS CEO, I wrote up some ideas on lowering cost of implementation. http://www.prudentcloud.com/saas/reducing-coireducing-coi-12052009/. Depending on the maturity of the implementation services or ease of implementation built into the product it has impact on both TCO and TCS. Would love to hear what you have seen in this area.
[…] of sales (includes sales + service + hosting + support) check this great article by Joel York – SaaS TCO – The Mirror Image of Total Cost of Service Link to this Post<a href="http://www.prudentcloud.com/saas/reducing-coi-12052009/" […]
Hi Rob,
The difference between SaaS and traditional license software is the Internet. With respect to lowering costs, the fundamental difference is the ability to aggregate customers onto a single, tightly integrated infrastructure. Take a look at these related posts…
https://chaotic-flow.com/2008/12/08/saas-model-economics-101a-aggregating-customers-for-low-cost-advantage/
https://chaotic-flow.com/2008/11/12/software-as-a-service-success-build-the-business-into-the-product/
That said, the basic economic principles for lowering TCO/TCS are available to on-premise software, provided it is fundamentally connected via the Internet AND it maintains a single application instance. The best example of this would probably be anti-virus software, which maintains a fat client, constant internet connection, server-based data and a shrink-wrap product image. And, it is routinely sold on a subscription/service basis….but, I would probably argue that these attributes are the fundamental attributes of SaaS and as such so are these applications…regardless of the client-side footprint.
I like the concept of aggregating TCO and TCS as a sound way of looking at a software business model. What I struggle with a little bit is how this is really different in a SaaS environment. Obviously the TCS and TCOs are much lower up-front in a SaaS model, but if you aggregate both out over a 3-year span for example, wouldn’t the same metrics work for on-premises software? And don’t the same economic principals exist regardless of the delivery model for things like support, ongoing upgrades, operations, etc? I openly admit that traditional license software companies don’t think about their businesses in these terms, but my instinct is that is only because it’s what they’re used to. They also rely heavily on ongoing maintenance fees with really high TCO/TCS ratios so perhaps they don’t need to build such efficient models. But if we accept that these metrics do work regardless of delivery model, then David’s objections would still be valid. Especially if customers start realizing they don’t get good value from their 22% maintenance fees, and SaaS erodes maintenance margins for traditional software companies.
Hi David,
Nice comment. It highlights very well the difficulty of identifying and counting hidden costs and shifting costs. The example you give would actually be an increase in costs across the value chain, decreasing TCS at the expense of TCO. The reason to consider both in parallel is to focus on lowering the total economic cost of delivering value (TCS + TCO). When you do this…without degrading and possibly improving service…you create a win-win scenario where the customer gets lower prices and the vendor increases profitability. If you only focus on one or the other, then you can have low prices and unprofitable vendors (the case for many a SaaS startup) or the scenario you describe of opportunistic cost cutting at the expense of your customers…both are bad business and unsustainable.
In the specific example, I would suggest that the issue is more about choosing your application and target customers wisely. A SaaS business that targets customers that prefer live support and offline documentation and has a complex application that entails difficultiy in learning or adoption may not be a great candidate for SaaS in the first place. In this case, I would blame the player…not the game. There are plenty of SaaS startups out there going after inappropriate applications and markets that are better served by managed services or traditional enterprise software.
However, TCO/TCS are “total costs” by definition and cannot miss a hidden cost in and of themselves, as they are merely mathematical constructs. Only, the people who are attempting to measure them can miss or inacurately measure a hidden cost.
Cheers,
JY
The TCO ignores some costs. The TCS ignores the same costs. User-generated support increase the customer’s costs. The problem with these costs is that the accounting system doesn’t capture them. The failures in accurately capturing costs leads to ROI claims that are utterly false. Further, the costs are felt, so CIOs know that something is wrong with the costing and have gone so far as to refuse to see their costs as strategic investments.
Printing manuals cost some fraction of a cent per page. Sending your customer a pdf and then having them print it out costs 25 cents per page. Sure, you save money, but your price isn’t linked to your costs. A user not reading the manual, and calling instead, increases the vendors cost well beyond the cost of a manual. But, yeah, SaaS never had a manual, and doesn’t really provide customer support. Instead, SaaS provides user frustration.
The more that these invisible costs are pushed off on to customers, the harder the product or service becomes to sell.
In reducing your costs, make sure you are not increasing your customer’s costs to use. Operational (use) costs always trump development costs.