Whenever a SaaS or Cloud services business develops a new service the questions usually come up “Should we have SLAs”?  “What should the SLAs be”? “What should the penalties be”?

Service Level Agreements are really about developing trust between you, as the service provider, and your customer.   If your prospect or customer does not trust that you will provide the service at a level that solves their business problem they will not buy the service or will not use it to the extent that it could be used.  The trust associated with an SLA is developed when they believe that the financial pain of not providing service at that level provides an incentive to plan ahead and invest the appropriate amount of money in providing the expected service levels.

First, what should the SLAs be?  This of course depends on the type of service but they are almost always associated with availability.  In developing an availability SLA, there are a variety of factors to take into account and ideally you’re in a position to provide better availability than the competition.  SaaS providers generally don’t talk very much about performance and don’t define or guarantee performance levels.  Performance is complex to define and measure which is one of the reasons SaaS providers don’t give an SLA for it.

I have seen many providers discuss SLAs in the context of the financial cost and risk of providing them, what risk and cost can be passed on to suppliers of the underlying infrastructure, and how reliable the infrastructure is.  Although these are part of the question they are only a limited piece of the picture.  Often the application itself is one of the key areas of availability vulnerability along with the strength of disaster recovery plans, security policies and the type of risks that are inherent in the type of application and data.  Balancing all of these things is not purely an engineering or financial exercise but is a management judgement based on the technical information, financial risks, competitive factors and a lot of judgement.

Given that you probably need an SLA for your SaaS service the question is what level and what the penalty should be.  I most commonly see SaaS availability SLAs of 99.5% or better excluding planned maintenance.  IaaS and PaaS SLAs tend to be better than that.  I also generally see SLA penalties to be reactive, meaning that the penalty money must be requested, and that it is not automatically deducted from the service charge.  A good example of a SaaS SLA is Ariba’s SLA and the associated detailed calculations.

It is also true that some major SaaS providers do not have any availability SLAs that they offer to their customers as a standard part of their service.  Salesforce is a good example of this and their view is that their past record shows that their service is reliable and no SLA costs provide as much pain as the negative publicity of a major outage.  Salesforce is one of the few major providers to talk about performance.  They include performance issues on their availability page but don’t define a performance level.  Their philosophy is that we’ll tell you when we think we have a performance problem which is certainly a step in the right direction.

Typically penalties relate to the length of an outage and the number of outages.  Often this is measured in downtime over a given period of a day, week, month or year with the amount of money increasing as the amount of time increases.  You do want to have a cap on the total amount of the SLA penalty.

When thinking about setting up the SLA think about it from the customer’s perspective.  First of all they don’t want any downtime and never want to collect SLA penalties from you.  Unless there are other problems, they aren’t interested in punishing you for SLA violations that aren’t your fault.  They do want you to pay attention to availability and engineer and support the service appropriately.  They want you to have some financial pain to motivate you to improve the service if the availability is not what it should be.

If you keep this customer perspective in mind and don’t make SLAs or penalties overly complex, having SLAs can give the customer additional confidence in your service.

Paul