Five conditions of those awesome. support
The last five years I have been working in those. support And I got some principles, following which, in my opinion, will make any of those. support cool and awesome. And if they are not followed, then the support will be dull and non-catchy.
Immediately I will explain that these tips / rules relate more to support via HelpDesk or e-mails, telephone support has some of its own characteristics.
Customers love fast support, they adore him. Because of the fast support, they can turn a blind eye to many things: the high price of the product, your mistakes, software bugs. The faster your support answers and solves problems, the better.
')
Unfortunately, fast support available 24/7 is expensive: more people are needed and infrastructure is available around the clock. Most of the time this is simply unprofitable, especially if you are not a large corporation, but a small start-up.
In this case, one interesting thing will help us.
The client at any time should know what state his request is in, what is being done on his problem now and when to expect the next answer from the engineer.
Add several statuses to the requests, make sure that for each change in the status of the request, the client receives information about it, an explanation of what is happening with his problem, and the date of the next checkpoint, i.e. when to wait for new information from the engineer.
This piece allows you to greatly increase the satisfaction from the support, without increasing the staff and the number of working supporters.
For example, client A notified us about the problem. Engineer C began to solve it, after 20 hours the problem was solved. The engineer notified the client about it. That is, the time from reporting a problem to solving it is 20 hours.
The second situation: client B notified us about the problem. He immediately receives a notification that his request has been received and an approximate reaction time - N hours.
Engineer C started to solve the problem and wrote that, most likely, the problem was caused by this and the next results will be in two or three hours. After three hours, the engineer writes that he found the exact reason, but the solution will take time and will be ready tomorrow. Tomorrow, after 20 hours from the source report, the problem is solved.
Both in the first and in the second cases the problem was solved equally quickly - in 20 hours. But in the second case, the client will be left with the impression that we reacted and solved the problem quickly.
Informed customer is joyful and happy with a big letter schA. This is generally a separate topic covered below. Uninformed - angry, writing angry letters and stomping their feet. And he can be understood - he has a problem, but he does not know what to expect from the future.
In my opinion, the answer / report of the supporter about the solved problem should answer the following questions:
If a message from an engineer answers these questions, then this is the complete, correct answer. Based on it, the client can make the right decisions and, if necessary, solve such problems in the future himself. Having received the correct answer, the client will not ask additional questions => the support provider will have more time for requests from other clients.
Example
The client writes: " My site is down, HELP! "
The engineer replies: " We have solved this problem, please check your site. "
This is a bad, bad answer, despite the presence of the word "please." Well, that site works, but what was it all the same?
A good answer looks like this:
This answer gives information, so he is good. Using this answer, the client can find the culprit in the problem or, for example, solve a similar problem in the future independently.
How much detail to describe the causes of the problem is up to you. If you know that the client is technically savvy, you can go into details. If the client is poorly versed in this, you can get by with a general description.
Generally arguing with a person is ineffective in terms of reaching an agreement. And arguing with a client is the worst and wrong thing you can do. Even if you are right. You always lose in a dispute with a client, already at that very moment, as you start this dispute.
No need to argue with the client: he is always right, even if not right. Seriously.
People tend not to admit their mistakes, especially in public, so they will stand up to the last, even if deep down they know that they are wrong.
Therefore persuade the client, if necessary, state your point of view, but never argue, do not say "you are wrong, we are right, look here.".
Life example :
The client wanted to move from one hosting to another. In the process of moving the site, the client, without warning, changed the DNS server of his domain too early. As a result, the site is unavailable. He writes: " Oh, you, boobies, you have a disgusting service, everything does not work for me. You broke everything! Aaa, panic !! ".
In fact, the client is wrong. His incorrect actions caused a problem. But does he need to say it now, poke him into his mistakes, argue that he really is to blame?
No, it is not necessary. Therefore, we write this: “Dear customer, a thousand apologies for this problem. This is our mistake, we are to blame. We should have warned you that it’s too early to change the DNS servers. We did not warn you and this caused an error. Sorry again and try changing them again. Everything will work as it should. ”
The client may rumble, but a little bit, and in fact he will be pleased that he did not screw up, but we, and we admit it. And he will love us.
We forgot about our pride, took responsibility for ourselves, and in return received a satisfied customer who wants to give us money.
A supporter must always offer a solution. Is always. If a supporter cannot offer at least some kind of solution, then this is a bad supporter.
If possible, it is better to offer several solutions, with a description of their pros and cons.
For example, the site does not work due to hosting restrictions. What could be the solution?
These solutions are much better than simply pointing out the cause of the problem, as they allow the client to choose the best path for him.
Do not consider the client an idiot. One of the problems of the IT industry and support is that the client is considered to be a lower class creature, because he doesn’t know what Perl and PHP are, he thinks that a computer is such a TV on the table, and hangs on his classmates. Yes, the client does not understand the technical stuff.
Yes, he is “blonde”, he doesn’t know how and it happens, everything breaks. So enjoy it!
That is why the client comes to us, in support, to IT-specialists. If the client would understand these things, then there would be no need for us.
But he probably understands other things, sales, business, and so on.
And if you consider the client an idiot, then all this is perfectly felt. And who wants to communicate with people who consider you an idiot?
You say: what about harmful, strange, inadequate customers, how to communicate with them? Guys, there are no such clients. And the sooner you believe it, the sooner your support will be cool and awesome.
Consider them just such adult children. Children may not understand some things, act up, stomp their feet, be offended. You are not seriously offended by children, right? So here, take pity on them, calm them down, explain in simple words that you wish them well. It works.
When the client does not understand what we want to say, explain as to yourself, as to your own little sister, who does not understand this technical language, explain with images.
And most importantly: customers need to love. They feel it and respond the same: -)
Immediately I will explain that these tips / rules relate more to support via HelpDesk or e-mails, telephone support has some of its own characteristics.
1. Quick response and responses
Customers love fast support, they adore him. Because of the fast support, they can turn a blind eye to many things: the high price of the product, your mistakes, software bugs. The faster your support answers and solves problems, the better.
')
Unfortunately, fast support available 24/7 is expensive: more people are needed and infrastructure is available around the clock. Most of the time this is simply unprofitable, especially if you are not a large corporation, but a small start-up.
In this case, one interesting thing will help us.
The client at any time should know what state his request is in, what is being done on his problem now and when to expect the next answer from the engineer.
Add several statuses to the requests, make sure that for each change in the status of the request, the client receives information about it, an explanation of what is happening with his problem, and the date of the next checkpoint, i.e. when to wait for new information from the engineer.
This piece allows you to greatly increase the satisfaction from the support, without increasing the staff and the number of working supporters.
For example, client A notified us about the problem. Engineer C began to solve it, after 20 hours the problem was solved. The engineer notified the client about it. That is, the time from reporting a problem to solving it is 20 hours.
The second situation: client B notified us about the problem. He immediately receives a notification that his request has been received and an approximate reaction time - N hours.
Engineer C started to solve the problem and wrote that, most likely, the problem was caused by this and the next results will be in two or three hours. After three hours, the engineer writes that he found the exact reason, but the solution will take time and will be ready tomorrow. Tomorrow, after 20 hours from the source report, the problem is solved.
Both in the first and in the second cases the problem was solved equally quickly - in 20 hours. But in the second case, the client will be left with the impression that we reacted and solved the problem quickly.
Informed customer is joyful and happy with a big letter schA. This is generally a separate topic covered below. Uninformed - angry, writing angry letters and stomping their feet. And he can be understood - he has a problem, but he does not know what to expect from the future.
2. Clear explanation
In my opinion, the answer / report of the supporter about the solved problem should answer the following questions:
- What caused the problem?
- What was done to solve the problem? what else to do?
- Is the problem solved completely now or not?
- Can there be a problem in the future? if yes, how to avoid it? [optional]
If a message from an engineer answers these questions, then this is the complete, correct answer. Based on it, the client can make the right decisions and, if necessary, solve such problems in the future himself. Having received the correct answer, the client will not ask additional questions => the support provider will have more time for requests from other clients.
Example
The client writes: " My site is down, HELP! "
The engineer replies: " We have solved this problem, please check your site. "
This is a bad, bad answer, despite the presence of the word "please." Well, that site works, but what was it all the same?
A good answer looks like this:
“We checked your site. There was a syntax error in site / file.php, because of which everything did not work.
We edited this file and fixed this error, at the moment everything is working correctly, please check: example.com
We do not know who changed the file. Date of change - DDMM. I checked your last requests, none of our engineers worked with your store. I saved the file before my change. The original and modified files are attached to my post. Please contact your hosting and check the FTP logs to find out who made the incorrect change. ”
This answer gives information, so he is good. Using this answer, the client can find the culprit in the problem or, for example, solve a similar problem in the future independently.
How much detail to describe the causes of the problem is up to you. If you know that the client is technically savvy, you can go into details. If the client is poorly versed in this, you can get by with a general description.
3. Never argue with a client
Generally arguing with a person is ineffective in terms of reaching an agreement. And arguing with a client is the worst and wrong thing you can do. Even if you are right. You always lose in a dispute with a client, already at that very moment, as you start this dispute.
No need to argue with the client: he is always right, even if not right. Seriously.
People tend not to admit their mistakes, especially in public, so they will stand up to the last, even if deep down they know that they are wrong.
Therefore persuade the client, if necessary, state your point of view, but never argue, do not say "you are wrong, we are right, look here.".
Life example :
The client wanted to move from one hosting to another. In the process of moving the site, the client, without warning, changed the DNS server of his domain too early. As a result, the site is unavailable. He writes: " Oh, you, boobies, you have a disgusting service, everything does not work for me. You broke everything! Aaa, panic !! ".
In fact, the client is wrong. His incorrect actions caused a problem. But does he need to say it now, poke him into his mistakes, argue that he really is to blame?
No, it is not necessary. Therefore, we write this: “Dear customer, a thousand apologies for this problem. This is our mistake, we are to blame. We should have warned you that it’s too early to change the DNS servers. We did not warn you and this caused an error. Sorry again and try changing them again. Everything will work as it should. ”
The client may rumble, but a little bit, and in fact he will be pleased that he did not screw up, but we, and we admit it. And he will love us.
We forgot about our pride, took responsibility for ourselves, and in return received a satisfied customer who wants to give us money.
4. Give the solution
A supporter must always offer a solution. Is always. If a supporter cannot offer at least some kind of solution, then this is a bad supporter.
If possible, it is better to offer several solutions, with a description of their pros and cons.
For example, the site does not work due to hosting restrictions. What could be the solution?
- You can change the site, adapting it to the limitations of hosting
- you can change hosting
- you can contact the hosting and ask to remove restrictions
These solutions are much better than simply pointing out the cause of the problem, as they allow the client to choose the best path for him.
5. Customer is not a fool
Do not consider the client an idiot. One of the problems of the IT industry and support is that the client is considered to be a lower class creature, because he doesn’t know what Perl and PHP are, he thinks that a computer is such a TV on the table, and hangs on his classmates. Yes, the client does not understand the technical stuff.
Yes, he is “blonde”, he doesn’t know how and it happens, everything breaks. So enjoy it!
That is why the client comes to us, in support, to IT-specialists. If the client would understand these things, then there would be no need for us.
But he probably understands other things, sales, business, and so on.
And if you consider the client an idiot, then all this is perfectly felt. And who wants to communicate with people who consider you an idiot?
You say: what about harmful, strange, inadequate customers, how to communicate with them? Guys, there are no such clients. And the sooner you believe it, the sooner your support will be cool and awesome.
Consider them just such adult children. Children may not understand some things, act up, stomp their feet, be offended. You are not seriously offended by children, right? So here, take pity on them, calm them down, explain in simple words that you wish them well. It works.
When the client does not understand what we want to say, explain as to yourself, as to your own little sister, who does not understand this technical language, explain with images.
And most importantly: customers need to love. They feel it and respond the same: -)
Source: https://habr.com/ru/post/54710/
All Articles