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.

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.

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.

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!

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

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.

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.

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.”

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.

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.