As I measured the quality of technical support work

And what came of it, and what did not ...

Shot from the series “The IT Crowd (Computer scientists)”

What does technical support do and how effectively does it work? - the farther in my work I moved away from the technical support tasks, the more I was worried about this issue, until in 2013 I finally realized that I had no idea what these “idlers” were doing. No, I did not doubt that the guys in technical support responsibly treat their work (and this was confirmed by customer reviews), but whether the quality of our services improves with time or decreases, what tasks arise in technical support and in what quantities, who do the lion’s share of work - I did not understand. This article is devoted to my attempts to understand the situation in technical support. But first, a little insight into the history:

How the quality of technical support work is measured in the world, and why this method did not suit me

The problem I encountered is not new. Thirty years ago, the British asked the same question - “and what, in fact, do IT people in government institutions, and do you need so many of them?”. The British approached this issue fundamentally and conducted a study, the result of which became 30 (thirty) volumes of recommendations on the organization of effective work of the IT service and methods of monitoring its work. Over time, these recommendations decreased to 5 volumes and became world famous under the name “ITIL methodology”. The whole essence of the methodology comes down to assigning a narrow area of ​​responsibility to specialists: dispatchers register applications, there is a first, second, third line of technical support, incident managers, problem managers, change managers, configuration managers, and so on - the list of different roles can be continued. Such a narrow cut into roles, on the one hand, limited the tasks of an individual specialist (and thus simplified his work and increased personal productivity), and on the other, made it impossible for the IT department to work without connecting the entire role of an accounting system through which some experts the pipeline could transfer the task to others. It is the need to use the accounting system (which the British called the proud word ServiceDesk) and helps to monitor the employment of specialists and measure various performance metrics for the entire IT department in general and individual employees in particular.

The method proposed by the British thirty years ago has the only drawback - it aims specialists to perform their working procedures, and not to solve customer problems. Globally, the methodology is process-oriented, not customer-oriented, and Arkady Raikin described the lack of methods of labor organization proposed in it in his miniature “ who made the costume? ". For example, according to the ITIL method, the user cannot contact the experts directly, but must first go through the dispatcher, who will register his appeal in the system, pass it on to the specialist and will control further execution. This complication contains reasonable grain - if the registration of applications is to be passed on to the technical specialists themselves, then part of the appeals will simply not be registered, because this ritual is by and large not needed either by users or technical specialists.
')
In principle, all the shortcomings of the ITIL methodology are not as such if you have enough money to contain a staff of dispatchers, managers and, directly, technical support specialists, as well as if you are sure that your users will not get away from you. But I have a small IT outsourcing company, and all technical support is 10 specialists. Keeping dedicated dispatchers for us (not to mention the managers) is an unaffordable luxury. In addition, our clients are used to receiving an immediate and competent answer to their questions. If I obliged our users, when calling technical support, to humbly wait for the dispatcher's response so that he would first register the application and then hand it over to a specialist, then I could lose a good half of the clients within six months. Therefore, the only thing left for me to do is to encourage technical support specialists to independently keep records of all calls to them without exception, which I tried to do:

My first unsuccessful attempt to measure something, tip

It is worth saying that in 2013 my company already had a system for recording technical support tasks (hereinafter referred to as ServiceDesk). True, it was used nominally - written appeals from users were automatically registered in it, and regulatory and preventive tasks were created, but applications received by telephone were rarely received, especially if they were resolved within a single call. In addition, the culture of working with the system itself suffered - for months (and sometimes years), the applications that had already been completed did not close, and there was no talk about updating the current task statuses. In the form in which the system worked in 2013, it was simply not possible to measure anything in it.

The first thing that came to mind in terms of encouraging specialists to register and close applications in ServiceDesk is to pay specialists a bonus for each registered and closed application. But this approach, obviously, implicitly motivates specialists to create as many reasons as possible for users to contact technical support, while it is much more appropriate to encourage specialists to work so that users have no reason to contact technical support. For this reason, I decided to make the bonus fund a fixed monthly amount that does not depend on the number of applications. It was assumed that a fixed amount would be divided among all technical support staff based on the proportion of registered and completed applications by each of the specialists. That is, if within a month each specialist registered and executed one application, then all experts share the bonus fund equally. It was assumed that one completed application will be equal to two registered applications within these proportions.

By the applications I made the first bonus fund symbolic - 10 000 rubles / month. So that the guys do not treat this as some kind of bonus system, which determines the priorities in their work, I called this system “socialist competition” and in May 2013 sent the following letter to everyone:

“Guys, we are slowly but surely moving towards developing a system of rewards and motivation.

The purpose of the motivation system for the company is to increase internal efficiency. The goal of the motivation system for each of you is to get an opportunity to objectively evaluate your contribution to the company and give you the opportunity to earn more by doing more and making higher quality.
I understand that assessing the amount of work done in our area is a thankless task. For this reason (in order not to punish the innocent and not to reward the uncomplicated), first I want to objectively understand the current load and conduct analytics on all customers, tasks assigned to them, current customer satisfaction and causes of uneven work volumes.

For these purposes, we have a small “socialist” competition with a prize of 10,000 rubles, which will be divided among all participants of the competition on the basis of the following principles: one registered application - 5 points, one closed application - 10 points. The rate of a point is defined as a prize amount divided by the sum of all points for all applications registered and closed for the month. For example, if 900 applications were closed in a month and 200 applications were registered, then the course rate is 1 ruble, the cost of one registered application is 5 rubles, and one closed application is 10 rubles.

Accordingly, it is in your interest to register (and close) as many applications as possible in the month of June. You went to the client's office, you were asked 3 questions, you answered them - registered 3 applications, closed them and earned 45 points in social competition, which will then be converted into rubles. Please register any squeak of users - so that in the future we will be able to make a complete bonus system, we need to see all the tasks arising right now. ”

The result of the first month of "socialist competition" was ... drumming ... nothing. The specialists did not change anything at all - the guys did not register more applications, snatch applications from each other, fight for the speedy closing of applications to do more. Everyone worked, as they used to work, and when they gave out funny applications for the applications, but no extra money was raised on any of the guys, and a tear of tenderness did not roll. Probably a normal businessman would have been furious that his subordinates did not appreciate his lordly generosity, but I was only provoked by this state of affairs, and I decided to observe the further behavior of specialists and gradually raise the budget for socialist competition. After 3 months, the budget has risen to 15,000 rubles per month, in another three - 20,000 rubles per month. The budget increase still did not cause any reaction of specialists, and the distribution of the premium from month to month was about the same (the real names of the employees were replaced here and then at their request):


Table 1 (clickable). Calculation of the premium for working with the ServiceDesk system in November 2013.

Every month I did a newsletter with the results of "socialist competition", and the guys received small awards for maintaining applications, said thank you and ran away with a premium in hand for lunch in the dining room. Judging by the size of the premiums, everyone worked about the same, but the bonus system took into account only the applications of users, and the regulatory and preventive tasks performed by the employees were not taken into account. Perhaps that is why, after about 8 months from the beginning of the “socialist competition,” I received a letter from one of the following employees:

“Can the fund be divided into prophylactic and routine applications, but somehow it is sad, no intrigue?”

Intrigue, need intrigue! And then Ostap suffered me:

Stillborn motivation system for working with the application system, cheaters, riot on the ship

For two months, in my free time from reading Habra, I was thinking about how to diversify the system of “social competition” and introduce intrigue into it. To begin with, I collected all the objective criteria for evaluating work on applications that could be measured at that time. They turned out a bit:

1. The number of registered applications;
2. The number of closed orders;
3. The number of completed regulatory and preventive tasks;
4. User evaluation by the application specialist.

Therefore, I decided to create an intrigue by introducing additional criteria into the motivation system, such as:

1. The bonus ratio of 1.5 increases points by 50% for two drummers in each of the categories (registration, closing of applications, implementation of preventive measures).
2. Deprimiruyuschy coefficient of 0.5, which reduces points by 50% for the weakest specialist in the category.
3. The coefficient of the subjective assessment of the quality of maintenance ServiceDesk for a month. It was assumed that such an assessment would be put by one of the specialists, who was assigned the role of “dispatcher” for this month (an additional premium coefficient was relied on for this role)
4. Deprimiruyushchy factor 0.5 for the failure of the standard of preventive tasks (40 tasks per month). This standard was absent from the three coolest specialists.
5. Deprimiruyuschy factor of 0.5 per deviation from the regulations of the implementation of preventive tasks. At the same time, the points deducted from the guilty employee were added to the employee who found deviations from the regulations.

Back in the motivation system, there were protection factors for writing articles on a blog for all kinds of office skills (in this way we taught guys to write instructions for users correctly), and also for participating in projects. As all these factors were related to each other, I will not tell you now - all this does not really matter, since this system soon had to be abandoned.

Having introduced new rules, I once again increased the bonus fund and made a newsletter. After studying the new rules of the game, Ilya Muromets (I remind you once again that the names of the employees were changed) immediately saw her imperfections and declared that he was “hacking” the bonus system in order to show her shortcomings. To do this, during the whole month Ilya did as much preventive tasks as possible so that the other colleagues would not be able to fulfill their standard for preventive measures and receive a reduction factor for the premium (and therefore reduced their premium and increased it). Ilya did almost succeed, and in March he received the biggest prize:


Table 2 (clickable). Calculation of the premium for working with the ServiceDesk system in March 2014. Here and below: N is the number of applications, P is the price in points, K is the raising (decreasing) coefficient.

True, Ilya did not have enough time for April (well, or his colleagues gave him a dark one - history is silent), and the April award looked like old reports:


Table 3 (clickable). Calculation of the premium for working with the ServiceDesk system in April 2014.

In the third month, Dobrynya Nikitich left everyone with a nose, having done almost all of the prophylaxis with one person. Dobrynya had a technical advantage for this - he lives in Novosibirsk and then woke up 3 hours earlier than the Moscow office (now by 4). Apparently, the time margin and territorial remoteness from the main team deprived Dobrynya of a sense of self-preservation, and in May 2014 he choked off half of the entire bonus fund:


Table 4 (clickable). Calculation of the premium for working with the ServiceDesk system in April 2014.

There was no fourth month of work on such a system of motivation - the masses began to grumble that the current system only demotivates. In principle, I now understand that such a reward system could take root only in an unhealthy team, where everyone only thinks about how to annoy others. In our case, the guys did not want to assess the quality of the work of others with the application system, did not want to “knock” on the neighbor, if they found a jamb in his work (to chide - surely, but in this case any error led to a decrease in the premium), and in In general, some people preferred to simply not undertake any tasks, if errors in their execution can lead to a decrease in the premium. As a result, in order not to bring people to sin (the masses have already started talking about arranging the dark one, including me, for the skillful management of the company), three months later I had to give up:

1. Direct participation of colleagues in the assessment of labor results and in influencing the size of the award;
2. Any demotivating factors (except for an objective assessment of the quality of work by users);
3. Any preferred employees in the bonus system.

After that, only three categories remained in the “socialist competition” system with two leaders in each category and with an assessment of the quality of work on requests by users. Until April 2015, this system worked without changes:


Table 5 (clickable). Calculation of the premium for working with the ServiceDesk system in April 2015.

The only achievement of the motivation system at the beginning of 2015 was the mass registration of all user appeals in the application system. But with the timely update of the status of applications and their closure in the system, the situation was still bad. In the study of applications in ServiceDesk in the middle of the month, the hair on my head stood on end on the volumes of tasks for which we either scored, or somehow we did, or we did it a long time ago. At the same time, if you kick technical support specialists (which I did at the end of each month), the applications were immediately closed in huge quantities and the picture of what was happening became much more biased. But in 2015, I was finally tired of this state of affairs, and I decided on another foray into the bonus system:

Fight for timely updating the status of tasks in the application system

In order to compete for the timely updating of statuses and closing tasks in the application system, I additionally divided users' applications into the bonus system into two types - closed on time and closed with deadlines. The applications closed on time, I did three times more valuable than all other tasks. At the same time, the coefficients for leadership remained only in three categories - registered applications, deadlines and preventive tasks. Applications made with deadlines, had no coefficients for leadership. Under the new system, to get a good award, it was not enough to work hard all month, and at the end of the month to close all the tasks done - it was necessary to keep the information in the ServiceDesk system up to date throughout the month.

Mindful of my past managerial “successes”, before changing anything in the established bonus system, I first assessed the size of changes over the old periods. Table 6 shows the calculation of the premium under the new system for April 2015 (Table 5 above contains the calculation for the same period using the old system). Additionally, in the report, I derived the number of “visits” - applications that were overdue and not closed in the reporting period:


Table 6 (clickable). Calculation of the premium for working with the ServiceDesk system in April 2015 using the new accounting system.

The picture in the reports loomed sad - the number of overdue and stuck requests exceeded the number of requests closed on time. However, despite the sadness of the situation, the new bonus system did not fundamentally change the current distribution of the bonus fund, and therefore did not threaten new conflicts with technical support specialists. Therefore, having crossed, I made a notification about the change in the bonus system (this time without changing the budget) and began to observe.

I would like to write here that the changes were not long in coming and, with the introduction of the new bonus system, life has finally gotten better. But in reality, the guys after learning about the changes in the bonus system were strained, closed most of the "hung" applications and ... began to save new ones. There were a few fewer applications made with overdue and “hanging”, but not so much that one could declare any serious victories on this front. The reason for the lack of any significant results turned out to be banal - some employees were ready to neglect the extra thousand rubles of premium, just not to tense up with quality maintenance of applications in ServiceDesk, and some individuals even purposefully sacrificed the quality of application maintenance in the system so that younger colleagues received a bigger bonus .

In order to push to work with the system of applications of those specialists who do not need a bonus from working with the system, I made the bonus fund dynamic when the size of the fund changes depending on the ratio of tasks closed on time to the total number of tasks in the application system (closed during the period and "). With this approach, it turned out that employees who are poorly ServiceDesk (do not close applications on time, leave hung applications), reduce the premium not only for themselves, but also for their colleagues. My calculation was that specialists who do not need a bonus do not go to spoil relations with colleagues who still need a bonus and will try to keep a more or less qualitative record of applications - a cunning plan, isn’t it? :)

So that innovation does not worsen the existing conditions, I calculated the level of the “bonus base” at which the current bonus fund (30,000 rubles) would correspond to the current quality of ServiceDesk maintenance - 47,000 rubles were released. Having made the next newsletter, I waited again and, after a couple of months, I saw much more fundamental qualitative changes - the number of overdue applications and “visits” decreased twice in the system:


Table 7 (clickable). Calculation of the premium for working with the ServiceDesk system in October 2015 with a dynamic bonus fund.

With this, I no longer make changes to the motivation system. In the next two years, I once raised the premium base, and the rest of the time I only considered and regularly paid the premium, and also watched the development of events.

Results, what happened and what did not work out at the moment

Thanks to the bonus system, in 4 years (already almost 5 years), the accounting system in my company has become more informative - all arising tasks began to be registered in it, and most of the tasks in the system began to be closed in a timely manner. Now in the application system at any time you can get more or less relevant information about the current status of the tasks performed. But the main thing is that now it is possible to more or less objectively measure the quality of our services: how many applications were made, how long they were made, for what services there were applications, what dynamics over time our services, what costs to support each service, who we have is a drummer and etc. For example, you can compare the results of work over the past two years:

	2016 year	2017 year
Fixed incidents	3267	2535
Service requests completed	1411	2373
Provided advice	113	148
Regular tasks completed	4138	3940
Fixed bugs	190	340
Time-resolved incidents	569	432
Deadlines for service requests	196	200
Median Incident Resolution Time	78 minutes	37 minutes
Median Service Request Time	61 minutes	43 minutes

Table 8. Comparison of the results of the work of technical support in 2016 and 2017.

In the previous paragraph, you probably paid attention to the use of “more or less” turnover. The fact is that the accuracy of accounting in the application system still leaves much to be desired. So, from the table above it follows that in 2017 compared to 2016, the number of incidents decreased by 741, and service requests, on the contrary, increased by 962. The reason for this change is simple - applications received by mail, we automatically register as incidental . In 2016, the guys just rarely checked the type of application when it was closed, and in 2017 they began to do it more often, which led to such a redistribution. The same parsley is also observed with the definition of categories of tasks - technical support specialists do not always correctly associate the task with the service affected by it. If we had dispatchers and managers in technical support, they would track such errors in the process of work, carry out explanatory work, and the accuracy of our accounting would be higher.

Also, according to the reports above, we just have a mountain of applications with deadlines, despite the fact that we have only a few real deadlines (well, okay - dozens). Most violations are related to the discrepancy between the features of the formal accounting of tasks and their real execution. For example:

1. There are tasks, the operational implementation of which will cause damage to the client more than good. For example, they found out that one of the fans on the server is spinning badly, but at the same time the server / disks do not heat up and there is no reason to run and change the fan convulsively (stopping the company). Accordingly, the application hangs in anticipation of a convenient moment for the work, and in the application system it turns out to be “hanging”.
2. Experts do not always put a request for “hold” (hold), when the task goes out of our area of ​​responsibility. For example, received a complaint about the quality of communication, diagnosed - the problem with the provider, handed him an appeal. At this moment, the order can / should be put on “hold” in order for the timer to stop (since the provider’s network is outside our area of ​​responsibility). In reality, the guys often do not do this, expecting that the provider will soon fix everything. If the provider solves the problem for a long time, then we get a delay in our accounting system.
3. Some applications still do not close on time, even when completed. Just sometimes it happens - you had to run away from work early, made a request and took up another task, forgot to close on time. Well, some specialists (apparently, with a very large salary), despite all my tricks, still work with the application system insofar as.
4. Peak load. When some kind of epidemic mows down half of our team, and our clients have employees on the contrary, they are healthy, they are overwhelmed with energy and they want to deal with the problems that they didn’t reach before. On such days it’s not up to the observance of all the formalities in ServiceDesk - to have time to answer calls.
5. Some applications are mini-projects, for which time is spent more than is allocated for standard applications. For example, the client writes that he is going to open a new office, the application is automatically registered and it remains to “hang” before the banquet associated with the opening of the office.
6. Some applications are inherently problems (within ITIL terminology). For example, when the base 1C of one single employee “freezes” for several seconds a day or when the first launch of Outlook by the user takes longer than usual - at the time of contacting technical support the error is no longer observed, but since it occurs regularly, the specialist needs to find and eliminate its cause. It often takes weeks to search for such reasons, but in the application system the longest period allowed for the execution of applications is 3 days.

Despite all the above disadvantages, the current quality of the work of technical support specialists with the application system suits me and, which is equally important, the system of motivation for working with the application system suits the specialists themselves.Of course, there is also something to polish and improve, but I think it is much more correct to focus my attention not on improving the quality of accounting for user requests, but on not having any reason to contact technical support. However, experience has shown that with the improvement of the quality of information systems in companies, the number of calls to technical support does not change, but only the nature of calls and the accompanying emotional background. But that's another story ...

Successes!

Ivan Kormachev
IT Department Company
www.depit.ru