SaaS and SLA - State of the Art

"You can get assent to almost any proposition so long as you are not going to do anything about it." (Chapman, John Jay)

Lately, I have been approached by a number of frustrated CIOs, asking me about what can be expected from a typical SLA in the industry and which provider offers an SLA with some beef.

A Typical SLA
Let’s see what a basic SaaS SLA should look like:
• Service Availability 
• System Response Time 
• Customer Service Response Time 
• Customer Service Availability 
• Service Outage Resolution Time 
• Failover Window For Disaster Recovery 
• Reclaiming Customer Data 
• Maintenance Notification 
• Proactive Service Outage Notification 
• RFO (Reason for Outage) 

Nice. Now let’s see what a typical SLA in the SaaS industry looks like:
• Service Availability 

Is that it? Yeah, that’s about it.  (Sometimes you may find Customer Support response time as well, the Lord be praised). The standard SLA in the industry only discusses ‘uptime’ and even that is usually very iffy, with mostly zero or negligible penalties.

Recently I have been meeting with CXOs of successful SaaS companies and asking them what their SLAs offer. Not surprisingly, their answers were reflective of the typical SLA above. Some did not even offer an SLA and one said, half jokingly, that they (the customers) should  say ‘thank you’ for even having the service available.  When asked about the future of SLA in the industry, the collective answer was that nothing will probably change, customers will not demand better SLOs (Service Level Objectives) and that the whole issue was quite irrelevant. One CEO suggested that the only concern of the CIO is ease of integration.

Is that so? Or are these guys burying their heads in the sand? When I asked about how many dealt with CIOs (as compared to business units), only one said that he did, and that it was an unpleasant experience.

How would you explain this discrepancy between what CIOs want and what SaaS CXOs would offer? And why is the state of SLAs in the industry is so pitiful?

A Quick Historical Review
I think the answers lie in the history of SaaS and how it penetrated the market. Around 12 years ago we started seeing the first SaaS applications (although no one came up with the name until a few years later).  SaaS mostly targeted the SMBs who had no access to the enterprise software that was available to the larger companies. Either from a cost, or complexity or support point of view, the on-premise applications were out of reach for the smaller companies. When they started becoming available over the Web, the SMB were so delighted to even have a solution they were not going to bitch about the service levels being offered in the contracts. They were just happy that the apps were available. So, SaaS companies offered a 99% uptime which seemed pretty good (except that it translated into four days of downtime!).  Nobody could talk about performance, as the dependency on the customers’ own network and on their ISPs allowed the providers an easy escape from accountability.

The Corporate Business Unit
Even though SaaS initially targeted the SMB, the big breakthrough came from the business units that found freedom in circumventing IT and getting their needs answered quickly (and in the process, flipping a bird to IT). The heads of the business units were mostly concerned with features and did not care much about SLAs. Even if they did, they did not have the experience and knowledge, that IT has accumulated over the years, on what to demand, how to verify that their service levels are met, etc.

The New IT Manager
More than ten years have passed with SaaS slowly establishing itself as mainstream, and conquering more and more territories. Old habits die hard and the sad state of SLAs remained where it had been a decade ago. Now, SaaS is finally entering the enterprise through the front door. There is a new generation of CIOs that are not threatened by SaaS and understand the freedom it offers them. They want to get back into the driver’s seat, clean up the mess that a decentralized SaaS policy created and control what is entering their domain.

As for the CIOs with the old-timer’s attitude, the Cloud hype has forced them to pay attention. When the CEOs caught on (hey, we can save a lot of money here) the pressure was on the CIOs to start acquiring Cloud Applications – SaaS. And, like it or not, there are numerous integration issues that demand that IT be in the picture.

Slowly, we are seeing a shift in the market. More and more CIOs and IT managers are in the picture. And when they see the lack of real certification or the famished SLAs offered by the vendors, they are probably baffled, at best, if not furious.

I believe that gradually, as more CIOs enter the picture, the SaaS providers will have to prove themselves as more mature, attentive and accountable vendors.  I think that the IT customers will step-up the pressure and changes will occur. SaaS providers will succumb to provide a serious document with real numbers and repercussions.

In short, the differentiator is no longer the fact that a vendor offers SaaS, nor the feature set, nor the pricing. To distinguish oneself, a SaaS vendor will have to excel in every aspect of the service and provide the assurances for the service levels that CIOs are expecting.