Как мы онбординг в iGMS переделывали и проблемы искали

Задачи:

Краткий итог: снижение количества обращений в поддержку на этапе подключения в 14 раз; выявлен большой список скрытых проблем и проработан план их устранения.

Контекст

iGMS — система для управления объявлениями на Airbnb, Booking.com и похожих сайтах для сдачи недвижимости в аренду. Рантье подключают свои аккаунты к системе, после чего могут управлять ценами на календарях, назначать задачи персоналу и общаться с гостями в едином интерфейсе. Продукт работает с 2015 года на высоко­конкурентном рынке.

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

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

Процесс

После обсуждения и уточнения задачи с руководством проекта, я собрал и изучили всё, до чего смог дотянуться: от команды поддержки получил список жалоб клиентов, возникающих на первых этапах работы с продуктом; макеты и скриншоты предыдущих, и нереализованных версий разных этапов; документацию разработчиков по работе с API подключаемых сервисов; описание прототипов; структурные схемы…

Куча материалов и источников для погружения в задачу

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

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

Составил несколько SQL-запросов и начал регулярно вытягивать данные из БД. На их основе собрал таблицу с визуализацией в Google Sheets, где отобразил показатели конверсии и оттока для разных групп пользователей. Этот документ до сих пор регулярно обновляется, служит хорошим подспорьем для расследований и иллюстрирует текущее здоровье продукта.

Таблица в Google Sheets с визуализацией показателей конверсии и оттока пользователей

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

На актуальной карте отобразил показатели воронки конверсии и описал выявленные проблемы на каждом этапе. Так мы смогли определить с руководством список требуемых изменений.

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

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

Далее, в несколько итераций, мы согласовали новую карту взаимодействия.

Схема нового пути пользователя с зафиксированными метриками и целями

На её основе я подготовил кликабельный прототип в фигме, покрывающий разные сценарии процесса подключения и несколько концептов для онбординга, помогающих пользователям сориентироваться в незнакомом интерфейсе.

Кликабельный прототип всего процесса в фигме

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

Концепты подходов к онбордингу новых пользователей в фигме

После успешной презентации, оставалось лишь…

Результат

Проект был запущен в марте 2020. На это время пришлось основное давление на рынки туризма и аренды в связи с началом пандемии COVID-19. Это оказало сильное влияние на активность и приток новых пользователей продукта.

Несмотря на кризис, данные конверсии показали положительную динамику. Клиенты стали более охотно проходить процесс онбординга самостоятельно. Количество обращений в поддержку на этом этапе сократилось с 14% до менее 1%, пользователям практически не требовалась помощь в процессе интеграции аккаунтов. В первую очередь, на это положительно повлияли визуальное упрощение интерфейса, расстановка правильных акцентов и сокращение количества этапов всего процесса.

Несколько экранов финального результата

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

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

iGMS 2020

✏ Заметка опубликована


Предыдущая

УберДата — используем реальные данные в макетах

Следующая

Как мы Booking.com к iGMS подключали

Другие заметки