KPI technical support Miran

“Did you happen to have such a red-faced person with three eyes and a necklace of skulls?” He asked.
- who dances between fires? BUT? Still so tall? And curves swords waving?
“Maybe there is,” he said politely, “I can't understand who you are talking about.” You know, very common features. Anyone can be. "

Victor Pelevin, "Chapaev and Emptiness"

Hi, Habr! My name is Alexander Solovyov, I lead technical support in the Miran data center.

Some time ago I took part in an interesting MITP dedicated to technical support KPI. In general, it was a useful event in terms of sharing experiences. But still, there was a residue of some “incompleteness”. The reason is, first of all, that the participants of the event shared their experiences, and neither they nor I summarized any generalization or even the results.
')
The event was organized by the SUPNET technical support community, which, judging by the last publication on their official page, dated September 2018, “went to nirvana.”

Therefore, I took the liberty of this article to share my insights and try to summarize what was said then based on my experience.

So, if we consider our technical support as a “black box”, then we can say this: this box performs a useful function, transforming non-formalized requests for support into formalized completed applications. The box has a certain performance, completed applications correspond to a given level of quality, and the operation of the box costs us quite expensive.

In general, this is all that you need to know about KPI technical support, but if the details are interesting - welcome under the cat ... Everyone who I promised to tell you about the knowledge level index is invited.

So, KPIs are divided into three groups:

• Performance indicators reflect the cost-effectiveness of achieving a certain result, for example, the average salary of an engineer.
• Performance indicators are actually a “progress bar”, for example, the percentage of violations of the response time to an application during the reporting period.
• Production indicators are significant indicators of operational activities, for example, the number of calls to technical support for the reporting period.

Performance indicators

I'll start with efficiency.

1. The average salary of a technical support engineer;
   
2. FRT - the average time of the first response to the application;
   
3. ART is the average lead time;
   
4. MTTR is the average repair time.
   

The average salary of an engineer

Since our wages are piecework, the meaning of this indicator is to show the management, in what light, in the words of our general, the PHT of technical support engineers. After commissioning the “balancing” of the payroll through the non-financial motivation of the relevance of the indicator diminished, but in general it is considered today. I will add that the indicator value is calculated for each line of technical support, which allows me to keep my finger on the pulse and, if necessary, adjust the rates of piecework for the next month.

FRT / ART

Both indicators are “growing” from the SLA (Service Level Agreement). Following the SLA, if the FRT / ART is exceeded, the client will have the right to recalculate the amount of payment for the services subjected to degradation. In my opinion, these indices are similar in meaning to the average temperature in the hospital). In practical terms, there are not many benefits from indexes, the only thing is that they allow the company’s management to understand that the indicators stated in the SLA are approximately met. The percentage of irregularities in response time / request execution is much more useful; these indicators make it possible to quickly and visually assess the dynamics of processing applications by technical support.

MTTR

Widely known in narrow circles indicator (aka IRT - incident Resolution Time), the average repair time, in our case, the benefits of the indicator are small because the services provided by our company vary greatly in nature. Maybe in the future we will consider MTTR separately for each product. However, since this is a really famous indicator, we consider it.

Performance indicators

Let's move to performance.

1. EKi - employee knowledge index;
   
2. CSi is the index of customer satisfaction with services;
   
3. FRTR - the percentage of violation of the reaction time to treatment;
   
4. ARTR - the percentage of violation of the execution time of applications.
   

CSi

Customer service satisfaction index is a digitized feedback from the consumer, i.e. customer opinion on the quality of services received. The index is calculated solely on the basis of the client’s subjective assessments that we receive after the completion of each application. CSi is the most important indicator, the most understandable and setting for absolutely everyone. Unlike previous indicators, the calculation method of which is obvious, I will tell you in detail about our CSi calculation method.

The index value depends on three parameters:

1. Reaction time to treatment, t ₁ ;
   
2. Decision time of the application, t ₂ ;
   
3. The quality of the decision of the application, q.

The formula for calculating CSi is as follows:

$$

$$CSi = \ frac {3} {({t_1} ^ {t_1} + {t_2} ^ {t_2} + {q ^ q})}$$

The range of possible values ​​of parameters is given in the table.

The values ​​obtained are interpreted according to the following table.

Eki

The employee knowledge level index shows the compliance of the employees knowledge with the minimum acceptable level acceptable for a technical support engineer. Allows you to stop the empty talk about the incompleteness of engineers to show the company's management how competent and ready-to-work technical support engineers are. The index doesn’t go much for engineers, but it’s good for management and our PR people).

The calculation of the index is made on the basis of objective data obtained as a result of regular testing of the training of engineers' knowledge, carried out according to the methodology of simulation, namely, the solution of typical situations called use cases. To whom it is interesting, in more detail about knowledge management in technical support told on KnowledgeConf 2019 .
In our company, EKi is calculated as the ratio of successfully executed user cases to the total number of user cases for a period.

$$

$$EKi = \ frac {U_w} {U_a}$$

Where,
U _w - the number of successfully resolved by the engineer of user cases during the reporting period;
U _a is the total number of utility cases solved by the engineer for the reporting period.

The values ​​obtained are interpreted according to the following table.

Levels 0.85 and 0.95 were obtained by us experimentally expertly, as a result of more than two years of practice of knowledge management of technical support engineers .

The percentage of violation of the reaction time / run time

Indices are the percentage of disturbed reaction time / runtime I mentioned above. In essence, they show how often technical support violates the SLA in terms of response time and execution time of requests.

Performance Indicators

Well, finally, production figures:

• Number of applications processed by the technical support for the reporting period:
  
  • calls from them;
  • from them messages from the monitoring system;
  • of which rejected;
  • from them client;
• Number of applications related to the operation of the product in the reporting period:
  
  • of which incidents;
  • from them appeals;
  • total time of “denial of service” for all customers by product during the reporting period.

There is a rule that determines the ratio of KPI for evaluating overall performance. According to this rule, indicators should be distributed in proportion 10/80/10 = performance indicators / production indicators / performance indicators.

For this reason, there are many production indicators and I will focus only on the most important ones from my point of view.

Number of calls to technical support

Understandably, the number of calls to technical support is an important indicator that must be taken into account both for organizing work and for reflecting the performance of technical support. Comes in all)

Since appeals are different from appeals, it is reasonable to differentiate the general flow of appeals by the totality of the sources of the appeals and the “essence” of the appeals. In our case, these are monitoring systems, incoming phone calls, erroneous calls, and finally client calls.

Number of applications related to the operation of the product

On the other hand, it makes sense to integrate the treatment of each of our products (services) into groups of the same name. For example, in our case, it is advisable to group calls related to the rental services of computing power and services related to the placement of equipment in the data center in different groups. Good practice when within a treatment group is divided into the total number of calls, the number of “service failures” and the total downtime for the services included in the product.

Conclusion

When it was too late to change significantly. As usual, after writing the article, google KPI technical support, googled a few interesting articles, here are a couple of them:

• What IT Helpdesk KPIs Should You Be Tracking?
• 8 Key help desk metrics and KPIs

I interpreted what I read and did not change anything in my article, because it seems to me more honest and more natural. If desired, the reader can check for himself how much our technical support is “in trend.”

Perhaps the most important thing that I learned from the reading, in our technical support should be added two additional indexes:

1. FCR - the number of applications resolved in the first application for support;
2. FTFR - the percentage of applications resolved in the first application for support.