A How-To Guide To SLAs (Service Level Agreements), Best Practices, And Why They Are So Important To Customers
You’ve heard it so many times: Transparent communication is the key to any successful relationship. The banking industry learned this lesson when cyber attacks began to plague their customers, and the official line for many financial institutions was to deny there was a problem. That is until the hacks became so profound and so persistent that it became impossible to cover them up any longer. Eventually, it became obvious that when breaches occurred, clear communication that addressed what was happening and what was being done to mitigate it was the best practice to preserve trust with the customer. Why then, when it comes to IT disruptions, do so many organizations fail to heed this example?
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.
Beyond the basic components listed earlier, here are some key SLA benefits that you should consider addressing:
- Effective Communication Methods – Ensure you have a communications platform in place to effectively alert your clients of service performance issues. This means more than just posting individually to Twitter or Tumblr. If your client’s employees are forced to take time out of their day to call your support staff and wait in a support queue, then they are wasting corporate dollars and they will become frustrated with your organization. Minimally, you should provide application uptime status by having an end-user facing, self-serve status page with the ability to subscribe to SMS, Twitter and e-mail alerts.
- Well-Defined Service Levels – At the most basic level, a decent SLA should define how long it will take for you as the provider to give an initial report of a suspected issue. Sometimes you won’t proactively know that there is a problem unless your end-user submits a ticket. Once this initial response is received, or an issue is reported, you should continue to report how much time has elapsed since the last action took place and ultimately until it is closed. Critical issues should obviously get faster response times and have escalation procedures in place, whereas minor service impairments allow more leeway for less urgent resolution times.
- Uptime Percentages – There are many different ways you can calculate your actual uptime statistics. Be as clear as possible about what 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– To gain an advantage, make your potential clients aware of the inconsistencies existing in your competitor’s agreements. For example, if you count scheduled maintenance and emergency service after a certain amount of time passes — and your competitor doesn’t — their uptime stats will look better. Don’t play that game. You need a balanced approach…if you promise the world but don’t make your metrics, your client will probably leave you; on the other hand, if you don’t maintain a reasonable uptime, you’ll never earn their business. Make sure your client can easily compare apples to apples. In other words, your 99.9% uptime might be higher than a competitor’s 99.98% if they are classifying all emergency downtime as a non-included uptime metric.
- Enforcement –Live by your promise. You may need to provide higher uptimes to more elite clients. Don’t be afraid to charge premiums for this – it is just like insurance. For example, perhaps you perform most of your scheduled maintenance on non-business hours (such as late Sunday) but you have a customer who absolutely needs 24 hours per day without interruption. In today’s world, it’s possible to roll these customers over to temporary virtual environments that will not be affected. If you have any outages that require billing credits, make sure your SLA outlines that distinctly (for example, in red). Even though theoretically each customer can have different uptime metrics (based on their usage and a particular feature set and/or server locations), it should not be the duty of the client to ascertain the billing. As the provider, you will want to address the possibility (however remote you think it is) that you cannot meet some element(s) of the SLA requirements. You might include a clause that spells out the customer’s right to terminate the contract or ask for a refund for losses incurred from a failure of service. Work with your client and be generous if you mess up. It might just save your renewal the next time it comes due.
Create Your Own Status Page
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 < 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.
Sample SLA
Request a sample SLA document.
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 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
