UseDesk меню


Katerina Vinokhodova
UseDesk Co-Owner
In young and inexperienced companies, as well as in big and strong companies, troubles with support are mainly caused by the mistakes at these three stages:

1. Receive a request
2. Process a request
3. Collect the statistics

In these series of articles, I am going to tell about the specifics of the processes at each stage. Let's start with receiving a request.

Today we will analyze three typical mistakes in setting the procedure of receiving a request, and cases when good at first sight ideas appear to be not so good when they are implemented not thoughtfully.
Let's display several contact emails
Idea: the customers may choose the email to contact the right department. Thus, we will not need to forward the messages internally, and we will not need to involve an employee in requests distribution work. Moreover, we will display the boss's email so the customers may contact him directly!
Here, they added a routing to different departments
Reality: This will never work. And this is what will happen next. The customers see many email addresses on the webpage, they get lost and make the wrong selection. The employees then continue forwarding the emails from one department to another department and spend on it 30 minutes of working time. At the same time, not every specialist knows which department should handle the request and eventually forwards a request into the wrong direction. The email should be addressed to the technical support but it is sent to the general support. Even worse, the email can be forwarded twice: Outlook does not show whether the email has been forwarded by one of your colleagues, it can be that the email has been forwarded to the accounting department an hour ago. Overall, the important emails got lost, problems are not solved, and the customers are angry.

Then employees start to invent additional internal steps. Maybe we can add everyone from our team to CC when forwarding a request to another department, so that we know that the email has been forwarded? Let's schedule a meeting for a couple of hours to define the procedure and set the order of email forwarding, agree on the format and timing? All this garbage will never work.

When the webpage contains a list of emails, it's easy to make a mistake and choose the wrong addressee. For example, the webpage says: "Accounting — issues related to payments". What if my question is how much do I pay under the tariff? Is it related to payments, or is it a general information? It is not clear. How does a customer know which "issues related to payments" are handled by accounting?

How this should be done: one point of entry is an ideal option for the customer. He does not need to think about which email address to use. Give him one email address. A customer does not care what you do to distribute incoming requests.

— And who will re-direct the emails? Now, at least part of the emails are addressed correctly!

If requests from outside come to different departments, the first step to manage distribution is to replace a bunch of email addresses with a customer request submission form where the customer may select the topic of the request. This form can be linked to appropriate email address depending on the topic.

By offering a customer a list of questions instead of a list of emails, you help to correlate the problem formulated in the customer's head with the proposed topic. Thus, you start speaking the same language with a customer.
Request submission form of online store – many topics but it's easy to choose the one you need
If you formulate the topics in a right way, the number of mistakes in requests distribution will go lower. But what to do with emails that still are sent to the wrong direction?

The second step is to relieve the team from forwarding the emails within team. To do this, all customer issues need to be reviewed in one application. There is no other recipe. Only the application accessible by each employee can reduce team's pain. The chain of steps to deliver problem solution can be followed here, as well as you can see which department's action is pending. Even given that the support team of the first line has implemented the helpdesk, still in order to forward a question to the operators of the second line they need to use Outlook, Skype, Slack, and so on — the chain is broken. Thus, you cannot view the final solution in the helpdesk, while, on the other end, you cannot view the beginning of communication in Outlook. Therefore, when the customer gets back to an operator of the first line, he will not be updated as the status of the solution is not available to the operator.

To delegate issues, UseDesk has a feature allowing to assign a request to a group or particular employee. Just one click and the request does not get lost. The departments that only help the support in answering customers' questions and this is not their main activity, are not required to have an access to the program just to wait for the ticket to be forwarded to them. If they got used to working with emails — no need to change it. You can set up notifications so that they are sent to email and reply to the request straight from email. The comments are pulled to the request and the whole chain is saved in one place.
Internal comments allows tracking the conversation with other departments
The third step — is to automate the customer request distribution. I've already described it in the article about automation.
We need more communication channels
Idea: We'll create the pages in social networks, accounts in Telegram, WhatsApp and Viber + live chat on the website. Customers will like it — they will be able to contact us in many ways, we give the options to choose from. It's 21st century out there! This will make us to stand out from competitors.
Reality: The group in is managed by SMM agency, they cannot answer any customer question and forward them to customer support via email.

You receive at best one message a day through the messengers, or, at worst scenario, the employees jump across several windows, answering the typical questions that are available in the knowledge base on the website. However, SOMEHOW, stupid customers do not read the knowledge base but contact the support team. When it comes to tickets that are to be resolved in collaboration with other departments, it is a complete mess.

The customer writes in Telegram:
— I have got an error 500 on the webpage, I cannot complete payment.
— Please, send me a screenshot!
— Here you go.
— Thank you, we will forward it to the technical department and will get back to you. Please, try to pay later ...

Then, this is what is likely to happen next internally. The employee sends an email to the technical department. This is the first call — the communication moved from Telegram to another communication channel. It is good, if the employee sets himself a reminder not to forget to "chase" the technical department, or, at least, makes a note on a piece of paper — "TECH, follow-up in an hour." The technical department celebrates March 8th today and will open your email the next day. Then, they will start exchanging emails and at some point someone is going to write: "you have missed our email that we have sent you before."

Meantime, the customer reaches out again — the error is still there. This request is assigned to another employee, who is not aware that the technical department is already working on this. He sends duplicating request to the technical department. You can imagine what happens next.

How this should be done: The customer is fine with contacting you via any channel. What he really cares about is to have the problem resolved. Preferably, within 3 days. If you operate better using a phone line — let customers to contact you via the phone. If you are not good in phone conversation — let customers email you. What is the purpose of having a messenger or chat, if the employees do not give quick replies there? You are expecting to delight the customers offering them new communication channels, but they are getting upset as these channels have a decorative fucnction only.

In order to implement new popular channels, you need to be able not only to receive the messages but actually solve the problems through them. The communication history should be accessible from any place — messenger, chat, email and phone. The second task is to figure out how to handle "long-term" problems that cannot be resolved online.

To do this, we have combined UseDesk with WhatsHelp. This program allows the employees to process messages from Telegram, Viber, and Facebook in one place. Now a conversation with a customers in a messenger is submitted as a request from WhatsHelp to UseDesk, moreover, the communication history is saved. If you need to involve other departments to assist you — just reassign the request and the work continues. If the customer prefers to be contacted via email — you can send an email right from UseDesk. The whole communication chain is stored in one place.
Conversation in WhatsHelp is duplicated in UseDesk
We will provide a ticket number to a customer
Idea: We will include ticket number in auto-reply message. Let a customer know that we have registered the request. It will increase customer's trust. When he calls and asks — 'what is the status of the ticket number 100500', we quickly find a ticket and answer!

Reality: Nobody knows what "ticket" is and how to find it by its number. The same is with order number, or voucher/invoice/mortgage/transaction/and other internal numbers. The customer has asked about a ticket, but where you find is not clear, you looked everywhere, and the results are — "I will call back later" and no progress on the issue. Overall, the team spends even more time to locate a ticket rather than solving the issue.

How this should be done: It could be a better idea to include an expected response time in auto-reply message, so that the customer would not be worried and would not send you tons of chasing emails.
If the customer reached out again, you can identify him by the details he provided upfront: name, phone number, email, issue.

Don't make the customer to memorize your internal identification numbers. Further, if you have communication history stored in one place, for example, in the customer's profile, finding the relevant ticket is easy regardless of who and when communicated with the customer before.

Giving the ticket numbers to customers is not a crime, if it only helps in your processes and does not ruin the impression of customers. If your team got used to the system with ticket numbers and your customers got used to provide a ticket number each time they reach out, and also they never change the email subject — this deserves an appraisal.
Things to remember
Do not give customers more than one email address on the website. Group the questions by topic and provide a request submission form. Use helpdesk to manage ticket distribution internally.
All communications via various channels should be stored in one place. Do not add new communication channels, until you define the processes in using the old ones.
Use customer identification methods that are preferred by customer not by you.

Olga Kuznetsova
Director of customer support department at HeadHunter
That happened about 4 years ago, I was a speaker at a conference, and the topic was "Best way to build customer feedback form". I've started my talk with the statement that I was not going to discuss process of handling the complaints (only lazy ones have not talked about it yet), but I wanted to talk about the submission and processing other types of feedback. Somewhat, a third part of an audience left the conference room at that point.

Now, the situation is changing: companies are starting to understand the importance of working with all types of requests and not only with complaints. We see the attempts to systematize procedures of feedback submission almost everywhere. The number one task now is automation and finding a right solution to handle the feedback submission. I'd like to point out two things here:

1) When creating an algorithm of submission and processing the feedback, always keep in mind a picture of a full lifecycle of incident management – include every phase of the lifecycle into the algorithm. The company is interested in not only closing a customer's incident but in solving the root cause of the problem as such. Meantime, we still see the same picture – the incidents are turned into problems, and companies react on them only when a customer's complaint has been received.

2) The process of feedback collection should be implemented in each communication channel you use. Not only in the voice channels. For example, a customer is having a phone conversation with an agent, and the customer shares some ideas how to improve the service, and the agent instead of noting the request and sending it for further processing, says - "you can write it in a special section on our website, thus, someone will read it".
Did you like this article?