Eight steps to define your company’s SLA

In an article published a few weeks ago, we talked about the concept and calculation of the SLA (Service Level Agreement). However, setting up an SLA-based culture requires your attention to some steps.

Today we will discuss a simple path to optimizing your team through SLA.

Step 1: know your reality

First of all, you need to know what kind of service you provide and what is reasonable for your customer.

There are two reasons that make this step very important:

First, it is very common for many customer service teams to search for other companies benchmarking, mainly with teams operating in the same industry. In most of cases, this is inadequate as the SLA must reflect an expectation of quality from your customer, which is much more related to the particularities of your processes and even the type of customers that you serve.

Only you know your customers’ background and objectivies, and a standard that fits another company can be terrible for yours. Just think like this: the SLA is derived from a contract, which determines responsibilities in case of non-compliance. Do you really want other teams to determine the cases in which your company can be sued?

Second, a key SLA concept:

The SLA should be defined from the customer’s perspective and not the team’s internal capability.

This means that you should not anchor the concept of “reasonable” in what you can deliver (measuring the average resolution time, for example), but rather in a pattern that works for the requester.

Step 2: align internally

Keep in mind that achieving SLA metrics should be a key indicator for your service performance. That is, the idea has to be accepted not only within the department but at the management level. Adopting an SLA-based culture does not make sense if it is isolated within a team.

Many companies, especially software developers, have strong interaction between support agents and developers. If there is no common goal, translated into shared metrics, the relationship between those teams can generate a lot of friction, affecting the level of final delivery.

Step 3: organize some things

It is common for companies to divide their customers into “categories”, for example, by contract value or service provided. It might make sense to adopt more specific metrics for each, as long as they are planned and clear to your customer from the moment of contracting.

In addition, it is very important to be clear about the types and categories of issues handled. The effort and procedures required when responding to a simple question can be very different from a systemic problem (or “bug”). It is unreasonable to think that the customer should expect the same treatment to a simple answer or a complex solution.

A well-categorized SLA is an excellent prioritization criterion in the operation’s routine, and this categorization will also be important for monitoring the queues, or adapting the queues to different SLAs and optimizing your process (see this article).

Step 4: define a Service Level Agreement

A major source of conflict in (almost) every customer service teams is the misalignment of expectations between the customer and internal agents. For this reason, especially in IT companies, all guaranteed characteristics of service provision (not only the support but the hole experience with the brand), such as the availability of the system and support hours, must already be clear when signing the contract.

These definitions are especially sensitive in the transition of the customer journey from sales to operation, since a major disruption in the way of treatment and proximity of communication can damage the relationship with the customer.

It must be clear to the customer how to contact your brand and what kind of support should be expected.

Step 5: translate to customer service

With regard to support, the Service Level Agreement generally defines the maximum resolution time, from the opening of a ticket, or the maximum wait that is acceptable for the first answer.

It is important that both the support team and the customer are aware of possible differences in handling rules between ticket categories, if any. For example: “questions” demands can only have a first answer deadline, while “bugs” can have a total solution time depending on the criticality (recall from step 3).

Step 6: implement in your helpdesk tool

Most task management or helpdesk programs already have some feature to calculate 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 attribution criteria, the ticket will get an “due date” and it will already be possible to calculate the “remaining” time until completion or the next necessary action, such as the first response:

Due date = Request date + Estimated SLA time

Time left for resolution or action = Due date - Current date

Implementing the rules in your helpdesk also allows you to create complex rules, such as the type/category/customer specific rules already discussed.

Note that the software allows working time, idle time or waiting for responses time to be computed. Thus, it is possible to filter what is the agent’s responsibility and draw up more precise action plans (we’ll talk more about this later on).

Step 7: monitor your results

An interesting feature of the SLA is that it can be measured in relation to the “achievement percentage”, or what percentage of your tickets are meeting the SLA rules, divided by process queue, category, or even by customer.

This power of analysis allows you to follow where the process bottlenecks are, or where there is a greater risk of a ticket not meeting the desired quality standard.

Of course, it is desirable that the percentage of not reached SLA is as low as possible. The idea of ​​queuing (or categories) control is to employ efforts where they are most needed, or to identify, in everyday operation, which queues are accumulating demand beyond capacity and thus have a greater risk of non-compliance with the service contract.

Step 8: improve your process

Direct consequences of the last step, action plans can be specific to a queue or a type of ticket. In addition to the daily performance and dinamic team resizing, changes in the process, creation of a knowledge base, documentation of standard procedures, among others, may be necessary in order to improve results.

A consequence of having a history of queue monitoring is the possibility of studying which queue (category) had the highest peaks and the highest history of overload.

Finally, once the initial obstacles to the implementation and refinement of an SLA policy have been overcome, there will be the possibility of evolving this concept even further 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.

Conclusion

The SLA, when properly implemented, brings a huge optimization potential for your team.

As it is related to the categories of requests received and the queues in the process, the SLA is the very translation of the sense of priority in the operational of a team that receives external requests.

Its contractual and performance indicative characteristics make the adoption of the SLA, however, not something trivial. The culture of a service directed to the SLA must become natural to the service team and also a performance parameter for the management.

Achieving SLA, by definition, should be a service key metric in your company, so it’s worth spending some time on a well-done implementation.