Reading a Perfect Hosting Service Level Agreement (SLA)

Service Level Agreement is a commitment between a service provider and a client. Particular aspects of the service – quality, availability, responsibilities – are agreed between the service provider and the service user.

The SLA describes the standards of providing the IT-services, establishes the rules and the limits for any service process.

If the company fails to comply with the SLA conditions performing the customer service, then it does not work well. Thus, SLA is a universal tool for assessing the level of service of the business. Providing an SLA tells about the maturity of the company and its readiness to take on a certain responsibility, ensure its compliance and hold liable for any negative consequences.

Only a self-reliant company can ensure the compliance with all procedures at a certain level, in which each step is regulated, and therefore calculated. A formal and pragmatic approach provides confidence not only for the company but also for the clients, as they know exactly what services, which way and in what volumes they will receive. Moreover, knowing how a company enforces its rights in negative circumstances gives customers a sense of safety. And this contributes to a greater confidence while signing the contract.

The SLA content is not regulated, so hosting providers can have different agreements. But there are best industry practices and recommendations by the leaders for a high-quality SLA. We gathered them in one place. Reading the hosting provider SLA make sure it has the following sections.

First of all, the SLA must contain the catalog of Services the company provides to the client. All its terms should be spelled out: geography, terms, restrictions. In addition to the general parameters, each company might have specific conditions.

Customers can have a lot of questions, and all solutions must initially be contained in the SLA. The consumer must clearly understand what he gets for his money.

The hosting provider must inform the client about how it determines the importance of each incident if it occurs, and how it builds its work to eliminate it. This section may include other sections – the Response and the Resolve time.

It is clear that the faster the company reacts, the more attractive it looks to the client. For example, the SLA may say that the company responds to the client's request within an hour, but resolves the problem, say, for twenty-four hours. This is the right approach, which helps clients not to get confused in the definitions of Response time and Resolve time.

In this section, the company sets the exact time for answering the customer's requests or to the incidents. This might be a simple triggered letter letting the client know that the company knows about the request and it won't be lost. The response is also an official confirmation that the company is aware of the issue and it's their responsibility from now on. The only thing for the client left after this response is to wait for a Resolve notification.

Our Response time according to the SLA is 15 minutes or less.

This is the maximum time required to execute the client's task or close the incident. This time depends on the complexity of the problem. It can be solved both for 5 minutes, and for several days. But these terms, as well as the conditions for their changes, should be mentioned in the SLA.

The correct procedure for the actions of the client-oriented company: the company gets a notification or a ticket, it responds to it within a specified time limit and informs that the task will be done within the determined time frame. In this case, the client understands that the message was received and taken to work. After the expiration of the determined period, the client's task must be solved. If the company failed, then it has violated the terms of the SLA and may incur penalties.

In our practice, we managed to solve the Major problems within seconds. At the same time, some Minor errors turned out to be deep code problems. Sometimes the Resolve time needs to be extended in order to provide the quality.

This section should regulate the communication procedure between the client and the company. At its best, it should list the communication channels (email, HelpDesk link, etc.). As the inquiries to the support might not be related to the problems with hosting (like billing) and by this will not fall under the error response/resolve time regulation, this section may specify its own reaction timing. The must-have information for this area is the support for working hours.

We ask our client to create tasks using the HelpDesk as it allows us to track the progress more effectively and have all actions logged in one place. When we need a live dialog we communicate with our clients through messengers or Skype.

Infrastructure is a living organism. It needs maintenance: upgrades, updates, fine tuning and other routine work. Sometimes those works require to stop the server. Therefore, the SLA regulates such works, including the outage time and frequency. Of course, the provider can't predict the release date of the urgent security update of the server software and unexpected outage can happen. It's good to have this case also described in the SLA. The client should know why his website will be unavailable, how often, and whether he will receive a refund.

Before performing the maintenance we analyze the website traffic and find the time when it has the least visitors. Then we inform the website owner about the upcoming outage. If we have to stop the servers due to the emergency maintenance, we send our customers an official report, explaining the reason for the outage.

The more detailed the procedure for imposing penalties is, the safer both the client and the provider will feel. If the conditions are not clear, ask the provider questions before signing the agreement, so that there won't be any surprises and disappointments.

Our clients can get a refund as money return or a balance credit if for some extraordinary reason we fail to comply with the SLA.

If the SLA has all the points described above, then you get a service with transparent guarantees and level of availability. Lie in the SLA is unprofitable for the provider. However, the fraud and deception on the part of the client are also excluded as this document protects both sides, including the hosting provider.

To sum up. A creditable SLA will describe the server and infrastructure availability, the services to be provided with measurable parameters and conditions, the priorities for the incidents or requests, the time for reaction and elimination and the penalties for violation of guaranteed parameters.

Demanding from hosting service provider to amend the SLA towards shortening the Resolve time, extending the guaranteed availability period, or tightening other conditions get ready for a way higher price.

To provide you with exclusive conditions the provider will need to find the exclusive resources like extra personnel, more expensive experts, spare virtual resources. If the provider accepts tickets only Monday to Friday within working hours, that means that it needs to be done this way to maintain the quality and the price balanced. If the client needs 24/7 support via the phone, it will be five times more expensive.

The SLA might also contain the links to the additional resources like policies or agreements. It also has the date of the last update somewhere near the heading, it's good to know that the provider keeps it fresh and updates regularly. The SLA is an instrument for both parties and needs to be used as an instrument – it should be effective, practical, certain and to the point.