“Not a single break!” or why should a customer fight technical support
Remember what memes surfed the internet seven years ago? In one of them, a client 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 - you can’t explain to such a client that the Earth is round!
Now jump to the client’s place and remember the hour-long conversations with the call center. Long expectations 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 everything always so bad? And so that the conversation really wonders, do people with the highest technical and angelic patience really need to be on both ends of the wire?
In general, people have long and repeatedly answeredto this question: everything is real and feasible. And neither users nor service owners can deny a positive result from technical support. Firstly, from the client’s side: there is support, and he pays money for it (whether it is included in the price of the purchased product or is paid after the fact), which means he needs it; besides, we all turn to it sooner or later, which means we consider this a better option than to puff ourselves and check whether our beloved chinchilla has reached the mains cable 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, if only to come less often. Suppose it even exists for show in some mossy corporation, where there is a stable income, which does not depend on customer satisfaction.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 soon as possible and get the desired result, the second hopes that the first hangs up quickly and never calls again ... well, so that he is still satisfied, this is already a bonus. The goals are clearly on the same plane: the conversation should be as short as possible and as effective as possible. Why are the first and second often unsatisfied?
The reasons, of course, may be the sea, starting with a biased customer relationship and ending with the incompetence of the agent. But let's take a balanced option when the client calls with a certain hope and belief that they will help him, and the engineer has certain experience and the necessary knowledge to help the client. Even under general favorable conditions, it is always likely that the conversation will not be asked. “You are incorrectly writing the server address in the settings of the router.” A small, insignificant word gives the conversation a negative connotation, the mood seems not to be spoiled, but the enthusiasm is not the same. “The man on the other side of the phone seemed to help, he pointed out an error ... but couldn’t he have done it a little more politely?”And the conversation goes further, but the phrases and intonation of the interlocutor no longer seem so friendly. The reaction to these phrases is corresponding, and the engineer himself already feels the dissatisfaction of the ungrateful client. If the problem was finally resolved, then both sighed that it was all over and hung up. But if you failed to help the client, then the end of the conversation can become much more picturesque.
As a result, we have almost all the signs of a decisive conversation: for the client, the stakes are high (and why should he still call someone - the problem is not solved), emotions mix 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 rates in this conversation are no higher than in the pharmacy lottery. Therefore, it is he who is responsible for the successful outcome of the call (emotionally) in most cases.
The engineer should feel like a lifesaver, and the client should not become a victim.
The ability to follow the conversation and redirect it in the right direction, smelling dangerous notes - this is a quality that would not hurt any person, especially if he earns his bread by communication. But to learn how to be a good child, to cherish and cherish a client, and to be his best friend, is simply unrealistic for an engineer in a short period of preparation. Here you need experience, and positive. And if there is experience, and even bad one, then often the old habits can no longer be beaten out by a new wedge of strict rules. The processes for improving the communication of engineers are more focused on the application of the “right” techniques than on the correction of learned errors. Therefore, I propose to look at three errors that an engineer should not make when communicating with a client if he does not want to see splashes from the telephone receiver.
• No charges. If you assume that the client made a mistake, formulate a neutral question that does not directly indicate the alleged mistake, but helps the client to find it himself. “Let's double-check the settings of the router, sometimes these Chinese boxes knock down the settings on their own.”
• No problem. Focus on the solution, not the problem. It is important for the client to solve his problem, and not make something work "as it should." Even if the client knows exactly how something works, he is unlikely to be satisfied with the exact answer why this something does not work. He probably needs to know when it will work again and what will be done so that it no longer breaks.
• Do not insist.The client is not obliged to accept any of your answers to faith, even if he is a hundred times true. He must understand him first. If the client does not want to listen to the answer, stop and return to the explanation of the purpose of your work - to solve the client’s problem. Next, briefly and clearly explain how your proposal relates to the client’s problem and should solve it.
• Nothing personal. The lion's share of the problems lies in the client’s misunderstanding of the operation of the equipment, service or program. It is not surprising that an engineer will look for a problem in precisely this and question your competence. You are calling to consult a specialist. Take it as a fresh look at the problem and support the engineer in the desire to check all the details.
• Be more specific.Emphasize that the solution to the problem is a priority for you, not its cause, and that it is he - the engineer who should help you find the answer. In an ideal situation, the engineer will devote a minimum of time explaining the causes of the problem, which you almost do not need, and immediately proceed to the solution. In an extreme case, he will cease to vigorously justify that disconnected communications - this is like the rotation of the earth - cannot be stopped, and will direct his energy in the right direction.
• Do not deny.If you hear an answer that does not suit you, wait to deny and say that your domestic rodent has been sitting in the cage all day and physically could not bite the wire. Ask how the proposed solution will fix your problem, ask for an explanation. A person can not always catch the line of thought of the interlocutor, technical support agents are no exception, and tips are always appropriate.
This, of course, is a view from two sides of just three small elements in the conversation. A 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 the task is one for all, and convey the right decision in the right words. I hope they will be useful to you too.
Now jump to the client’s place and remember the hour-long conversations with the call center. Long expectations 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 everything always so bad? And so that the conversation really wonders, do people with the highest technical and angelic patience really need to be on both ends of the wire?
In general, people have long and repeatedly answeredto this question: everything is real and feasible. And neither users nor service owners can deny a positive result from technical support. Firstly, from the client’s side: there is support, and he pays money for it (whether it is included in the price of the purchased product or is paid after the fact), which means he needs it; besides, we all turn to it sooner or later, which means we consider this a better option than to puff ourselves and check whether our beloved chinchilla has reached the mains cable 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, if only to come less often. Suppose it even exists for show in some mossy corporation, where there is a stable income, which does not depend on customer satisfaction.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 soon as possible and get the desired result, the second hopes that the first hangs up quickly and never calls again ... well, so that he is still satisfied, this is already a bonus. The goals are clearly on the same plane: the conversation should be as short as possible and as effective as possible. Why are the first and second often unsatisfied?
The reasons, of course, may be the sea, starting with a biased customer relationship and ending with the incompetence of the agent. But let's take a balanced option when the client calls with a certain hope and belief that they will help him, and the engineer has certain experience and the necessary knowledge to help the client. Even under general favorable conditions, it is always likely that the conversation will not be asked. “You are incorrectly writing the server address in the settings of the router.” A small, insignificant word gives the conversation a negative connotation, the mood seems not to be spoiled, but the enthusiasm is not the same. “The man on the other side of the phone seemed to help, he pointed out an error ... but couldn’t he have done it a little more politely?”And the conversation goes further, but the phrases and intonation of the interlocutor no longer seem so friendly. The reaction to these phrases is corresponding, and the engineer himself already feels the dissatisfaction of the ungrateful client. If the problem was finally resolved, then both sighed that it was all over and hung up. But if you failed to help the client, then the end of the conversation can become much more picturesque.
As a result, we have almost all the signs of a decisive conversation: for the client, the stakes are high (and why should he still call someone - the problem is not solved), emotions mix 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 rates in this conversation are no higher than in the pharmacy lottery. Therefore, it is he who is responsible for the successful outcome of the call (emotionally) in most cases.
The engineer should feel like a lifesaver, and the client should not become a victim.
Reassure customer
The ability to follow the conversation and redirect it in the right direction, smelling dangerous notes - this is a quality that would not hurt any person, especially if he earns his bread by communication. But to learn how to be a good child, to cherish and cherish a client, and to be his best friend, is simply unrealistic for an engineer in a short period of preparation. Here you need experience, and positive. And if there is experience, and even bad one, then often the old habits can no longer be beaten out by a new wedge of strict rules. The processes for improving the communication of engineers are more focused on the application of the “right” techniques than on the correction of learned errors. Therefore, I propose to look at three errors that an engineer should not make when communicating with a client if he does not want to see splashes from the telephone receiver.
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 helps the client to find it himself. “Let's double-check the settings of the router, sometimes these Chinese boxes knock down the settings on their own.”
• No problem. Focus on the solution, not the problem. It is important for the client to solve his problem, and not make something work "as it should." Even if the client knows exactly how something works, he is unlikely to be satisfied with the exact answer why this something does not work. He probably needs to know when it will work again and what will be done so that it no longer breaks.
• Do not insist.The client is not obliged to accept any of your answers to faith, even if he is a hundred times true. He must understand him first. If the client does not want to listen to the answer, stop and return to the explanation of the purpose of your work - to solve the client’s problem. Next, briefly and clearly explain how your proposal relates to the client’s problem and should solve it.
Do not push the engineer
Of course, there are three ideas for the client how to keep the situation under control and not make the enemy a rescuer:
• Nothing personal. The lion's share of the problems lies in the client’s misunderstanding of the operation of the equipment, service or program. It is not surprising that an engineer will look for a problem in precisely this and question your competence. You are calling to consult a specialist. Take it as a fresh look at the problem and support the engineer in the desire to check all the details.
• Be more specific.Emphasize that the solution to the problem is a priority for you, not its cause, and that it is he - the engineer who should help you find the answer. In an ideal situation, the engineer will devote a minimum of time explaining the causes of the problem, which you almost do not need, and immediately proceed to the solution. In an extreme case, he will cease to vigorously justify that disconnected communications - this is like the rotation of the earth - cannot be stopped, and will direct his energy in the right direction.
• Do not deny.If you hear an answer that does not suit you, wait to deny and say that your domestic rodent has been sitting in the cage all day and physically could not bite the wire. Ask how the proposed solution will fix your problem, ask for an explanation. A person can not always catch the line of thought of the interlocutor, technical support agents are no exception, and tips are always appropriate.
This, of course, is a view from two sides of just three small elements in the conversation. A 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 the task is one for all, and convey the right decision in the right words. I hope they will be useful to you too.