Cloud / SaaS Service Level Agreement Redux

One of the most popular posts on this blog continues to be my SaaS Service Level Agreement post from last year. I've also published several additional pieces since covering additional SLA best practices - whether you are looking for a cloud computing SLA, cloud SLA, a SaaS SLA or an on-demand SLA.

I thought it would be useful to re-summarize and bring up to date my recommendations both for what people shopping for SaaS or Cloud Computing solutions should be asking for in Service Level Agreements, and what vendors should consider offering in their SaaS and Cloud Computing SLAs.

In my experience, there are four key areas to consider in your SLA:

First is addressing control: The service level agreement must guarantee the quality and performance of operational functions like availability, reliability, performance, maintenance, backup, disaster recovery, etc that used to be under the control of the in-house IT function when the applications were running on-premises and managed by internal IT, but are now under the vendor's control since the applications are running in the cloud and managed by the vendor.

Second is addressing operational risk: The service level agreement should also address perceived risks around security, privacy and data ownership - I say perceived because most SaaS vendors are actually far better at these things than nearly all of their clients are. Guaranteed commitments to undergoing regular SAS70 Type II audits and external security evaluations are also important parts of mitigating operational risk.

Third is addressing business risk: As cloud computing companies become more comfortable with their ability to deliver value and success, more of them will start to include business success guarantees in the SLA - such as guarantees around successful and timely implementations, the quality of technical support, business value received and even to money back guarantees - if a client isn't satisfied, they get their money back. Cloud/SaaS vendor can rationally consider offering business risk guarantees because their track record of successful implementations is typically vastly higher than their enterprise software counterparts.

Last is penalties, rewards and transparency: The service level agreement must have real financial penalties / teeth when an SLA violation occurs. If there isn't any pain for the vendor when they fail to meet their SLA, the SLA doesn't mean anything. Similarly, the buyer should also be willing to pay a reward for extraordinary service level achievements that deliver real benefits - if 100% availability is an important goal for you, consider paying the vendor a bonus when they achieve it. Transparency is also important - the vendor should also maintain a public website with continuous updates as to how the vendor is performing against their SLA, and should publish their SLA and their privacy policies. The best cloud vendors realize that their excellence in operations and their SLAs are real selling points, so they aren't afraid to open their kimonos in public.

These ideas leads to specific SLA terms that I recommend cloud / SaaS buyers discuss with their vendors, and that SaaS / Cloud vendors should consider including in their service level agreements:

Control oriented Service Level Agreement Terms

• 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 a fail over window for disaster recovery SLA in the case of a catastrophic failure of the vendor's infrastructure.

Operational Risk oriented Service Level Agreement Terms

• Ensure that you can get your data back if you ever decide to leave and that it is unambiguous that you own your data.
  
• Ensure that the vendor will assist you in migrating away, for an appropriate professional services fee.
• Ensure that you can retain your data on the vendor's system for an appropriate fee if you ever need to stop using the service but don't want to lose access to your data.
• Review the vendor's privacy policy and make sure that you understand what happens according to the SLA if there is ever a privacy breach.
  
• Ensure that the vendor undertakes annual SAS70 Type II audits, and that the vendor further undergoes annual third party security and penetration testing.
  

Business Risk oriented Service Level Agreement Terms

• 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 criteria for the quality and timeliness of professional services engagements with bonuses for implementations that go better than planned and penalties for those that do not.
• Look for guarantees around proactive communications - look for monthly product feature updates and quarterly roadmap updates and understand how your requests for new features and product changes will be prioritized.
• Ask for money-back guarantees - cloud vendors may be willing to offer you a money-back guarantee, particularly if you are willing to commit to a pre-agreed upon scope of work and criteria for success. If you are comparing multiple vendors this can be a great way to reduce your risk or at least to understand how confident the vendors are that they will meet your needs.

Penalties / Rewards and Transparency oriented Service Level Agreement Terms

• In each of the above sections, ensure that the vendor documents the methodology for measuring performance and calculating penalties and rewards.
  
• Understand whether you will be issued an automatic credit if a failure occurs that impacts you, or must you ask your vendor for a credit to receive one
  
• Understand whether you can you get out of your contract if the vendor continuously and materially fails to meet their SLA
  
• Ensure the vendor guarantees transparency and proactive notification of system availability, production issues, scheduled downtime and pending updates.
  
• Review the vendor's public real-time status website that shows their operational performance. If they don't have one, think about looking for another vendor.
  
• Review the vendor's published service level agreement and understand how it applies to you (and how it compares to this list. If the SLA isn't published on the company website, decide whether that is a red flag to you.
  

The secret sauce behind all of this is that cloud vendors can do all of these things much more cheaply and a lot better than nearly all of their clients can, because can spread the cost of doing all of this well across thousands of clients. The best cloud vendors have figured out that this is both a huge competitive advantage and that it drives significantly value to their clients.

I realize this is a very long post - but I wanted to try to make it comprehensive and I hope that both prospective SaaS / Cloud buyers and vendors find it helpful. At Intacct, we publish our SLA, which we call "Buy with Confidence" as well as our privacy policy and our real-time system status.