UseDesk меню
Request a Demo
Send us a request for an online demonstration at the time that's convenient for you. We will give you an overview and answer any questions you may have about the system.
Select Time and Date
Company information
For example, write how many support employees you have now, which channels you use, how many calls you receive per day, etc.
By clicking the button, you agree that you have read our Privacy Policy

[Voice of the Customer]: Support at iGooods on steroids

We talked to Andrei Scherbakov of iGooods about how to use all the features in Usedesk, help customers in 25 channels, and handle a 10x increase in calls. We got a useful longread for everyone who wants to set up customer support and run the helpdesk seamlessly.
About the company
Food delivery from stores
Customers of Metro, Lenta, Globus, Karusel, Auchan stores
Channels of communication
100 000
Tickets per month
Support team members
Cities in Russia covers iGooods
Andrey Shcherbakov
Head of the customer service at iGooods
We have all the channels merged - this is a fact. In the end, we have only telephony and Usedesk - that's it. For us, Usedesk serves not only as a ticketing system, but also as a CRM-system to see the history of customer requests, order history, and quickly navigate it. This is great stuff.
Purchasers choose products for the customer carefully, as for themselves
How iGooods works
iGooods company delivers food, goods from hypermarkets to stores in St. Petersburg, Moscow, Kazan and ten other cities. The client orders in the catalogue, on a site or in an application all products, the goods which he needs, our buyer goes to the store to the necessary shelf, collects these orders and further passes the order to the courier, the courier brings to the house of the client. So we take the customer off the hook for going to the store, planning their budget, because they can immediately see how much they're going to spend on products. No need to be surprised at the checkout that he spent so much. Plus he can conveniently make regular purchases, repeating his last order, he can replenish his grocery stock literally at the click of a button.

We collect the order on the day of delivery, so the products are all as fresh and high-quality as possible in terms of timing. But there is a particular nuance to this as well: we don't have our warehouse. We take it straight from the supermarket shelves, and some goods may be missing, so we rely on what we have leftover. If the buyer sees that some product is absent, he agrees on a replacement with the client or acts according to the client's instructions; he may replace it at his discretion and choose analogues. The clients speak very highly of us. I'm happy that our buyers are very attentive and choose products for themselves. Generally, I like the service. Now, of course, we faced a great demand for our service. Many people are sitting at home and have no choice. Therefore the number of inquiries and orders has increased proportionally many times over.
About working in the crisis
Now everyone is wondering how everyone is working in rush mode. We haven't come out of any rush yet. It seems to me that we are just now climbing this wave and our demand for orders literally at one time increased by about 3-4 times, then the number of inquiries increased by about the same amount. Now we're about ten times short of our capacity in terms of demand. The same proportion has increased the number of calls, and if you take the number of calls, then the number has increased by 20 times a day. And if before support was handled by all the staff we had, we had time for everything during the shift. We had time to transmit requests, fix topics, and work. There was even time for operators to rest, but now we have doubled our staff and added outsourcing, and we are still not enough.
What support does
Our usual standard support tasks include answering questions from new customers. For example, on how to place orders, on our terms and conditions, geography, cost, etc. We also deal with claims or questions about orders we've placed or already delivered. When a customer has something gone wrong, he wants to change something. For example: something was wrong in the delivery, or low-quality goods were found out, and we solve these claims and sort them out, compensate or refund for low-quality goods. We collect feedback if something does not work for the client, but there is no specific claim. For example, there is a bug in the application, something is wrong with it, or there is some suggestion for improvement. We also collect this and pass it on to the developers.

At the same time, we are also the internal support for the employees. These are the buyers, stores, and couriers, as well as partners. We also work with the franchise scheme: we still have franchisees. We work as support for them as well: for their employees and supervisors, their buyers, their couriers.
25 channels in one place
Channels are many. We have regional phones for each city, chat on the site, groups in social networks for each region made separately by our SMM-department in Instagram, VKontakte, Facebook. Plus reviews on the site - just a published widget with reviews, mail, and another different review platform.
We connected AppStore and Google Play reviews almost immediately to Usedesk through AppFollow. We processed there, but when we did, literally a few days later, our app and website went down-not working for hours. During that time, we got hundreds of reviews on Appstore and Google Play. We handle everything through Usedesk. We have no other options. We stopped doing it directly because it is convenient in Usedesk. We have these channels in separate filters.

We don't have any channels that aren't engaged. Even Yandex chats we've hooked up. You type "products" in search, then you find iGoods and there chat, clients also write there actively, so now all channels are involved, and support is like that, on steroids.

To support employees (couriers, buyers, partners, stores), we have a service chatbot connected to Usedesk. And all requests come from them come to Usedesk, an employee on duty works with them, and he also writes to them himself if something is needed. For example, a client asks to postpone the order date or has a complaint from him. The manager needs to write this urgently.

Initially, this was done as one big group in Telegram, in which everyone sat, 100-200 people, and corresponded with each other chaotically about orders, about problems that arise. And when we saw all this with my colleague Maxim (he is responsible for the call centre and employees)... We were a little horrified by this chaos. We decided that it was necessary to structure this communication somehow and make it somehow isolated. Each employee had his access to the chatbot and wrote only on his orders. And we on the support side saw all the requests from these employees not mixed up with each other. This was probably the first solution at Usedesk. We created a chatbot in Telegram and connected it with the channel on Usedesk. That's the main task we have.

The operators are divided into two main groups: the writing support employees, who are responsible for text channels, chats, social networks, mail and telephony - those who are responsible for incoming calls. Channels are also divided between the written support employees, so as not to rush to everything at once.
About the reality before Usedesk
Before Usedesk, our predecessors used Telegram groups. It was about communicating with employees. For communicating with customers - direct front-ends to Vkontakte, mail, Facebook, messengers, and Appstore reviews - that is a bunch of logins and a bunch of tabs that written support had to sit in. They would open it all up and tables - google charts that captured a bunch of information on customer feedback. But we weren't one hundred percent away from spreadsheets yet. We were just about ready to go, but unfortunately, the crisis that's happened now has shifted our plans a little bit. We decided not to add more confusion for the time being, so there are still tables. Tables, Telegram groups, access to each of the accounts if you take text appeals. That was reality.
Why move to Usedesk?
What was the challenge? Disparate channels, disjointed individual appeals from clients and internal employees. It is impossible to understand their typology. It is not clear by what categories these appeals come, what is going on in this Telegram group. Moreover, if a customer contacts us, we do not know whether he has ever got us through the channel, whether other employees have written to him or not, or what has happened before. In other words, there was complete misinformation, some information vacuum that had to be eliminated.

And there was also one more task, to start collecting support statistics and feedback that could help change the service. Because the service had been in existence for four years, but since then no useful feedback had been collected that could qualitatively change the service. Yes, there were requests, chats, individual cases, but some trends were difficult to identify, because everything is scattered, all this is not collected in categories.

Plus there was a problem with the fact that telephony is set up on a separate virtual PBX of Beeline. Beeline - this solution is not the best in terms of scaling, because there and the management is difficult to configure, or instead it is entirely customizable. The answer is more suitable for small businesses. There were cell phones for operators, not virtual PBXs and headsets. That's why we were still looking for a headsets system to register requests, which integrates with the virtual PBX and supports normal phone channels. We looked in different directions: both Zendesk and some other. There weren't many companies that offer easy connection to a virtual PBX and start registering requests and phone calls from there.

You had a full-fledged solution and ready integration, which... it was written out that we could work with Mango. We had experience working with Mango, so we settled on it as a telephony option. Usedesk was an excellent addition to the puzzle in the form of a system for registering requests and processing tickets. So we connected everything basically in a day. What day? In half an hour we integrated one with the other and started getting tickets for the calls at once, which was very cool. That's how the decision was made.
In the customer card, you can immediately see information about orders
About the useful integration of Usedesk with the internal system
We recently finished the integration with our database and started identifying customers in Usedesk by mail and phone number, and it's right a breakthrough for us, for all operators. We finally when a customer calls, we can immediately, if there is a request or his request in chat, in social networks, if the mail or phone number is identified, we can immediately see all of his order history, the last active orders, clickable links to his profile in our system, in our database. The links were made clickable to his order, which means that you already know almost everything about the customer when you get a call or a letter. You can immediately open the desired order and respond without unnecessary requests. For us, Usedesk serves as a ticket system and as a CRM system, so we can see the history of customer requests, order history, and quickly navigate it. This is excellent stuff.

Plus, the integration itself around the client's profile, which informs about all his appeals, is also a handy thing, which is just like when you see what the client wrote to the chat, see what he wrote in the discussions in Vkontakte, some answers gave, saw that he called, you can listen to the same recording from the virtual PBX. That's great. It's a little bit where there are in the ticketing systems. That's really helpful.
We got high when we started working with letters in Usedesk
Before, we had to get everyone into the same email account. First of all, it's Google-based, and Google doesn't like it when everyone goes into the same account, it starts blocking and starts swearing about it when there's a lot of traffic. There's no such problem with Usedesk. Operators can log in as much as they want, and it's easier to connect a person to Usedesk, too, than to give them some passwords from their Google account. And it's easier to disconnect it also since you don't have to change the main accounts' password. Again, replying to a customer in an email client or Google, you can't see anything about the customer. Responding to him in Usedesk, you see him in the mail, you see the entire order history, which is loaded from our system via API, that is, it is more contextual communication obtained. So, of course, it is much more pleasant.
The importance of separating questions by subject
We have made our typical topics of requests to keep statistics and modify the work of our support. This statistic is also maintained for internal employees since they sometimes ask questions on our functionality. "Do what I want" - and we don't do and can't do that at all, and we shouldn't. We started to register such requests with a specific tag and give out statistics to responsible employees, how often customers or couriers come to us with such a question. And is it possible to somehow change their way of working or instructions so that we don't get these requests? Previously, it was difficult to reason: we did not know how many of these requests, it was unclear who was making them when they all wrote in a Telegram chat.

It's the same for clients. We did more than 20 subjects in queries and chats about 10. Customer inquiries are informational, claims and order related issues. They are also registered, and we understand the technical aspects and typical questions of customers. We can pay more attention to them.

Additional fields in inquiries also depend on the channel of application, in the tickets with telephony they are less, in the text ones there can be more. In chats with employees, there won't be topics that refer to customers, either. Everything is conveniently separated.
About automation
We have done everything to automate: immediately we were advised to close tickets and chats if they do not have any activity because these requests are not automatically closed. Then assigning conversations to groups. This was also not immediately obvious, but we did it. Transferring rights from different channels to specific employees or groups.

We also experimented a little bit with the notification get-requests. We notified Telegram through a separate bot using a get-request about messages coming to a particular group, to a specific channel. Those operators for whom the notification in their browsers did not work could see that they had received a message. It's pretty easy to do with the constructor. Just write a request, and it sends to Telegram the name of the sender of this message, a link to the ticket, to the chat. The operator, who saw it first, can click on the link and go to the desired chat in Usedesk. The thing is exciting, you can experiment with it, but I don't have time for that yet. It would be cool to set up such push notifications in the bot by some keywords to attract the attention of certain groups of employees to different problems. That is, you can come up with a lot of different scenarios. That's probably the main thing we use in terms of useful automation.

I won't say that we have everything entirely automated, but we do feel the effect of it, and every solution to automate and simplify the work of our employees, it makes us happy, it causes pleasant emotions.
About claims handling: from spreadsheets to the system
We tried to make our process for working with claims in Usedesk. For example, all of our requests were registered in a table with the following parameters: number, date, the essence of the claim, some result from the employee. We sorted out what a request consists of and turned it into a ticket form. We made the subject, additional fields in the ticket-claims: quality of goods, delay, etc. And made rules for assigning these claims to the claims staff. So that conditionally the employee of the incoming telephone support or written support, recorded all the information from the client, put the type of treatment "claim", chose an additional category "appeal for quality" and this claim flew to the employee of the claims department. He could take it from the list of new.

This is a way to get away from the table, which is the only one we have left, and it is challenging to execute because you need to fill in a lot of fields - a time of treatment, employee, order numbers. All this is in Usedesk automatically, and there is no sense to fill in the hands. And we need a time limit because in the table there is no reminder of when the claim is resolved, an explicit reminder status other than the colour or the inscription "completed". You can do as in the query at once a reminder, move it to any time, or shift the responsibility to someone else. It's a full-fledged ticket operation. Roughly this is how we envisioned it, that any client's problem is a ticket to be solved, and there must be a result, which can be counted, fixed and seen in reports.
It's significant that you respond quickly, even after seven.
There are people who, after the bot answers that we're resting, still write and help. And I don't see how, but you have a great system set up for reminding people of pledges made. If you say, say, you said that we'd come back to you in two weeks with an answer, then exactly two weeks later, someone writes to me and says that we took the task from you in work, while we are still doing. I had already forgotten all about these tasks.
What not to forget when starting a helpdesk from scratch
First of all, we studied what we could do in Usedesk on some of the promotional materials provided before we made our decision. We realized that the channels we had with clients, with employees, with our IT, would all be closed for the most part, and this solution worked for us. Further, when we were already connected, we asked our manager questions and received a lot of useful information from him and the support. We read the knowledge base a lot. It is well written and basically all up to date; there is no outdated data. And there, unlike many other systems and companies, you have prescribed things, which services themselves should define, up to the fact that you have to go to Slack, go to the settings, in the settings select a screenshot, press this, and you get here and then paste this into Usedesk. That's just commendable.

The second point is that you have to set the task right if you want to do something. You want to automate; you wish to remove manual labour, you want to collect many channels for one employee in one convenient place or collect usage statistics.

We just somehow decomposed these tasks and thought about whether or not Usedesk could solve them. We couldn't solve a problem with Usedesk, but it was so unsolvable that we even stopped solving it. Since it's not correctly algorithmized in any way, it can't be built into the process; maybe it shouldn't be done. What good would it do? This is also possible. At some point, you realize that you're doing many unnecessary things that don't produce any effect, and a lot of time is spent on them.

So the general advice is to take the freshest possible look at the actions that you're doing, break them down into separate areas, figure out what those actions are, what they are and what the result of that action is: a report of some kind, a message or notice. And see how Usedesk can make it easier for you, automatically.

It was a big plus that they gave us a month to try it out for free.
It was a real drag. That was the determining factor. I don't remember any other service that allowed us to do a full test. Not on two users, but our entire staff. We were able to try it on ourselves to see how much of a working story it was, and in the end, we were so hooked that we didn't want to give it up...
How to deal with employee inertia when moving
When you move to a new system, it's more difficult to retrain the old employees, to show them the benefits of it all, because they have certain habits and not all the things work as well and quickly as they did in the old systems. There are still some nuances. We have employees of different ages, different generations, some of them have already developed habits over a year or two to do certain things that turned out not to be very useful. They work, but they're not sufficient, they're slow, and so on. So, of course, we encountered a particular aversion and inertia in this respect. It's still difficult, for example, to explain to an operator why he should look for a chat with an employee in Yuzdesk instead of writing to him in person. But there's much more benefit when you show the service when you say, guys, here you see all the information about the client at once, you see information about how the other operator communicated, you can prompt him with comments if he writes some nonsense.

We've noticed that now operators themselves are actively using built-in comments when you press the lock and write in a yellow background: he's wrong. Or something else: go ahead, tell him this one. It's that kind of sufflation. They started to use it; they started to say to themselves something, remind themselves, leave comments for themselves. Even someone started using time reminders that reopen the request, which is excellent.
Share with your colleagues:
Did you like this briefcase?

We know a lot about customer service
Once a week, we will send you an article on how to create better customer service. Do you mind?
We know a lot about customer service
Once every two weeks, we will send exciting and valuable materials about customer service - articles, cases, and system updates. Do you mind?