Life hacks from Haier: they launched high-speed processing of tickets from scratch

Initially, Haier household appliances were sold through distributors. Since 2017, the company has launched online sales and brand shops.

Before the 2020 pandemic, sales were growing smoothly, and support was outsourced and consisted of two parts: online store support – ordering, delivery; after-sales service – requests for repairs, maintenance. Each unit had different curators.

But with the beginning of quarantine in 2020, sales through the online store have grown significantly, and behind them the call center began to develop. Since mid-2020, we began to transfer support to internal competence and build a call center within the company. We immediately created an adult unified support system, relying on the international COPC standards of the best industry experience in recent years.

My experience with Usedesk as the main helpdesk system started at Haier. Before that, I worked with their competitor, but it turned out that Usedesk is a pleasant alternative to a foreign solution. There are two reasons why we chose Usedesk: it is easier to configure and it is cheaper. Its competitor has a rather complex logic for setting the rules, and in Usedesk it is implemented in a more native and modern way. It was nice to see that they have made a big step forward in recent years and added many useful features.

In my 10-year experience of working in support service, I set up various helpdesk systems – I formed business requirements and business processes. Therefore, after joining the Haier team and starting to rebuild the internal call center, I consciously set up the helpdesk system to shorten the processing time of requests as much as possible.

My advice, if you are just implementing a helpdesk, is to start with one channel:

• Set up a funnel for incoming calls.
  
• Connect an auto-response system.
  
• Set standards for employees.
  
• Enable reminders for them.
  
• Set up analytics and quality control.

And when everything is ready, it is easier to connect the remaining channels according to the same principle – no matter how many there are, five or fifteen.

The concept is to tag incoming tickets as much as possible by subject matter and priority at the system level. Then, based on these rules, tickets are put into the necessary filter queues, with different skill groups of employees. If, after automatic filtering, a ticket has ended up in the wrong place, then the agent manually tags it by assigning the desired subject of the ticket, and the ticket is included in the required filter. Suppose everything is configured correctly in the system due to the correct distribution of tickets across channels and competent work with priorities. In that case, there are several SLA levels depending on the complexity and importance of the ticket – the processing time of tasks is greatly reduced.

We have several skill groups within each of the two partially interchangeable directions. That is, inside the direction, employees are universal specialists, and now we are all agents, for with the exception of beginners, we include them in all skill groups. With our specifics, this is more convenient – this allows you to distribute the workload between employees as efficiently as possible and quickly respond to a sharp influx of tickets on some topic. Thanks to the statistics that Usedesk collects, we see the situation with incoming tickets (where employees have time or do not have time), and SLA begins to "sink" based on how quickly the queue is assembled and how much time is spent on processing. Depending on this, we reinforce this or that channel with agents.

There are two options for the agent to process tickets:

• The agent takes turns processing tickets from the list, which is formed from all queues of its skill groups in order of priority by SLA.
• The agent sees filters by subject and chooses which ones to process first. For example, we see that now we have many tickets dropped into the "delivery" filter, so we operationally increase the priority of their processing and postpone the remaining tickets, on less active topics, for several hours.

We are also experimenting with the settings of filters, tags, and automatic rules in Usedesk in order to choose the optimal scheme, taking into account the peculiarities of the business and the profile of the distribution of the incoming stream by time: days, weeks, months. After all, the smaller the volumes, the easier it is to maneuver, the less they need for streaming processes and the more you can use an individual approach to different client situations. The higher the load, the more important it is for the agent to work with the tickets and topics offered by the system without thinking about the choice. With a high load, the distribution of agents by skill groups and levels becomes more relevant: the first, second, and third lines of support.

For example, say you want several agents to constantly and consistently deal only with delivery. You create a delivery skill group, add the necessary agents to it, and set up tags and filters so that participants can only see a list of delivery tickets. As a result, they only answer shipping questions and don't take on other tasks. This approach helps the agents of the skill group to work faster, as it saves them time and intellectual effort in not having to switch between different issues.

At the same time, from the point of view of a set of knowledge, agents can be universal and from shift to shift, they can be transferred from one skill group to another. For example, today an agent is in a skill group for delivery, tomorrow for warranty calls, and so on in a circle. This allows very flexible distribution of the workload between employees depending on changes in the flow of incoming calls and makes them interchangeable.

We immediately set up a funnel for the incoming message flow, and in the end, we did a very good job: they managed to process tickets day-to-day and fulfill SLA well. We managed to realize the old dream of all support services – the client receives the first response within an hour. Questions that require several iterations are solved on average in a day, and almost never longer than three days – in situations where additional information from the client or the participation of some other services is needed.

To prevent agents from monitoring the status of tickets manually and "copy-pasting," we have set up three levels of auto-responses for incoming tickets: a standard message about accepting an application, a reminder, and a close.

Depending on the topic of the tickets, we understand how long it takes on average to process it. On this basis, we define the standard. For example, if it takes an hour to respond to a specific topic, the agent can process seven tickets of this type in one eight-hour working day. If the processing of the application takes a minute, then the standard, respectively, is different.

The most interesting thing is how to use the system to configure the distribution of simple and complex cases among agents.
There are two options:

• For general employees – one standard for all; the system offers the agent tasks of different complexity in a balanced way.
  
• For employees with a narrow specialization, there are different standards; some take only simple cases, and some only complex ones.

For example, right now we do not have a clear distribution of agents by specialization – they are universal in terms of the set of knowledge. Therefore, at this stage, we set performance standards based on the average ticket processing time. In the future, when the volumes grow, I think we will switch to a different scheme for distributing the load and assessing the effectiveness of employees.

Now we look more at the number of ticket iterations – we highlight tasks that require more iterations. This is necessary to understand why there are so many iterations and find a way to reduce their number. If this is not possible, then we try to automate some iterations and further speed up the processing of tickets.

For example, we had a situation where an agent quite often had to remind a colleague from a neighboring department that we were waiting for him to answer on a task. Seeing this, we configured SLA-based proactive automatic pinging of the adjuster. Now, if an agent working with a ticket receives additional information from a subcontractor, he uses the "On Hold" status. Such a pending ticket goes into a separate filter, in which a rule is set up: when the deadline approaches, the subcontractor receives a reminder to resolve the issue.

Depending on the topic, the business process for handling tickets is slightly different. We have described all business processes, so we know the time it takes on average for each stage and how to iteratively optimize it and manage the distribution of intervals between reminders.

Suppose we want to solve a complex client issue in three days. In that case, we arrange the processes internally so that all iterations fit into those three days, including internal communication with related departments and the possible need to obtain additional information from the client. For example, if we need to do three reminder letters on topic X, we allocate a maximum of 12 hours for each. That is, each topic has rules that specify the timing of auto-replies.

We look at daily, weekly and monthly analytics, depending on the tasks for optimizing the processes we have set ourselves. We use statistics from Usedesk for operational control and analytical work – these are two separate blocks. The task of operational control is to timely identify and fix problems in the work of operators; the task of analytical work is to detect systemic problems in the work of support, if any. The most interesting thing is to find growth points and areas for improvement.

Operational control. Supervisors and team leaders from the QA department do a high-level check daily that employees meet the SLA and look at the time between iterations. For example, say an agent took the first ticket at 10 a.m., the second at 11 a.m. The interval between the "completed" status for the first ticket and the "in progress" status for the second is half an hour. This raises the question of what the person did for half an hour.

Within the framework of weekly and monthly checks, Quality Control analyzes the work of support in detail. We use one of the basic rules of Usedesk, according to which, after completing a ticket, the client receives an automatic message with a ticket to share feedback on the quality and speed of resolving his issue. Team leaders review these ratings daily and individually check badly rated tickets. You can look at all the tickets with negative ratings and then see a breakdown by agent to see which agent has the most negative reviews.
The same goes for the topics – you can see a breakdown in order to understand which of them are difficult and cause negative assessments. Sometimes such applications are reopened and agents are finalizing them. Sometimes they are based on the subjective opinion of the client, but it also helps a lot to work on the tone of communication and business processes in general.

Analytical work. Regular reporting very clearly shows all the looming drops in key performance parameters in real-time, especially if you have customized it to suit your needs and it starts "talking" to you. This allows you to either increase the power promptly or make other changes that help employees to flexibly adapt to the changing load of the incoming traffic flow.

Right now we have connected only mail and debugged processes on all mail channels. According to the same scheme, we are preparing to connect the chat on the site, and after that, the chat in the application.