Five conditions of drop dead tech. support

    The last five years I have been working in those. support. And I have developed some principles, following which, in my opinion, will make any of those. support cool and drop dead. And if you do not follow them, then the support will be dull and non-cool.

    I’ll immediately explain that these tips / rules are more relevant to support via HelpDesk or e-mails, telephone support has some of its own characteristics.

    1. Fast response and answers


    Customers love quick support, they love it. Because of the quick support, they can turn a blind eye to many things: the high price of the product, your mistakes, software bugs. The faster your support responds and solves problems, the better.

    Unfortunately, the quick support available 24/7 is expensive: you need more people and you need infrastructure around the clock. Most often, this is simply unprofitable, especially if you are not a large corporation, but a small startup.

    In this case, one interesting thing will help us.

    The client at any time should know what state his request is in, what is currently being done on his problem and when to expect the next response 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 this, 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 an engineer.

    This thing allows you to greatly increase your satisfaction with support, without increasing the staff and number of working support workers.

    For example, client A informed us of a problem. Engineer Ts started to solve it, after 20 hours the problem was resolved. The engineer informed the client of this. That is, the time from reporting the problem to solving it is 20 hours.

    Second situation: client Bnotified us of the problem. He immediately receives a notification that his request has been received and the approximate reaction time is N hours.
    Engineer Ts started to solve the problem and wrote that, most likely, the problem was caused by this and the immediate results will be in two to three hours. Three hours later, 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 original report, the problem is resolved.

    And in the first and second cases, the problem was solved equally quickly - in 20 hours. But in the second case, the client will have the impression that we responded and resolved the problem quickly.

    An informed client is joyful and happy with a capital letter. This is generally a separate topic, discussed below. Uninformed - gets angry, writes angry letters and stamps his 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 support team on the solved problem should answer the following questions:

    • what caused the problem?
    • What was done to solve the problem? what else needs to be done?
    • Is the problem solved completely now or not?
    • could there be a problem in the future? if so, how to avoid this? [optional]

    If the engineer’s message answers these questions, this is the complete, correct answer. Based on it, the client can make the right decision and, if necessary, solve such problems in the future himself. Having received the correct answer, the client will not ask additional questions => the support will have more time for requests from other clients.

    Example
    A client writes: “ My site is down, HELP! ” The
    engineer replies: “ We have solved this problem, please check your site.

    This is a bad, unsuitable answer, despite the presence of the word “please”. It’s good that the site is working, but what was it all the same?

    A good answer looks something like this:
    “We checked your site. There was a syntax error in the file site / file.php, due to 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 recent 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 message. Please contact your hosting and check the FTP logs to find out who made the incorrect change. ”


    This answer provides information, so it is good. Using this answer, the client can find the one to blame for the problem or, for example, solve a similar problem in the future on their own.

    How detailed you describe the causes of the problem is up to you. If you know that the client is technically savvy, you can delve into the details. If the client is poorly versed in this, you can get by with a general description.

    3. Never argue with a customer


    In general, 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, at the very moment you start this dispute.

    No need to argue with the client: he is always right, even if he is not right. Seriously.
    People tend not to admit their mistakes, especially publicly, so they will stand their ground 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 changed the DNS server of its domain too early without warning. As a result, the site is unavailable. He writes: " Ah, you boobies, you have a disgusting service, everything doesn’t work for me. You broke everything! Ahh, panic !! ".

    In fact, the client is not right. His incorrect actions caused a problem. But does he need to say this now, poke him into his mistakes, argue that he is really 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 server. 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 mumble, but a little bit, and in fact he will be pleased that he did not mess up, but we, and we recognize this. And he will love us.
    We forgot about our pride, took responsibility on ourselves, and in return received a satisfied client who wants to give us money.

    4. Let's make a decision


    The sapper must always offer a solution. Is always. If the supporter cannot offer at least some solution, 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 hosting restrictions
    • can change hosting
    • you can contact the hosting and ask to remove the restrictions

    These solutions are much better than simply indicating 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 a lower-level creature, because he does not know what Perl and PHP are, believes that the computer is such a TV on the table, and hangs on classmates.ru. Yes, the client does not understand the technical stuff.
    Yes, he is a “blonde”, doesn’t know anything and happens, he breaks everything. So rejoice at it!

    That is why the client comes to us, in support, to IT specialists. If the client would understand these things, then we would not need.
    But he probably understands other things, in sales, doing 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 clients, how to communicate with them? Guys, there are no such clients. And the sooner you believe it, the faster your support will be cool and drop dead.

    Consider them just such grown-up children. Children may not understand some things, be capricious, stomp their feet, take offense. You don’t take offense seriously at children, right? So here, take pity on them, calm them down, explain in simple words that you wish them well. It is valid.
    When the client does not understand what we want to say, explain as yourself, as your own little sister, who does not understand this technical language, explain in images.

    Well and most importantly: customers need to be loved. They feel it and answer the same :-)

    Also popular now: