SaaS Marketing Strategy Advisors

To illustrate the dramatic impact of longer customer life on lifetime revenue,  I've calculated the lifetime customer revenue at several publicly-held SaaS companies, using 5-year, 3-year and 1-year renewal multipliers.  As expected, a higher renewal multiplier yields substantially higher revenue.

In last month's newsletter, I wrote about the challenges that face companies trying to offer both a SaaS solution along with an on-premise solution.  My conclusion:  It is possible and sometimes required, but it's certainly challenging.  For the vendor, it's almost like running two separate businesses.

Well, the post was linked to a discussion within the Software as a Service Group on LinkedIn and it stirred up passionate and enlightening commentary.  Opinions, based on a wealth of experience, ranged from "it's do-able and we've proven it" to "it's suicidal." Check it out and weigh in with your own thoughts.

I advise companies marketing and selling SaaS solutions to enterprises that they need to disclose their roadmap to prospective customers. Remember this fundamental precept of SaaS marketing: You're selling a promise, not a product. You need to earn the prospect's confidence that you'll deliver valuable enhancements over the life of the subscription.

Of course, even in the on-premise world, vendors typically need to show their product direction as well. It's doubly important with SaaS solutions.

An analogy from the publishing world illustrates the differences. An on-premise application is like a book. Whatever words and pictures are bound between the covers as you walk out of Borders or open the package from Amazon is what you've bought.

A SaaS solution, by contrast, is more like a magazine or newspaper subscription. As a customer, you're not exactly sure what stories will be covered next week or next month, but you're paying for the publication based on the expectation - the promise -  that it will provide you with valuable content over the life of your subscription.

Any lessons that we can borrow from the publishing world that can help us?

Prepare an "editorial calendar"

Some publications prepare an editorial calendar. They identify the general areas they'll be covering over the coming year. They usually don't provide much detail - a paragraph or two - but enough to convey where they'll be focusing their editorial resources.

SaaS vendors can do something similar. Show the prospective customer the general direction of your solution, and given them a sense of where you're applying your development resources. There's no need to provide many details, especially as you get further out on the calendar. In fact, in an agile development environment, you're not likely to have many details far in advance in any case.

Establish a pattern

A second idea borrowed from publishers is to show your back issues. Let the prospective customer see that you have a history of delivering valuable content quarter after quarter. Show the timeline of product enhancements over the last few years.

One final thought on this topic. Don't obsess over the potential hazards of disclosing your future plans. Some of that deeply-seated caution is a remnant of the on-premise world. When companies introduced products every 18 months and could bring out a new "killer" feature, they could truly steal a march on their competitors.

In the SaaS world, competitors can usually respond much more quickly.  Any particular feature advantage is usually neutralized within a quarter or two.


Moreover, the whole notion of springing a surprise usually doesn't sit well with your large enterprise customers. Think about it. Before the latest enhancements get rolled out to hundreds or thousands of people in their organization, the folks who are responsible need to carefully understand it and prepare for it. They'll expect advance notice, not a surprise.

For people like me who have spent lots of time in the traditional on-premise world before the SaaS world existed, I understand that this reticence about disclosure is a tough habit to break. NDAs and embargoes were all standard fare. Of course, in some cases they're still required. But it might be better to leave much of that behind.

"Try & buy" has been widely used as a marketing technique for SaaS applications, especially consumer applications. The customer signs up for a free trial of some limited duration, gains some experience with the solution, and, if satisfied, subscribes once the trial period expires.

Is this technique appropriate for enterprise applications?  It might be, but companies should think through a couple of issues beforehand.  

For one, in many cases the concerns of enterprise buyers extend well beyond price.  They're just as concerned about issues such as performance, security, and integration.  That's not to say that large companies - with professional procurement departments - won't negotiate aggressively on price, but other equally important concerns will likely factor into the process of purchasing a critical application for enterprise-wide deployment.  

Enterprise buyers may, in fact, be more interested in the "trial" portion, than the "free" bit.  They may want the ability to pilot the application in a "sandbox," configuring and testing it before deploying it widely.  

A second issue to consider is whether the "try & buy" model fits your business model.  "Try & buy" is really part of the broader issue of the cost of customer acquisition.  Can you recover the cost of the acquiring a new customer over the life of the customer's subscription?  If acquiring a customer through "try & buy," or whatever other customer acquisition programs you use, costs $1000 and the customer can be expected to yield $10,000 over the life of the subscription, it may make sense.  If the total subscription value is $800, you'll probably want to rethink your customer acquisition programs.  (Jeff Kaplan of THINKstrategies offers insights into this funding and viability issue as well:  Will the Rising Cost of Sales Cost SaaS Companies VC Funding?)

I fly often enough that I can lip sync the emergency instructions along with the flight attendant, but I still dutifully follow the instructions and look around to locate the exit nearest to me. ("Remember, it may be behind you.") Though I'd hope never to use it, I do get a sense of reassurance that it's there.

Prospective SaaS application customers often need that same reassurance. Yes, they expect that they'll love your application, will gain incalculably valuable benefits from it, and have no plans to ever leave, but just in case....

Enterprise customers for your SaaS application may decide to leave for any number of reasons. After a time, they may determine, for example that the application is too sensitive to be off-premise, it requires extensive customization, or it needs to be more tightly integrated with other systems. A retailer, for example, may decide that their e-commerce application is simply too central to the core of their business to be supported via a SaaS application.

During the evaluation process, in fact, prospective buyers typically won't know which of these reasons, or others, might be a factor down the road. But they do know enough that they should prepare for whatever may come up that would cause them to want to leave the SaaS application.

To reassure these prospects, Marketing and Sales needs to address these concerns during the selling process. Show them the escape chutes. Talk about the "red lights leading to white lights." Do the hand gestures pointing to the exits.

That is, you should promote the "exits" from your SaaS application. Talk about customers' retaining ownership of their own data. Point out your policy related to returning data to the customer. (If you don't have such a policy, that's a separate discussion.) Market whatever other policies, practices, and features that would make it easy for the customer to walk away.

Yes, I recognize there's something counter-intuitive here. You could even say it's downright unnatural for marketing and sales professionals to talk about how easy it is for customers to leave. But think like an enterprise buyer, especially someone new to SaaS applications. Of course, they expect that all will go well, but just in case.... Show them the escape chute and give them the reassurance they need.