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