Интро
Я работаю в отделе развития заботы о клиентах и помогаю создавать сервис, в котором операторы могут удобно и быстро отвечать пользователям, обратившимся в поддержку. На текущий момент кол-во посетителей сайта более
40 млн уникальных пользователей в месяц, обращений в подержку N в день, из которых более 70% про некоректное начисление бонусов. Обработкой этих тикетов занимается отдельная вторая линия, которая обрабатывает их в сложнонагруженных системах.
Задача упростить обработку тикетов, чтобы разгрузить вторую линию, оставить их на первой и существенно сократить время обработки.
Изучение процесса AS IS
Для лучшего погружения в проблематику я изучала текущий user flow для понимания реального опыта работы оператора. Так как над задачей мы с бизнес-аналитиком работали паралельно и я изучала диаграмму планируемую работы, мне хотелось больше ориентироваться на опыт оператора, а не на ограничения систем, которые как в процессе проработки можно улучшить или изменить
Составление флоу To be
Я созвонилась с оператором и записала процесс обработки тикета. Выяснила, что для проверки начисления бонусов оператор ходит в несколько систем, чтобы перепроверить в какой именно отвалились данные, чтобы там прописать скрипт и запустить отправку бонусов заново. На один тикет в среднем уходит около 5 минут, так как необходимо тратить время на поиск в сложных системах небольших данных. Ниже представлены скриншоты систем, в которые заходит оператор для выяснения данных по заказу. Зеленым стикером я фиксировала действие оператора на экране
После понимания флоу оператора я перешла и изучения требований к системе, я перешла к проектированию нового раздела. На мой взгляд, он существенно упрощает работу оператору — ему не нужно искать, где именно произошел сбой в передаче данных, мы буквально свели все действия к нажатию одной кнопки. Сейчас покажу.
В моей гипотезе обработка бонусов является частью текущего интерфейса операторов первой линии для их будущего удобства. Сюда же прокидывается данные из трех систем, но в табличном отображении. Мы знаем, что корректные данные абсолютно всегда приходят в первом столбце (и напишем об этом в инструкции), поэтому ориентируемся на данные, относительно первого столбца. Если есть расхождение — подсвечиваем красным, чтобы оператор обратил внимание и видим, что в одном товаре мы не протянули статус, из-за чего начисление бонусов не случилось. Одним нажатием мы протаскиваем новый запрос в стороннюю систему (так как это единичный запрос на один товар, он проходит быстро и без ошибок), бонусы подтягиваются и начисление бонусов для пользователя происходит.
В целом основные сценарии получились простыми. Мы ориентируемся на индикатор статуса и корректируем его (либо протаскиваем отмену товара, либо его доставку).
Проверка решения
Само решение я прорабатывала, опираясь на диаграмму взаимодействия систем, а так на флоу оператору, который я изучала ранее: его основные действия, сценарии, данные. Получилась довольно простая система, но теперь необходимо проверить решение на реальных операторах. Для этого я собрала прототип, сформировала гипотезы и подготовилась к глубинным интервью.
Мы пообщались с 6 операторами, с каждым по часу и получили данные.
Гипотезы:
Все данные по исследованию хранятся в фигджеме, что очень помогало при презентации исследования и выводов стейкхолдерами и защиты своей задачи
В рамках исследования некоторые мои гипотезы не подтвердились и я скорректировала решение, основываясь уже на реальном фидбеке пользователя. Так же вовремя проработки задачи я пользовалась отличной фичей — кросс-ревью с другим дизайнером. Очень помогало иногда свежим взглядом посмотреть на сценарии, над которыми работаешь уже месяц и в некоторых местах глаз замыливался.
Пример сценариев, которые передавались в разработку
Результат
Внедрение новой более простой системы обработки заказов с бонусами полностью разгрузило вторую линию, а решение одной задачи сократило с 5 минут до среднего показателя 1 минута, что значительно повлияло на AHT и количество обработки тикетов одним оператором.
