Сегментированный онбординг: свой путь администратору, пользователю и наблюдателю

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

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

Три роли по умолчанию и что для каждой значит ценность

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

• Администратор (создатель аккаунта, владелец настройки). Его задача — заставить продукт работать на команду: подключить данные, настроить рабочее пространство, раздать права, позвать людей. Его первая ценность не личная: она наступает в момент, когда система заработала для приведённой им команды. Он терпит больше всех трения при настройке, но именно он несёт решение о покупке — поэтому его заминки обходятся вам дороже всех остальных.
• Конечный пользователь (приглашённый исполнитель). Его задача — ежедневный глагол вашего продукта: завести задачу, записать звонок, опубликовать пост. Инструмент выбирал не он, и мотивации администратора он не разделяет; его первая ценность — сделать один настоящий кусок собственной работы быстрее или лучше, чем раньше. Любой шаг настройки, показанный ему, — чистое трение: настройку уже сделал кто-то другой.
• Наблюдатель (потребитель результата). Руководители, заглядывающие в дашборд, заинтересованные лица, читающие отчёты. Их задача — найти нужное и понять его. Их первая ценность — один взгляд на отчёт, отвечающий на важный для них вопрос. Весь их онбординг вполне законно может состоять из двух тултипов и внятно подписанной навигации.

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

Откуда берётся сигнал о сегменте

Чтобы ветвиться, надо знать, с кем вы говорите, — и источники сигнала выстраиваются по надёжности:

1. Факты продукта. Уровень прав, роль в рабочем пространстве, тариф. Если продукт уже знает, что у пользователя доступ только на чтение, опрос не нужен: самая надёжная сегментация — та, о которой нельзя соврать.
2. Контекст прихода. Самостоятельная регистрация против перехода по приглашению — самое ценное разделение в командных продуктах, и достаётся оно бесплатно. Приглашённый приходит в уже существующее рабочее пространство, и один этот факт обязан перекроить всю его первую сессию.
3. Приветственный опрос из одного вопроса. Там, где фактов не хватает, спросите — один раз, с тремя-четырьмя вариантами, сформулированными как задачи («настроить всё для команды» / «делать здесь свою ежедневную работу» / «смотреть отчёты»). Заявленное намерение неидеально, но короткий честный вопрос работает лучше длинной догадки, а заодно даёт объявленные данные для всех последующих сценариев. В NudgePath ответы на опрос попадают в ту же модель сегментов, что и атрибуты продукта, так что «что человек сказал» и «кто он есть» управляют одной и той же логикой ветвления.
4. Поведение в первой сессии. Там, где даже вопрос — перебор, смотрите, что человек трогает первым, и подстраивайтесь со второй сессии. Поведение со временем исправляет неверно размеченных: администратор, который сам себя таким назвал и ни разу не открыл настройки, о чём-то вам сообщает.

Как спроектировать три сценария

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

Сценарий администратора несёт полную дугу настройки, но выстроенную ради ощущения движения: чек-лист идёт от подключения данных к первому результату и дальше к приглашению команды, причём приглашение подано через выгоду («ваша команда увидит этот дашборд, а не пустой экран»). Чисто административные темы — права, оплата — всплывают на тех экранах, где они уместны, а не в приветственном сценарии.

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

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

Не дать ветвлению взорваться

Классический провал сегментированного онбординга — не недостаток сегментации, а матрица. Три роли × четыре тарифа × три отрасли — это тридцать шесть сценариев, а тридцать шесть сценариев означают тридцать пять, которые вы никогда не будете поддерживать. Ограничители:

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

Разберитесь с неудобными случаями осознанно

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

Мерьте каждый сценарий по его собственному определению ценности

Сегментированному онбордингу нужен сегментированный замер — и именно здесь команды чаще всего перечёркивают собственную работу: одна усреднённая цифра активации спрячет провал одного сценария за успехом другого. Определите активацию для каждой роли — у администратора это команда, работающая на настоящих данных, у конечного пользователя — первая выполненная задача, у наблюдателя, возможно, второй добровольный визит — и читайте воронку каждого сегмента отдельно. А потом тестируйте внутри сегментов: A/B чек-листа конечного пользователя — только среди конечных пользователей, с контрольной группой, подтверждающей, что ветка обыгрывает общий сценарий, на смену которому она пришла. Именно это сравнение и оправдывает всю программу — а гонять его по каждому сегменту платформы вроде NudgePath как раз и созданы делать рутиной, а не подвигом.

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