Clever Geek Handbook

Technical support Miran: how it works

The fire in which you burn must be maintained.

V.O. Pelevin, “Generation P”






Hello, Habr! My name is Alexander Soloviev, I’m the head of technical support for Miran data centers.



Tell me, have you tried to write textbooks? Me not. Nevertheless, the text below is a kind of training manual for organizing technical support. As part of the article, I would like to tell you what the technical support of Miran data centers is: what kind of “gears” spin and why they spin in this way and not otherwise.





For the convenience of the reader, I will divide this article into several semantic parts.



  1. In the first, we will talk about the basic elements of TP work - staffing, application life cycle, and prioritization.
  2. In the second part, we will address the issues of maintaining the knowledge of technical support engineers at a given level.
  3. In the third , final part, we will talk about how to make all of the above work.


I will talk about motivation, in particular, non-financial, as well as give a couple of tips on organizing corporate rewards and punishments.



Technical Support Basics



To organize the work of technical support, you need to answer a few simple questions:



  1. It requires support for one product (service) or it is a multi-product support, i.e. supporting several completely different products?
  2. What SLA is required for technical support calls?
  3. Do I need to provide round-the-clock support?




First



Monoproduct support requires a minimum number of specialists. For example, if you expect about ten applications per shift, you can try to shift the support to a specialized engineer.

Multi-product support requires either the selection of product specialists or the separation of the traffic of calls by complexity, which is expressed in the organization of several support lines.

We took the path of dividing engineers in accordance with their knowledge and competencies into three components: the first, additional and second technical support lines.



Second



The stiffer the SLA, the more resources a company will need to comply. These are a variety of resources: qualified engineers, information systems, equipment, regulatory documents, and more. Consider the issue of staff. To fulfill SLA requirements, the staff should be proportional to the average number of technical support calls, taking into account time and quality standards.



Based on the above, the staff of our engineers is as follows:

• first line - 10 people;

• additional line - 4 people;

• second line - 5 people.



Third



Round-the-clock technical support is an expensive service. High-quality performance of this service in 24x7x365 mode will require at least 5 engineers, and this is in the simplest case, i.e. in case of single product support. If you need to organize round-the-clock support, feel free to multiply the costs by 5. But, first of all, think about whether you need it (can you do without a self-service portal, etc.). If you still need it, is it possible to outsource it.







What are all these people doing



The task of first-line engineers is to quickly and efficiently process the client’s appeal. To process means to correctly classify and send to work.

After processing, the engineer of the first line either solves the application on his own if it is from the “do it quickly, here and now” section, or transfers the application to another line if it is “long-playing” or if it is a “malfunction”.

The task of the additional line engineers is to work with applications that take more than one day to complete.

The task of the second-line engineers is to troubleshoot as quickly as possible and solve complex applications “here and now”.



Engineer Modes



First line : schedule - 2/2, 12-hour shifts from 08:00 and 20:00.

Additional line : schedule - five days, 8-hour shifts from 08:00 and from 12:00.

Second line : schedule - 2/2, 12-hour shifts from 08:00 and 20:00.



Engineer shift schedules are maintained through Google Calendar.







Life cycle and status of applications in TP



The easiest way to track the application life cycle is according to this scheme:





I will explain each of the points separately.







Application typing



The type of application is the most important criterion. It determines the reaction rate and the time to resolve the problem indicated in the ticket. In Miran, according to ITIL, requests are divided into the following types. I give them in order of importance:



Incidents

Incidents include equipment malfunctions and malfunctions, as well as any other events that entailed a significant deterioration in the quality of services. Applications of this type are executed in order of priority and take precedence over other types of applications. Only incidents can take precedence over processing.



Examples of incidents: service unavailability, hardware failure.



RFS - Service Request

The customer has a need for service as part of the services provided. The request is not related to a failure or failure in the IT infrastructure. It is carried out immediately in the general queue in the absence of priority applications.



Example: a request to restart the server.



RFC - Change Request

Request for a change in the composition and / or scope of services provided to the client. Processing time is determined by the management of the company individually in agreement with the client.



Examples: a request for switching equipment.



RFI - Request for Information

Information on the service was requested, including reports on the volume of energy consumption, service reports, etc. It is carried out immediately in the general queue in the absence of priority applications.



The priority of the application, affecting the speed of reaction and decision, is calculated on the basis of information received from the client, taking into account a number of internal rules and orders. There are two priorities: initial and final. The initial priority is set according to the client and determines the speed of incident processing. The final priority is set by the engineer after completion of work and reflects the actual level of degradation of services. Often these priorities are not equal.



Priorities are allocated as follows:





I think this can smoothly finish the analysis of the theory. Behind the scenes there will be timings of reactions to incidents and requests, escalation levels, financial motivation and other information, more or less standard for other companies. Let's move on to more interesting things.



Maintaining the required level of knowledge



In the work of the technical support service, we strive to regulate everything that is regulated, to be transparent to the client, and also to formalize and digitize any information that may turn out to be useful and applicable in the future. Feedback from clients, the level of knowledge of our employees, their achievements and facaps - all this is meticulously digitized, analyzed and subsequently affects management decisions.



For several days off, a technical support engineer may change some regulations, new “introductory” ones will appear, which means that at the beginning of the shift it is necessary to take care of checking the relevance of the engineers' knowledge. This is done with the help of situational modeling technology, by training to resolve situations in which the specified knowledge is in demand. We call one situation a case. At the beginning of the shift, the engineer receives a batch of several user cases. This approach allows engineers to maintain the necessary knowledge in their minds and constantly update them. As a result, the quality of work increases. To reduce stress, the deadline for solving user cases is set at the end of the shift, although in fact the specialist only needs ten minutes.



What exactly does a typical user case consist of?



In total there are 4 semantic blocks:



  1. Information block

    It contains useful information that needs to be learned.
  2. Block bundle

    This block allows you to associate new information with the "transport" of this information in human memory.
  3. Answer options

    In fact, this is the "transport" of information in memory.
  4. Proof link

    Link to any trusted source where you can examine this information.






This is what a standard user case looks like on the example of historical material



All blocks of the usercase are related in meaning and theme. Ideally, the information block should contain a hint of an answer option, and for clarification, you need to open prooflink and study in detail the question being examined there.



Introducing this practice, I came across one unpleasant moment: there is not a single full-fledged tool on the market that would allow you to store a knowledge base, “smartly” distribute user cases by employees and check their answers.



Currently we are using a bunch of several tools.





In fact, the system works as follows:



  1. A list of employees involved in the training of knowledge is formed.
  2. For each employee, topics of user cases are defined.
  3. A user case is created for each topic and transferred to the employee.
  4. During the working day, the engineer must solve all the user cases.
  5. The answers are checked, and the result of the verification of each user case is stored in the system.


A good engineer solves one user case in about a minute. To cheat and “count” is quite problematic, we took care of our own anti-cheat system.



Remember: in no case try to manage the level of knowledge of employees in those departments where you do not control motivation.



Gun, parrots and motivation



I spoke in sufficient detail about how the technical support service works. It remains to understand another important point: why does it even work? :)



Everything rests on two pillars. These pillars are non-financial and financial motivation.



The famous gangster Al Capone said: "With a kind word and a gun you can achieve much more than just a kind word." Regrettably, in this metaphor financial motivation is a good word, and non-financial is already a “good old” gun.



Non-financial motivation





Three pillars of non-financial motivation: hunger, cold and peace objectivity of assessment, evidence of accrual, ease of administration



Any person reacts very negatively to fines expressed in money ... but fortunately, they are much easier to worry about fines in “parrots”. Meanwhile, parrots, if you can cook them, very, very significantly motivate employees.



We have chosen as quality. the parrot is off, but theoretically you can choose something else. Leisure time is good because we feel it by all employees, it is in demand for its intended purpose and there is no need to explain to subordinates what it is and what it is for. First of all, when choosing a unit of account, one should proceed from the fact that it should not be a “spherical horse in a vacuum”. The accounting unit must be tangible for the employee.



In the framework of non-financial motivation, employees are deprived not of money, but of time off and, accordingly, the opportunity to use the benefits of non-financial motivation. This is unpleasant, but not like a fine: there is an incentive to grow, and a person’s loyalty to the company does not suffer. “Feats” are encouraged by time off. An employee can use the day off for its intended purpose: for example, lying around at home, but this is not so interesting. It’s more interesting to go to a casino with blackjack and mademoiselle to pay some time off for events that are significant for yourself or your company, for example: medical services outside the VHI, obtaining professional certificates, fitness or tour packages, finally.



The only minus time off compared to money is that each use case, either in direct or in monetary terms, needs to be separately verified by the authorities, which is not always convenient. The price of time off from us is 3000 rubles, you may have more or less. The main thing is mutual comfort from using a unit of non-financial motivation.



Let me give you a living example when a specific work is awarded in a non-financial way.



Drawing up good documents with user cases for the knowledge base is not so much a task as a process. Every month, something new appears: customers, hardware, software. All this, for the reasons already mentioned above, requires careful attention and documentation.



If at the very beginning I worked on the compilation of these documents myself, now the knowledge base replenishment system works almost autonomously. My task is to guide employees in the right direction, give them a motion vector and carry out exit control.



My experience shows that the “price” of one good document equipped with a sufficient number of user cases is three days off.



The engineer receives two days off for a document that does not require significant corrections.



A person receives one day off if many corrections are required, and it is easier to make them yourself than to explain how to do it correctly.



We tried to give more time off for this work - from 10 days or more. But practice has shown that too much a reward frightens off, and there are practically no people who want to receive it. Therefore, it is important not to overdo it with the promotion of employees. It can get you sideways in the most unexpected way. Experiment, but do it carefully.



Financial motivation



Each application completed by a TP engineer is rewarded with bonuses. The value of the bonus is directly proportional to the complexity of the application and the qualifications required for its implementation. The final salary of an engineer is determined by the sum of these bonuses. Of course, in the case of a “crooked” execution of the application, the bonus for it burns out.



Another nuance: the salary of an engineer is always in the range determined by his position. In the laziest month, a person will not receive less than the lower limit of this range, nor will he receive more than the upper one in the most productive one. Nevertheless, no one will leave offended: all the schools are punished, and processing is encouraged through non-financial motivation.



To summarize



The article turned out to be unexpectedly voluminous, but this is not surprising: we examined the life of Miran’s technical support almost entirely, omitting only the most boring or general details. Nevertheless, if I nevertheless forgot to write about something interesting for you, or during the reading you had questions regarding the organization of the TP service, I will be happy to answer them in the comments.



Related Materials





More articles:


All Articles