Виктория Кравченко

Восемь уроков: как превратить знакомство с пользователем в серьезные отношения

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

Однако, достаточно вспомнить тот же Adobe Photoshop, чтобы понять безапелляционность такого утверждения. Игнорируя адаптацию «новичков», вы делаете свою бизнес-модель уязвимой, не говоря уж про страдания пользователя.

Родион Насакин, директор по региональному маркетингу в Восточной Европе компании Wrike, рассказывает, как превратить знакомство с пользователем в серьезные отношения.


Как не стать МММ

Разовые платежи за софт «на всю жизнь» все менее интересны и для индустрии, и для пользователей. Бал правят подписки, встроенные покупки, freemium и другие растянутые во времени варианты монетизации. Это меняет правила игры и подход к метрикам успеха — с регистрацией нового клиента борьба за выручку только начинается.


Не стоит забывать про конкуренцию

Какой бы сервис или приложение вы ни разрабатывали, с каждым годом на вашем рынке будет все теснее.


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


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


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

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

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


Урок 1. Фокусироваться на чужой работе вместо своих функций

Людей не интересует ваша функциональность от слова «вообще». Они хотят решить свою проблему. Когда вам говорят, что непонятно, кто за что отвечает, а срыв сроков стал привычным делом, хуже всего — показать в ответ скриншоты диаграммы Ганта и графиков производительности. Это будет разговор слепого с глухим.


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


Урок 2. Искать адвокатов продукта среди знатоков

В большинстве компаний есть люди, которых считают знатоками новых технологий. iPhone у них появляется в течение нескольких дней после начала продаж в Штатах, а их заявки на новый ноутбук заставляют ИТ-службу гуглить непонятные слова.

  • В случае с массовым рынком эти люди, так называемые early adopters, — первичная аудитория продукта. Они служат стартовым трамплином для выхода в мейнстрим.
  • В случае с корпоративным продуктом то же самое происходит на уровне отдела или компании. Если продукт понравится людям, которые, по мнению коллег, разбираются в технологиях лучше прочих, вы убьете двух зайцев сразу. Во-первых, авторитетное мнение знакомого человека заставит пользователя изучить продукт тщательнее и с позитивным ожиданием результата. Во-вторых, новому пользователю может быть проще обратиться с вопросом к своему знающему коллеге, чем написать в поддержку.

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


Урок 3. Внятно отвечать на вопросы «Зачем?» и «Как?»

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


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


Нужно быть готовым рассказать о пользе решения, исходя из его ценности как для бизнеса, так и конечного пользователя. Начальник отдела будет рад получить централизованный хаб для ведения всех задач сотрудников с быстрым поиском. Это сделает процессы прозрачнее и позволит сэкономить десятки рабочих часов в неделю. Его подчиненных больше впечатлит простота, с которой они смогут создавать задачу в системе из любого email’а без необходимости копировать и вводить текст вручную.


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


Не забудьте рассказать им про лучшие практики, чтобы софт использовали так, как вы задумали. В случае с B2B помогут тренинги для команд и отделов с вопросами и ответами, ну и конечно исчерпывающие FAQ и документация.


Урок 4. Поддержка в одно касание

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


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


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


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



Урок 5. Использовать обратную связь в работе над UX

Роль поддержки не сводится к «неотложке». Информация, которую собирают эти ребята, — ценный источник жизненной правды, которая может разрушить иллюзии UX-дизайнеров и продукт-менеджеров. Все, что нужно — научиться собирать, агрегировать и использовать эти данные.


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


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

Разделите число жалоб на число людей, которые выполняли такое действие. Такой «коэффициент проблемности» поможет быстро оценить, какие моменты в UX наименее очевидны для понимания.


С подобными цифрами у вас появляется повод для общения с UI/UX-дизайнером (или повод открыть соответствующую вакансию). В идеале это не должны быть разовые запросы, а устоявшаяся переработка обратной связи в UX-повестку.


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


Урок 6. Найти ответственных за успех

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

В первую очередь речь идет о больших аккаунтах из сотен и тысяч пользователей. На Западе за такими сотрудниками закрепилось название Customer Success Reps или Managers (CSM).


CSM-специалисты сосредоточены каждый на своих аккаунтах и более детально, чем поддержка, погружаются в особенности работы «подопечных» с продуктом. У клиента появляется прямой и персональный контакт, которому он может задавать специфические вопросы («Как мне построить в системе диаграмму Ганта вот для этих задач по конференции?»). К тому же CSM служат связующим звеном между пользователем, разработчиком, поддержкой и отделом продаж.


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


Урок 7. Не притворяться единственным приложением в мире

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

Маркетологи уже хранят файлы в Dropbox, продажи ведутся в Salesforce, поддержка закрывает тикеты в Jira и так далее. И когда мы представляете свое решение для всей команды, будьте готовы к вопросу об интеграции со всеми инструментами, которыми эта команда пользуется.


Урок 8. Все в ответе

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

Гарантий нет, и пунктами выше пространство для улучшений не ограничивается.


Не забывайте:

  1. Разработчики и продукт-менеджеры отвечают за создание продукта, который решает реальные проблемы.
  2. UI/UX-специалисты делают его понятным и интуитивным в использовании.
  3. Маркетинг и дизайн объясняют пользователям, что именно это лучший подход к решению их задач.
  4. И, наконец, команды, работающие напрямую с пользователем, обеспечивают его гладкий переход к этому новому подходу.

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



comments powered by Disqus

Подпишитесь на рассылку RUSBASE

Мы будем вам писать только тогда, когда это действительно очень важно

Нажмите "Нравится",
чтобы читать Rusbase в Facebook