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.
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
✓ 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