An SLA, or service level agreement, is the most important annex to an IT support contract. It says how quickly the provider will respond, in what time they will solve the problem and what happens when they fail to meet it. Without a specific SLA you are buying a promise, not a service. Below I go through the clauses worth reading carefully before you sign the contract.

Response time is not resolution time

This is the most common misunderstanding. Response time says after how long someone will take up the ticket. Resolution time says when the problem will be solved. These are two different values and they must be separated in the contract.

A response in 15 minutes sounds great, but it means nothing if the resolution has no deadline at all. Check whether the SLA defines both parameters and whether the resolution time is not written down as a vague “we will make every effort”.

Priorities and ticket classification

Not every ticket is equally urgent. A good SLA divides matters into categories and assigns them different times. A typical split looks like this:

  • Critical. The failure blocks the work of the whole company or a key system. The shortest response and resolution times.
  • High. The problem affects part of the team or an important function, but the company still works.
  • Normal. A single workstation, an annoying but not blocking matter.
  • Low. Requests, changes, minor configurations.

Check who decides the priority. If it is solely the provider, they may understate the weight of tickets to fit the times more easily. It is best when the classification is described objectively.

Service windows and support hours

Establish the hours during which the SLA applies. The standard in the SME sector is usually 8:00 to 18:00 on business days. If you work shifts, at weekends, or have systems that must run after hours, ask about extended-mode support and how it is billed.

Separately, check the service windows, that is the scheduled breaks for updates. They should be announced in advance and fall outside your peak hours.

Contractual penalties, the credibility test

This is the simplest way to check whether the provider believes their own declarations. If the SLA provides for credits or penalties for missing the times, it means the company takes the risk on itself. If there are no such clauses, the declared times are only a wish.

I always ask the provider one question: what will I get if you do not meet these times. If the answer is murky or comes down to an apology, the whole SLA is only decoration in the offer.

Penalties do not have to be draconian. It is enough that they are real, for example a reduction of the subscription for a month in which the provider did not meet the agreement.

Scope, what the SLA covers at all

It happens that great-looking times apply only to a narrow slice of the services. Check what the SLA covers:

  • Which systems and devices are covered by the time guarantees.
  • What is included in the subscription and what is billed separately.
  • Whether support covers hardware, software and cloud services, or only selected elements.
  • How the time is counted when the problem lies with an external provider, for example the internet operator.

Reporting and escalation

The contract should specify how you will check whether the SLA is being met. Without reports you rely on the provider’s word. It is good when you receive a periodic summary of tickets with response and resolution times.

Also establish the escalation path. Who is the emergency contact, how to reach a decision-maker when the first line cannot handle the problem. In a crisis minutes count, not searching for a phone number.

Exclusions, what the SLA does not cover

Just as important as what the SLA guarantees is what has been excluded from it. Every contract has exceptions and it is worth knowing them before they become an unpleasant surprise on the day of a failure.

Typical exclusions are:

  • Failures on the side of external providers, for example the internet operator or the cloud provider.
  • Problems resulting from changes you made without the provider’s knowledge.
  • Hardware without manufacturer support or software past its end of support.
  • Force majeure events, such as flooding or a fire in the server room.

Exclusions in themselves are normal. The point is for them to be clearly described and for you to know where the provider’s responsibility ends and your own risk begins, which is worth covering for example with a good recovery plan.

Points to check before signing

Before you accept the SLA, go through this short list:

  • Response time and resolution time are separated and given numerically.
  • Tickets have clear priority categories.
  • Support hours match how you work.
  • There are credits or penalties for missing the times.
  • It is clear exactly what is covered and what is paid separately.
  • You receive reports and have a described escalation path.

If any of these points is unclear, ask for clarification in writing. A serious provider has no problem with this, because they operate by these rules themselves.

A well written SLA is not bureaucracy, it is your safeguard for a difficult day. In our managed IT services we treat it as the foundation of the cooperation, not an annex for formality’s sake, and we will gladly go through every clause with you before you sign anything. If you want someone to take a look at an SLA you have just received to sign, get in touch. Our IT helpdesk team works with such contracts every day and will quickly point out the weak spots.