Three surefire ways to spoil the relationship between support and development

It often happens that a client reports a problem, and then it turns out that there is no problem at all, or it lies in a completely different place. If you immediately send such a request to support, you will go through all the circles of hell and return to your starting position instead of solving the client's problem with little blood. To not waste time and save your and your client's nerves, find out the essence of the problem on the shore. To do this, walk through the steps with the client and identify the problem.

Send customer requests to development immediately

Client: Good afternoon! I cannot open your application

Support: Hello! Accepted. I give it to development. As soon as they clarify something, I'll call you back.

Support: Cap, we have a problem. The client cannot open our application. What could it be?

Development: Finally got to your question. I just opened the app. Everything is working. I don't know what the client does not open there.

Support: $ # * @% !!!

Customer: Good afternoon! I cannot open your application.

Support: Hello! Let's try to open it together with you. What is your first action?

Client: Well, I go to the site, and I cannot enter the program.

Support: Yeah. Do I understand correctly that you want to log into the system through the browser on the computer and not the phone application?

Client: Well, yes!

Support: Got you. Checking. Everything works. Let's try again together. Enter password. Perhaps you entered the wrong one by mistake?

Client: The password is correct; I have everything written down. Here it is, the password ... .. Aaaaaa. Stop. I have the capslock on. Everything works now. Thank you! Excuse me.

Support: Glad to help. Please contact.

Katerina Vinokhodova,

Usedesk co-founder

If you send a task for development in the form of a couple of phrases, the developers will have to find out all the details on their own and pull the support every time. So you get a conflict from scratch, and support and development will waste time and nerve cells. To prevent this from happening, give the support an algorithm of actions and draw up a standard application form for operators.

Formulate tasks for development in free-form

Here are three points that must be included in the problem statement to avoid conflicts:

1. Mass character of the problem. One of the biggest mistakes of a support employee is to send a task to development without understanding how massive it is. It depends on where to look for the cause of the problem. For example, a client complains that hieroglyphs come to the chat instead of the Cyrillic alphabet. If this is an isolated case, most likely, there is a problem in the browser or the encoding simply flew off - this problem can be quickly solved on the client-side. If the client's partners who use your service also see hieroglyphs in their chats, then the problem is on the service's side - it needs to be given to development.

And the massive nature of the problem immediately increases the level of its criticality - more on that later.

2. The criticality of the problem. If you submit a task for development without determining its criticality at the start, developers will not immediately understand what order to take tasks into work. One problem can wait a week, but you need to drop everything and urgently run to help for the sake of another. It does not happen that the developers immediately take on non-urgent tasks while the burning ones are gathering dust on the shelf, instantly finding out the criticality of the task and only then giving it to development.

An outraged client complained about the support, and we started to figure it out

It turned out that the operator, instead of a high level of criticality, set the average, and the task was pushed to higher priority. I had to urgently sort out the situation - to apologize to the client and offer compensation

The last step is to quickly fix the problem. The customer is satisfied, the conflict is over. We use four levels of the criticality of tasks, but you can develop your system.

We use four levels of the criticality of tasks, but you can develop your system.

Severity levels

1 Doesn't affect work at all, just creates inconvenience

2 Affects work, but not critical

3 Critically affects work, but you can endure a couple of days

4 Stops the user completely

Examples of

✓ The calendar looks ugly
✓ It is inconvenient to select a period in the calendar
✓ When saving settings, an error occasionally pops up, although the settings are saved
✓ For ten cases of using the template, the layout flies once
✓ Reports section does not work
✓ The system does not open
✓ The system does not receive letters
✓ The automation rule does not work

3. Describe the problem using a template. Without a template, the operator will write an essay on a free subject, and the development will solve this puzzle and swear a lot. But suppose you give the operator a template. In that case, all he has to do is to fill in all the items: specify the company ID, note the severity of the problem, determine the level of criticality, describe all the customer steps after which the error occurs, specify the URL of the problem, add screenshots. And the developer can quickly run through the familiar structure, understand the situation and decide what to do and when to do it.

For example, identifying the customer will prompt the developers to prioritize the task based on the customer's importance to the company. And specifying the part of the system where the problem occurred will help quickly assign a performer and find the weak points in the system that need to be reworked.

You can use our template or create your one on its basis → download the template for setting tasks for developers (.pdf).

Support: Cap, we have a problem. The client's app doesn't work. I have sent you the information.

Development: Yeah, I see, it's Ivan Ivanovich again.

I see that we can quickly fix it. Yes, I see the error; I got it. Let's get to work right away.


Support: Great! He is waiting.

Support: Cap, we have a problem. The app does not work for the client. I sent you some info.

Development: Yeah, I ran it diagonally; in two hours, I can take a closer look.

Support: But this is Ivan Ivanovich; I wrote you a postscript at the end of the document. He called and swore himself. If we don't do it right away, there will be a brain rupture.

Development: $ # * @% !!! So I would say right away, I didn't finish reading ... I'm watching…. And what exactly does not work for him?

Support: Ummm ... I'll send you a screen now ... Here ... Development: Soooo, I see. And then does this problem arise? Support: I wrote.

Development: $ # * @% !!! Where? I do not see.

Support: In the fourth paragraph, the fifth sentence.

Development: Yeah, I found it. Is there an error URL?

Support: $ # * @% !!!

If you throw tasks around haphazardly, you'll quickly lose control over them, and dissatisfied customers will run to your competitors and start writing angry reviews and ruining your karma. To keep all tasks under control, generate requests in an automated system that allows you to set deadlines for each task and keep track of its completion. We work in the Jira service, but you can use any other.

To make this system work, you need:

1. To appoint an administrator on the development side. A task administrator at the development side accepts tasks from the support team and distributes them. If there is no such person, the operators will constantly bother the developers and distract them from their work, which will lead to conflicts. The administrator's function may be assumed by the head of the development department, the project manager, or you can hire a special person to do this job. He will control each employee's workload and distribute tasks evenly, depending on their complexity and deadlines.

2. Set deadlines for different tasks. The developer will gradually take on tasks depending on the level of their criticality. For example, tasks with the fourth level of criticality are taken to work immediately, with the third - in the next week, with the second - in a week, with the first - in two weeks. In this way, developers will get an even workload, and helpdesk operators will know exactly when all their tasks are due and will be able to warn clients immediately when there is movement on their issue.

Send tasks to the common chat, PM, or e-mail of developers

To make it easier for the support to navigate the tasks, we linked the support requests in Jira to the tasks that the development performs. So the operator can at any time go into his tasks and see the development tasks associated with it: at what stage they are and what is with the deadlines

3. Set control points. Depending on the complexity of the tasks and a bunch of other factors, the dates may shift. So that this does not surprise operators who are waiting for the solution of their tasks, you need to set deadlines for reconciliation. For example, support staff contact the administrator every Tuesday and specify the deadlines for their tasks. This way, they will know what is happening with their tasks and communicate the changes to clients in time.

4. Establish feedback development → support. It happens that a developer in the process of solving a problem has additional questions about the support. Without an answer, he cannot continue to work. We had a case when developers wrote questions to tasks in Jira. Comments were sent to the support staff in the corporate mail, but they did not read them. As a result, we got a lot of tasks stuck. When it turned out, we set up the system so that messages with references to operators came to them in the form of tickets in Usedesk, as from customers, and the problem was solved. To prevent hanging due to communication problems, provide the development with the opportunity to receive feedback from the support.

5. Create a separate chat for critical tasks. We have a particular chat for especially essential tasks, where operators also drop them as soon as they set a task in Jira. And sometimes it happens that the problem is exact, the solution is too, but it takes time to formulate a problem according to a template. Then the operator describes the task in the chat, and the developers immediately start looking at it, after which it is formulated in Jira. Development primarily takes tasks from the chat into work.

Support: I set a task, it is on, so I duplicate it in the chat.

Administrator: Got it. Look…. I see the task is on fire. Ivan now has a window. I give the task to him and set the deadline the day after tomorrow.

Support: Great! Thank you.

Support: Cap, I threw you a problem yesterday. What with her? When can you watch it?
Developer: I was going yesterday, but I was completely lost. Everything is on fire today. Tomorrow I'll see for sure. ….

Support: Well, how is my task? I'd like to be quick; otherwise, the client called again. What should I tell him?

Development: $ # * @% !!! Bro, I'm sorry, I don't have time. Can you ask Ivan to look?

Support: $ # * @% !!!