UseDesk меню


Katerina Vinokhodova
UseDesk Co-Owner
In early December, Nick rubbed his hands when he reviewed the sales statistics. The number of orders has nearly doubled compared to November, and it was a promising month that was expected to result in January vacation in Krasnaya Polyana. By December 20, the sales began to decline.

The support inbox turned into a fairy tale pot that kept brewing without stopping, and even the magic words could not help. He started answering incoming requests by himself, and even this did not help the customer support team to handle the stream of tickets. The response time was too long; customers were getting angry and ordered in other shops.

Why Nick's team was not able to handle an increasing amount of support requests before the New Year? Nick did not consider the workload. When he was attending the university, he skipped Mass Customer Support Theory classes, and now he did not calculate the number of employees needed during peak periods. On top of that, the team processed the tickets in chaotic order without a clear plan, and this approach contributed to the fact that the team ended up catching the tiger by the tail.

We are not going to blow your mind with the MCST formulas rather we want to introduce the strategies for managing the queue of incoming emails, and describe the principles for email organization and better queue management. We will explain in what way and in what order you need to reply to the customers so that they don't get angry but happy with the service. Let us share three helpful tips with Nick and you.
0. Here it is — an Easy Life Hack
Cut down the queue by creating a knowledge base on your website. Choose a location for it such that the customers can easily see it. Dedicate a section in the knowledge base for FAQs, or provide the answers to commonly asked questions on each relevant page where the customers are more likely will search for the answers.

For example, the customers just piled up Nick's email with questions about time and cost of delivery. If he had posted this information on the website page containing the order form, he would have saved both customers' and support team's time. Remember, the best customer service is no service. First, think about a way to drastically cut down the amount of the requests. Well, let's move on.
1. First — come, First — served vs Sorting and Prioritization
For smaller teams, the simple principle of "first — come, first — served" will work. This means that you process the old requests first. That is actually the path that Nick's team followed. However, the troubles began with the difficult questions and claims. The customers wait for a reply for too long, even longer than they have patience for waiting for a response.
Not all requests are equally urgent. The goal is to identify the most urgent ones.
Therefore, your job consists of two tasks:

Sorting — that is, split one large queue into multiple small flows based on some factors. You can use such sorting factors as the subject of the request, value, complexity of question, first letter of the client's name, or color of client's eyes.

Prioritization — identify those customers who can wait and those who need an urgent help —
blue — eyed or green — eyed customers

Let's have a look into Nick's inbox:
The oldest letter takes priority over the other ones.

However, if you look at the customer type, then VIP should have the highest priority.

If you look at the subject line, then "URGEEEENT" seems to be a hint also.

Hmm. So each of the letter can be prioritized depending on the parameter chosen. To solve the problem, you need only to answer the question: what is the most important in each email?

Let's recommend Nick to prioritize the parameters as follows:

  1. Subject
  2. Customer type
  3. Request's time and date
Now, we will add a little magic. Let's go back to the table and turn every data point into a number. We assigned each data point a score, where 3 is the most urgent, and 1 - can wait. Then, we multiplied each score by the level of importance of the parameter.
Here we go! That was a smart idea to add "URGEEEENT" into the subject line, and that guy got an answer first. Thus, let's correct the sequence of the steps:

  1. Sort the requests by the parameters
  2. Determine the importance of each parameter
  3. Assign a priority to each parameter's value
Now, when you have determined the order in which the requests should be taken, let's define the way to allocate them within the team, and identify who answers what.
2. Are you the last in line? vs Next customer, please!
These two approaches of ticket queue management are well known.

Remember when you were a child, if you needed to visit a doctor, you came to a hospital during the doctor's working hours and shouted: "Who is the last one in line?"
The rule was strictly observed as you did not have a choice to visit another doctor unless your health was in a critical condition. The structure was clear: the city was divided into districts, where each district was assigned with the district doctor, who knew everyone since their childhood; and the doctor kept a record of your illnesses, usually, in an incomprehensible handwriting.

If we transfer the structure to the customer service sphere, you as a patient would be a regular customer, and your doctor would be your account manager. He keeps track of everything happened to your body and knows how to help. It sounds good but, in reality, when you have a temperature and runny nose, you face a long line with about 10 people going ahead of line and sneaking into the office just to "quickly pick-up a medical certificate".

The problem of "attaching" the customer to the agent is that the customer's request may be stuck in the agent's queue while the agent is busy with another customer.

What it would be like if the doctors worked in the same way as McDonald's? The total line can be divided into the sub-flows that are directed to the open cash registers.
In this case, the first available agent serves each new customer. Imagine that you do not have to wait in line for the district doctor working in office 9 but you can go to any other doctor because it looks like another doctor is attached to the district where people get sick less often.
— Can I see your personal health record?

— Oh, it is in the office next to yours!
Here, we faced another approach to queue management. People coming to MacDonald's have a new request each time. Therefore, a customer can easily be served by any available cashier. However, a personal health record is necessary for doctor's service. He can't do anything without it. I believe, you've already figured out a solution which is to enable access to the patients' records for every doctor. In Nick's case, that would be good to provide the agents with access to the history of a customer request, so that even VIP — customer can be served by any agent.

UseDesk can help with that as it keeps the relevant information, updates on the communications with the customer, and all the notes and comments of the agents on the customer file.
Thus, the customer's service is not dependent on the workload of his account manager, and the customer's request is resolved faster. Any agent can pick—up the ticket and reply within moments, without wasting time on clarifying the details.
3. Generalists vs Specialists
If your team consists of universal fire fighters only, you distribute the requests evenly. This ensures that everyone has something to work with, regardless of what the subject matter of the request is and what the skills of the agent are. But if you have a larger team, then it becomes more difficult to maintain the skills of each agent on the same level.

Further, the complex requests require involvement of multiple departments. Therefore, the responsibilities should be distributed either within the support team, or among the departments of the company. Some of employees are responsible for finding a right dress size and color for the customer, while others - for the delivery, and a separate group handles refunds. When sorting and prioritizing of requests are done, the next step is identifying a way of how to route a question to the right specialist.

Let's see how to do it:

1. Let a customer to write the question and choose whom to address it. On your website, place the contact information for every department, and let the customer solve the puzzle by selecting a right addressee. Obviously, the option is far from being the best one. The customer is likely will forward a question to a wrong department and will reach his golden years awaiting an answer, while we will endlessly forward the question from the department to the department searching for those who can answer.
2. A gentle option with elegant elements: let the customer choose the subject of the request from the drop-down menu. This is a great way to sort questions upfront, even before they are submitted to the support team. Let's see how to do it:
When the subject has been defined, the support team does not need to read through each message to figure out its content, all it has to do is only to assign the request to the appropriate agent. This significantly simplifies the organization of the processes in the customer support, and helps to organize the analytics data. However, make sure you don't annoy a customer by giving a list with 100500 subject lines to choose from. Do not forget about the catchall "other" option. The customer is not going to be happy if he does not find the subject that fits the request.
3. Provide just one email address for the customers, so they do not need to think about the subject, and we will do that filtering job on our side. To implement this idea, enable the settings in UseDesk that allow automatic adding the tags to the requests according to the selected rules, and assigning the appropriate specialist or a group of agents. For example, all questions that are related to "louboutins" go straight to Nick.
Thus, we delegate the job of sorting and routing the requests to the robot, and we do not spend time on the system configuration. Decision about whom to assign the request depends not only on the request content but also on the channel, the time when the request is received, priority, status, and so on. We can set a very complex logic, and then enjoy working with the assigned requests avoiding any confusion. Even if the system routed a request not accurately, you can easily re-route it manually.

Let's pause here. Next time we will go into more details: how to divide a team, which customers should be served ahead of line, and how the task differentiation can be helpful. Meanwhile, please, share your thoughts in the comments. How do you manage your ticket queue?
Did you like this article?