5 rules for working with tickets

Whether you are a client or a technical support specialist, with remote interaction (in our case, through tickets), both you and the other side need more discipline. Each ticket is a separate task with its own cycle of execution, its participants and its goal. So, how to optimize the interaction through the ticket system ?

1. The rule of "one to one"

Each ticket (it is a “bug”) is a relationship between two people: those who have declared a problem and those who will solve it. If this is a bug - someone reports it, someone understands it, if this is a question - someone asks it, someone answers. No matter how many people on both sides are involved in resolving the issue, only two people participate in this communication.

The responsibility of the person who creates the ticket is to talk about the problem. When you create a ticket, you insist that the problem exists: someone can say that everything works, someone can argue that he has no such error, someone else - that the description of the problem is too muddy and no one understands what, in fact, the case. The task of creating a ticket is to ensure its viability. If you created a ticket, you are its guardian angel until the moment of closing.
')
The task of the second side is to provide a solution. If a ticket is assigned to you, your task is to convince the other side that your decision is the best. You may be told that this solution is not enough, that it is ineffective or does not fully solve the problem. Of course, your task is to investigate the roots of the problem, calculate all possible options and propose a good solution, but all this is secondary, because your main task is to close the ticket.

In ticket systems, one always sells his vision of the question to another.

2. Close it!

Ticket system is not a chat, and you are not here to talk. You are here to solve your question. Tickets that do not close for weeks are a real nightmare for both the applicant and the technical specialist: they are difficult to track and even harder to control. A ticket can have hundreds of comments that eventually make you forget what the problem was.

All this is a mistake on both sides. The ticket must be formulated briefly and to the point. The scenario of the ideal ticket is: the problem - clarifying questions - a short explanation - the decision - closing the ticket, thank you all.

3. Do not close it!

Every time you discover a bug and create a ticket, you spend your time. Each time a tech support employee processes your ticket, the provider company spends a lot of resources.

If you confirm the closure of the ticket, and the problem has not been solved properly, you throw your money and the provider money in the trash. If the ticket is created, you can not say "Okay, we will understand later." If it is running, all measures must be taken to resolve the problem.

Look at it this way: when you created a ticket, you had a certain task in your head, something went wrong. If you do not have enough time at the moment, and you close the question, someone else will find the same bug in the future and will again spend time - his own and the provider - to solve this problem. Make the world a little better, do not close the ticket until you have received a full answer to your request.

4. Shh ... no noise!

Every time you leave a comment on a ticket, address it to someone - otherwise your comment will be considered just a statement of your opinion, what is called “communication noise” in psychology. Remember, a ticket is a communication between two participants.

Always address your question / request / requirement to a specific person with whom you communicate to close your problem. Everything else just complicates the process of solving the problem, but in no way helps in it.

5. Speak louder

Always talk about what does not suit you. Each time you report a problem, explain exactly what went wrong. It is your task to explain what works incorrectly in the product, what is not documented, what the questions are. You have received the service, and it is your right to report the problem, and your duty to explain what specifically does not meet your expectations.

The formula for the ticket is: “This is what we have, and this is what we should have.” You sort of move the project from point A to point B: something went wrong at point A, and it would be better for all of us to be at point B. Obviously, your task is to draw this line from point A to point B.

Say, if you have a question, it means that there is not enough information in the documents - and this is the root of the problem. Instead of asking: "How to connect X?", Say: "In current documents there is no information on how to connect X. Please complete them."

Every time you create a ticket, feel like an artist - draw a clear line from point A to point B.