Is your call very important to us? Or how the prioritization system works in service departments

Hello, dear Reader. Today I will tell you how the prioritization system calls the company's technical support, whose presence in the organization can significantly reduce the response time to the request, properly distribute the limited resources of the service division, quickly and efficiently respond to acute problems of customers, who do not tolerate delay. Features of the system, we consider the real example of our company.

So, imagine a situation that you turned to organization X for a certain service / product. Perhaps, even at the stage of purchase, you had doubts about the reasonableness of choosing a company, but for some reason you still purchased the service / product. As it turned out later - very vain. The quality of the service / product does not meet expectations, a return is not provided, but it is still necessary to make this product work. Exit - support service. But here is bad luck. The support service doesn’t seem to notice your requests for help, do not contact them by phone, as if emails immediately go to spam. Familiar?

What can be the cause of such problems and does this have to do with the inefficient allocation of resources in the service departments and the wrong prioritization of customer requests? I will try to shed light on these questions using the example of the prioritization system of Infowchch JSC.

We will consider the main criteria for raising or lowering the priority of contacting the technical support service, the mechanics of their work, consider the order in which applications for employees and their immediate managers are lined up. To begin, let's find out how the prioritization system for customer calls looks from the inside.
')
The prioritization of calls in the service departments when working with queues often raises questions. The organization must grow to a certain level of maturity in order to begin to give this aspect of service delivery the necessary attention. Of course, the volume of requests must reach that level so that the criteria for prioritization “matured”, and the number of errors due to the “human factor” has increased to unacceptable values ​​(which is easily seen by the growing number of “noisy” customers and escalations from the management), and The economic effect of process automation has become tangible.

Have you ever analyzed how much time employees spend on routinely administering business processes in your unit? I think that even if they had to do this, it was not too often. Meanwhile, routine can take a significant amount of employee time. It cannot be said that it is not important, because it ensures the functioning of the whole mechanism, but at the same time, such work does not bring any measurable result that the management wants to see in the KPI. For example, the technical support service is hardly interested in how much the employee spent time administering applications (i.e., prioritization, filling in service fields and other related twisting of small screws in a large application mechanism in a CRM system). On the control, as a rule, only the number of processed and resolved applications, the results of quality control and CSAT (Customer Satisfaction). Meanwhile, practice shows that it is necessary to deal with this issue:

One or two minutes for an application * number of applications =?
And how much is this a week? And a month? And a year?
And if you multiply this number of hours by the average payroll service department?

Managers always have more important tasks that do not need delay, and investing time in automating part of the routine, and even getting the consent and support of related departments, whose interests this automation affects, is not always possible. To (not) fortunately, in the modern economic model there are crises that encourage companies to work in economy mode and turn their attention to the optimization of monstrous processes wound in fat years. Previously non-urgent task of optimizing and automating processes come to the fore. It happened in our organization.

The economic situation in the country does not contribute to hiring employees for each new task, and the growth crisis in terms of economy creates a unique situation in which the heads of departments have no choice but to revise processes so that the service does not suffer and the payroll does not grow.

So, the goal is to provide the previous level of KPI technical support in the conditions of growing number of requests and restricting the hiring of new employees.

Tasks:

• Simplification and unification of prioritization of requests for technical support engineers;
• Ensuring the correct order of processing applications.

The problem is that there is more work, the number of workers is not growing or is growing too slowly, the priority requirements do not reflect the real situation with a large number of different nuances.

Solutions:

• Control of staff time (in this article will not be considered);
• Improving the skills and productivity of employees (also some other time);
• Reduction of labor costs for routine administration of processes, in particular, the process of prioritizing applications (which will be discussed further).

On average, an employee spends up to one and a half minutes simply to qualify the appeal and assign him the right priority based on a specific set of requirements. This is an indispensable part of the process of handling calls in any contact center that you cannot get rid of under any circumstances. In our case, the one-time priority in the treatment was kept with him throughout the work with the application and was never recalculated in the light of new data. This situation did not require automation, while the head of the department was able to keep in mind all the escalations received from adjacent departments, managed to look through all the open calls and apply "manual control" to the order of processing requests from customers. On small volumes in a team where there is only one manager, this approach is justified and sufficient. But its effectiveness is very limited, not suitable for companies with two or more shifts, and does not exclude the "human factor". There is always a chance to make a mistake, overlook or simply forget about any request, do not promptly inform a colleague from the next shift about any escalation. As a result of such failures, customers tend to suffer, and this is unacceptable. As a result, we made a decision to completely revise the prioritization system of applications for technical support, to exclude the “human factor” as much as possible, to solve the problem of “non-updated” priority indicators in cases.

Due to the fact that the CRM system has been used in the company for a long time, we have already accumulated a decent amount of data both about our customers and about the most typical problems and situations in the organization’s work with the customer, the customer with the product, the product with the customer’s infrastructure, etc. P. Having consulted with colleagues in the workshop and having studied the experience of building similar systems of dynamic prioritization in other companies, we developed our own, corresponding to our realities and fit into our business processes.

It was decided to build a system of priorities in the form of numerical values ​​from 0 to 1, where the highest priority is given to the treatment with a priority value of "1". They must be processed first. Accordingly, the value “0” has the lowest priority and gets into the field of view of a technical support engineer only after processing all the more significant requests. The general scheme is as follows:



As you can see, the existing SLA system and specific sources of receipt of applications were taken as the basis of the priority of the appeal. Our company has three types of technical support contracts that offer customers various SLAs. Each of these contracts received its base number. The same applies to the sources of the application. In this case, the system automatically puts a higher priority when choosing from two basic ones. And then the fun began. Baseline values ​​do not take into account all possible nuances in the work of technical support.

I will give an example:

A very large and incredibly important customer wrote us an e-mail with a proposal to change the icon in the interface. What should we do? Do we urgently need all the efforts to find a careless designer who painted such a disgusting pictogram, make him / her immediately redo everything, approve the layout, strain the technical department and immediately release a hotfix for this customer?

At the same time, a smaller client is experiencing serious difficulties with the product, because of which he actually stopped the business, and sends a request to our support service.
Should we lower the first request in priority and help the second client, though not so large and incredibly important, but whose problem is more acute?

Agree, having in the arsenal only a limited amount of resources, it is impossible to be available on demand at once for all comers. And the vast majority of customers are well aware of this. Even the largest and most important customer will not insist on an immediate resolution of the issue with an ugly pictogram, since this is only a minor inconvenience, and not a real problem that prevents normal operation. Therefore, setting the right priorities in conditions of limited resources is very important. Equally important is the accuracy and simplicity of this mechanism.

Proceeding from this logic, we supplemented the basic prioritization system with certain coefficients that are activated in different situations:




That is, the final formula looks like this:

Basic indicator + floating indicator = Final priority value.
I will try for clarity, to carry out the calculation of the examples given earlier.

For example number 1, the calculation is as follows:

Premium SLA + Presale Escalation + Post-Sale Escalation + Organization Weight * Number of Users Over 10,000 + Problem Severity * Functional Requests + Work Duration = 0.07 + 0 + 0 + 0.03 * 0.38 + 0.56 * 0.02-0 = 0.07 + 0.0114 + 0.0112 = 0.09 As you can see, the final priority indicator is quite low, despite decent input data (Premium support, large client).

For example number 2, the calculation is as follows:

Extended SLA + Presale Escalation + After Sales Escalation + Organization Weight * Number of Users 100 + Problem Severity * Critical Problem + Work Duration = 0.04 + 0 + 0 + 0.03 * 0.03 + 0.56 * 0.42 = 0.04 + 0.0009 + 0.24 = 0.28 Here the situation is reversed. Despite the fact that the organization is not at all large and has a more modest contract for technical support, due to the high level of importance of the problem, the priority of the application exceeds the application from Example 1.

That is, having in its arsenal the entire set of necessary data, the system automatically raised a more critical problem from a small organization over a low-priority one, despite the higher weight of the first customer. The system is able to automatically recalculate the priority of the application in nine different parameters, increase the basic priority indicator with the help of 18 different coefficients, thereby increasing or decreasing the basic priority number. This indicator is not static. It changes when new data appears in the call classification and instantly changes the ranking of requests in the processing queue. This allows us to distribute applications exactly in the order in which they need to be processed.



This is how the line of calls for a technical support engineer now looks. There is no need to find out the priority of the application. Technical support engineers simply process requests from top to bottom in turn.

As you can see, when creating the prioritization system, we tried to take into account all possible nuances arising during processing of the treatment: this is the seriousness of the applicant’s problem, and the SLA, which is fixed in the maintenance contract, various types of escalations and even the duration of work with circulation since its opening in our CRM system. And taking into account the fact that most of these parameters are put down automatically, our engineers no longer spend time administering the priority of the call and can concentrate on studying the customer’s problem and developing solutions, and be in touch with those who urgently need urgent help. Shift managers no longer need to constantly keep in mind the information on all “special” applications and respond to their re-opening in time, and customers can be sure that all their requests will be processed as soon as possible and never disappear from the field of technical support before their full resolution.

The new system is implemented in our CRM and has been functioning since the beginning of December 2016 (week 51). During its pilot operation, we have already noticed a decrease in the number of escalations:



The attentive reader will undoubtedly pay attention to the fact that the current implementation does not take into account the “Backlog”. The thing is that this is the next stage of our automation. As soon as the mechanism for the automatic calculation of Backlog is ready, we will add it to the existing prioritization system and recalculate the coefficients. In the meantime, the "shadowing" of backlog is carried out in manual mode. A separate post will be devoted to the description of the backlog calculation mechanism, after the mechanism is fully ready and implemented.

An article with a detailed description of the mathematical apparatus for calculating the coefficients of the prioritization mechanism described above will also be published soon.

For this, I have everything, I will be glad to talk in the comments.

UPD: Finally, an article of my colleague has been published describing the mathematical apparatus of this prioritization system.