Всем привет, на связи Иннокентий Беляев – руководитель отдела технической поддержки 65apps. В этот раз хочу рассказать вам, как мы помогли увеличить лояльность пользователей и оценку в сторах через внедрение custdev подхода к развитию продукта на проекта “Лента”.
Предыстория
Компания «Лента» пришла к нам в 65apps в апреле 2020 года – в самом начале пандемии. На тот момент у компании уже было мобильное приложение, которое по факту было каталогом товаров.
Уже тогда у “Ленты” были масштабные планы по развитию мобильного приложения: полное обновление электронной программы лояльности, внедрение новой функциональности по сбору корзины и оформлению заказов и доставки.
То есть перед нами стояла большая задача — помочь сделать полноценное e-com приложение.
Помимо разработки в комплекс наших услуг входила и техническая поддержка — мы отслеживали общую работоспособность приложения и оперативно исправляли баги.
Мы понимали, что любые большие изменения в мобильном приложении — это всегда риск падения оценки в сторах и, соответственно, урон для репутации бренда. Негативную обратную связь всегда оставляют охотнее.
Поэтому мы предложили клиенту расширить услуги нашей команды — внедрить работу первой линии тех поддержки и закрывать весь фронт задач общения с пользователями сторах.
Сегодня рассказываем об этом кейсе подробно.
Перед тем, как начать
Несмотря на то, что для пользователя онлайн-магазин «Лента» — единый продукт, внутри работают достаточно обособленные друг от друга команды разработки: сайта, бэкенда, мобильных приложений. И работа с обратной связью была не систематизирована.
Поэтому мы решили расширить задачи технической поддержки: обеспечивать не только работоспособность МП и устранение багов, но и повышение уровня клиентского сервиса и лояльности пользователей.
У нас сформировалось три вектора работы для команды поддержки мобильного приложения:
- Реагировать на сбои и контролировать исправления дефектов
- Тесно работать с обратной связью (через обращения и отзывы)
- Внедрить и развивать custdev подход (аналитика обратной связи и реакция на нее)
И разделили данные работы на три этапа:
- Аналитика текущей ситуации
- Создание системы реагирования на обратную связь
- Внедрение инсайтов в план развития продукта
Подготовительный шаг. Синхронизация команды
На этом этапе для нас важно было пересмотреть все роли как команд, так и конкретных специалистов, исключая «узкие горлышки», «bus factor» и не закрытые ранее варианты проблем.
Для пользователя зачастую продукты и бренд неразделимы, и если пользователь жалуется на работу кассира в отзыве приложения или опоздание курьера – то и эту обратную связь мы обязаны обработать. Карта эскалации должна иметь выходы на всех участников-элементов экосистемы продукта. Будь то служба доставки, работа офлайн магазина, доступность сайта или баги мобильной части.
Уважайте обратную связь от пользователей. Игнорировать ее = игнорировать пользователя, а значит уничтожать зачатки формирования его лояльности.
Также важно сформировать систему, при которой команда поддержки не только извещает о новых дефектах и жалобах, но и имеет доступ к информации о грядущих релизах.
Ежедневные или еженедельные митинги с командой разработки позволят вам минимизировать риск ущерба и повысить скорость исправления и предоставления решения на ту или иную проблему пользователя.
Шаг 1. Анализ текущих отзывов и ответов
На этом этапе мы уже можем анализировать отзывы пользователей и сопоставлять их с текущей классификацией уже известных проблем.
Анализируем эффекты от предоставленных ответов, разделив их на:
- Недопустимые – ответы категорически не подходящие для решения проблемы и перевода негативного пользовательского опыта в положительный.
- Неэффективные – ответы, требующие доработки, которые по тем или иным причинам не побудили пользователя изменить оценку (не было дано полное решение, недостаточный уровень эмпатии и т.д.).
- Эффективные – ответы, побудившие пользователя изменить оценку в положительную сторону и решающие проблему.
Купить рекламу Отключить
Инсайты, которые мы вынесли на этом шаге:
- Ответы не всегда были конструктивными — не закрывали боль пользователя или не соответствовали приоритетной проблеме, побудившей пользователя написать отзыв.
- Отсутствие какой-либо персонализации — реакции пользователей отличаются друг от друга, поэтому лучше применять к каждому пользователю разный подход для решения одной и той же проблемы.
- Большая часть отзывов не покрывалось ответами.
Шаг 2. Формирование матрицы ответов
Совместно с командой «Ленты» мы составили универсальную формулу ответа на отзыв:
- Приветствие;
- Извинения;
- Решение проблемы пользователя;
- Благодарность;
- Подпись.
Более подробно о фомулах и составе ответа мы рассказали тут.
Также сформировали оптимальные пути эскалации и прописали шаблоны ответов по каждому виду отзыва.
Например, если пользователь пишет о проблеме с авторизацией, сразу просим отправить номер телефона на почту, потому что этого достаточно для решения проблемы – т.е. мы уже не запрашиваем модель устройства, версию ОС и мобильного приложения.
Таким образом, мы сократили путь эскалации и облегчили объем данных, запрашиваемых у пользователя.
Ниже приведена матрица ответов, где по вертикали идет разделение по проблеме, о которой сообщает пользователь, а по горизонтали – градация по настроению пользователя, т.е. как именно он к ней относится.
Благодаря этому мы имеем:
- Несколько формулировок на одну проблему.
- Спектр формулировок, разделенный по цветам (настроению).
Это позволяет оптимизировать скорость предоставления ответа без потери чувства эмпатии, а значит для пользователя будет очевидно, что по ту сторону диалога находится живой человек, а не бот. Это особенно важный момент, т.к. новые пользователи перед скачиванием приложения обращают внимание на отзывы и ответы, предоставленные на них техподдержкой.
Шаг 3. Проверка эффективности новых ответов
Здесь мы тестируем гипотезы тех или иных формулировок, классифицируем ответы на три категории, как и в шаге 1. Но при этом тщательнее прорабатываем формулировки ответов, исходя из того, на сколько условных пунктов (звезд) пользователь исправил оценку.
Первоначальной целью было достичь показателя 25% пользователей, получивших ответ и изменивших оценку. Но в результате нам удалось побудить 45-50% пользователей изменить оценку после ответа техподдержки.
Шаг 4. Повторять, повторять…
Нужно учитывать тот факт, что всегда будут появляться новые проблемы, а значит процесс формирования матрицы должен быть регулярным. Да и старые формулировки просто устаревают.
Шаг 5. Внедряем custdev подход
Фундамент для custdev подхода нужно выстраивать с участием команды техподдержки. Потому что это бесплатный источник продуктовых инсайтов, отличная возможность проверки гипотез исправления багов и возможность реагировать здесь и сейчас.
На первый взгляд может показаться, что это трудоемкий процесс, требующий специальных инструментов, но в жизни все проще и можно использовать вполне простые “ручные” методы сбора и ведения аналитики. Например, гугл таблицы 🙂
При этом даже ручной сбор позволит практически не терять скорость предоставления ответа и высвобождать время продуктовых менеджеров и аналитиков
Более подробно о том как выстроить работу, мы писали в здесь.
Результаты
Ниже приведены показатели, которых нам удалось достичь на текущий момент совместно с компанией «Лента».
Источник: vc.ru