Международная процессинговая компания PayU

Было: Два ящика: саппорт@ и инфо@. Сюда падали письма от мерчантов, от клиентов, спам, плюс внутренняя переписка.

Боль: Письма на разную тематику перемешаны, адресаты получают письма не вовремя, нужное удаляется или забывается. Какое из писем важно, а какое подождет? Какое повторное? А почему это вопрос еще не закрыт? А на это письмо уже ответили?

Что сделали: создали ящик для внутренней почты в аутлуке, а ящики саппорт и инфо подключили к Usedesk.

Стало: в Юздеск поступают только вопросы по делу, команда не тратит время на выгребание мусора, а сразу видит, с чем ей работать. Контролировать поток стало легче, потому что сразу видно статус запроса:

• открыт — значит пора отвечать,
• в ожидании — ждем дополнительной информации от клиента,
• на удержании — уточняем на своей стороне у другого отдела или партнера.
• выполнен — вопрос решен.

В зависимости от статуса и приоритета сотрудники фильтруют запросы и в первую очередь отвечают на открытое и срочное. В фильтре запросов «На удержании» видно все нерешенные проблемы.

Было: Если для ответа клиенту нам нужны технические детали, писали письмо отделу интеграции, и долго ждали ответа или забывали о нем.

Боль: Интеграция добирается до письма через два дня, когда клиент уже написал несколько гневных писем, почему его проблема не решена. Любые коммуникации с другими отделами затягиваются, и не видно ни ответственного, ни стадию решения вопроса.

Что сделали: Добавили сотрудников интеграции и продаж в Юздеск. Создали правила, чтобы запрос автоматически назначался на нужную группу в зависимости от тематики.

Стало: У каждого письма есть исполнитель. Если нужна помощь коллег, сотрудник поддержки переназначает запрос с внутренним комментарием, который не виден клиенту «ребята, дайте логи по платежу». Коллеги добавляют комментарий, возвращают поддержке запрос для ответа клиенту. Вся история решения вопроса сохраняется, поэтому легко поднять информацию в любой момент, чтобы разобраться детально.

Было: не видно, если кто-то уже начал работу над письмом, и на одно письмо одновременно отвечают два сотрудника.

Боль: время тратится впустую, ведь вместо одного письма поддержка могла ответить на два. Разные ответы приводили клиентов в замешательство. Один сотрудник написал, что возврат средств был сегодня, другой — что деньги клиент получит завтра. В итоге клиент остался без конкретного ответа.

Стало: в хелпдеске есть детектор коллизий. Это уведомление, которое всплывает, когда кто-то просматривает запрос или обновляет. Это помогает избежать двойных ответов и неловких ситуаций.

Было: если клиент писал раньше, он рассчитывает, что о его проблеме уже известно. Но история обращений не сохранялась. И вместо того, чтобы дать ответ клиенту сразу, сотрудники переспрашивали детали ситуации несколько раз.

Боль: даже если вся информация для решения вопроса у нас уже была — то не было инструмента, чтобы сразу увидеть ее. Это отнимало время и требовало от клиента дополнительных усилий, чтобы получить ответ.

Стало: профиль клиента в хелпдеске сохраняет историю обращений и все контакты клиента. Контекст обращения сразу ясен и сотрудники переходят к делу без утомительных допросов.

Было: клиенты часто задают одинаковые вопросы, на которые есть шаблоны ответов. Они хранились у каждого сотрудника в вордовском файле. Сотрудник находил нужный, копировал и вставлял в письмо.

Боль: переключения между почтой и файлом утомляют и отнимают время. Невозможно контролировать, как используют и обновляют шаблоны сотрудники.

Что сделали: все шаблоны завели в UseDesk. Доступ к редактированию есть только у руководителя, так что все обновления централизованы, никакой самодеятельности. Кроме самого текста к шаблону добавляются действия. Автоматически меняются статусы и присваиваются теги, которые потом тянут за собой срабатывание правил обработки запросов.

Стало: сотрудники отвечают клиентам в 2 клика, и статусы не нужно менять руками. Присвоенные теги помогают посчитать, сколько обращений по разным темам: возвратам, успешным и не успешным платежам, сбоям.

Было: когда для решения вопроса запрашивают дополнительную информацию от клиента, он не всегда отвечает, и вопрос остается нерешенным.

Боль: приходится мониторить нерешенные вопросы и ставить напоминалки вручную. Когда их накапливается критическое количество, на них просто перестают реагировать.

Что сделали: создали правила обработки запросов.

Стало: система сама напоминает клиентам, что от них ожидают данных для дальнейшего решения вопроса. Если ответ не поступает, запрос через некоторое время закрывается автоматически и не висит как нерешенный.

Было: Если что-то ломалось, на массовые претензии отвечали вручную, а после каждого информировали о завершении сбоя.

Боль: Любой сбой или обновление означали для команды наводнение из потока запросов. Не хватало рук, чтобы обработать все в течение дня. В результате половина обратившихся не получали ответа.

Что сделали: Каждое письмо помечается тегом «сбой». Настраивается правило, чтобы всем письмам с этим тегом уходили одинаковые уведомления.

Стало: вместо 50 писем один клик на кнопку «Запустить правило», и все клиенты оповещены, об окончании сбоя.

Было: Никакой статистики не было. Пытались вытащить данные из аутлука, но это было долго и неточно.

Боль: Сколько запросов, какие, какой срок обработки, кто сколько выполняет — не было представления, что происходит в поддержке, в какой точке качества находится команда и куда двигаться.

Что сделали: Получили статистику и проанализировали все показатели.

Стало: Теперь процессы меняются на основе цифр, а не догадок. Для сотрудников установили KPI по времени обработки запросов. Данные по тематике обращений помогают находить узкие места и улучшать сервис. Обновляются шаблоны, чтобы у клиента не оставалось вопросов после первого ответа. Если плательщики обращаются с одинаковыми вопросами, то ищется решение совместно с мерчантом.