KPI Miran Technical Support
““ Do you happen to have such a friend with a red face, three eyes and a necklace of skulls? ”He asked.
“ Who is dancing between the bonfires? And is he still tall? And he waves with saber sabers? ”
“ 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 the Void"
Hello, Habr! My name is Alexander Solovyov, I lead technical support in the Miran data center.
Some time ago I took part in an interesting meeting dedicated to KPI technical support. In general, it was a useful event in terms of sharing experiences. But nevertheless, there remained a precipitate of some “incompleteness”. The reason is, first of all, that the participants of the event shared their experience, and neither I nor they summed up any generalizations or even results.
The event was organized by the SUPNET technical support community which, judging by the latest publication on their official page, dated September 2018, “went into nirvana”.
Therefore, I took the liberty in this article to share my best practices and try to summarize what was said then on the basis of 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 informal support requests into formalized completed applications. The box has a certain performance, completed orders correspond to a given level of quality, and the operation of the box is quite expensive for us.
In general, this is all you need to know about KPI technical support, but if you are interested in the details, welcome to kat ... Everyone is invited there to whom I promised to tell you about the knowledge level index.
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 - in fact, “progress bar”, for example, the percentage of violations of the reaction time to the application for the reporting period.
- Performance indicators - significant indicators of operational activities, for example, the number of requests for technical support for the reporting period.
Performance indicators
I'll start with efficiency.
- The average salary of a technical support engineer;
- FRT - average time of the first response to the application;
- ART - average lead time;
- MTTR is the average repair time.
The average salary of an engineer
Since our wages are piece-rate, the meaning of this indicator is to show management in what light, in the words of our general, is the payroll fund of technical support engineers. After putting into operation the “balancing” of payroll funds through non-financial motivation, the indicator has become less relevant, but in general it is still considered. I will add that the indicator value is calculated for each technical support line, which allows me to keep my finger on the pulse and, if necessary, adjust the rates of piecework wages for the next month.
FRT / ART
Both indicators “grow” from the SLA (Service Level Agreement). Following the SLA, if the FRT / ART is exceeded, the client has the right to recalculate the amount of payment for degraded services. In my opinion, these indices are similar in meaning to the average temperature in a hospital). In practical terms, the benefits of the indices are not many, the only thing is that they allow the company management to understand that the indicators stated in the SLA are approximately fulfilled. Much more useful is the percentage of violations of the response / execution time of the application; these indicators allow you to quickly and clearly evaluate the dynamics of processing applications with technical support.
MTTR
The indicator, widely known in narrow circles (aka IRT - incident Resolution Time), the average repair time, in our case, the use of the indicator is 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 truly famous indicator, we consider it.
Performance indicators
Let's move on to performance.
- EKi - employee knowledge index;
- CSi - customer satisfaction index with service;
- FRTR - percentage of violation of the response time to treatment;
- ARTR - percentage of violation of lead time.
Csi
Customer Satisfaction Index is a digitized customer feedback, i.e. customer opinion on the quality of services received. The calculation of the index is made solely on the basis of the subjective assessments of the client that we receive after completing each application. CSi is the most important indicator, the most understandable and relevant for absolutely everyone. Unlike the previous indicators, the calculation method of which is obvious, I will tell in detail about our CSi calculation method.
The index value depends on three parameters:
- Reaction time to circulation, t 1 ;
- Application decision time, t 2 ;
- The quality of the decision of the application, q.
The formula for calculating CSi is as follows:
The range of possible parameter values is given in the table.
| Parameters | Values |
|---|---|
| 1 - fast; 2 - satisfactory; 3 - slowly; |
| 1 - fast; 2 - satisfactory; 3 - slowly; |
| 1 - good; 2 - satisfactory; 3 - bad; |
The resulting values are interpreted according to the following table.
| CSi value | Conclusion |
|---|---|
| CSi = 1.0 | Customer is fully satisfied with the service. |
| 0.25 ≤ CSi <1.0 | The service is acceptable to the customer. |
| CSi <0.25 | Customer not satisfied with service |
Eki
The employee knowledge level index shows whether employees' knowledge corresponds to the minimum acceptable level acceptable to the technical support engineer. Allows you to
The calculation of the index is based on objective data obtained as a result of a regular check of the training of engineers' knowledge, carried out by the method of simulation modeling, namely the solution of typical situations called user cases. Who cares, I talked more about knowledge management in tech support at KnowledgeConf 2019 .
In our company, EKi is calculated as the ratio of successfully completed user cases to the total number of user cases for the period.
where,
U w is the number of user cases successfully solved by the engineer for the reporting period;
U a - the total number of user cases decided by the engineer for the reporting period.
The resulting values are interpreted according to the following table.
| EKi value | Conclusion |
|---|---|
| EKi> 0.95 | Engineer knowledge is more than adequate to the position |
| 0.85 ≤ EKi ≤ 0.95 | Engineer knowledge is at an acceptable level. |
| EKi <0.85 | Engineer knowledge is not enough |
The levels of 0.85 and 0.95 were obtained by us
Percentage of violation of reaction time / runtime
Indices of the percentage of violation of the reaction time / runtime I mentioned above. In fact, they show how often technical support violates the SLA in terms of reaction time and lead time.
Performance indicators
Well, finally, production indicators:
- the number of applications processed by technical support for the reporting period:
- of which calls;
- of which messages from the monitoring system;
- of which rejected;
- of which are client;
- the number of applications related to the operation of the product in the reporting period:
- of which are incidents;
- of which are appeals;
- The total “denial of service” time for all product customers for the reporting period.
There is a rule determining the KPI ratio for evaluating overall performance. According to this rule, indicators should be distributed in the 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 from my point of view.
Number of technical support calls
Clearly, the number of calls to technical support is an important indicator that must be taken into account both for the organization of work and for reflecting the performance of technical support. It’s for everyone)
Since there are discrepancies in appeals, it makes sense to differentiate the general stream of appeals according to the totality of the sources of appeals and the “essence” of appeals. In our case, these are monitoring systems, incoming phone calls, erroneous calls, and finally client calls.
The number of applications related to the operation of the product
On the other hand, it makes sense to integrate appeals regarding each of our products (services) into the groups of the same name. For example, in our case, it is advisable to group the calls related to the rental services of computing power and services related to the placement of equipment in the data center in different groups. It’s good practice when calls within a group are divided by the total number of calls, the number of “denial of service” and the total downtime for services included in the product.
Conclusion
I comprehended 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 how much our technical support is “in trend”.
Perhaps the main thing that I learned from what I read was that in our technical support we should have two additional indexes:
1. FCR - the number of applications resolved as part of the first request for support;
2. FTFR - percentage of applications resolved as part of the first application for support.