Я начинаю B2B-онбординг с первого обязательства клиента, а не с приветственного письма
Приветственное письмо приятно получить. Но само по себе оно не делает нового клиента пользователем продукта. В B2B-сервисе человек начинает разбираться в системе в тот момент, когда должен сделать первое настоящее действие: назначить ответственного, принять заявку, сверить заказ, закрыть смену. Поэтому я начинаю онбординг не с набора экранов и подсказок, а с первого обязательства клиента.
Это не обязательно большая задача. Важно другое: после неё в работе компании что-то должно измениться. Пока пользователь только смотрит демо, читает письмо или ходит по меню, продукт не проверен. Он проверяется, когда человек рискует рабочим временем и решением.
Почему «показать возможности» — слабая цель
Представим руководителя отдела, который получил доступ к новому сервису. В письме ему предлагают создать проект, пригласить коллег и посмотреть отчёт. Он может всё это сделать — и всё равно вернуться в привычную таблицу через два дня.
Не потому, что он ленив. Просто у него пока нет причины доверить сервису реальную часть дня. Красивый обзор не отвечает на вопрос: «Что я теперь могу не держать в голове?»
Я стараюсь сформулировать первый шаг иначе: какую конкретную ответственность пользователь отдаст системе уже сегодня? Например, руководитель утверждает приоритет заявки, менеджер фиксирует обещанный срок, мастер принимает работу в очередь. У каждого действия есть владелец, предмет решения и понятный результат.
Такой подход полезен ещё до разработки. Он быстро показывает, не маскируем ли мы отсутствие сценария длинным списком функций. Если команда не может назвать первое обязательство, скорее всего, она пока строит витрину, а не рабочий инструмент.
Первое обязательство должно быть безопасным
Есть другая крайность: попросить новичка сразу перенести в продукт весь критичный процесс. Это похоже на переезд, когда вы сначала сдаёте ключи от старой квартиры, а потом начинаете искать коробки. Люди разумно сопротивляются такому старту.
Хорошее первое действие достаточно значимо, чтобы его нельзя было выполнить «для галочки», и достаточно ограничено, чтобы ошибку можно было заметить и поправить. У него есть три свойства.
- Оно происходит регулярно, а не раз в год.
- Результат видит сам пользователь или его коллега.
- Есть привычный путь назад: можно свериться со старым источником, не потеряв работу.
Например, не стоит начинать внедрение системы управления задачами с требования перенести весь архив. Лучше выбрать одну новую заявку и довести её до понятного следующего шага. Не нужно сразу заставлять отдел продаж жить в новом отчёте. Достаточно, чтобы менеджер один раз передал обязательство в исполнение так, чтобы исполнитель не уточнял детали в чате.
Именно такую проверку я называю началом онбординга. Не дату выдачи доступов, не первое письмо и не количество проведённых вебинаров.
У первого действия должен быть адресат
Ещё одна частая ошибка — предложить пользователю что-то сделать «в системе», но не показать, кому станет легче от результата. Человек создал запись, выбрал статус, сохранил форму — а дальше тишина. В такой ситуации новый сервис ощущается как дополнительная отчётность.
Рабочее действие почти всегда кому-то передаёт мяч. Менеджер уточнил состав заказа — производство увидело задачу. Руководитель подтвердил приоритет — исполнитель понял, за что браться. Специалист отметил исключение — коллега получил сигнал, что обычное правило больше не работает.
Когда этот адресат назван заранее, интерфейс обычно становится проще. Появляется не абстрактная кнопка «сохранить», а понятный итог: «передать на проверку», «поставить в очередь», «вернуть с причиной». И клиент видит, что продукт не просит лишний клик, а помогает договориться с другим человеком.
Что измерять без самообмана
На раннем этапе легко увлечься удобными цифрами: сколько людей открыли письмо, посмотрели ролик, прошли подсказки. Они полезны для диагностики, но не отвечают на главный вопрос — вошла ли система в работу.
Я бы смотрел на более приземлённые признаки. Выполнил ли новый пользователь первый рабочий сценарий без постоянной помощи? Появился ли результат у следующего участника процесса? Повторил ли он действие в следующий цикл? Возникла ли понятная обратная связь, а не молчаливый уход обратно в таблицу?
Не обязательно сразу строить сложную аналитику. Иногда достаточно на коротком созвоне открыть несколько свежих объектов и честно спросить: «Где вы остановились?» Такой разбор даёт продуктовой команде больше, чем высокий процент прочтения письма.
Сначала определить момент доверия
У каждого продукта есть момент, после которого пользователь перестаёт относиться к нему как к эксперименту. В одном сервисе это первая корректно закрытая заявка. В другом — когда система сама напомнила о риске и человек успел принять решение. В третьем — когда коллега принял результат без уточняющего звонка.
Полезно обсудить этот момент с клиентом прямо: «После какого действия вы скажете, что сервис уже помогает, а не просто установлен?» Ответ обычно оказывается конкретнее, чем слова про удобство и автоматизацию.
Если клиент говорит: «Когда я увижу все данные», разговор ещё не закончен. Какие данные? Для какого решения? Что произойдёт, если их не будет? Чем точнее вопрос, тем меньше шансов построить ещё один экран, который открывают только на встречах.
Эта логика хорошо сочетается с принципом первого самостоятельного результата в B2B-продукте. Пользователь не должен ждать, пока его проведут за руку по десяти шагам. Но самостоятельность появляется не из инструкции. Она появляется, когда следующий ход понятен и у человека есть право его сделать.
Онбординг начинается до интерфейса
Очень часто проблема не в том, что в продукте мало подсказок. Проблема в том, что до выдачи доступа никто не договорился о простых вещах: кто работает первым, откуда берутся исходные данные, какое решение остаётся за человеком, а какое уже можно доверить правилу.
Допустим, сервис должен помочь руководителю распределять обращения. Если обращения поступают из трёх мест, статусы называются по-разному, а приоритет меняется голосовым сообщением, интерфейс тут не главный герой. Сначала нужно определить один стартовый вход и один понятный результат. Иначе клиент получит не онбординг, а экскурсию по чужому беспорядку.
Поэтому перед первым входом я бы проверил небольшой список:
- Кто выполнит первый рабочий сценарий по имени и роли?
- Какое решение он примет в системе?
- Какие данные нужны именно для этого решения?
- Кому будет виден результат?
- Что делать, если сценарий не сработал или данных не хватило?
Если на любой вопрос ответ звучит как «потом разберёмся», лучше не прятать эту неопределённость за красивым welcome-flow. Её нужно вынести в план запуска.
Не путать обучение с закреплением привычки
Обучение отвечает на вопрос «как нажать». Онбординг отвечает на вопрос «зачем мне возвращаться сюда завтра». Это разные работы.
Часовой созвон может быть полезным. Но после него пользователь остаётся один в реальном дне, где звонят клиенты, горят сроки и коллеги пишут в привычный мессенджер. Если в этот день сервис не помогает сделать один важный шаг проще и яснее, знания быстро выветриваются.
Я предпочитаю короткий цикл: показать конкретный сценарий, дать человеку выполнить его в своей работе, увидеть результат, разобрать препятствие. Такая петля честнее большого обучения, потому что показывает не то, что система умеет в идеальной среде, а то, где она пока не стыкуется с жизнью клиента.
Кто отвечает за следующий шаг
У онбординга часто нет владельца. Продажи считают, что клиент уже передан, внедрение ждёт данных, поддержка узнаёт о проблеме последней, а продукт видит только общую статистику входов. В такой схеме пользователь легко оказывается между командами.
Я бы назначил владельца не «всего счастья клиента», а конкретного первого результата. Его задача — убедиться, что выбранный сценарий выполнен, результат дошёл до следующего участника и препятствие не осталось без ответа. Это может быть менеджер внедрения, руководитель со стороны клиента или ответственный за продукт — зависит от модели работы. Важно, чтобы имя было известно.
Тогда обратная связь становится полезнее. Вместо общего «клиенту сложно» можно увидеть: на втором шаге не хватило права, статус назывался непонятно, коллега не получил уведомление. Такие детали можно исправлять без догадок и без попытки перепроектировать всё сразу.
Именно так первый рабочий сценарий становится не разовой активацией, а началом управляемого развития продукта.
Не обещать больше, чем можно поддержать
На старте особенно соблазнительно пообещать клиенту, что команда поможет с каждым исключением. Но у такой заботы есть цена: пользователь не учится опираться на понятный продукт, а команда начинает держать процесс на личных договорённостях.
Честнее сразу показать границу. Вот сценарий, который сервис поддерживает сейчас. Вот вариант, который пока требует ручной проверки. Вот способ сообщить о нехватке. Такая ясность не отпугивает зрелого клиента; она позволяет ему планировать работу и доверять словам команды.
Онбординг не должен создавать иллюзию, будто любая задача решается нажатием одной кнопки. Его задача скромнее и важнее: дать человеку первый надёжный опыт, в котором обещание продукта совпало с результатом.
В этом же месте часто обнаруживаются настоящие продуктовые вопросы: неясное название статуса, лишнее поле, недостаток прав, непонятное уведомление. Их полезно отделять от индивидуальных пожеланий. Как только команда начинает переписывать правило для каждого нового клиента, масштабирование превращается в обслуживание исключений. Об этом я писал отдельно: новый сегмент не должен размывать правила SaaS.
Как понять, что первый сценарий выбран правильно
Признак не в том, что пользователь поставил галочку в чек-листе. Правильный сценарий меняет разговор команды. Вместо «где это посмотреть?» появляются вопросы уровня «почему система предлагает именно этот вариант?» или «как нам обработать исключение?». Это уже разговор о работе, а не о входе в продукт.
Ещё один хороший знак: клиент может передать сценарий коллеге без разработчика или менеджера рядом. Не обязательно идеальным языком. Важно, что он понимает границу ответственности и следующий шаг. Для B2B это важнее впечатляющего первого экрана: люди работают сменами, уходят в отпуск, меняют роли. Продукт, который держится на одном «знающем» пользователе, пока не стал частью процесса. Похожую проверку я разбирал в заметке о передаче дела коллеге.
Что стоит сделать на ближайшем запуске
Выберите не экран, а одно обязательство нового пользователя. Сформулируйте его простым предложением: «После первого дня этот человек сам делает ___, а коллега видит ___». Затем сократите путь до этого результата и заранее договоритесь, как проверить ошибку.
Так продукт перестаёт знакомить клиента с собой и начинает занимать честное место в его работе. А это и есть начало настоящего онбординга.
Обсудим?