International processing company
PayU:

Before: Two boxes: support @ and info @.
Letters from merchants, from clients, spam, plus internal correspondence fell here.
Pain: Letters on different topics are mixed, recipients receive letters at the wrong time, and deleted or forgotten. Which letter is important and which one will wait? What is repetitive? Why is this question not closed yet? Have you already answered this letter?

What had been done: we created a box for internal mail in Outlook, and the support and info boxes were connected to Usedesk.

After: only questions about the case are sent to Usedesk; the team does not waste time on garbage collection but immediately sees what to work with. Controlling the flow has become more comfortable because the request's status is directly visible:

• open - means it's time to answer;
• pending - we are waiting for additional information from the client;
• on hold - check on our side with another department or partner;
• completed - the issue is resolved. Based on status and priority, employees filter requests and respond to open and urgent requests first.
  
  All unresolved problems are visible in the On Hold query filter.

Before: If we need technical details to respond to a client, we wrote a letter to the integration department and waited a long time to answer or forgot about it.

Pain: The integration gets to the letter two days later, when the client has already written several angry e-mails about why his problem has not been resolved. Any communication with other departments is delayed, and neither the responsible person nor the stage of the issue is visible.

What has been done: We added integration and sales staff to Usedesk. We created rules to automatically assign the request to the right group, depending on the topic.

After: Each letter has a performer. If you need help from colleagues, the support employee reassigns the request with an internal comment, which is not visible to the client "guys, give the payment logs." Colleagues add a comment, return a request to support to respond to the client. The entire history of the solution to the issue is saved, so it is easy to raise the information at any time to understand in detail.

Before: not visible if someone has already started work on the letter, and two employees are simultaneously answering one letter.

Pain: time is wasted, because instead of one letter, support could answer two. Clients were confused by the different answers. One employee wrote that the refund was made today, the other that the client will receive the money tomorrow. As a result, the client was left without a concrete answer.

Now: the helpdesk has a collision detector. This is a notification that pops up when someone views a request or updates. This helps to avoid double answers and awkward situations.

Before: if the client wrote before, he expects that his problem is already known. But the history of requests was not saved. And instead of giving an answer to the client right away, the staff asked the details of the situation several times.

Pain: even if we already had all the information to resolve the issue, we did not have a tool to immediately see it. This took time and required extra effort on the part of the client to get a response.

Now: the customer profile in the helpdesk saves the history of calls and all customer contacts. The context of the appeal is immediately clear and employees get down to business without tedious questioning.

Before: clients often ask the same questions to which there are templates for answers. They were kept by each employee in a Word file. The employee found the right one, copied and pasted it into the letter.

Before: when additional information is requested from the client to resolve the issue, he does not always answer, and the issue remains unresolved.

Pain: you have to monitor unresolved issues and set reminders manually. When a critical amount of them accumulates, they simply stop responding to them.

What has been done: created rules for processing requests.

After: the system itself reminds customers that data is expected from them to further resolve the issue. If no response is received, the request is closed automatically after a while and does not hang as unresolved.

Before: If something broke, massive claims were answered manually, and after each one, they were informed about the completion of the failure.

Pain: Any failure or update meant a flood of requests for the team. There weren't enough hands to handle everything during the day. As a result, half of those who applied did not receive an answer.

What has been done: Each letter is marked with a "failure" tag. A rule is configured so that all emails with this tag will receive the same notification.

Now: instead of 50 letters, one click on the "Run rule" button, and all clients are notified about the end of the failure.

Before: There were no statistics. We tried to extract data from Outlook, but it was long and inaccurate.

Pain: How many requests, which ones, how long to process, who fulfills how much - there was no idea what was happening in support, at what point of quality the team was and where to go.

What has been done: Received statistics and analyzed all indicators.

After: Now, processes change based on numbers, not guesswork, KPIs were set for employees for the processing time of requests. Data by subject matter helps you find bottlenecks and improve service. Templates are updated so that the client does not have any questions after the first answer. If the payers ask the same questions, then a solution is sought together with the merchant.