Rescuers, go ahead!

Living and working in the modern IT world, we all - sooner or later, one way or another - contact the technical support service. What it looks like for us, the users, is more or less represented. But what is on the far side of the moon? Few of us know how the support service in this or that organization is usually arranged ... We also did not really understand how to properly organize the work of the caliper when more than 10 years ago we faced such a task. During this time we have come a long way, filled ourselves with a lot of bumps, and now we want to share with you our experience in this area.

In this article I will tell you what principles our support service is guided by and what techniques it uses in its work. Now I want to give only a brief overview of what is being done and how it is done here, and if you want more details on some issue, I can write about it in the future.

So, how do Chip and Dale work at DevExpress:

')

No one is forgotten. Nothing is forgotten

(no question should be lost)

One of the most terrible mistakes in the work of support services is ignoring the user. Therefore, we try to make sure that not a single question, not a single plea for help is left without our attention.

When we realized that we needed to control the entire incoming flow of questions, we developed our own message tracking system for the support, aka Support Center . In this system, for each user question is assigned a support staff member. If the person responsible for the question for some reason does not respond to it at the right time (fell ill, went on vacation or for some other reason left the battlefield), we have a notification mechanism for this - so that the coordinator can transfer such question to another support specialist.

Each problem can have many external and internal statuses depending on the type of issue (for example, a bug can be Reproduced, Fixed or By Design). But at the same time we try to follow the rule that any message from the user changes the status of the problem to active. Even if a person just wrote “Thank you!” - it will never be superfluous to answer him “Please!”

We do not sleep for days

(answer to a question within 24 hours)

We understand that each user wants to solve his problem as soon as possible. Therefore, asking his question to us, he knows for sure that he will receive an answer (at the latest) within 24 hours, excluding holidays and weekends.

Of course, if we succeed, we give the answer much faster. For example, we try to isolate and track the easiest questions and answer them as soon as we find them.

But 24 hours to answer in our case is a necessary minimum, which is due to the fact that our users are distributed around the world. In addition, our support service works in several shifts to provide the best coverage of different time zones.

Faster! More often! Fuller!

(the number of question reactivations should be minimal)

If a person turned to a support service, then he really needs help. Therefore, we try to help, not “process incoming requests.” To do this, we make our responses as complete as possible. For example:

(bad answer):

“How to do this is written in this document .”

(good answer):

“In order to solve your problem, you need to do this and that. You might also need this. In more detail, you can read here and here , and also watch online video or download a working example from our site. If you have more questions about this issue, let us know and we will be happy to help you. ”

Walking on a rake

(we collect all the rakes that someone has already attacked)

We decided to make sure that users could find the answer to their question as quickly as possible, even without contacting customer support. Here we proceeded from the fact that if someone ever turned to us with a problem, this information should not be wasted. To do this, we do this:

• All incoming questions, all communication with users is only in English. As a result, we avoid such a situation that the same problem can be recorded and discussed in different languages ​​in our database of questions.
• We made a public base of all user problems (questions, bugs and requests). Of course, if the user wishes, he can always hide his question from people's eyes (for example, if he sent us his code), but the majority of questions are still in the public domain.
• We implemented our own search engine, adapted to our needs and delivering the best results on the basis of our questions. This search offers each user to search for a ready-made solution before he writes his request to our support team.

Say no to the phone

(we do not provide phone caliper)

We are often asked the question why we do not have a telephone support service, because sometimes it can be very useful - many problems can be solved with the help of live communication.

In our case, we believe that the telephone support is not suitable for us, since almost every problem requires examining the user code or passing it different text objects, for example, hyperlinks or code examples. Therefore, support through forums, e-mail or a specialized web interface is much more suitable for us.

Tell Me Why

(most importantly, understand why the user wants it)

When considering a user’s question, at first we always try to pay special attention to identifying the user's true problem, and not why the way he is trying to solve this problem does not work.

Often, a correct understanding of the user's task greatly expands the range of ways to solve it, which means that the likelihood that at least one of them will satisfy him will be much higher.

... there are always two ways out!

(we try to provide a solution to the user always, if possible)

Even if the problem relates to the features of the product (By Design), we always try to offer the customer an alternative solution. And if this method does not exist, then we let the user know what we are going to do in this direction:

• If such functionality can be added to the product, then we will document the user's suggestion in some form and, ideally, give him a public way to track the status of his request in our Support Center.
• If such functionality cannot be added to the product under any circumstances, then we honestly inform the user so that he himself will make further decisions about the use of our product.

We always think about you

(work on the user's problem is going on, even if “the ball is on his side”)

Another important technique that our support service uses in its work: follow-up 's.
For example, we have already sent a response to the user, and after some time, a thought came to us one of us how else it would be possible to help the user solve his problem. In this case, we add additional information to our correspondence with the user, without waiting until he himself reactivates his problem.

Moreover, this information may be useful not only for this particular user, but it will also be useful for everyone else who reads our correspondence with him later (if the problem is recorded as public), which means that the value of any add-on increases many times over.

A can of cola and hot dog fix please

(the problem is fixed only when it is fixed by the user)

Another important rule to which we arrived at our work is: it is not enough just to diagnose a problem - especially if it is a bug in a product - the main thing is to save the user from this problem as soon as possible.

For example, a user has found a bug in the product that makes it impossible to continue working. If we just confirm that this is a bug, and let the user know: “Hurray! Bug fixed! Wait for the next update ... which will be in six months, ”he will remain dissatisfied all this time, and his dissatisfaction will grow with each passing day. To avoid such problems, we built the work in DevExpress to update our products in such a way that at any moment any user could get a new build containing a hot fix to his problem.

Programmer - support friend

(developers and calipers - one team. And the user's best friends)

A support engineer is always between two lights. On the one hand, he needs to solve the user's problem, and as soon as possible; on the other hand, very often in order to find the cause of this problem, and even more so to fix a bug, it cannot do without the help of developers. And product developers are almost always busy with their business, and therefore it is very difficult for them to enter the support position.

To remedy this situation, we use the following techniques in our work:

• Developers and supportrs for one product (or group of products) are combined into one team. They sit in one room and they have one goal - to make the product successful, and its users happy. This allows us to increase the efficiency of interaction and mutual assistance between our employees at the human level.
• Most developers periodically allocate some time to track incoming traffic questions for their products. If they have something to say on the user's problem, then they write their comments for the supportrs. If they see that some question is asked too often, then this is a reason to supplement the documentation or even improve the product in this direction.
• In exceptional cases, if the support service has an excessive number of questions for some force majeure reason, then product developers or other people involved in the development process (for example, technical writers) assume the function of supporting users. The experience of live communication with users of their own product in this case is of particular value for our developers and helps them better understand what people want from the product.