Organization of control over the observance of response time to customer calls in the service department

The time has come to talk about how our company monitors compliance with the SLA (Service Level Agreement - in the broad sense, this agreement to provide technical support, including the response time to a request) in customer requests for technical support, what tools are created to comply with it and What place did this parameter take in our system of prioritizing calls described in my previous article “Your call is very important to us? Or how the prioritization system works in service departments . ”

Some of the material will seem trivial, especially to professionals from large call centers, but for specialists of small and medium-sized organizations, where the processes of providing the service are just beginning to “mature”, the material will be useful.


It may seem that the calculation of the backlog rate (eng. Backlog is the accumulated deferred work), which is designed to track the response time to a call, is a rather trivial thing that does not require much effort. In fact, what is there to count? From the reaction time at the moment we subtract the time of creation / re-opening of the circulation, express the result in hours or minutes and display in each open application - the backlog is ready. The greater the value, the longer the customer waits for a response, therefore, the higher the priority of his appeal. But this state of affairs persists until the organization has several customer support groups with different SLAs processed by the same team of specialists. In this situation, it will be wrong to consider one backlog at all, to express it in hours or minutes, it will be wrong to use this indicator to determine the priority in working with references. After all, we pledge to respond to one group of customers within an hour, another - within two hours, the third within eight hours, and the fourth group is generally ready to wait a day.
')
This suggests the option of distinguishing requests from different groups of customers to different queues and assigning each of them to an individual specialist / team. Yes, perhaps this is an ideal option, but often it is not achievable, especially in small organizations or in conditions of limited resources, where one person / team is involved at once with all groups of customers. Jumping over queues of requests and trying to understand which one of them is the backbone of a specific message more powerful than the others is a dubious pleasure. We will talk further about how to stop worrying about backlog and start living.

So, given:

• One team of technical support and customer service, supporting all categories of customers and all categories of requests.
• Five customer groups with different SLAs.
• SalesForce CRM system.

It is necessary:

Create a time-sensitive reaction of a single system for calculating and displaying the backlog of calls to technical support, prescribed in the SLA assigned to the contracting authority or type of call. As noted above, back-to-head computing is no longer applicable in this situation. Therefore, it was decided to use for its display not the absolute values ​​of time, but a relative value, let's call it conditionally Bucket (basket).

For each group of customers, one such Bucket is equal to the response time interval set in SLA, that is, 1, 2, 8, 12, 24 hours expressed in minutes. To automate the correct calculation of backlog for each group of customers in the CRM system, a special rule was created, which, depending on the type of agreement for technical support of the organization, assigned requests from employees of this organization a certain value of Bucket.



Here, however, it should be noted that, despite the fact that Company X has a service contract for the product with a clear indication of the response time for service requests, not all types of requests from employees of this company are assigned the same Bucket value. For applications that are not related to maintenance, there is a separate SLA, and such applications are assigned a special Bucket, based on another rule, which is triggered when the treatment is classified as a “non-technical request”.

Here we are talking about the various wishes for the implementation of new functions and other requests that are not related to the technical difficulties of using products. As you understand, this is done so that, as a matter of priority, the technical support team serves applications with real technical problems that prevent our customers from working with the product.
Thus, the final backlog calculation formula is as follows:

(XY) / Z

Where:

X is the current time,
Y - time of creation / reopening of the application,
Z - Bucket assigned to the application on the basis of its classification or organization SLA.

The resulting value is presented as a number, rounded to the thousandth. This is the relative backlog indicator, which allows us to determine the implementation of SLA in each specific application, without looking into the service agreement of each organization:



Consequently, any treatment in which the backlog value is less than one is processed in the normal mode, since the SLA in this case is not violated. But if this value exceeds one, the application automatically begins to rise in priority. The higher the backlog value, the higher the priority of the application.

As you guessed, we included the backlog parameter in our general system of prioritization described in the article of my colleague - “Simple mathematics for solving difficult problems” , and our engineers and technical support managers do not need to manually monitor this parameter. It automatically affects the overall priority indicator of the application according to the established weight in the overall prioritization system. That's all I have, I will be glad to talk in the comments and answer questions.