Mobifitness: fled to Usedesk to solve non-standard tasks

I have been working at Mobifitness for a little less than two years. When I arrived, the company already had a helpdesk system - a competitor to Usedesk. We did not like many things there, for example, it is very important for us that the technical support of the systems we use is also at a high level, as we have about our clients. In the previous helpdesk system, the support responded once a month at best and usually refused a request to solve a non-standard problem. Plus, they do not accept requests in Russian, so we had to translate questions into English, the essence of which they did not always understand and could not answer. And the guys from Usedesk always listen - they are ready to help and offer options for solving non-standard problems themselves.

It was not me who selected the replacement for the old system - our leader decided everything. He says we will go to Usedesk, to these cheerful guys - look, try. I tested the system for a very long time, tortured the managers and technical support of Usedesk. I liked the abundance of functionality and the ability to connect different channels and services seamlessly. For example, we very easily connected UIS and Telegram telephony without sending a bunch of letters to technical support. I understand that our previous helpdesk system has similar functionality, for example, the same widgets. But for us, two parameters were decisive in the choice at once - functionality and technical support.

We have universal soldiers in technical support, but each has some of his own skills, which he has pumped steeper than others. Therefore, we set up several rules in Usedesk so that when a specific task comes from a client, a ticket for word forms is automatically assigned to an employee who is more advanced on this issue. We do not have many such rules - this is more suitable for guys who have many employees and have a clear separation. We are still kids, but after the expansion, which we will soon implement, we will actively use this functionality.

We have auto-replies set up everywhere, except for Vkontakte - there, we have a single group where they write about marketing and technical support. It's cool that the skip can be configured for each channel separately because it is different everywhere with us. Immediately after sending the request, the client receives a notice that we received it, indicating the number of the application and the time when we will respond. Sometimes the client can be worried and call - then it will be convenient for him to give the application number and immediately receive an answer.

Now we are still working from 10:00 to 19:00 from Monday to Friday, and on Sundays, we only respond to written requests. But very soon, we will switch to 2/2 - the break will only be at night. I really like that in Usedesk, you can set the opening hours of your office and department and prescribe rules for different situations. For example, if the letter arrived on a weekday morning, the message's text will be one, if on Friday evening, it will be different. And if the client writes through the widget, then, in addition to skipping, a message is added to the auto-reply stating that the answer will come to the mail. The fact is that the widget is located on our site, where the client works - the page is constantly updated, so we will not respond to it in the widget.

Sometimes it happens that a client contacted support, he was asked a clarifying question, and a ticket was put on hold. But the client himself figured out the problem or the task became irrelevant, and he no longer responds. The ticket should not hang for years; therefore, after a specific time, the client receives a message with a reminder, they say, we are waiting for information from you. If the client is silent, he gets the second gap, where it is said that if he does not answer, the application will be closed after a particular time. If we still do not receive a response, the application will automatically complete after 72 hours.

Also, even though we are B2B, sometimes there are situations when our clients apply on behalf of their end customers, for example, visitors to fitness clubs. They describe the problem; we ask the client to clarify something because, according to our internal rules, we do not contact the end client without the club's permission. But next time, a client may come to a fitness club in a day or two, and then they will not answer us right away. So, therefore, in the auto-disclaimer about the closure, we write, they say, guys, if the problem has not yet been resolved and for some reason, you could not provide information earlier, you write, the application will be reopened.

I don't particularly appreciate that employees can change the SLA of the ticket. Fortunately, now my team is small, and I trust everyone, but soon we will begin to expand, and I am not satisfied that the new guys will have the opportunity to correct the SLA to meet the deadlines. We discussed this for a very long time with the support of Usedesk, because technically it is not easy to implement restrictions for specific employees on some actions. Still, the guys met me halfway and took the task to work.

And since it won't be fast, tech support suggested a temporary solution to me on how to track changes to ticket SLA. I have my chat with a bot in Telegram, just for two. I set up a post-request in Usedesk, and now the bot sends me a skip every time one of the employees changes the SLA in the ticket: "Employee so-and-so changed the SLA in such-and-such a ticket." If it happened within the framework of my rules, I do not react. And if I see that this is incomprehensible, then I just copy the request number, climb into Usedesk and figure out what happened there.

From the bot's message, I immediately understand whether it's worth worrying about. The fact is that we have different SLAs for different types of tasks. For technical support, the first response time is one hour, for implementation - four hours. And it happens that the client applies for the performance, but he formulates the question so that, according to word forms, the rule in Usedesk assigns him to a technical support employee. When he opens a request and sees that this is not his profile, he immediately reassigns the ticket to a colleague from the implementation. The time of the first response in the ticket automatically changes from one to four hours - this is normal. If I see that a technical support employee has changed the SLA for implementation in his ticket, I will immediately understand that he just wants to get more time to respond. Fortunately, I did not have such cases, but God takes care of him.

Another example of a situation with a change in SLA is the transfer of a task to development. For development, the deadlines for a response are even longer, so when a technical support employee transfers a task to the developers, he changes the SLA in the ticket and leaves a comment with a link to the task board. The development does not use Usedesk - we create all tasks on our internal board with the comment "Ticket for support" and a link to the ticket in Usedesk. Suppose I see that an employee has changed the SLA for development, but the card on the board does not contain a link to the ticket in Usedesk with a comment, and the ticket contains links to the board with a task for developers. In that case, I will immediately go to him with questions.

Even though the SLA is displayed in the tickets and the counter ticks, it is also displayed in red for overdue tasks; it is still not always noticed. It was my pain because we also answer calls and textual consultations; that is, we are often distracted and may not notice that the response time has expired. With the help of Usedesk technical support, I solved this problem in four minutes via a post ticket.

In two minutes, I created a bot and took another two minutes to configure it in Usedesk. And now, 15 minutes before the end of the ticket period, the bot tags the responsible employee in our internal telegram chat with a reminder that the deadline is on. This is very important for us because now we all work remotely and sit on Telegram. And since this is our primary communication channel, we notice messages in it immediately, unlike mail, to which a reminder can also be connected in Usedesk.

Tags in Usedesk are what I fell in love with at first sight - a very cool thing. For example, if some accident occurs, I put tags on tickets with error messages, and without any extra effort, I get reasons to go to the manager and say, look, we had a problem here, here, and there. Or, banally, an analysis of the victims. After all, tags can be added to call tickets. By tags in written and oral communications, we can see how many customers were affected.

After all, when the problem is solved, and the programmers can relax, the very peak of work begins for technical support - you need to notify all the victims. It takes hours to unsubscribe dozens or even hundreds of users manually, and in Usedesk it takes about three minutes. Using a trigger rule, we send a message according to the template to all clients in whose hits there is a certain tag. For example, all clients with the tag "Accident of such and such a number" are sent the message "The accident was eliminated ...". It doesn't matter how many victims - 3 or 103. This saves us time at times.

Tags are beneficial when we have an update. As requests come in, we tag all tickets in which customers ask about the same feature or some client's problem is not solved without it. When the update is ready, we simply bulk send this tag, and it is automatically removed. One click - and all clients waiting for the update are aware; the tag is no longer needed.

We have many tags; you can hang everything on them; any rule is a very cool tool.

Immediately after connecting UIS telephony to Usedesk, we had a sharp jump in applications. The fact is that our entire office uses the dialer, including the sales and marketing department, who also answer calls, while Usedesk is only for support. As a result, immediately after the integration, Usedesk sent us a fierce amount of tickets for all calls. It doesn't matter that the employee is not in Usedesk - system sees the call and creates a ticket.

When we found this out, I wrote to the guys from technical support, and they sent me detailed instructions, according to which I set up a rule in UIS in 15 minutes. I entered the extensions of all employees into it, and now, the call turns into a ticket only when the number from the list is included. That is, now a ticket is created only when a technical support employee answers the call.

All calls are saved on the client's card, but it is not always convenient to listen to them. And here is precisely the same wish that I am going to send to Usedesk: it would be great to transcribe the call so that you can download it, listen to it, and read it in text. This would significantly speed up our work because it can be trivial: an employee went on vacation, transferred all the cases, but forgot or thought the problem was solved and closed the ticket. And then the client suddenly appears. We have already discussed this with the support guys before - they say that, in theory, it is possible. So now I just have to send them a request for this feature.

There is also an interesting thing that will come in handy for kids. After connecting UIS, we wanted to send customers a skip with a proposal to evaluate the technical support operator's work quality. That is, we needed to configure the system so that the message "How do you rate this call?" left only to those customers who call technical support. We discussed this for a long time with the Usedesk guys, they offered several options that did not suit me, and as a result, I was able to set everything up myself. When I told them about my method of technical support, they replied that they considered this option but did not offer it because it would violate the statistics for the channels. But I don't need it, so this method turned out to be perfect.

Now, after the call ends, Usedesk itself checks whether the client who called has e-mail; that is, we wrote it down on the card or not. After all, our end customers can call; not all callers have cards in Usedesk. If there is mail, the channel is automatically changed from UIS telephony to mail, and the Usedesk bot sends a message to it: "You spoke to the employee [Name]. How do you rate the call? "And then a link to the assessment. I understand perfectly well that such a solution is not suitable for those interested in seeing channel statistics. But for those who do not care about it, it will help out a lot. After all, we did not set up estimates on the UIS itself, but here we could do such a thing for free.

I have set up a rule that sends "Bad" and "Normal" ratings to my Telegram - I look through tickets with an "Excellent" rating later. In Telegram, I receive the ticket number, rating, comment, and which of the agents was given this rating. In Usedesk, you can automatically send a message in response to a negative rating with a question that you didn't like, but I'm not for that. I prefer to look through each ticket myself and delve into the problem. Fortunately, we have few negative assessments.

I was delighted with the knowledge base in Usedesk, which we created for our clients - the guys from the technical support transferred it from the previous helpdesk system. At first, I didn't really like the design, but then I was told that it supports CSS styles, opened them, started working with them, and went well. In it, you can customize everything for yourself, right down to the font styles - it's very cool. Our knowledge base for clients is located in the Usedesk widget and on our website as a direct link to the Usedocks.

Every Monday morning, we review the data for the past week - general statistics on SLA, CSI, and the number of incoming calls. Be sure to look at the percentage of open tickets at the end of the week. These are currently open tickets, but for some reason, they are on hold or pending; that is, we are waiting for a response from the client. Channel statistics are not important to us, so we don't look at them.

We analyze customers' wishes. Conveniently, you can highlight statistics for the tags that interest me. I can save them once and regularly view statistics on them. These are tags according to customer expectations - I use them to view wishes. I come to the development and say that I have already accumulated so many such wishes from clients that I need to do something about this. I understand that we had it in our plan, but judging by clients' tickets, the priorities are changing. In such cases, I ask the developer to adjust the plans and first do what is more important for the clients.

Separate tags are configured for my calls. That is, for each incoming call, the "incoming" tag is immediately triggered, and a responsible employee is assigned. This is necessary so that you can work with calls separately.

Motivate employees. Quarterly employee bonuses depend on the percentage of customer satisfaction, which is formed on the basis of SLA and CSI for the month. We have different requirements for implementation and technical support, because they have different processes, tasks, their execution time and communication with other services. We keep statistics and take everything into account. For example, when I see that a client gave an employee a rating of "bad" or "normal", but from the point of view of our work, everything was done correctly, I ask the client what exactly is wrong. Sometimes it happens that a customer accidentally presses the wrong button. Then I do not include this ticket in the statistics, and it does not participate in the selection either as a plus or as a minus. On the basis of these data, the awards of the department are built. In the report, you can see statistics for each individual agent and, based on these data, calculate the percentage of bonuses for each, but we have a motivation system set up for the entire department - we are guys who are one for all and all for one.

Now we are rebuilding our implementation work system and will attach clients to an employee. We will know that this employee is dealing with these clients so that when he calls, we immediately know who to transfer to. We also have expansion plans soon. When we recruit new employees, we will begin to use auto-assignment of requests at the entrance more actively than now. And I will finally find the time and send the rest of my Wishlist to Usedesk.