Панель настроек, которая продаёт: ~20% больше self-serve апгрейдов от locked-состояний

Во FlippingBook, платформе интерактивных флипбуков, защита контента означала одно: пароль. Enterprise-клиентам нужно было больше. Сейлзы теряли около 6 лидов в месяц, саппорт получал 50+ тикетов в месяц с вопросом, как ограничить доступ, а enterprise-клиенты были готовы платить до 3x от базовой цены за продвинутую безопасность. В тарифах не было контроля доступа, который можно было бы им продать.

Я переделал настройки приватности в пять режимов: Public, Shareable link, Password, Protected Embed и Private. Этот пост про одну часть проекта: как показать режимы, которых у клиента пока нет.

Показать закрытым

Обычный ход: спрятать продвинутые настройки от младших тарифов. Я показал все режимы, а у тех, которых нет в тарифе, поставил locked-состояние.

Клиент узнаёт, что продукт умеет что-то, в тот момент, когда пытается это сделать. Если опция скрыта, такого момента не случается.

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

Что происходит по клику

Клик по закрытой опции открывает контекстный тултип с тремя вещами: короткое value proposition для бизнеса, ссылка в help center и кнопка Upgrade. Self-serve воронка продаж живёт внутри самой фичи, поэтому клиенту не нужно выходить из настроек или общаться с сейлзами.

Locked-состояние я оформил как компонент. Глобальные системные locked-стейты я добавил в наш UI kit, и у нас появился единый визуальный язык для пейволлов, а те же стейты использовались в других частях продукта.

Цифры

Аналитика показала, что locked-стейты и контекстные тултипы подняли self-serve апгрейды, начатые внутри портала, примерно на 20%, измеряли по кликам на CTA. Self-serve значит, что апгрейд прошёл мимо отдела продаж.

Во второй фазе эффект усилился. Когда мы запустили Restricted Access (проверка по email, домену и SSO), эти продвинутые настройки стали главным триггером апгрейда для B2B-аккаунтов на начальных тарифах, и они переходили на Team или Enterprise прямо из панели Privacy.

По всему проекту тикеты про приватность снизились с примерно 50 до примерно 10 в месяц, а больше 70% enterprise-аккаунтов настроили два и больше режимов в первые три месяца.

Чеклист для locked-состояния

Вот что я бы проверил на любой настройке за пейволлом.

1. Видимость. Опция стоит на экране на своём месте, в том же списке, что и открытые.
2. Заметная закрытость. Состояние читается как недоступное до клика, а hover и press всё равно откликаются, как у любого контрола.
3. Одно предложение о пользе. Тултип говорит, что настройка даёт клиенту, бизнес-языком.
4. Одно действие. Одна кнопка Upgrade, рядом ссылка на help center как второй путь.
5. Один компонент. Locked-состояние живёт в дизайн-системе, поэтому каждой команде, которой нужен пейволл, не приходится рисовать свой.
6. Измерение на клике. Отслеживать CTA у каждой закрытой опции и по возможности связывать клики с завершёнными апгрейдами, потому что клик показывает интерес, а выручка приходит позже.
7. Честность. Закрывать только то, что в старшем тарифе действительно есть. Ложный замок стоит больше доверия, чем приносит.

Четыре способа всё испортить: спрятать фичу, чтобы клиенты не узнали о ней, поставить модальную стену по клику, которая обрывает человека посреди задачи, сделать кнопку Upgrade без строки о том, что она открывает, и свой пейволл в каждой части продукта.

Что я бы всё равно поменял

В ретроспективе кейса я отмечаю структурный компромисс: защита паролем это и отдельный режим, и модификатор поверх других режимов. Мы оставили так, чтобы переиспользовать легаси-логику паролей, это сэкономило недели разработки. Более чистая модель: пользователь сначала выбирает, у кого есть доступ, а потом включает требование пароля. Для этой темы это тоже важно, потому что каждый лишний модификатор это ещё одна вещь, которую нужно закрыть и объяснить.