We destroy the queue of appeals. Part 1
In early December, looking at the sales statistics, Nikolai rubbed his hands: there were twice as many orders as in November, and the month promised the January holidays in Krasnaya Polyana. By the 20th, sales began to fall. The mailbox of support turned into a pot from a fairy tale that he cooked without stopping and no magic words helped. I had to sit down myself for the letters, but the support still did not cope: they answered for a long time, the customers were angry and ordered in another store. What prevented the team of Nicholas to withstand the influx of appeals before the new year? Nikolai did not take into account the load. At university, he skipped the Queuing Theory and now did not calculate how many employees he would need during the peak of appeals. In addition, the team randomly processed applications without a clear plan and could not keep the queue by the tail.
We will not torment you with the TMO formulas, but today we will tell you about the second: the strategy of managing the queue of e-mails. What are the principles for forming and processing queues, how and in what order to respond to customers, so that they do not get psyched and are happy. Let us give Nikolay and you three useful ideas.
Cut off part of the queue, creating a knowledge base on the site. Place it where customers will see. Collect the FAQ in a special section or leave the answers on each page, where customers often have questions. For example, customers showered Nikolai with letters about the time and cost of delivery. If he had placed this information on the checkout page, he would have saved time for both customers and customer support. Remember that the best service is the lack of service. First, think about how to drastically reduce the number of hits. Then we went further.
For small teams, the simplest principle will do: first come, first served. This means that you process old requests first. That was how Nicholas’s support service worked. But the trouble happened to complex issues and complaints: customers waited in the wings longer than their nerves were enough.
Therefore, the essence of working with the queue is reduced to two actions:
')
Sort - that is, divide one large queue into several small ones by parameters. By time, by topic, by value, by complexity, by the first letter of the client's name, by eye color.
Assign priority - to determine who will wait in this small queue, and who will receive the answer first: green-eyed or blue-eyed?
Let's get down to business. Nikolay has three letters:
By time, the priority is the oldest letter.
If you look at the type of client, then he should respond to the first one.
And the topic “SROCHNAAAA” seems to hint.
Hm For each of the parameters was a different priority. To solve the problem, it remains to answer the question:
What is the most important thing in the client's letter?
Let's offer Nikolay the following order:
Now a little magic. Let's return to the table and for clarity, we will translate everything into numbers. Assign a score to each value, where 3 is the most urgent and 1 is waiting. And multiply by the importance of the parameter.
Voila The guy prudently pointed out the topic URGENT and received a prize in the form of a quick response.
Thus, we correct the sequence of our steps:
You have determined the order in which to process the letters. Now let's figure out how to distribute them to the team - who will respond to which letter.
These two methods of distributing the queue of requests by responsible agents are well known to you.
Remember how in childhood we came to the polyclinic only according to the schedule of work of the district doctor and shouted “who is the last?”, Standing in the queue. It somehow happened this way:
The rule was strictly observed - it was possible to get to another district officer only if you were dying. The meaning of the scheme is clear: the city is divided into sections, the responsible doctor is attached to the section, the district officer knows you from the cradle, he has a thick card where the histories of your illnesses are written in an incomprehensible hand.
If you translate service into a customer service plane, then you are a regular customer here, and the doctor is your personal manager. He is aware of events in your body and knows how to help. It sounds good, but in reality you are doomed to an agonizing wait with temperature and snot, when 10 people run in front of you “just for help”.
The problem of “attaching” a client to an agent is that in a personal queue a client's call is stuck when the responsible agent is focused on another client.
And what if the doctors worked in McDonalds? The queue flow is divided into streams that flow to the free checkout.
Each new client is served by the first one who is released.
Imagine that you did not have to wait in line for your precinct office in office 9, and you calmly went to another doctor, because on his station you see less sick.
Here we are faced with different principles of forming a queue. People come to McDuck every time with a new request. Therefore, any client easily serves any free cashier. A medical history is important to the doctor. Without a card here anywhere. You guessed the decision - to give access to this card to each doctor. And in the case of our Nicholas, show agents the history of customer requests, so that even an employee can help any employee.
Usedesk will cope with this , which stores the client card with up-to-date information about the interaction and comments of previous employees.
So the client does not depend on the “employment” of the personal manager, and gets a decision faster. Any agent will respond in seconds without spending time clarifying the details.
If there are universal fighters in your team, you distribute requests automatically evenly. This ensures that everyone has something to work with, without taking into account the subject matter and skills of the employee. But the bigger the team, the harder it is to maintain the same skill set for each agent. And complex issues require the use of other departments. Therefore, areas of responsibility are shared either within the support team, or between departments in the company. Some are responsible for choosing the size and color of the dress, others for communication with the courier, and others for returning money. This is the next step after sorting and prioritizing - to route the question to specialists.
Let's see how to do it.
1. Offer to formulate a question and choose the addressee to the client himself. We place on the site addresses of all departments of the company, and the client puzzles his head where to write.
On all sides, the option is so-so. The client does not guess the direction and grow old in anticipation of a response, and we will have to endlessly send letters from department to department in search of a responsible person.
2. A sparing option with elements of elegance: letting you choose a topic of appeal from the list. A great way to sort questions before they get into the support system.
The topic has already been determined, the support will not have to additionally review the contents of the letter and isolate the essence, it remains only to address the person in charge. It is great to simplify the task in setting up the processes inside the support and in further analytics. But try not to tire the client with a choice of 100,500 themes. And do not forget about the universal “other” - the client will be offended if he does not find the necessary subject matter.
3. Let customers write to one address, without thinking about the wording, we will sort on our side. To do this, we set up rules in Yuzdeska , which, according to the conditions, assign tags to requests and assign them to a responsible specialist or group. All questions containing “labutenes” are immediately sent to Nikolay.
We shift the responsibility for sorting and routing to the robot, so you have to tinker with the configuration. To whom to assign a letter depends not only on the content, but on the channel and the time of access, priority, status, and so on. We load as many complex logic as we like, and then with enjoy the work with the assigned letters without confusion. Even if the system was wrong and the request did not go there, it is easy to reassign it manually.
At this interrupt, and next time delve into the details. How to divide a team, who to skip out of turn and for what to use task branching. In the meantime, go share in the comments how you handle the queue.
We will not torment you with the TMO formulas, but today we will tell you about the second: the strategy of managing the queue of e-mails. What are the principles for forming and processing queues, how and in what order to respond to customers, so that they do not get psyched and are happy. Let us give Nikolay and you three useful ideas.
0. And immediately here you live hacking
Cut off part of the queue, creating a knowledge base on the site. Place it where customers will see. Collect the FAQ in a special section or leave the answers on each page, where customers often have questions. For example, customers showered Nikolai with letters about the time and cost of delivery. If he had placed this information on the checkout page, he would have saved time for both customers and customer support. Remember that the best service is the lack of service. First, think about how to drastically reduce the number of hits. Then we went further.
1. First come-first processed vs sort and priority
For small teams, the simplest principle will do: first come, first served. This means that you process old requests first. That was how Nicholas’s support service worked. But the trouble happened to complex issues and complaints: customers waited in the wings longer than their nerves were enough.
Not all calls are equally urgent. The task is to find the most urgent.
Therefore, the essence of working with the queue is reduced to two actions:
')
Sort - that is, divide one large queue into several small ones by parameters. By time, by topic, by value, by complexity, by the first letter of the client's name, by eye color.
Assign priority - to determine who will wait in this small queue, and who will receive the answer first: green-eyed or blue-eyed?
Let's get down to business. Nikolay has three letters:
By time, the priority is the oldest letter.
If you look at the type of client, then he should respond to the first one.
And the topic “SROCHNAAAA” seems to hint.
Hm For each of the parameters was a different priority. To solve the problem, it remains to answer the question:
What is the most important thing in the client's letter?
Let's offer Nikolay the following order:
- Theme
- Who is customer
- Circulation time
Now a little magic. Let's return to the table and for clarity, we will translate everything into numbers. Assign a score to each value, where 3 is the most urgent and 1 is waiting. And multiply by the importance of the parameter.
Voila The guy prudently pointed out the topic URGENT and received a prize in the form of a quick response.
Thus, we correct the sequence of our steps:
- Sort letters by parameters
- Determine the importance of parameters
- Give priority to parameter values
You have determined the order in which to process the letters. Now let's figure out how to distribute them to the team - who will respond to which letter.
2. Who is the last? vs free ticket!
These two methods of distributing the queue of requests by responsible agents are well known to you.
Remember how in childhood we came to the polyclinic only according to the schedule of work of the district doctor and shouted “who is the last?”, Standing in the queue. It somehow happened this way:
The rule was strictly observed - it was possible to get to another district officer only if you were dying. The meaning of the scheme is clear: the city is divided into sections, the responsible doctor is attached to the section, the district officer knows you from the cradle, he has a thick card where the histories of your illnesses are written in an incomprehensible hand.
If you translate service into a customer service plane, then you are a regular customer here, and the doctor is your personal manager. He is aware of events in your body and knows how to help. It sounds good, but in reality you are doomed to an agonizing wait with temperature and snot, when 10 people run in front of you “just for help”.
The problem of “attaching” a client to an agent is that in a personal queue a client's call is stuck when the responsible agent is focused on another client.
And what if the doctors worked in McDonalds? The queue flow is divided into streams that flow to the free checkout.
Each new client is served by the first one who is released.
Imagine that you did not have to wait in line for your precinct office in office 9, and you calmly went to another doctor, because on his station you see less sick.
-Let your card!
-Oh, she is in the next room!
Here we are faced with different principles of forming a queue. People come to McDuck every time with a new request. Therefore, any client easily serves any free cashier. A medical history is important to the doctor. Without a card here anywhere. You guessed the decision - to give access to this card to each doctor. And in the case of our Nicholas, show agents the history of customer requests, so that even an employee can help any employee.
Usedesk will cope with this , which stores the client card with up-to-date information about the interaction and comments of previous employees.
So the client does not depend on the “employment” of the personal manager, and gets a decision faster. Any agent will respond in seconds without spending time clarifying the details.
3. Universals vs narrow specialists
If there are universal fighters in your team, you distribute requests automatically evenly. This ensures that everyone has something to work with, without taking into account the subject matter and skills of the employee. But the bigger the team, the harder it is to maintain the same skill set for each agent. And complex issues require the use of other departments. Therefore, areas of responsibility are shared either within the support team, or between departments in the company. Some are responsible for choosing the size and color of the dress, others for communication with the courier, and others for returning money. This is the next step after sorting and prioritizing - to route the question to specialists.
Let's see how to do it.
1. Offer to formulate a question and choose the addressee to the client himself. We place on the site addresses of all departments of the company, and the client puzzles his head where to write.
On all sides, the option is so-so. The client does not guess the direction and grow old in anticipation of a response, and we will have to endlessly send letters from department to department in search of a responsible person.
2. A sparing option with elements of elegance: letting you choose a topic of appeal from the list. A great way to sort questions before they get into the support system.
The topic has already been determined, the support will not have to additionally review the contents of the letter and isolate the essence, it remains only to address the person in charge. It is great to simplify the task in setting up the processes inside the support and in further analytics. But try not to tire the client with a choice of 100,500 themes. And do not forget about the universal “other” - the client will be offended if he does not find the necessary subject matter.
3. Let customers write to one address, without thinking about the wording, we will sort on our side. To do this, we set up rules in Yuzdeska , which, according to the conditions, assign tags to requests and assign them to a responsible specialist or group. All questions containing “labutenes” are immediately sent to Nikolay.
We shift the responsibility for sorting and routing to the robot, so you have to tinker with the configuration. To whom to assign a letter depends not only on the content, but on the channel and the time of access, priority, status, and so on. We load as many complex logic as we like, and then with enjoy the work with the assigned letters without confusion. Even if the system was wrong and the request did not go there, it is easy to reassign it manually.
At this interrupt, and next time delve into the details. How to divide a team, who to skip out of turn and for what to use task branching. In the meantime, go share in the comments how you handle the queue.
Source: https://habr.com/ru/post/298884/
All Articles