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