Why set your process SLA today (and how to use it)

Today, we will talk about the SLA (Service Level Agreement). As its name suggests, this contract determines a minimum level of service provided agreed directly with your customer. A common feeling is that SLA is a concept for very large or very mature operations, but the truth is that the sooner you focus on the process and define your SLA, the sooner you will have excellence in your process.

This way, the SLA is represented by one of the most important indicators of the operation and deserves a careful look.

Follow this article and learn how and why to implement the SLA, difficulties and tips that can help you.

Establish your service level, and stick to it

Every operations team must have indicators that determine the current level of service, in the most diverse dimensions: solution time, satisfaction, acceptance level, financial return, throughput, among others. Only then, it will be possible to establish goals and improvement plans, measuring the objectives’ achievements. Process indicators must also represent the delivery of value by your team and factors for the company’s growth.

In other words: you will not professionalize your team and optimize your results if you do not develop ways to measure what is important (and not just “measure”). If you want to learn more about metrics, check out our article.

Today, however, we will talk about something even more essential: meeting the expectation of quality in the service provided.

The Service Level Agreement (SLA) establishes requirements for the service or product generally provided for in the contract, as well as the responsibilities of the parties involved and the consequences of any non-compliance. Likewise, the SLA is also a protection against unrealistic expectations and defines what the customer should expect, allowing the adoption of a work pattern, and avoiding mismatches that can harm both the supplier and the requester.

The SLA in service

For service (or any team in operations that receives demands and requests from external or internal customers), the SLA generally translates into a timeout metric for resolving open calls, or the maximum time from the request in which the question must be resolved.

The SLA must be defined from the client’s perspective and not from the internal capacity of the team so that it is measurable externally. Thus, it will not consider the agent’s working time, or any of the internal steps of the process, as these factors are invisible to the applicant. For example, the deadline for a first response, or the total resolution time, can be considered. There is also a third alternative: the applicant’s waiting time, which is the sum of the waits for each of the agent’s returns during the handling of the call.

The SLA must be defined from the customer’s perspective and not from the internal capacity of the team.

It is possible that the SLA is defined by the ticket category or related to the issue’s criticality (more critical tickets receive less time to complete). The important thing here is that these criteria are clear to your client and team.

How to calculate

Today, many of the task management or helpdesk programs already have some way of calculating the SLA. From the moment the ticket is created, the software is able to compute the time spent in each step of the process. If there is an SLA assignment criterion, the ticket will be given a “due date” and it will now be possible to calculate the “remaining” time until completion or the next necessary action, such as the first response.

Expiration date = Request date + SLA expected time

Time remaining to complete agent ticket or action = Expiration date - Current date

This calculation is automatic and you only need to configure your SLA policy in the program. Depending on your criteria, it may be necessary to screen the ticket (categorization) until the remaining time is viewed.

However, for many companies, this calculation may not be so simple. Firstly, it is impossible to count the passage of time for all your requests without the aid of an appropriate tool. Although it is already the reality of most helpdesk software (support), many operations teams use other software to manage their tasks and the conversions of the indicator may not be as practical (for example, if it is necessary to calculate the “date” due date “manually for each request).

Often, the lead time itself (time elapsed between the beginning and end of a process) replaces the adoption of a metric related to the SLA, despite being different concepts, precisely because it is easier to measure. Nor can we disregard that today, in the reality of many companies, there is not even the collection or checking of this agreement (SLA) by the customer, which further reduces the perception of urgency in its adoption.

So, is it really worth it?

As a company that acts directly in the most diverse realities of the operating team, we can say that yes, the SLA is necessary, possible to be implemented and brings benefits to those who adopt it.

First, despite the fact that many operations teams do not use helpdesk software, some of them relate to the support team and their calls have a life cycle that goes beyond their own team. A possible example here is development teams that interface with and address technical issues that arrive through support. With the process appropriately modelled, it is possible to create stages of responsibility of the developers, integrate the task management tool with the helpdesk tool and thus bring the vision of the SLA. Note that communication here will also benefit, as both teams have unified information.

Even if there is no possibility of integrating your team to another that measures the SLA, there may be a tool that better meets your needs, in addition to allowing the implementation of the metric, or another more creative solution.

As already mentioned, it is essential that internal and external expectations are aligned. A mismatch of standards can lead to a relationship crisis, no matter how much your team is in a position to satisfy the customer.

In addition, you already know that one of the biggest challenges for an autonomous and productive team is prioritizing demands. SLA is an excellent criterion not only to prioritize tasks but also to allocate teams dynamically, providing more resources where it is most needed. This is efficiency.

Likewise, the SLA is also a protection against unrealistic expectations and defines what the customer should expect, allowing the adoption of a work pattern, and avoiding mismatches that can harm both the supplier and the requester.

Finally, once the initial obstacles to the implementation of the SLA policy are overcome, there will be a possibility to further evolve this concept through the SLO (service-level objective). The SLO is an internal metric, a “more aggressive” version of the SLA, a target to be reached by your team, narrowing the deadlines and standards imposed by the SLA and taking the team’s production to a new level. Here, the SLA concept meets that of improvement.

The SLA when well defined and when well lived by the team becomes a great productivity tool, especially when aligned with the value chain of the company as a whole. It is possible to understand more clearly which points of the process need adjustment, as well as to make the operation more fluid and autonomous.

Are you curious about how you can apply SLA concepts in your process? Deskflows has the Leader Guide, a program that helps the operation leader to understand the main levers for improving their process and accompanies the action plan with you! Click here and schedule your first free session now.