<   BLOG
Important General Nuances of SLA for Customers of Software Technical Support Services
26 MAY 2023

Reading time: ~13 min.

In the face of ever-increasing competition, work on the quality of services is an integral part of the service business.

Since it is impossible to imagine any improvements without metrics and agreements regarding these metrics, we come to the idea of SLA. Let’s discuss what it is and why it is actually needed.

In this article:
  • SLA – what is it?
  • What is an SLA for?
  • What is OLA?
  • Difference between SLA and OLA.
  • What is usually in the SLA agreement for software technical support?
  • SLI and SLO.
  • SLA agreement through the eyes of the customer and the IT company.
  • How do you know if the SLA is good enough?
  • How is SLA work built?
  • Advantages of SLA for the customer and contractor.
  • Checklist: important SLA points.

SLA – what is it?

SLA (Service Level Agreement – service level agreement) is an external document (existing between the customer and the contractor) that describes the parameters of the service provided. ‘SLA Compliance’ is equivalent to the service work is going the way that the fact parameters do not go beyond the metric ranges declared in the agreement.

The SLA defines the timing for eliminating arising problems, the speed of response to calls, the availability of the support service, and other parameters.

Our other articles on the topic of software technical support:

What is an SLA for?

In fact, the SLA defines the characteristics of the services provided and shares responsibility for the results between the customer and the performer, and sometimes several performers independent of each other. The document specifies the rights and obligations of the parties.

SLA agreements are actively used where the contractor and the customer of services are autonomous in relation to each other. And although the agreements within the company that are concluded to ensure the SLA are often reminiscent of it, a different term is used for them – OLA.

What is OLA?

What should be in OLA? To fulfill the SLA with an external client, a service company needs to monitor the process of providing services internally – set deadlines for responding to requests, etc. To do this, an OLA gets formed – Operational Level Agreement – an internal document of the company similar to SLA, which defines the areas of responsibility of departments.

The OLA describes exactly how the service is provided – who is responsible for it, according to what rules this responsibility is transferred, what metrics are evaluated, what indicators must be observed. In fact, the OLA determines how individual groups and employees of the service company will interact when providing an external service.

OLA conditions must comply with the SLA or be more stringent in order to act as a guarantee of compliance with the latter, therefore, in order to form an SLA, it is better to first think over the OLA and agree the details with the clients. If a specialist cannot physically get to work in less than 2 hours, the company should not promise the client that it will solve his problem in an hour.

Difference between SLA and OLA

The main difference between SLA and OLA is that the first document describes the interaction with an external client, and the second describes the work of departments within the company.

Moreover, if the SLA speaks the language of the client and the service parameters that are important for him (e.g., we ensure the availability of the service 99.8% of the time), then the OLA plunges into the technical details and details of the interaction between individual departments and specialists (e.g.,: a specialist registers an application within 10 minutes, the engineer responds to it within 2 hours, the developer deals with the solution within 5 hours).

Despite the differences in granularity and bidirectionality (defining requirements for both interacting parties), OLA often refers to as an internal SLA. Thus, we will also use this term.

What is usually in the SLA agreement for software technical support?

The SLA usually contains the description of the service offered and defines the scope of responsibility, limiting the scope of interaction with users to only pre-announced objects or products.

SLAs usually include the following items.

1. General information – about the parties that enter into the agreement.

2. Parameters and boundaries of the services provided:
  • by territory – for example, only in the customer’s office, but not in the home offices of his employees;
  • by equipment;
  • according to the schedule – for example, around the clock;
  • by users – only specified persons or the entire company team can report problems.
3. Criteria that services are rendered properly. These are usually measurable parameters that can be assessed by both the client and the service company itself. You can use one or more options from the list:
  • response time to applications – the time of the first reaction, transfer of the application to a specialized specialist or resolution of the issue;
  • downtime of the client’s business – the maximum time during which the client’s business will be idle due to a breakdown that is in the area of responsibility of the service company;
  • availability of the client’s business – the minimum time  during which the client’s business will function normally.
4. Description of service reporting and claims process.

5. Responsibility of the performer, in particular penalties for violations (if any).

6. How to deal with claims.

7. Also, the SLA usually states under what conditions the service is considered rendered (when the contractor’s responsibility ceases).

To prevent the SLA from becoming a headache for all the interested parties, it is important to indicate realistically achievable service parameters that both parties interpret the same.

We do not recommend specifying too many parameters in the SLA or using any indirect indicators that weakly correlate with the actions of the performer. They just make the job harder.

Choosing the right metrics to monitor, like choosing the right metrics, requires experience and understanding. For example, you can’t mindlessly motivate employees to solve customer problems faster – this will affect the quality of the solution.

SLI and SLO

Separately, it is worth talking about two quantitative indicators.
  • SLI is an indicator that displays user experience. The Service Level Indicator lets you quantify how a service is performing. Typically, SLI is measured as a percentage, ranging from 0 (terrible experience) to 100 (perfect service).
  • SLO (Service Level Objectives) is the SLI target the company is striving for.

SLA agreement

Since the SLA defines the interaction of two parties – the client and the contractor – let’s analyze how the agreement works for each of them.

Through the eyes of the client

SLA agreement. SLA level. As part of the SLA, the customer receives service delivery metrics – a clear description of what exactly he pays for.

It is useful for the client that the deadlines for the execution of requests (incident or for service) are prescribed in the SLA. Of course, any customer wants their issue resolved instantly, but an agreement (especially with several levels of service) perfectly demonstrates that “instantaneous” costs money, and sometimes you can wait several hours to make a solution cheaper. He gets a decent answer to the question: “Why wasn’t my problem solved yesterday?”.

The quality parameters included in the SLA allow you to compare expectations from the service with reality. And besides, the responsibility of the contractor for non-compliance with the declared parameters (up to fines) is important to the customer. SLA, in which responsibility is not spelled out, is just a declaration of intent. And the declared responsibility increases the Customer’s confidence in the service provider.

Through the eyes of an IT service company

From the point of view of the service department or the company, SLA is a set of target metrics that performers strive for. The SLA is actually very helpful because it puts things in order not only in relationships with the client, but also (along the chain) in the business processes of the service IT company itself.

It is important that the company has tools that will allow it to monitor compliance with the SLA and, in case of violation, quickly find the cause or the culprit.


In interaction with the client, the SLA helps to limit the area of responsibility.

How do you know if the SLA is good enough?

A well-designed SLA should give the client control over the service he receives. It is desirable that at the same time the levers of control be clear to him – the clauses of the agreement must be unambiguously interpreted by both the customer and the contractor.

Let’s go through the main items that should be added to the SLA.

Like any official document, SLA should clearly define what is included in the very concept of “service”, who exactly provides it and what it consists of. Therefore, it is worth starting with the definitions of services, roles and special terms. This part should answer the following questions:
  • What service does the performer provide – what, when and where does it do?
  • What are the limitations of the service – geographical, temporal? Let’s assume that software maintenance is performed 24/7/365.
  • Are there any priorities? If, within the framework of the service, some situations should be handled differently, it is necessary to specify what is a normal appeal, and what situation will be considered as urgent.
  • Which division (or several divisions) of the performer is involved, what is his (their) role?
  • What are the functions of the employees of the department? If we mention technical support specialists, we explain that their function is to register a bug and transfer it to a specialized specialist.
The SLA should contain service metrics that are understandable to the client and characterize its quality.

It is important that the performer fully determines the compliance of the service with these metrics (has an influence on them). Here it is worth focusing on specific metrics that determine exactly the provider’s service – for example, the speed of restoring the program after a shutdown.

Metrics must be realistic. SLA is a search for a balance between the interests of a client who wants “yesterday” and a contractor who cannot go faster (or can but to the detriment of other clients).

You don’t need many metrics. A large number of metrics will confuse the performer, he will not be able to properly prioritize his own work, being afraid to go beyond some of the metrics.

If several departments are involved in the provision of a service and you want to prescribe metrics for each, this can be done in OLA by setting only one general parameter in SLA, which will fit the entire sequence of actions. Or set several versions of this metric in the SLA, depending on the connection of new participants to the solution of the problem (relatively speaking, if the problem goes to the third level of support, then the allowable response time increases by a day).

How is SLA work built?

The scheme of work under the prepared agreement is extremely clear:
  • we communicate the parameters of the agreement to all employees of the client;
  • we try to comply with the metrics related to our side;
  • we constantly measure the actual compliance of the parameters with the declared indicators;
  • draw conclusions — optimize processes within the company;
  • we periodically review the SLA, since the ideal agreement, like spherical support in a vacuum, is an unattainable ideal.
Note that it is easier to comply with SLA if the processes in the service company are debugged. Various automation tools help with this.

Advantages of SLA for the customer and contractor

A service level agreement is beneficial to both the customer and the contractor.

Customer:

  • understands the parameters of the service for which it pays;
  • knows how long it will take to fix a particular problem;
  • has the ability to hold the contractor liable for violations of the parameters of the provision of services;
  • may explicitly share responsibility with the service provider.

Executor:

  • sets explicit parameters of the service and can take them into account when distributing responsibilities among its specialists;
  • protected from unreasonable claims from the client;
  • can plan staff expansion depending on the pool of clients;
  • ready to provide several levels of service with different costs;
  • explicitly shares responsibility for incidents with the client.

Checklist: Important SLA Points

When compiling or familiarizing yourself with the SLA, we recommend that you pay attention to the following points:
  • KPIs should be understandable and convenient for the client and allow them to get an idea of the characteristics of the service.
  • Informing about SLA. It is important that the SLA be communicated to all affected users.
  • Monitoring compliance with SLA. SLA compliance control is provided on both sides.
  • SLA review. The agreement must be reviewed regularly as the business of the customer and the contractor is evolving – the main parameters of services can also evolve.

If you have any questions about SLA technical support services for a software product, contact us for a free consultation.

Related Articles