Intel stock 21a

Software as a Service (SaaS) vendors have a huge advantage over traditional enterprise software vendors, because they host and process all your user interactions. They not only know how many licences you bought, they know how many you use, how often and even which browser you run. This makes for a huge advantage in marketing and customer support, and it could provide the basis for some powerful information products based on aggregate usage.

Google most obviously uses this SaaS model: It knows what you're searching for, reads your Gmail and knows the timing (and maybe even the content) of your Google Phone calls - all in the name of service of well-targeted advertising. I should know. As a consultant, the only ads that ever show up are ads for my clients. Google's algorithms know I'm very interested in these companies, so they figure I should find out even more about them through their advertising.

As I pointed out more than five years ago, SaaS vendors don't need usability labs or focus groups. They can just monitor how customers use their product in real-time, in real situations. SaaS, like no other business model before, can be instrumented to provide powerful insights into user behavior and market preferences.

In theory, that is. In practice, however, this level of user measurement is typically limited to smaller companies and earlier-stage products. Google is the exception that proves the rule: No "normal" company can afford to instrument its flagship SaaS products to get tons of usable information.

More customers, more computations and more complications

Why? Think Big Data. To make the information from clickstreams useful in understanding user problems, customer preferences and market trends, you must link the individual clicks across a long series of user entries to give the clicks meaning in context. You'd need to subdivide the aggregations by user language, product version, geography and user demographics. You'd need to separate "idiot user" actions from "expert who can't find her way through our mess" actions. You'd need extensive A/B testing.

If a SaaS vendor has 1 million users, then it has 1 billion clicks and 1 trillion analytical permutations. Just the act of collecting a comprehensive data set could affect product performance, let alone storage. I've heard people say they can't find anything off the shelf that can scale up to the task.

That's where Wall Street comes in. It won't be big boosters for all this data collection and digestion; it has no short-term payoff but plenty of short-term costs. In other words, it's poison.

It's conceptually possible for SaaS vendors to lower support costs, facilitate the ultimate user-centric design and have much more effective marketing, but the commercial reality is much more primitive. Many SaaS vendors we've worked with barely have the customer master synchronized between their operational system, their accounting system and their CRM. (Seriously, we've seen our share of SaaS vendors who "sync" this stuff by redundant typing.)

Three steps to finding the needle in SaaS vendor data haystack

It's not like SaaS vendors need to be the NSA. The business case has to be made for each stage of the investment. Luckily, that's not hard.

The first part of the business case has to be operational scalability. The SaaS system must be integrated with the company's operational system for order entry, renewals and accounting. Integration should be bi-directional, but not necessarily a closed-loop or two-phase commit. Cost efficiency and scalability can only take you so far; once the basic integration has taken place, you need to move to revenues.

This is where SaaS vendors really can shine. Every marketer knows that the most profitable revenues come from renewals, even if every sales rep focuses on the bright shiny object of a new customer win. So part two of the business case comes from increasing renewals and detecting "customer health" so problems can be resolved before the contract expires.

At this stage, it's too early to replace customer surveys. The goal is monitoring adoption and customer usage levels. While the exact threshold of "there's trouble here" varies wildly and will have to be discovered by each SaaS vendor, the general idea is to identify the red, yellow and green levels of adoption and usage by category of user. All you have to do is save one or two at-risk customers and you've paid for a decent project.

Once you get the renewal rate above 90 percent, you have to switch gears again in the business case. Part three is upsell revenue - figuring out which customers are most likely to buy more. The general analytical exercise is similar to what you did in part two, but the specific findings and action items will be different. So will the payoffs - upsell revenues are nicely profitable and have the sex appeal that interests the sales folks.

With all of these projects, the focus will be aggregate activity levels, not the excruciating detail of full clickstream analysis. This means it will be both technically and financially tractable, with projects measured in months instead of years.