Все, что стоит проверить перед запуском функции в B2B-SaaS

Проблема не всегда в самой функции. Как я вижу, часто проблема в том, что перед запуском проверили только разработку, ну рекламу по минимуму. А надо было проверить весь контур.

1. Кому эта функция реально нужна

База: для кого мы это сделали? В бизнесовых саасах пользователем может быть кто угодно: администратор, аналитик, руководитель отдела, сотрудник поддержки, закупщик, безопасник, клиентский менеджер. И у каждого будет свой сценарий.

Т.о. перед релизом стоит проверить:

1. кто основной пользователь функции;
2. кто принимает решение о ее использовании;
3. кто получит от нее пользу;
4. кто будет мешать внедрению;
5. насколько часто возникает этот сценарий;
6. это массовая потребность или просьба одного громкого клиента.

Последний пункт особенно важен. В B2B один крупный клиент может звучать как весь рынок. Он пишет в чаты, дергает аккаунта, приходит на встречи, формулирует запросы, трясет бюджетом. Но это еще не значит, что функция будет нужна.

2. Какую проблему закрывает функция

Или какая работа у клиента станет проще после запуска? Какие варианты могут быть:

1. клиент быстрее собирает отчет;
2. менеджер меньше ошибается при обработке заявки;
3. руководитель видит проблему до того, как она набрала обороты;
4. администратор не дергает поддержку по типовым настройкам;
5. команда клиента экономит время на ручных действиях.

Если такую пользу нельзя сформулировать в одну-две понятные фразы, то функция скорее всего не готова к запуску с точки зрения коммуникации. Она может быть готова технически. Но клиенту нужно решение проблемы, а не просто новая фича.

3. Где пользователь найдет функцию и что сделает первым

Даже самая полезная функция может не взлететь, если ее плохо встроили в сценарий.

А это может быть из-за таких причин:

1. функцию спрятали в настройках;
2. она называется не так, как клиент привык думать о задаче;
3. первый шаг непонятен;
4. после включения визуально ничего не происходит;
5. нет подсказки, что делать дальше;
6. успех сценария неочевиден.

Для B2B это особенно больно, потому что пользователь часто не сидит в продукте весь день из любопытства. Он заходит решить конкретную задачу. Если не понял за пару секунд, куда нажмать и что изменилось, он просто вернеться к старому процессу.

Перед релизом стоит пройти путь глазами клиента: как узнает о фишке, где найдет, что сначала надо сделать, как понять, что получилось, нужно ли будет подключать коллег.

Особенно полезно проверить сценарий на человеке, который не участвовал в разработке. Потому что команда продукта часто страдает профессиональной слепотой: нам кажется очевидным то, что мы обсуждали три месяца в Jira, Figma и на созвонах.

Пользователь этих созвонов не видел. Счастливчик.

4. Что будет с тарифами и монетизацией

Рано или поздно всплывает вопрос денег. А значит, перед релизом следует понять:

1. функция входит во все тарифы, только в топовые или как вообще;
2. она нужна для upsell;
3. может ли она стать причиной повышения чека;
4. не обесценивает ли она платные возможности;
5. не ломает ли текущую тарифную сетку;
6. как объяснить клиенту, почему она стоит денег.

Нередко в таких саасах опасно запускать все просто в общий доступ, а потом через полгода пытаться это монетизировать. Хотя и такие схемы часто встречаю. Но вместе с тем бывает, что клиенты быстро привыкают к бесплатности новой ценности, а потом любая попытка завернуть ее в тариф выглядит как отъем конфет.

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

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

Если роли нет, это тревожный сигнал. Возможно, функция просто прикольная. А такое в B2B обычно проигрывает.

5. Готовы ли продажи

Если продажи не понимают, как объяснять новую возможность, они начнут объяснять ее как смогут. А смогут иногда слишком творчески.

Перед релизом продажам нужно дать:

1. короткое описание функции человеческим языком;
2. кому она полезна, а кому нет;
3. какую боль закрывает;
4. в каких сделках ее стоит показывать, а в каких нет;
5. какие ограничения нельзя замалчивать;
6. чем она отличается от похожих возможностей конкурентов;
7. какие вопросы может задать клиент.

Особенно важно определить, кому не подходит. Ведь хочется продавать всем. Но честные ограничения экономят много времени, поверьте.

6. Готова ли поддержка

Если поддержка узнает о релизе последней, это очень нехорошо. И вместе с тем очень часто встречается даже у бигтехов.

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

Так что до релиза у поддержки должны быть:

1. подробный FAQ;
2. короткая внутренняя инструкция;
3. список ограничений;
4. сценарии типовых ответов;
5. понимание, куда эскалировать сложные случаи;
6. контакты ответственного продакта или команды;
7. критерии, что считать багом, а что ожидаемым поведением.

Иначе просто зазря будут перегружаться и поддержка, и продакт, и разраб, и все вокруг.

7. Готовы ли сопровождение клиентов и внедрение

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

Перед релизом нужно понять:

1. надо ли проводить клиентов через настройку;
2. кто внутри клиента должен участвовать;
3. нужна ли инструкция для администратора;
4. можно ли сделать шаблон внедрения;
5. какие клиенты должны узнать о функции первыми;
6. кому нужна персональная коммуникация;
7. какие аккаунты могут стать пилотными кейсами.

В B2B функция может не взлететь не потому, что плохая, а потому что ее никто не встроил в процесс клиента. Типа сделали отчет, но руководитель не попросил команду им пользоваться. Или добавили автоматизацию, но администратор не выдал права. Или, скажем, запустили интеграцию, но на стороне клиента нужен безопасник, который ушел в отпуск.

8. Настроена ли аналитика

Один из самых неприятных сценариев: функция запущена, прошло две недели, и команда спрашивает за результат. А ответа нет. Потому что события не настроены, воронка не собрана, критерии успеха не определены.

Да, это уже совсем для тупых, согласен. Базово бизнес такое не пропустит. Но я задался целью собрать максимум, пускай даже с самыми очевидными моментами. Поэтому пункту про аналитику быть!

Перед запуском нужно решить:

1. что считаем первым использованием;
2. что считаем успешным использованием;
3. какую долю клиентов ожидаем увидеть в функции;
4. за какой период смотрим adoption;
5. какие сегменты сравниваем;
6. какие события трекаем;
7. как отличаем случайный клик от реального использования;
8. какие качественные сигналы собираем от клиентов.

Можно еще и не по юзерам смотреть, а в целом по компании, например:

1. сколько аккаунтов включили функцию;
2. сколько дошли до целевого действия;
3. сколько используют повторно;
4. какие роли внутри компании пользуются;
5. влияет ли функция на удержание;
6. помогает ли расширять тариф;
7. снизилось ли количество ручных обращений.

Иначе можно обмануться красивой цифрой в 1000 пользователей, которые открыли раздел. Да, открыли. Посмотрели. Закрыли. И тут же вернулись к наскальной живописи или, чего хуже, в Excel.

9. Есть ли план на случай, если не взлетит

Планировать провалы очень неприятно, но очень необходимо. Поэтому заранее решаем:

1. через сколько дней смотрим первые данные;
2. какие метрики считаем тревожными;
3. что делаем при низком adoption;
4. кого опрашиваем;
5. какие гипотезы проверяем;
6. можно ли быстро улучшить онбординг;
7. нужен ли дополнительный показ клиентам;
8. стоит ли доработать сценарий;
9. когда признаем, что функция не оправдала ожиданий.

Функция после релиза почти всегда требует докрутки. Это нормально.

10. Как сообщаем о запуске

Плохо: Мы обновили функциональность раздела и добавили новые возможности для повышения эффективности процессов.

Хорошо: Теперь администратор может настроить права доступа для всей команды за несколько минут, без ручной выдачи каждому сотруднику.

То есть надо по фактам, канцеляризм уже всех достал. И для разных пользователей нужны разные сообщения:

1. администратору — как включить и настроить;
2. руководителю — какую пользу даст;
3. рядовому пользователю — как начать;
4. продажам — как объяснять;
5. поддержке — как отвечать;
6. текущим клиентам — почему это важно именно им;
7. новым клиентам — где это усиливает продукт.

Получилось сильно объемнее, чем я планировал. Извините, пожалуйста. На днях планирую слить это в чек-лист, чтобы было покороче и возможно нагляднее.

Кстати, вам есть что добавить к этому?