Как с помощью технической поддержки мобильного приложения увеличить лояльность пользователей: кейс «ЛЕНТА»
Иннокентий Беляев
руководитель support-направления 65apps
Рассказываем, как мы помогли увеличить лояльность пользователей и оценку в сторах через внедрение custdev подхода к развитию продукта на проекте «Лента».
Предыстория
Компания «Лента» пришла к нам в 65apps в апреле 2020 года – в самом начале пандемии. На тот момент у компании уже было мобильное приложение, которое по факту было каталогом товаров.

Уже тогда у "Ленты" были масштабные планы по развитию мобильного приложения: полное обновление электронной программы лояльности, внедрение новой функциональности по сбору корзины и оформлению заказов и доставки.
То есть перед нами стояла большая задача — помочь сделать полноценное e-comm приложение.
Помимо разработки в комплекс наших услуг входила и техническая поддержка — мы отслеживали общую работоспособность приложения и оперативно исправляли баги.

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

Сегодня рассказываем об этом кейсе подробно.
Перед тем, как начать
Несмотря на то, что для пользователя онлайн-магазин «Лента» — единый продукт, внутри работают достаточно обособленные друг от друга команды разработки: сайта, бэкенда, мобильных приложений. И работа с обратной связью была не систематизирована.

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

У нас сформировалось три вектора работы для команды поддержки мобильного приложения:

  • Реагировать на сбои и контролировать исправления дефектов
  • Тесно работать с обратной связью (через обращения и отзывы)
  • Внедрить и развивать custdev подход (аналитика обратной связи и реакция на нее)

И разделили данные работы на три этапа:

  • Аналитика текущей ситуации
  • Создание системы реагирования на обратную связь
  • Внедрение инсайтов в план развития продукта
Подготовительный шаг. Синхронизация команды
На этом этапе для нас важно было пересмотреть все роли как команд, так и конкретных специалистов, исключая «узкие горлышки», «bus factor» и не закрытые ранее варианты проблем.

Для пользователя зачастую продукты и бренд неразделимы, и если пользователь жалуется на работу кассира в отзыве приложения или опоздание курьера – то и эту обратную связь мы обязаны обработать. Карта эскалации должна иметь выходы на всех участников-элементов экосистемы продукта. Будь то служба доставки, работа офлайн магазина, доступность сайта или баги мобильной части.

Уважайте обратную связь от пользователей.
Игнорировать ее = игнорировать пользователя, а значит уничтожать зачатки формирования его лояльности.
Также важно сформировать систему, при которой команда поддержки не только извещает о новых дефектах и жалобах, но и имеет доступ к информации о грядущих релизах.
Ежедневные или еженедельные митинги с командой разработки позволят вам минимизировать риск ущерба и повысить скорость исправления и предоставления решения на ту или иную проблему пользователя.
Шаг 1. Анализ текущих отзывов и ответов
На этом этапе мы уже можем анализировать отзывы пользователей и сопоставлять их с текущей классификацией уже известных проблем.

Анализируем эффекты от предоставленных ответов, разделив их на:

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


Инсайты, которые мы вынесли на этом шаге:

  • Ответы не всегда были конструктивными — не закрывали боль пользователя или не соответствовали приоритетной проблеме, побудившей пользователя написать отзыв.
  • Отсутствие какой-либо персонализации — реакции пользователей отличаются друг от друга, поэтому лучше применять к каждому пользователю разный подход для решения одной и той же проблемы.
  • Большая часть отзывов не покрывалось ответами.
Шаг 2. Формирование матрицы ответов
Совместно с командой «Ленты» мы составили универсальную формулу ответа на отзыв:

  • Приветствие;
  • Извинения;
  • Решение проблемы пользователя;
  • Благодарность;
  • Подпись.

Более подробно о фомулах и составе ответа мы рассказали тут.
Также сформировали оптимальные пути эскалации и прописали шаблоны ответов по каждому виду отзыва.

Например, если пользователь пишет о проблеме с авторизацией, сразу просим отправить номер телефона на почту, потому что этого достаточно для решения проблемы – т.е. мы уже не запрашиваем модель устройства, версию ОС и мобильного приложения.

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

Ниже приведена матрица ответов, где по вертикали идет разделение по проблеме, о которой сообщает пользователь, а по горизонтали – градация по настроению пользователя, т.е. как именно он к ней относится.

Шаг 3. Проверка эффективности новых ответов
Здесь мы тестируем гипотезы тех или иных формулировок, классифицируем ответы на три категории, как и в шаге 1. Но при этом тщательнее прорабатываем формулировки ответов, исходя из того, на сколько условных пунктов (звезд) пользователь исправил оценку.

Первоначальной целью было достичь показателя 25% пользователей, получивших ответ и изменивших оценку. Но в результате нам удалось побудить 45-50% пользователей изменить оценку после ответа техподдержки.
Шаг 4. Повторять, повторять…
Нужно учитывать тот факт, что всегда будут появляться новые проблемы, а значит процесс формирования матрицы должен быть регулярным. Да и старые формулировки просто устаревают.
Шаг 5. Внедряем custdev подход
Фундамент для custdev подхода нужно выстраивать с участием команды техподдержки. Потому что это бесплатный источник продуктовых инсайтов, отличная возможность проверки гипотез исправления багов и возможность реагировать здесь и сейчас.


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

Результаты

Ниже приведены показатели, которых нам удалось достичь на текущий момент совместно с компанией «Лента».