“Not a single break!” Or why should a customer fight with technical support
Remember, what memes walked on the Internet about seven years ago? In one of them, a customer knocked out uninterrupted Internet from technical support and complained about daily breaks. It was both funny and sad. Put yourself in the place of a support engineer - yes such a client cannot explain that the Earth is round!
Now jump to the place of the client and remember the hour conversations with the call center. Long waits on the phone, attempts to get a handful of useful information ... On the other side, too, they don’t seem to be very tense. Is it always that bad? And for the conversation to really be set, do people really need people with higher technical and angelic patience at both ends of the wire?
In general, people have long and repeatedly answered this question: everything is real and feasible. Yes, and a positive result from technical support can not deny neither users nor the owners of services. First, on the client side: support exists, and he pays money for it (whether it is included in the price of the product purchased or paid after the fact), and it means he needs it; besides, we all turn to it sooner or later, which means we consider it to be a better option than to puff ourselves and check if the favorite chinchilla got to the power cord behind the cabinet. Secondly, technical support is also unlikely to consider itself a self-sufficient service, to which customers as the most distant relative - let it be, just to come less often. Suppose it even exists for the sake of a tick in some moss-covered corporation, where there is a steady income that does not depend on customer satisfaction. If such technical support exists, then with a minimal goal - so that the client has a place to call when he suddenly needs it (and yes, he may need exactly the information that is written in bold text on the first page of the user manual, but more on that later).
As a result, we have two at the ends of one line: one hopes to end the conversation as quickly as possible and get the desired result, the second one hopes that the first one will hang up and never call again ... well, so that he is still satisfied, this is already a bonus. Objectives are clearly on the same plane: the conversation should be as short as possible and as efficient as possible. Why is the first and second often unhappy?
')
The reasons, of course, can be the sea, starting with the prejudice of the client and ending with the incompetence of the agent. But let's take a balanced option, when a customer calls with a certain hope and faith that he will be helped, and the engineer has certain experience and necessary knowledge to help the client. Even under general favorable conditions it is always likely that the conversation will not be set. “You incorrectly register the server address in the settings of the router.” Some small insignificant word gives the conversation a negative connotation, the mood is not spoiled, but the enthusiasm is not the same. “The person at the end of the phone seemed to help, pointed out the mistake ... but could he really have done it a little more politely?” And the conversation goes on, but the phrases and the intonation of the interlocutor no longer seem so benevolent. The response to these phrases is appropriate, and already the engineer himself feels the discontent of the ungrateful client. If the problem was finally resolved, then both sighed that everything was over, and hung up. But if you failed to help the client, the end of the conversation can become much more picturesque.
As a result, we have almost all signs of a decisive conversation : for a client, the stakes are high (and then why would he call someone else - the problem is not solved), emotions are mixed in the conversation and capture both, and opinions differ by default almost from the very beginning . Only one of the signs is missing: for an engineer, the stakes in this conversation are not higher than in the lottery. Therefore, it is he who is responsible for the successful outcome of the call (emotionally) in the absolute majority of cases.
The engineer should feel like a lifeguard, and the client should not become a victim.
The ability to follow the conversation and redirect it in the right direction, sensing dangerous notes - this is a quality that would not hurt anyone, especially if he earns his bread by intercourse. But to learn how to be a good boy, to cherish and nurture a client and be his best friend, for a short period of preparation, an engineer is simply unreal. Here you need experience, and a positive one. And if there is experience, and even bad, then often old habits can no longer be knocked out by strict rules with a new wedge. The processes of improving the communication of engineers are more likely sharpened on the use of "correct" techniques, than on correcting learned mistakes. Therefore, I propose to look at three errors that the engineer should not make when communicating with the client, if he does not want to see the spray from the handset.
• No charges. If you assume that the client made a mistake, formulate a neutral question that does not directly indicate the alleged mistake, but will help the client to find it himself. "Let's recheck the settings of the router, sometimes these Chinese boxes knock down the settings by themselves."
• No problem. Concentrate on the solution, not the problem. It is important for the client to solve his problem, and not to make something work “as it should”. Even if the client knows exactly how something works, it is unlikely to be satisfied with the exact answer, why this something does not work. He certainly needs to know when it will work again and what will be done so that it does not break anymore.
• Do not insist. The client is not obliged to accept any answer to your faith, whether he is at least a hundred times correct. He must first understand him. If the client does not want to listen to the answer, stop and go back to explaining the purpose of your work - to solve the client's problem. Further briefly and clearly explain how your proposal relates to the client’s problem and should solve it.
• Nothing personal. The lion's share of problems lies in the misunderstanding by the client of the operation of the equipment, service or program. No wonder the engineer will look for this problem and question your competence. You do call to consult with a specialist. Think of it as a fresh look at the problem and support the engineer in wanting to check all the details.
• Be specific. Emphasize that it is the solution of the problem that is your priority, and not its cause, and that it is the engineer who should help you find the answer. In an ideal scenario, the engineer will devote a minimum of time to explaining the causes of the problem, which you almost do not need, and will immediately proceed to the solution. In the extreme case, he will cease to vigorously justify himself that the interruptions of communication are like the rotation of the earth, they cannot be stopped, and he will direct his energy in the right direction.
• Do not deny. If you heard an answer that does not suit you, wait to deny and say that your domestic rodent was caged all day and was physically unable to gnaw through the wire. Ask exactly how the proposed solution will fix your problem, ask for explanations. A person can not always catch the interlocutor's thoughts, technical support agents are not an exception, and prompts are always relevant.
This, of course, is a view from two sides of all on three small elements in the conversation. The conversation is usually much more complicated. But these three simple elements can help in time to feel the approaching conflict and build a “security zone”, remember that there is one task for everyone and bring the right decision with the right words. I hope they will be useful to you too.
Now jump to the place of the client and remember the hour conversations with the call center. Long waits on the phone, attempts to get a handful of useful information ... On the other side, too, they don’t seem to be very tense. Is it always that bad? And for the conversation to really be set, do people really need people with higher technical and angelic patience at both ends of the wire?
In general, people have long and repeatedly answered this question: everything is real and feasible. Yes, and a positive result from technical support can not deny neither users nor the owners of services. First, on the client side: support exists, and he pays money for it (whether it is included in the price of the product purchased or paid after the fact), and it means he needs it; besides, we all turn to it sooner or later, which means we consider it to be a better option than to puff ourselves and check if the favorite chinchilla got to the power cord behind the cabinet. Secondly, technical support is also unlikely to consider itself a self-sufficient service, to which customers as the most distant relative - let it be, just to come less often. Suppose it even exists for the sake of a tick in some moss-covered corporation, where there is a steady income that does not depend on customer satisfaction. If such technical support exists, then with a minimal goal - so that the client has a place to call when he suddenly needs it (and yes, he may need exactly the information that is written in bold text on the first page of the user manual, but more on that later).
As a result, we have two at the ends of one line: one hopes to end the conversation as quickly as possible and get the desired result, the second one hopes that the first one will hang up and never call again ... well, so that he is still satisfied, this is already a bonus. Objectives are clearly on the same plane: the conversation should be as short as possible and as efficient as possible. Why is the first and second often unhappy?
')
The reasons, of course, can be the sea, starting with the prejudice of the client and ending with the incompetence of the agent. But let's take a balanced option, when a customer calls with a certain hope and faith that he will be helped, and the engineer has certain experience and necessary knowledge to help the client. Even under general favorable conditions it is always likely that the conversation will not be set. “You incorrectly register the server address in the settings of the router.” Some small insignificant word gives the conversation a negative connotation, the mood is not spoiled, but the enthusiasm is not the same. “The person at the end of the phone seemed to help, pointed out the mistake ... but could he really have done it a little more politely?” And the conversation goes on, but the phrases and the intonation of the interlocutor no longer seem so benevolent. The response to these phrases is appropriate, and already the engineer himself feels the discontent of the ungrateful client. If the problem was finally resolved, then both sighed that everything was over, and hung up. But if you failed to help the client, the end of the conversation can become much more picturesque.
As a result, we have almost all signs of a decisive conversation : for a client, the stakes are high (and then why would he call someone else - the problem is not solved), emotions are mixed in the conversation and capture both, and opinions differ by default almost from the very beginning . Only one of the signs is missing: for an engineer, the stakes in this conversation are not higher than in the lottery. Therefore, it is he who is responsible for the successful outcome of the call (emotionally) in the absolute majority of cases.
The engineer should feel like a lifeguard, and the client should not become a victim.
Calm the client
The ability to follow the conversation and redirect it in the right direction, sensing dangerous notes - this is a quality that would not hurt anyone, especially if he earns his bread by intercourse. But to learn how to be a good boy, to cherish and nurture a client and be his best friend, for a short period of preparation, an engineer is simply unreal. Here you need experience, and a positive one. And if there is experience, and even bad, then often old habits can no longer be knocked out by strict rules with a new wedge. The processes of improving the communication of engineers are more likely sharpened on the use of "correct" techniques, than on correcting learned mistakes. Therefore, I propose to look at three errors that the engineer should not make when communicating with the client, if he does not want to see the spray from the handset.
What should be done so that the client does not feel like a victim:
• No charges. If you assume that the client made a mistake, formulate a neutral question that does not directly indicate the alleged mistake, but will help the client to find it himself. "Let's recheck the settings of the router, sometimes these Chinese boxes knock down the settings by themselves."
• No problem. Concentrate on the solution, not the problem. It is important for the client to solve his problem, and not to make something work “as it should”. Even if the client knows exactly how something works, it is unlikely to be satisfied with the exact answer, why this something does not work. He certainly needs to know when it will work again and what will be done so that it does not break anymore.
• Do not insist. The client is not obliged to accept any answer to your faith, whether he is at least a hundred times correct. He must first understand him. If the client does not want to listen to the answer, stop and go back to explaining the purpose of your work - to solve the client's problem. Further briefly and clearly explain how your proposal relates to the client’s problem and should solve it.
Do not press on the engineer
Of course, there are three ideas for the client, how to keep the situation under control and not make an enemy of a rescuer:
• Nothing personal. The lion's share of problems lies in the misunderstanding by the client of the operation of the equipment, service or program. No wonder the engineer will look for this problem and question your competence. You do call to consult with a specialist. Think of it as a fresh look at the problem and support the engineer in wanting to check all the details.
• Be specific. Emphasize that it is the solution of the problem that is your priority, and not its cause, and that it is the engineer who should help you find the answer. In an ideal scenario, the engineer will devote a minimum of time to explaining the causes of the problem, which you almost do not need, and will immediately proceed to the solution. In the extreme case, he will cease to vigorously justify himself that the interruptions of communication are like the rotation of the earth, they cannot be stopped, and he will direct his energy in the right direction.
• Do not deny. If you heard an answer that does not suit you, wait to deny and say that your domestic rodent was caged all day and was physically unable to gnaw through the wire. Ask exactly how the proposed solution will fix your problem, ask for explanations. A person can not always catch the interlocutor's thoughts, technical support agents are not an exception, and prompts are always relevant.
This, of course, is a view from two sides of all on three small elements in the conversation. The conversation is usually much more complicated. But these three simple elements can help in time to feel the approaching conflict and build a “security zone”, remember that there is one task for everyone and bring the right decision with the right words. I hope they will be useful to you too.
Source: https://habr.com/ru/post/255131/
All Articles