Идеи для сокращения onboarding из b2b продаж
Онбординг происходит, когда вы в первый раз заходите в приложение или на сайт. Вас заинтересовала реклама, вы перешли на сайт/в приложение, зашли в демо-доступ и перед вами личный кабинет. Вы хотите разобраться как там все устроено, и что вы можете с этим сделать. Если вам что-то или кто-то помогает в этом, то происходит онбординг.
С точки зрения бизнеса, онбординг — это этап пути пользователя (CJM), перед тем как он купит продукт или подпишется на приложение.
Михаил Цвик, Product Owner Revolut делится своим видением о месте онбординга в структуре воронки продаж в этой статье. Вот такую он приводит схему:
И вот так описывает задачу этого этапа: “Онбординг продаёт веру в то, что продукт решит конкретную проблему, полностью сопровождая его на пути к покупке, демонстрируя пользователю решение и конкретные кейсы”.
Это ключевой этап демонстрации ценности продукта, который затем ведет к решению: покупать или нет. Здесь нужно дать пользователю причину и достаточно мотивации для совершения покупки.
Что бывает не так с онбордингом?
Проблему можно понять через типичный сценарий поиска софта для управления проектами.
Недавно выбирал себе программу. Погуглил топ-10 решений и зашел в самый рекомендуемый (отмел по пути те, у которых не было демо-доступа). Передо мной предстал таинственный личный кабинет без навигации и всплыли назойливые окна подсказок про разные кнопки. Потыкав там пару кнопок я убежал, потому что не увидел как я могу создавать задачи и перетаскивать их туда-сюда.
Вспомнив из головы, что есть Trello (сила бренда), я зашел, сразу создал первые задачи, увидел кучу помогающих шаблонов и остался. Мой запрос удовлетворен: простое управление, которое я могу раскрасить под себя. Я пришел за софтом не для того, чтобы еще в нем разбираться. Onboarding в Trello длился наверное полминуты, после чего я остался.
В первом случае мне пытались помогать, но по сути мешали, во втором активных действий со стороны программы не было, просто она настроена так, что я быстро смог решить свою ключевую задачу.
Вообще бывает много причин неудачного онбординга и оттока пользователей, например в этой статье резюмированы 6 штук.
На что это влияет?
На продажи и рост компании. Чем больше людей стали пользователями, тем больше купит затем подписку и останется надолго. Хороший онбординг — это рост конверсий и сокращение цикла продаж.
Вот таблица, которая помогает понять для чего нужен хороший быстрый onboarding.
Что отличает хороший onboarding от провального?
Наличие момента, когда у пользователя защелкивается: эта штука — то, что мне нужно! (Потому, что решает мою проблему).
Еще это называют “Aга!-момент”.
Чем раньше он происходит, тем выше конверсия в оплату впоследствии и тем больше прибыль.
В примере с Trello — я сразу смог решить свою задачу, за которой пришел: создать список задач и разместить их на экране для визуализации и контроля. Это было почти мгновенно и Trello больше не нужно тратить деньги на привлечение меня как покупателя. Чем больше таких как я, тем меньше стоимость привлечения покупателя: CAC.
Как сделать onboarding более конвертирующим и быстрым?
Быстрее приводить человека к “Ага!-моменту”.
Тот же Михаил Цвик, который Product Owner в Revolut, а ранее работал в Wrike, советует создавать предконфигурации продукта под каждый сегмент целевой аудитории. Это означало на примере Wrike показать пользователю кастомизированные шаблоны, такие как: event management, campaign management и так далее, в зависимости от того кем этот пользователь являлся. Контролировали же они кто пришел через рекламные объявления вроде “Wrike для маркетологов”. Подробнее тут.
Чтобы понять почему это работает возьмем пример живого продажника.
Как улучшать онбординг на примере b2b-продаж
Представим, что продается онлайн обучение soft skills для среднего менеджмента. В переписке с потенциальным клиентом мы назвали главное преимущество: “Обучение состоит на 90% из практики, с постоянным сопровождением личного ментора”. И вот заинтересованный клиент пришел на конференцию в Zoom.
- Он пришел в ожидании, что ему продемонстрируют как реализовано: “Обучение на практике с постоянным сопровождением”. Он уже в общем и целом понимает почему это хорошо, так как мы попали в боль. Сейчас он хочет понять сможет ли он это применить у себя с пользой.
- Если менеджер, проводящий демо опытный, он уже к этому моменту знает причину интереса и в чем конкретно эта штука может помочь потенциальному клиенту. Если еще не знает, он обязательно должен считать запрос.
- Допустим у клиента периодически возникает ситуация, что на руководителя команды назначить некого, потому что старый ушел, а более младших не продвинуть — не умеют управлять. Поэтому клиенту приходится нанимать на рынке, а затем еще обучать человека специфическим процедурам самой компании. Это дороже, чем повысить кого-то изнутри, так как тратится рабочее время сразу нескольких руководителей.
- Значит менеджер, проводящий демонстрацию должен в самом начале сказать, что специально для таких целей есть пакет по подготовке кадрового резерва к руководящей роли, и сейчас он покажет как тот работает.
- Затем он должен показать какие курсы наиболее релевантны для кадрового резерва и дать клиенту попробовать практическую часть. При этом ему нужно постоянно снабжать показ комментариями о том, что отработка навыков идет на собственных рабочих задачах ученика. А еще нужно показывать как его сопровождает ментор, и как они вместе достигают успеха.
- После чего нужно сказать о том как они уже помогли с точно такой же задачей какой-то известной компании спросить могла бы эта платформа помочь с решением задачи клиента, которая у него есть прямо сейчас?
После такой встречи (если продукт действительно выполняет заявленные задачи), клиент пойдет согласовывать ваше предложение внутри компании.
Если бы менеджер просто демонстрировал функционал личного кабинета, то на второй минуте презентации клиент бы попросил закончить и прислать имейл с информацией. Больше бы мы его не увидели.
Ключевые вещи, которые можно взять из этого дедовского метода в web / mobile
- Пользователь с самого начала должен видеть, что это нацелено на решение его проблемы. Отсюда предконфигурация у Wrike;
- Для этого нужно очень подробно знать проблему пользователя и демонстрировать ему только те функции, которые помогают ему решить проблему;
- Он должен максимально быстро понять как работает то, что его интересует. Например в моем случае — быстро создание задач и легкое управление их перемещением в Trello;
- Он должен, в идеале, сам совершить успешное действие и получить результат как в моем случае с Trello.
Так достигается желаемый “Ага!-момент”. Ребята из Trello смогли срежиссировать его для меня в течение менее минуты без подсказок и всплывающих окон. Это пример “идеальной системы” — когда ты ничего видимого не делаешь, но функция выполняется.
Я считаю, что нужно насколько возможно избегать подсказок и направлений, чтобы человек сам без труда мог получить, что ему нужно. Подсказки — это как скобки в тексте: зачем их ставить и удлинять предложение, если вместо этого можно выразить смысл точнее.
Спасибо за внимание и пишите, если хотите пообщаться: konstantin.leshchenko@gmail.com!
Источники