Service Level Agreements

Service with a smile.

A clear Service Level Agreement is just as important as the technology when choosing an IT supplier, both as a set of expectations and a way of building relationships
Software as a Service (SaaS) and other Cloud technologies are quickly becoming the de facto delivery platform for practically all business management processes. According to the latest report from analyst firm Gartner, worldwide SaaS revenue will reach $14.5bn this year – an increase on last year’s $12.3bn*.
Organisations of all sizes and across every sector have recognised the benefits of scale, cost efficiency and continuity that SaaS offers. However, like any service, before you choose your provider you need to ensure that they can indeed provide what they promise. And this is where a good Service Level Agreement (SLA) comes in.
An SLA is one of the first steps by which a vendor can – or at least should – begin to build a relationship with a client. It would be foolish to see it as a ‘set of rules’ that the vendor should act by, or demands set down by the client. An SLA is there to protect both parties, with their interests drawn up in a balanced and fair manner.  Yes it is a contract, but it should be a negotiated agreement and not one that is dictated.
Be prepared SLAs in the SaaS sphere matter because vendors do experience unintended downtime. While these unexpected outages are usually solved in a matter of hours they will obviously impact end users. The distributed nature of SaaS can make the reason for an outage difficult to identify; you may operate in the UK but your applications and data could be held anywhere in the world – and if a single domino falls, they could all go.
What to look out for A good SLA covering SaaS provision is not just about uptime – although you do want a contract that guarantees at least 99% + availability.
Here are some areas to consider:

• Assume the worst. If your vendor goes out of business what provision is made to keep your system live? 
• Does the vendor own its own data centres or does it use a partner? If it does use a partner, then ask to see its SLA.
• What data security arrangements has your vendor put in place?
• What are your vendor’s procedures in the case of loss of data?
• Does the SLA cover performance levels, as a slow application will affect your operations?
• Does the SLA cover all global regions? You may be UK based but your customer might access your applications from anywhere. Ensure the SLA covers the regions your data is held, transferred across and consumed.
• How exactly is performance measured; is it speed of data delivery; uptime; response times?
• How do you report a problem; what are your vendor’s support phone numbers, email addresses and ticket procedures; what languages are supported and what hours can the vendor be contacted in? Are its support services local, regional or follow-the-sun?
• Is there a clear differentiation between the time it takes your provider to respond in the case of a problem and the time it takes them to fix it? There should be, as the two are not the same.
• What are the different severity levels your vendor places on an incident? Two hours outage might be considered a low priority to your vendor; it may be high for you.
• Does the SLA cover all the technologies and likely issues across your provider’s entire infrastructure?
• What happens if your provider breaches its SLA?
• Does the SLA cover how you can terminate your contract?
• How do you terminate the contract if you’re unhappy?

Conclusion Primarily, the secret behind a good SLA for a SaaS contract is comprehensiveness.  It needs to cover every reasonable eventuality and be fair on both the customer and vendor. Finally, it needs to be written in clear, jargon-free language, with all acronyms and technologies thoroughly explained. If you can understand it, then you can act on it.
Source * www.eweek.com/c/a/Cloud-Computing/SaaS-Revenue-to-Reach-145-Billion-in-2012-Gartner-567722/