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.
By clicking the button, you agree that you have read our Privacy Policy
[Voice of the Customer]: Support at iGooods on steroids
We talked 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
- IndustryFood delivery from stores
- CustomersCustomers of Metro, Lenta, Globus, Karusel and Auchan
- 25Channels of communication
- 100 000Tickets per month
- 35Support team members
“
We have all the channels merged — this is a fact. In the end, we have only telephone 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 navigate it quickly. This is great stuff.
Purchasers choose products for the customer carefully, as though they were for themselves
How iGooods works
iGooods delivers food and goods from markets to stores in St. Petersburg, Moscow, Kazan and ten other cities. The client orders from the catalogue on the site or in an application, our buyer goes to the store, collects these orders and passes the order to the courier. Then, the courier the good to the client. So, we take the customer off the hook for going to the store and planning their budget because they can immediately see how much they're going to spend. No getting surprised at the checkout. Plus, they can conveniently make regular purchases. By repeating the last order, the customer can replenish their 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. But there is a particular nuance to this as well: we don't have a warehouse. We take goods straight from the supermarket shelves, and some goods may be missing, so we rely on what we have left over. If the buyer sees that a product is absent, they agrees on a replacement with the client or act according to the client's instructions. They may replace it at their discretion and choose similar products. 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 are facing 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.
iGooods delivers food and goods from markets to stores in St. Petersburg, Moscow, Kazan and ten other cities. The client orders from the catalogue on the site or in an application, our buyer goes to the store, collects these orders and passes the order to the courier. Then, the courier the good to the client. So, we take the customer off the hook for going to the store and planning their budget because they can immediately see how much they're going to spend. No getting surprised at the checkout. Plus, they can conveniently make regular purchases. By repeating the last order, the customer can replenish their 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. But there is a particular nuance to this as well: we don't have a warehouse. We take goods straight from the supermarket shelves, and some goods may be missing, so we rely on what we have left over. If the buyer sees that a product is absent, they agrees on a replacement with the client or act according to the client's instructions. They may replace it at their discretion and choose similar products. 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 are facing 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 at one point literally increased by about 3-4 times, then the number of inquiries increased by about the same amount. The number of calls have increased by the same proportion, and if you take the number of calls, then the number has increased by 20 times. Before, support was handled by all the staff we had, we had time for everything during the shift. We had time to send requests, fix issues and work. There was even time for operators to rest, but now we have doubled our staff and outsourced, and it's still not enough.
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 at one point literally increased by about 3-4 times, then the number of inquiries increased by about the same amount. The number of calls have increased by the same proportion, and if you take the number of calls, then the number has increased by 20 times. Before, support was handled by all the staff we had, we had time for everything during the shift. We had time to send requests, fix issues and work. There was even time for operators to rest, but now we have doubled our staff and outsourced, and it's still not enough.
What support does
Our usual 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 that have been placed or already delivered. When something gone wrong, the customer will want to change something. For example: something was wrong in the delivery, or low-quality goods were found, and we solve these claims and sort them out and compensate or refund for low-quality goods. We collect feedback if something does not work for the client, but there is no specific request. For example, bug reports or a suggestion for improvement. We 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 and their couriers.
Our usual 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 that have been placed or already delivered. When something gone wrong, the customer will want to change something. For example: something was wrong in the delivery, or low-quality goods were found, and we solve these claims and sort them out and compensate or refund for low-quality goods. We collect feedback if something does not work for the client, but there is no specific request. For example, bug reports or a suggestion for improvement. We 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 and their couriers.
25 channels in one place
There are many channels. We have regional phones numbers for each city, chat on the site and groups in social networks for each region made separately by our SMM-department on Instagram, VKontakte and Facebook. Plus reviews on the site — just a widget with reviews, email, and another review platform.
There are many channels. We have regional phones numbers for each city, chat on the site and groups in social networks for each region made separately by our SMM-department on Instagram, VKontakte and Facebook. Plus reviews on the site — just a widget with reviews, email, and another review platform.
We connected App Store 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 the App Store and Google Play. We handle everything through Usedesk. We had no other options. Now we've 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 are hooked up. You type "products" in search, then you find iGoods and the chat. Clients also write there actively, so now all channels are involved, and support is like it's on steroids.
To support employees (couriers, buyers, partners, stores), we have a service chatbot connected to Usedesk. And all requests that come from them come to Usedesk. An employee on duty works with them and also writes to them if something is needed. For example, if a client asks to postpone the order date or has a complaint. The manager needs to respond to this urgently.
Initially, this was done as one big group in Telegram, in which 100-200 people and corresponded with each other chaotically about orders and problems that arise. And when we saw all this with my colleague Maxim (he is responsible for the call center and employees), we were a little horrified by the chaos. We decided that it was necessary to structure this communication somehow and somehow isolate it. Each employee had access to the chatbot and responded only on their orders. We on the support side saw all the requests from these employees that were no longer mixed up with each other. This was probably the first solution with 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, email and phone — 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.
We don't have any channels that aren't engaged. Even Yandex chats are hooked up. You type "products" in search, then you find iGoods and the chat. Clients also write there actively, so now all channels are involved, and support is like it's on steroids.
To support employees (couriers, buyers, partners, stores), we have a service chatbot connected to Usedesk. And all requests that come from them come to Usedesk. An employee on duty works with them and also writes to them if something is needed. For example, if a client asks to postpone the order date or has a complaint. The manager needs to respond to this urgently.
Initially, this was done as one big group in Telegram, in which 100-200 people and corresponded with each other chaotically about orders and problems that arise. And when we saw all this with my colleague Maxim (he is responsible for the call center and employees), we were a little horrified by the chaos. We decided that it was necessary to structure this communication somehow and somehow isolate it. Each employee had access to the chatbot and responded only on their orders. We on the support side saw all the requests from these employees that were no longer mixed up with each other. This was probably the first solution with 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, email and phone — 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.
The reality before Usedesk
Before Usedesk, our predecessors used Telegram groups. It was about communicating with employees. For communicating with customers — direct frontends to Vkontakte, email, Facebook, messengers, and App Store reviews, there were a lot of logins and a bunch of tabs that written support had to have open. They would open it all up along with tables — Google charts that captured a bunch of information on customer feedback. But we hadn't gotten one hundred percent away from spreadsheets yet. We were just about ready to go, but unfortunately, the crisis that's happening now 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 chats, that was reality.
Before Usedesk, our predecessors used Telegram groups. It was about communicating with employees. For communicating with customers — direct frontends to Vkontakte, email, Facebook, messengers, and App Store reviews, there were a lot of logins and a bunch of tabs that written support had to have open. They would open it all up along with tables — Google charts that captured a bunch of information on customer feedback. But we hadn't gotten one hundred percent away from spreadsheets yet. We were just about ready to go, but unfortunately, the crisis that's happening now 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 chats, that was reality.
Why move to Usedesk?
What was the challenge? Disparate channels, disjointed individual requests from clients and internal employees. It is impossible to understand their type. It is not clear by what categories these requests come from or what is going on in this Telegram group. Moreover, if a customer contacts us, we do not know whether they have ever contacted us through the channel, whether other employees have written to them or not or what has happened before. In other words, there was complete misinformation, an information vacuum that had to be eliminated.
What was the challenge? Disparate channels, disjointed individual requests from clients and internal employees. It is impossible to understand their type. It is not clear by what categories these requests come from or what is going on in this Telegram group. Moreover, if a customer contacts us, we do not know whether they have ever contacted us through the channel, whether other employees have written to them or not or what has happened before. In other words, there was complete misinformation, an information vacuum that had to be eliminated.
Plus there was a problem with the fact that the phone system is set up on a separate Beeline virtual PBX. Beeline is not the best in terms of scaling because the management is difficult to configure. It is more suitable for small businesses. There were cellphones for operators, not virtual PBXs and headsets. That's why we were still looking for a headset system to register requests that integrate with the virtual PBX and supports normal phone channels. We looked in different directions: both Zendesk and some other. There weren't many companies offering easy connection to a virtual PBX and the ability to register requests and phone calls from there.
You had a full-fledged solution with ready integration 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 as a system for registering requests and processing tickets. So we connected everything basically in one 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.
What was the challenge? Disparate channels, disjointed individual requests from clients and internal employees. It is impossible to understand their type. It is not clear by what categories these requests come from or what is going on in this Telegram group. Moreover, if a customer contacts us, we do not know whether they have ever contacted us through the channel, whether other employees have written to them or not or what has happened before. In other words, there was complete misinformation, an information vacuum that had to be eliminated.
What was the challenge? Disparate channels, disjointed individual requests from clients and internal employees. It is impossible to understand their type. It is not clear by what categories these requests come from or what is going on in this Telegram group. Moreover, if a customer contacts us, we do not know whether they have ever contacted us through the channel, whether other employees have written to them or not or what has happened before. In other words, there was complete misinformation, an information vacuum that had to be eliminated.
Plus there was a problem with the fact that the phone system is set up on a separate Beeline virtual PBX. Beeline is not the best in terms of scaling because the management is difficult to configure. It is more suitable for small businesses. There were cellphones for operators, not virtual PBXs and headsets. That's why we were still looking for a headset system to register requests that integrate with the virtual PBX and supports normal phone channels. We looked in different directions: both Zendesk and some other. There weren't many companies offering easy connection to a virtual PBX and the ability to register requests and phone calls from there.
You had a full-fledged solution with ready integration 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 as a system for registering requests and processing tickets. So we connected everything basically in one 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 integration of Usedesk with the internal system
We recently finished the integration with our database and started identifying customers in Usedesk by email and phone number, and a breakthrough for us, for all operators. Finally, when a customer calls, we can immediately if there is a request from social networks. If the email or phone number is identified, we can immediately see their order history, the last active orders and clickable links to their profile in our system. You already know almost everything about the customer when you get a call or a message. 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 navigate it quickly. This is excellent stuff.
Plus, the integration itself around the client's profile, which informs about all their requests, is also a handy thing. You can see what the client wrote to the chat, see what they wrote in the discussions in Vkontakte, the answers given, can see that they called, you can listen to the recording from the virtual PBX. That's great. That's really helpful.
We recently finished the integration with our database and started identifying customers in Usedesk by email and phone number, and a breakthrough for us, for all operators. Finally, when a customer calls, we can immediately if there is a request from social networks. If the email or phone number is identified, we can immediately see their order history, the last active orders and clickable links to their profile in our system. You already know almost everything about the customer when you get a call or a message. 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 navigate it quickly. This is excellent stuff.
Plus, the integration itself around the client's profile, which informs about all their requests, is also a handy thing. You can see what the client wrote to the chat, see what they wrote in the discussions in Vkontakte, the answers given, can see that they called, you can listen to the recording from the virtual PBX. That's great. That's really helpful.
We got excited 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 getting angry 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, than to give them some passwords for a Google account. And it's easier to disconnect it 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 them in Usedesk, you see their mail, you see the entire order history, which is loaded from our system via API. There is much more contextual communication. So, of course, it is much more pleasant.
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 getting angry 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, than to give them some passwords for a Google account. And it's easier to disconnect it 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 them in Usedesk, you see their mail, you see the entire order history, which is loaded from our system via API. There is much more contextual communication. So, of course, it is much more pleasant.
The importance of separating questions by subject
We have listed typical topics of requests to keep statistics and modify our support work. We sometimes get requests for things we're unable to do. We started to register such requests with a specific tag and give out statistics to the employees responsible about how often customers or couriers come to us with such a question and try to determine if it possible to somehow change the 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 there were and it was unclear who was making them when they all wrote in a Telegram chat.
It's the same for clients. We have more than 20 subjects in queries and about 10 in chats. Customer inquiries are informational, requests and order related issues. They are also registered and we understand the technical aspects and typical questions from customers. We can pay more attention to them.
Additional fields in inquiries also depend on the channel. There can be more fields for tickets related to text requests and fewer for phone requests. In chats with employees, there won't be topics that refer to customers, either. Everything is conveniently separated.
We have listed typical topics of requests to keep statistics and modify our support work. We sometimes get requests for things we're unable to do. We started to register such requests with a specific tag and give out statistics to the employees responsible about how often customers or couriers come to us with such a question and try to determine if it possible to somehow change the 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 there were and it was unclear who was making them when they all wrote in a Telegram chat.
It's the same for clients. We have more than 20 subjects in queries and about 10 in chats. Customer inquiries are informational, requests and order related issues. They are also registered and we understand the technical aspects and typical questions from customers. We can pay more attention to them.
Additional fields in inquiries also depend on the channel. There can be more fields for tickets related to text requests and fewer for phone requests. 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. We were immediately advised to close tickets and chats if they do not have any activity because these requests are not closed automatically. 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 who see the notification in their browsers could see that they had received a message. It's pretty easy to do with the constructor. Just write a request and it sends the name of the sender of this message and 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. It's exciting, you can experiment with it, but I don't have time for that yet. It would be cool to set up push notifications in the bot by keywords to direct certain groups of employees to different problems. 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 makes us happy.
We have done everything to automate. We were immediately advised to close tickets and chats if they do not have any activity because these requests are not closed automatically. 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 who see the notification in their browsers could see that they had received a message. It's pretty easy to do with the constructor. Just write a request and it sends the name of the sender of this message and 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. It's exciting, you can experiment with it, but I don't have time for that yet. It would be cool to set up push notifications in the bot by keywords to direct certain groups of employees to different problems. 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 makes us happy.
About claims handling: from spreadsheets to the system
We tried to make a 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 and result from the employee. We sorted out what a request consists of and turned it into a ticket. We added the subject and additional fields in the ticket-claims: quality of goods, delay, etc., and then made rules for assigning these claims to the claims staff so that conditionally, the employee handling the incoming telephone support or written support recorded all the information from the client, set the type of to "claim," chose an additional category, "appeal for quality." It is then sent to an employee in the claims department. They can take it from the list of new tickets.
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, employee and order numbers. All this is in Usedesk automatically. And we need a time limit because in the table, there is no reminder of when the claim is resolved other than the color or a note that reads, "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 system. This is roughly 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.
We tried to make a 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 and result from the employee. We sorted out what a request consists of and turned it into a ticket. We added the subject and additional fields in the ticket-claims: quality of goods, delay, etc., and then made rules for assigning these claims to the claims staff so that conditionally, the employee handling the incoming telephone support or written support recorded all the information from the client, set the type of to "claim," chose an additional category, "appeal for quality." It is then sent to an employee in the claims department. They can take it from the list of new tickets.
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, employee and order numbers. All this is in Usedesk automatically. And we need a time limit because in the table, there is no reminder of when the claim is resolved other than the color or a note that reads, "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 system. This is roughly 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.
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 to keep in mind when starting a helpdesk from scratch
First of all, we studied what we could do in Usedesk from 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 department 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. And there, unlike many other systems and companies, you have prescribed things, which services themselves should define, including 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 correctly if you want to do something. You want to automate, you wish to remove manual labor, you want to collect many channels for one employee in one convenient place or collect usage statistics.
We broke these tasks down 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, so 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.
First of all, we studied what we could do in Usedesk from 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 department 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. And there, unlike many other systems and companies, you have prescribed things, which services themselves should define, including 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 correctly if you want to do something. You want to automate, you wish to remove manual labor, you want to collect many channels for one employee in one convenient place or collect usage statistics.
We broke these tasks down 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, so 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
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 ourselves to see how well it worked, and in the end, we were so hooked that we didn't want to give it up.
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 ourselves to see how well it worked, and in the end, we were so hooked that we didn't want to give it up.
How to deal with employee aversion 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 everything works as well and as 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 efficient, they're slow, and so on. So, of course, we encountered a particular aversion in this respect. It's still difficult, for example, to explain to an operator why they should look for a chat with an employee in Usedesk instead of writing to them in person. But there's much more benefit 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 them with comments if they write 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: "they're wrong." Or something else: go ahead, tell them this one. It's that kind of sufflation. They started to use it, they started reminded themselves, leaving comments for themselves. Someone even started using time reminders that reopen the request, which is excellent.
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 everything works as well and as 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 efficient, they're slow, and so on. So, of course, we encountered a particular aversion in this respect. It's still difficult, for example, to explain to an operator why they should look for a chat with an employee in Usedesk instead of writing to them in person. But there's much more benefit 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 them with comments if they write 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: "they're wrong." Or something else: go ahead, tell them this one. It's that kind of sufflation. They started to use it, they started reminded themselves, leaving comments for themselves. Someone even started using time reminders that reopen the request, which is excellent.
Share with your colleagues:
Did you like this briefcase?
Error get alias
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?
