SaaS Service Level Agreement 2.0

June 2009 update- You can find an updated version of this post here...

This week I attended IBM's "Accelerating Business Value" conference at their amazing Palisades conference center near Armonk NY. It was good to hear very senior IBM executives singing the praises of SaaS and talking about their plans for cloud computing. It was also a nice opportunity to catch up with SaaS pundits old and new like Bill McNee from Saugatuck, Amy Wohl, Judith Hurwitz, Frank Gens from IDC and Ken Boasso from Keychain Logic.

My favorite presentation was from Ken Harris, the CIO of Shaklee and former CIO from Gap, Nike, and Pepsi. The topic was "Creating Successful SaaS Relationships, Lessons from a CIO" but the session was really more about how to negotiate contracts and what to look for in Service Level Agreements with SaaS vendors, most of which I thought was good advice. Ken currently has ten SaaS applications deployed at Shaklee so he's got some good experience here.

Ken started out by talking about why all CIOs should love SaaS vs. on-premises software - lower cost to start, faster time to value, better initial and ongoing functionality, lower cost for maintenance and easy initial and ongoing integration. He's clearly a convert to SaaS and had great stories about the same project taking him 18 months and costing low seven figures in the old on-premises software days vs. 120 days and low six figures with SaaS today.

Ken also dove into what he sees are the CIO's concerns around SaaS, which unsurprisingly were almost all control related - Loss of control over operations, loss of control over security/privacy, and loss of control over the software if the vendor is acquired or goes out of business.

Ken said he believed that security and privacy was really a red herring - that SaaS applications are actually far better than almost any CIO can deliver, but no CIO would ever admit that to his CEO and it's an easy objection to raise if a CIO really doesn't want SaaS, which I thought was good and honest insight. In fact this was an undercurrent of much of Ken's presentation - that many CIO's know that SaaS vendors run their operations a lot better than nearly every in-house IT department but CIO's are loathe to admit this because it can reflect badly on them with their boss, the CEO.

The meat of the presentation was a framework Ken has developed for negotiating Service Level Agreements with his SaaS vendors. Most SaaS vendors either offer no SLAs, or only an SLA around system availability, and there isn't always a penalty if the availability goals are not met.

Ken's recommendations for SaaS SLAs were:

• Establish a system availability SLA, based on average monthly availability, with bonuses for overachieving and increasingly steep penalties for downtime beyond the agreed level.
• Establish a system response time SLA, based on average monthly response time, with penalties for slow system performance.
• Establish an error resolution time SLA, with different windows for different severity levels (system down vs. workaround) and again with penalties for not being responsive.
• Establish a fail over window for disaster recovery SLA in the case of a catastrophic failure of the vendor's infrastructure.
  
• Ensure that you can get your data back if you ever decide to leave, and that the vendor will assist you in migrating away, for an appropriate professional services fee.
  

All of this seemed quite reasonable to me, and in fact Intacct already offers every one of these terms in our standard "Buy with Confidence" agreement except for an SLA around response time - and this just might be the catalyst to add it to our program since our operations team already measures and manages response time and it's pretty good.

In addition to all of these items, Intacct also guarantees a bit more with SLAs for:

• The quality and timeliness of professional services engagements
• Proactive notification of system availability and roadmap changes
  
• Proactive communication with monthly product updates and quarterly roadmap updates

At Intacct we also measure our customer satisfaction - every quarter we survey our customers, and we base the compensation for every one of our employees based on how our customers answer the question "Would you recommend Intacct to your friends?"

So what didn't I agree with? Ken said he asks his SaaS vendors, for an extra fee, to offer a private, non-shared instance of the product just for Shaklee's use. It wasn't clear if he always asks for this, or always gets it, but he did spend quite a bit of time talking about it. To me this is a slippery slope away from multi-tenancy and all of the shared infrastructure and shared operating benefits that come along with it that make the SaaS model so efficient. It will be interesting to see if this model starts to become more common as SaaS scales up to the enterprise.

What I liked about Ken's presentation was seeing inside the CIO's thought process - since Ken knows he's giving up some control to the SaaS vendor, he expects that the SaaS vendor will make up for this by guaranteeing performance in those areas that he could have controlled if he had been running the same applications in house. He also recognizes that the SaaS vendors almost always do this better and more cost effectively than he could do it himself, so he uses this as a tool to reduce his risk and establish shared performance goals rather than as a club to beat the vendor up.

As I've said here many times before, the reason I think SaaS is going to win is because it forces both the client and the vendor to be goal aligned, and thinking about what should be in a SaaS SLA from the CIO's perspective is a great way to help achieve that alignment.