In the work of the technical support service, we strive to regulate everything that is regulated, to be transparent for the client, as well as formalize and digitize any information that may later be useful and applicable. Feedback from customers, the level of knowledge of our employees, their achievements and failures - all this is meticulously digitized, analyzed and subsequently influenced by management decisions.
Within a few days off of a technical support engineer, some regulations may change, new "introductory" ones will appear, which means that at the beginning of the shift, you need to take care of checking the relevance of the engineers' knowledge. This is done using situational modeling technology, through training to resolve situations in which the specified knowledge is in demand. We call one situation a use case. At the beginning of the shift, the engineer receives a portion of several use cases. This approach allows engineers to keep the knowledge they need in mind and keep it updated. As a result, the quality of work is improved. To reduce stress, the deadline for solving use cases is set at the end of the shift, although in fact ten minutes are enough for the specialist.
What exactly does a typical use case consist of?
There are 4 semantic blocks in it: IT support technician job description
Information block
It contains useful information that needs to be learned.
Link
block This block allows you to link new information with the "transport" of this information in the memory of a person.
Variants of answer
In fact, this is the "transport" of information into memory.
Proof Link
A link to a trusted source where you can study this information.
standard use case based on historical material
This is how a standard use case looks like on the example of historical material.
All blocks of a use case are related in meaning and theme. Ideally, the information block should contain a hint at the answer option, and for clarification, you need to open a prooflink and study the issue under discussion in detail.
While introducing this practice, I encountered 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 use cases among employees and check their answers.
At the moment we are using a bunch of several tools.
Request Tracker (RT) - defines the logic of interaction between systems.
Google Calendar API "gives" a list of employees and the number of use cases for each.
Google Spreadsheets provides information for the formation of a use case.
In fact, the system works as follows:
A list of employees participating in knowledge training is formed.
Use case topics are defined for each employee.
A use case is created for each topic and transferred to the employee.
During the working day, the engineer must solve all the use cases.
The answers are checked, and the result of checking each use case is saved in the system.
A good engineer solves one use case in about a minute. Cheating and “cheating” is quite problematic, we also 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 talked in some detail about how the technical support service works. There is one more important point to understand: why does it work at all? :)
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 pistol you can achieve much more than just a kind word." Sadly, in this metaphor, financial motivation is a good word, and non-financial motivation is a good old gun.
Non-financial motivation
Three pillars of non-financial motivation
Three pillars of non-financial motivation: hunger, cold and calmness, objectivity of assessment, obviousness of accrual, ease of administration
Any person reacts very negatively to fines expressed in money ... but fortunately, it is much easier to worry about fines in “parrots”. Meanwhile, parrots, if you know how to cook them, very, very significantly motivate employees.
We chose as. parrot day off, but theoretically you can choose something else. Day off 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 unit of account must be tangible to the employee.
As part of non-financial motivation, employees are deprived not of money, but of time off and, accordingly, opportunities to enjoy the benefits of non-financial motivation. This is unpleasant, but not like a monetary fine: there is an incentive to grow, and a person's loyalty to the company does not suffer. "Feats" are encouraged by taking time off. An employee can use the time off for its intended purpose: for example, to lie around at home, but this is not so interesting. It is more interesting to go to a casino with blackjack and mademoiselles to pay with time off for any significant events for oneself or the company, for example: medical services outside the VHI, obtaining professional certificates, fitness or a tour, finally.
The only disadvantage of taking time off in comparison with money is that each use case, either in direct or in monetary terms, must be separately approved by the authorities, which is not always convenient. The price of a day off with us is 3000 rubles, you can 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 of a particular job being rewarded in a non-financial way.
Writing good documents with use cases for a knowledge base is not so much a task as a process. Every month something new appears: clients, equipment, software. All this, for the reasons already mentioned above, requires careful attention and documentation.
If at the very beginning I worked on compiling these documents on my own, now the knowledge base replenishment system works almost autonomously. My task is to direct employees in the right direction, to give them a vector of movement and to exercise final control.
My experience shows that the "price" of one good document with a sufficient number of use cases is three days off.
An engineer receives two days off for a document that does not require significant corrections.
A person gets one day off if a lot of corrections are required, and it is easier to make them yourself than to explain how to do it right.
We tried to give more time off for this job - 10 days or more. But practice has shown that too much reward scares away, and there are practically no people willing to receive it. Therefore, it is important not to overdo it with employee rewards. This can get you sideways in the most unexpected way. Experiment, but do it carefully.
Financial motivation
Each application made by a TP engineer is rewarded with bonuses. The amount of the bonus is directly proportional to the complexity of the application and the qualifications required to complete it. The final salary of an engineer is determined by the sum of these bonuses. Of course, in the case of a “crooked” order execution, the bonus for it will expire.
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 end of this range, nor will he receive more of the upper one in the most productive one. Nevertheless, no one will leave offended: all shoals are punished, and overwork is encouraged through non-financial motivation.
No comments:
Post a Comment