The battle of psychics in technical support, or how to help the user correctly put the priority of the incident
User Vasiliy applies to technical support “ A number is not allocated when registering a document with error 1234; to fix, you have to restart the application server service. The error occurred on 05.05 at approximately 15: 10-15: 50. Impact of the incident: Reduced user efficiency . "
But in fact, Vasily did not say that restarting the application server service leads to errors when updating user online reports for all company employees. In other words, no user can view current online reports on existing documents, which is equivalent to stopping the workflow in the company in principle. It turns out that Vasily did not give the necessary information in order for his appeal to be assigned the correct priority - and this despite the fact that he had such an opportunity. And, if the real priority is lower than stated - it is not so bad, otherwise it can have dangerous consequences. In this connection, a legitimate question arises: how to find out what the user wanted to convey, but for some reason he was shy and told a completely different thing at the last moment?
Due to the specifics of the vendor business model of our company, we can contact us for technical support as a business representative who provides his own support to end users (that is, the platform integrator) and the end user Docsvision directly. We work with hundreds of companies (these are thousands of users), and I, as the head of technical support, are acutely aware of the problem of not being able to agree in advance on all the rules for submitting applications. The cornerstone of this article has become such an important aspect as the prioritization of incidents.
')
Of course, the technical support service formulates these rules in the form of an open offer, but who reads it? Any technical support employee must have come up against a situation where the user had in mind something different from what he said during the call. I encounter the wrong prioritization of incidents by users in practice so often that I see reasons to single out this as a problem. In my practice, in about every 3 incidents, it turns out that the priority should have been different.
Our ticket filing system provides the ability to fully describe the incident and its importance to the user. We developed it on the basis of information from the processed tickets, more specifically, the fact that users wrote about the importance and urgency of the ticket in the course of its decision. The system looks like a master form, offering the user a consistent choice of answers to questions. The variant of each next question depends on the answer to the previous one. When asking questions to the user, in addition to answer options, prompts are offered to select the answer that is most appropriate for his particular problem. After answering all the proposed questions, the system prioritizes the incident on the basis of the information provided to them and guided by our customized logic. An example of how the choice of the nature of the impact of the problem when creating a ticket
After the introduction of this form into operation, in the created incidents, users began to provide significantly more information than before. And sometimes they even applied the necessary logs to analyze problem behavior, which is undoubtedly a big plus! But what still does not satisfy us in the solution we found is that a considerable number of users set signs incorrectly, as a result of which they receive an incorrect priority in the incident. That in itself is a bomb escalation with the theme (I quote) " Everything is on fire, and technical support is solving my incident slowly !!! 111 ".
Why is it that users put the wrong signs that directly affect the priority setting? After analyzing a series of incidents, it became clear that people do not always understand the relationship between the information they give and the priority that is followed in the incident. And what to do with it?
Is there a panacea that could help in such cases? What other options are there to avoid this misunderstanding?
We have not yet found a panacea that would allow us to avoid this influence of the “human factor” and the resulting non-optimal waste of resources, both ours and users.
I wonder if other companies face the problem of setting the correct priority and what solutions have you met?
But in fact, Vasily did not say that restarting the application server service leads to errors when updating user online reports for all company employees. In other words, no user can view current online reports on existing documents, which is equivalent to stopping the workflow in the company in principle. It turns out that Vasily did not give the necessary information in order for his appeal to be assigned the correct priority - and this despite the fact that he had such an opportunity. And, if the real priority is lower than stated - it is not so bad, otherwise it can have dangerous consequences. In this connection, a legitimate question arises: how to find out what the user wanted to convey, but for some reason he was shy and told a completely different thing at the last moment?
Priority issue
Due to the specifics of the vendor business model of our company, we can contact us for technical support as a business representative who provides his own support to end users (that is, the platform integrator) and the end user Docsvision directly. We work with hundreds of companies (these are thousands of users), and I, as the head of technical support, are acutely aware of the problem of not being able to agree in advance on all the rules for submitting applications. The cornerstone of this article has become such an important aspect as the prioritization of incidents.
')
Of course, the technical support service formulates these rules in the form of an open offer, but who reads it? Any technical support employee must have come up against a situation where the user had in mind something different from what he said during the call. I encounter the wrong prioritization of incidents by users in practice so often that I see reasons to single out this as a problem. In my practice, in about every 3 incidents, it turns out that the priority should have been different.
Our solution: application form
Our ticket filing system provides the ability to fully describe the incident and its importance to the user. We developed it on the basis of information from the processed tickets, more specifically, the fact that users wrote about the importance and urgency of the ticket in the course of its decision. The system looks like a master form, offering the user a consistent choice of answers to questions. The variant of each next question depends on the answer to the previous one. When asking questions to the user, in addition to answer options, prompts are offered to select the answer that is most appropriate for his particular problem. After answering all the proposed questions, the system prioritizes the incident on the basis of the information provided to them and guided by our customized logic. An example of how the choice of the nature of the impact of the problem when creating a ticket
After the introduction of this form into operation, in the created incidents, users began to provide significantly more information than before. And sometimes they even applied the necessary logs to analyze problem behavior, which is undoubtedly a big plus! But what still does not satisfy us in the solution we found is that a considerable number of users set signs incorrectly, as a result of which they receive an incorrect priority in the incident. That in itself is a bomb escalation with the theme (I quote) " Everything is on fire, and technical support is solving my incident slowly !!! 111 ".
Why is it that users put the wrong signs that directly affect the priority setting? After analyzing a series of incidents, it became clear that people do not always understand the relationship between the information they give and the priority that is followed in the incident. And what to do with it?
Panacea?
Is there a panacea that could help in such cases? What other options are there to avoid this misunderstanding?
- Hiring 100,500 specialists of line 1, who together with the user will create each incident, asking him the right guiding questions, interpreting the answers, putting down the right signs to determine priority - effectively, but not profitable.
- To oblige the company, whose users contact you for technical support, to train their colleagues in the tricks of the message in the incidents of the necessary information, which directly affects the priority setting. The option, I think, is quite good in theory. In practice, we have so far failed to implement this.
- Set a limit on the creation of incidents with the ability to independently put a high priority. In addition, each subsequent treatment, created over the limit, comes at an additional cost. On the one hand, this will force colleagues to be more attentive to the information provided on the criticality and urgency of the impact of incidents on work, on the other hand, it may prompt questions like “Why should we pay money for bugs in your product?”. It should be added that this practice is not fiction, I myself met her, however, in foreign companies.
We have not yet found a panacea that would allow us to avoid this influence of the “human factor” and the resulting non-optimal waste of resources, both ours and users.
I wonder if other companies face the problem of setting the correct priority and what solutions have you met?
Source: https://habr.com/ru/post/313722/
All Articles