Finding the secret sauce for a profitable SaaS business model

It is my understanding that the point of running a software or services business is to make money. But very few companies have done so yet in the SaaS space. Several recent articles have taken note of this “missing” profitability and pointed to the the costs of doing business using the Software as a Service (SaaS) model.

In SaaS and the Elusive Path to Profitability, the author looks at financial reports from some of the major SaaS players such as salesforce.com, RightNow Technologies, and NetSuite. He notes that these SaaS companies are pouring resources into sales and marketing and losing the battle for profitability. He speculates that they are essentially following a loss-leader strategy - lose money acquiring new business in hopes of becoming profitable over the life of the customer relationship through long-term subscriptions or up-sell.

Oracle’s Larry Ellison also recently dissed the SaaS industry with his now infamous quote “it’s hard to point to any Software-as-a-Service provider that’s doing a good job of improving its profitability.”

Admittedly, SaaS is still at a relatively early stage of market development and acceptance, and these big industry players have spent a lot of resources educating a market about a paradigm shift. But relying on long-term customer retention or up-sell to make a profit some time in the distant future seems a fragile strategy at best. On top of this, SaaS companies must contend with accelerating competition as more companies jump on the SaaS bandwagon.

Given these concerns, it is reasonable to ask: for businesses that are providing SaaS solutions to enterprises and SMBs, how can they be profitable?  What is the secret sauce?

In a previous post I described a measure for SaaS profitability using a simple (and obvious) equation:

Average cost structure per customer

However many SaaS companies seem to ignore this equation - throttling for maximum growth not maximum profitability. They build the core SaaS application well enough, but they conduct sales, marketing, and support using the same resources as they would with traditional on-premise applications (e.g. direct marketing, print ads, sales staff and SEs visiting companies, trade shows, etc). Sales do scale with these efforts, but so do the costs and expenses.

One of the often-promoted virtues/goals of SaaS is to achieve economies of scale so that the cost of acquiring and supporting 100 customers is just marginally higher than for 1 customer. Depending on your hosting solution, you can typically meet this scalability goal for the hardware and software infrastructures costs. But this is where most SaaS consultants or service providers stop.  It is the cost of human resources - the staffing - that does not scale well.

Since staffing is typically the most expensive item in any budget, incorporate automation and self-service at every possible point in the SaaS application that would otherwise require a team to handle.

While you can’t and don’t want to replace all human interaction, you can identify all of the points in a SaaS application where support staff would traditionally need to interact with the customer (e.g. early sales, marketing, demos, provisioning, configuration, billing, monitoring, renewals, etc). Then evaluate which of these “touch-points” can be handled as part of the SaaS application design. Where possible, let the technology (automation) or enable the customer (self-service) to do the tasks that would otherwise require support staff to handle.

This is the secret sauce for SaaS - design the application so that it can scale incrementally up to very large numbers without adding additional sales, support or back-end staff. This approach should be a key component of your strategic blueprint. Model the work flows, high value scenarios, and application touch-points and then design the SaaS application to incorporate and then take over selected services that would otherwise be handled by marketing, sales and support staff.

My post is already way to long, so I will stop here.  But in a future series of posts I will take a prototypical SaaS application, examine several phases in the customer life cycle that are traditionally a source of non-scalable costs, and then give examples as to how these services can be incorporated into the SaaS application and become scalable.