Машинное обучение сэкономило 5 млн рублей в месяц на техподдержке

Служба поддержки глазами Продукта

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

Особенно важно это для служб поддержки в такси. Поддержка сталкивается с несколькими типами клиентов: водителями, пассажирами и таксопарками. Популярность агрегаторов такси при этом только растёт. В период активного роста через Ситимобил, например, совершалось 13 млн поездок ежемесячно.

В среднем 8% пользователей обращались в службу поддержки: это 1 млн обращений в месяц. Большинство из обращений требуют срочного ответа, ведь пользователь не будет ждать ответа несколько дней, когда что-то идёт не так прямо сейчас, в поездке.

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

Поиск решения лежит в понимании трех операционных метрик любой службы поддержки:

• количество входящих  обращений от пользователей,
• количество обращений, обрабатываемых сотрудником в час,
• распределение рабочего времени сотрудника.

Таким образом, инициативы так или иначе влияют на формулу:

(Число обращений) х (Стоимость обработки одного обращения) = (Затраты на службу поддержки)

Стоимость обработки одного обращения рассчитывается так:

(Стоимость обработки одного обращения) = (Зарплатная ставка в час) / ((60 минут) / (Время обработки одного обращения)) / (% времени, когда сотрудник работает)

Расчет подобного уравнения и понимание драйверов каждой из метрик — первый этап в поиске оптимального продуктового решения для службы поддержки. При этом, если компания работает с большими объемами обращений, экономия даже нескольких секунд приводит к значительному сокращению затрат.

В нашем кейсе, результат принесли проекты по сокращению числа обращений и сокращению времени обработки. При этом, важно было сохранить живое общение с пользователем и сохранить гибкость в управлении поддержкой. Исследовав рынок и учтя факторы, мы разработали собственного рабочего места сотрудника.

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

• новое рабочее место для быстрой обработки обращений с командой из одного продукта, пяти разработчиков и одного тестировщика,
• автоматизации для сокращения входящих обращений с командой из одного продукта и трех  ML-разработчиков (специалисты по машинному обучению).

В течение работы над проектом, продуктовая команда работала совместно с командой клиентского сервиса, чтобы учесть специфику работы линейных сотрудников.

Рабочее место сотрудника поддержки

Основная задача — максимально упростить работу сотрудников с обращениями в каналах: чат и звонок. Метрика, которую оптимизировали — Время обработки одного обращения (average handling time или АНТ).

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

Проект начался с трехстороннего исследования проблем старого рабочего места и потребностей сотрудников. Продуктовая команда проводила глубинные интервью как с руководителями, так и с линейными сотрудниками.

Примеры вопросов:

• На какие типы обращений тратишь больше всего времени?
• Что бы хотел изменить в текущем рабочем месте?

Сложность в интервью — сотрудники привыкают к неудобствам старого рабочего места и не думают, что бывает по-другому. Поэтому второй этап — самостоятельное исследование. Команда прошла стажировку в качестве сотрудников поддержки, самостоятельно отвечала на обращения пользователей и фиксировала все несовершенства процесса.

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

Наконец, команда изучала практики конкурентов и поставщиков готовых решений.

Следующий этап  — создание  плана целевого состояния рабочего места, составленный менеджером продукта. План включал перечень найденных проблем на этапе исследования, концепцию нового рабочего места и перечень фичей, а также этапы разработки и внедрения.

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

Дополнительный функционал добавлялся как микросервис. Он связан с возможностью совершить новые действия с обращением пользователя. Примеры:

• отменить заказ с возвратом денег за отмену,
• пересчитать платное ожидание,
• проставить статус или тему обращения,
• вернуть деньги, списанные за поездку.

Действия сотрудников были проранжированы по частоте. Эта частота определила порядок добавления новых фичей и действий в рабочее место. Второй фактор — затраты времени сотрудника на совершение действия. Например, если “возврат денег за поездку” — самое частое обращение пользователей и новый интерфейс позволит делать это быстрее — внедряем этот функционал в первую очередь.

Таким образом, компания начинала выигрывать от перехода на новое рабочее место еще до его полного внедрения.

С технической стороны, команда разработки делилась на frontend, backend, qa и дизайнера.

Frontend реализовывался на ReactJS и отвечал за пользовательские интерфейсы (UI). В нашем случае, это те самые действия сотрудника с обращением.

Backend реализовывали на фреймворке Symfony языка PHP. Бэк занимался API и закрытой админкой для настройки рабочего места сотрудника. Каждая фича выкатывалась под ручкой и можно было гибко настраивать функционал под нужды сотрудников поддержки. В том числе, возможность отключить функционал для некоторых групп сотрудников. Это важно, например, для стажеров, которым рано давать доступ к операциям с деньгами.

На момент полного внедрения  AHT сократился с 230 секунд до 195 секунд для звонков и с 500 до 385 секунд по чатам. Эффект получили за счет ухода от переключения между окнами.

Кроме этого, сработала фича:

• подсказки при выборе тематики обращений. ML-команда научила систему анализировать десятки параметров при поступлении звонка и по итогу отдавать топ 5-10 вероятных тематик обращения. Такие предсказанные предложения тематик сократили время обработки звонка на 4 секунды.

Суммарно же сокращение АНТ принесло компании экономию бюджета службы поддержки на 20%.

Интерактивное голосовое меню (Interactive Voice Response, IVR) и чат-боты

Задача — сократить число обращений пользователей, которые требуют участия сотрудника, при этом не ухудшить впечатление от клиентского сервиса. Метрика, которую оптимизировали — число обращений, закрытое без участия сотрудника и без переоткрытия пользователем.

В звонках использовались два подхода:

• IVR, позволяющий получить информацию или совершить самостоятельное действие. Пример: для отмены заказа, нажмите 5 или скажите “отмена”,
• Автоматическая маршрутизация, когда система сама понимает, с кем нужно соединить пользователя.

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

• Что мы знаем о пользователе? Например, статус заказа, наличие открытого обращения в поддержку
• Почему он или она сейчас обращается в поддержку?
• С какой вероятностью можем это угадать?

Изменение логики или фразы проверялось на группе пользователей перед раскаткой на базу.

За счет новой логики работы IVR и маршрутизации сократилась потребность в соединении с оператором.

Примеры удачных логик IVR:

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

Примеры маршрутизации:

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

Похожие действия реализовали и в чатах, проанализировав типичные сценарии переписок. Мы постоянно тестировали новые автоматизации и оставляли только те, у которых были низкие переоткрытия, оставляя возможность быстро связаться с человеком.

С технической точки зрения, логики были реализованы через API поставщика услуг связи. Каждый новый сценарий привязывался через него и менял настройки телефонии.

В итоге, удалось автоматически закрывать 35% обращений: из них 17% заслуга чат-ботов, остальное IVR и маршрутизация.

Итоги проекта

В результате этого проекта компания получила ощутимую экономию затрат. Оценить эффект можно по формуле (стоимость обращения индикативная):

Без автоматизации:

Обращения в месяц: 1 млн

Стоимость обработки одного обращения: 10 руб.

Итого затрат в месяц: 10 млн руб.

С автоматизацией:

Обращения в месяц: 1 млн — 35% = 650 тыс. (те, которые попадут к сотруднику)

Стоимость обработки одного обращения: 10 руб. — 20% = 8 рублей (те же сотрудники, но работают на 20% быстрее)

Итого затрат в месяц: 5,2 млн руб.

Естественно, эти цифры не учитываю затрат на разработку, но решение хорошо окупается на горизонте 2-3х лет. Кроме этого, совместная работа над проектом позволила повысить мотивацию и вовлеченность сотрудников службы поддержки. Провели оценку удовлетворенности сотрудников службы поддержки до начала проекта и после завершения. Удовлетворенность выросла на 17%, при этом сотрудники положительно отмечали:

• обучение новому, работая с технической командой,
• чувство причастности из-за участия в большом проекте,
• возможность повлиять на ежедневную работу.

Этот дополнительный эффект тоже стоит учитывать при оценке результатов проекта.