SLA Building Blocks: The Basics Of A Service Level Agreement
The ability to achieve positive outcomes after IT disruptions (yes, they can improve the relationship between the client and provider!) will hinge on the most important piece of insurance your organization has, the Service Level Agreement, or SLA. Service Level Agreements are contracts that outline how a service is delivered to a client, made popular decades ago in the telecommunications industry. With the rise of cloud-based providers—and the fact that over 90% of businesses use the cloud—the importance of SLAs has multiplied. They are so important because when there are disruptions or failures, a realistic and clear SLA can be the difference for a service provider between keeping a client and losing them; and for the client, it provides the foundation for a trusting relationship regarding a crucial function for their business. A Service Level Agreement is a binding arrangement — usually initiated by the provider — that sets the expectations, timetables, and priorities for services or applications being provided by an IT company to its client, defines acceptable parameters for continuous and efficient provision of these same services or applications, and further provides for some form of SLA Reporting. This agreement requires the provider to measure and meet minimum uptime thresholds and other requirements on a periodic (usually monthly) basis in exchange for a fee. SLA Reporting documents uptime statistics, issues that have been addressed, and other information pertinent to the provision of services or applications, usually online in the form of a dashboard. When constructing an SLA for your client, here are some basic components you should include:
- Statement of intent of the parties involved, i.e. why are we executing this agreement? What are the goals?
- Responsibilities of each party (including expected performance parameters with applicable metrics)
- The duration of the agreement
- A description of the applications and services covered by the agreement
- Procedures for monitoring the service levels and manner and periodicity of SLA Reporting
- A plan and schedule for rectifying disruptions and options for post-incident remediation
- Problem or complaint resolution procedures
- Outline of contract alteration process
Why 9 Is Your Lucky Number
The more 9’s the better… this refers to the “Table of Nines”, a calculus used to determine the accepted measure of your reliability as an IT provider… “uptime”.Typically, uptime (also known as availability) is measured by “Nines”. This measurement is the total expected uptime within a given period of time, calculated out to a specific percentage. You will see in this table that the more “nines” you have, the better. However, maintaining the top level of uptime efficiency is challenging, so setting reasonable expectations and response mechanisms in your SLA is crucial to maintaining something equally as valuable as uptime, and that is trust. Try this calculator to see what your “9X% Factor” is in projected downtime: https://uptime.ly
Putting A Stake Down When The Ground Is Moving
Remember, for many businesses, moving to the Cloud seems to make sense but there are many concerns. Aside from the standard legal considerations such as overall liability, third-party indemnification, and data confidentiality, businesses are very worried about uptime availability and your responsibilities – and their remedies – if your service or application goes down. Understand that your clients may depend on you to facilitate mission-critical processes. If your service or application is unavailable, then you are damaging their business. Since the perception of many businesses is that when you move to the Cloud the risk of an application outage increases, you should then begin to see that your client’s concerns are justifiable.
With an appreciation for your client’s application availability concerns now in mind, you can choose to either ignore them and haggle over contractual details during your SLA negotiation – or you can proactively address their concerns. Ignoring them isn’t a good idea; demonstrating that you understand your client’s concerns and addressing them before your client even needs to ask is the client-focused approach to SLA negotiation. This will get your relationship with your client off on the right foot.
Effective Communication Methods
Well-Defined Service Levels
There are many different ways you can calculate your actual uptime statistics. Be as clear as possible about what service level agreement metrics you use.
Describe how you factor in emergency vs. regular outages, scheduled maintenance, and what application features are critical to your formula. Depending on the service you provide, your minimum uptime guarantee should be relevant to your average client’s need. We recommend that you try to guarantee 99.9% uptime or greater. However, if your Internet hosting provider can’t guarantee more than 99.9%, then you have a problem since you can only be as good as your slowest link. Don’t provide a metric you’ll never meet; this will only result in mismatched expectations and will fuel a lack of trust.
Eliminate Inaccurate Calculations
Getting Started: An SLA Blueprint And Beyond
Now that we have thoroughly addressed the mechanics of SLAs, it’s time to return to that point about communication we made at the beginning of this article. An SLA is not a cure-all…it is not going to protect you or your customers from frustration and disappointment if it does not proactively address concerns about how application downtime is communicated to end-users. Does this then beg the question as to what is a viable and uncomplicated option for communicating this critical information to customers? An application status page provides the communications platform your customers may not even know to ask for during the SLA negotiation phase of the sales process. Application downtime will certainly come up in these negotiations—and given the long timeframe SaaS companies operate on, that is a question of “when” rather than “if” application downtime happens. What may not come up in these conversations however is how application downtime is communicated.
So why should you plan to include an application status page in the service level agreement template you put in front of new customers?
Even though the customer may not think to ask for it, providing a self-service communications tool like an application status page that customers can use to directly access information about the current status of your application, be reminded of the application’s otherwise excellent track record, and elect to automatically receive SMS, Twitter and/or email alerts at the end user-level provides an alternate version of the application downtime story. By including an application status page in your standard service level agreement template, you are letting customers know that not only will your application be up and running > 99% of the time, but also for that unfortunate less than 1% of the time they will not have to wonder what’s going on—the inconvenience of application downtime will not be compounded by a time-consuming, confusing communications process.
Developing a customer-focused SLA that includes the elements mentioned above will set you apart from the competition as a proactive provider, and will help you to establish a more trusting, lasting relationship with your clients.
Remember, your customers are becoming smarter every day, and many of them are learning to never accept the standard SLA, they want their service level agreement best practices.
They know that in most cases the standard SLA is vendor-focused. They know that there is always something better—if they fight. Why make them fight?
Sources: CIO.com, Upwork.com