Пробный доступ к B2B-продукту: как давать демо и не слить продукт

Пробный доступ к B2B-продукту лучше давать персонально и на срок: человек оставляет заявку, администратор решает, кому открыть кабинет, выдаёт одноразовую ссылку и пробу на несколько суток, а каждое действие внутри попадает в журнал. Данные в кабинете демонстрационные, доступ отзывается в любой момент. Так покупатель трогает продукт руками, а компания знает каждого, кто внутри, и может закрыть вход до того, как продукт растащат на скриншоты и идеи.

Чем опасно открытое демо

Демо по кнопке «Попробовать» без проверки удобно для массового сервиса за 500 ₽ в месяц. Для B2B-продукта, который продаётся за серьёзные деньги и долго внедряется, у открытого демо три слабых места.

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

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

Ручная выдача вместо автоматической регистрации

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

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

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

Одноразовая ссылка и срок пробы

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

Сроков два, и их полезно разделять:

• Срок приглашения. Сколько ссылка ждёт активации. В пультах собственника это 72 часа.
• Срок пробы. Сколько работает кабинет после активации. Там 7 суток.

Срок считается по времени сервера, часы на телефоне пользователя на него не влияют. Продление и перевыпуск ссылки делаются из карточки сотрудника, без правки базы руками. Если ссылка ушла не тому человеку, администратор перевыпускает её, и старая перестаёт работать.

Похожий подход годится и для передачи паролей клиентам: я разбирал его в статье про ссылки на один просмотр.

Вход администратора и двухфакторная защита

Самая ценная учётная запись в такой системе принадлежит администратору: он выдаёт доступы и видит все заявки. Его вход я закрываю вторым фактором, кодом из приложения-аутентификатора. Такие коды работают по алгоритму TOTP из RFC 6238, где рекомендованный шаг смены кода 30 секунд. Подробно про варианты второго фактора есть гид по 2FA.

Остальное по входу:

• пароли хранятся только в виде хеша медленным алгоритмом; памятка OWASP на первом месте ставит Argon2id, scrypt допускает как запасной вариант;
• частота попыток входа ограничена, подбор пароля упирается в паузы;
• формы защищены от подделки запросов с чужих сайтов;
• первый администратор создаётся только командой на сервере, через сайт его не завести.

Из практики: ключ 2FA при ручном вводе легко набрать с ошибкой, и коды не подходят. Надёжнее отдавать ссылку otpauth, которая добавляет ключ в приложение без ручного набора.

Демоданные вместо реальных

Соблазн показать продукт «на живой базе» понятен: так убедительнее. Но реальная база клиентов, сотрудников или сделок в демо означает, что посторонний человек видит чужие персональные данные. По ст. 7 закона № 152-ФЗ оператор обязан не раскрывать их третьим лицам без согласия человека, если иное не предусмотрено законом. Пробный пользователь как раз третье лицо. Чем это грозит компании, разобрано в статье что грозит за утечку базы.

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

Ещё одна деталь: кнопка сброса кабинета к исходным данным. Пробный пользователь может всё переломать, и это нормально, он же пробует. Сброс я защищаю подтверждением, например вводом названия организации.

Журнал действий и отзыв доступа

Журнал отвечает на вопросы продажника и безопасника одновременно: кто зашёл, когда, какие разделы открывал, кто выдал и продлил доступ. В журнал пишутся действия, пароли и токены туда не попадают никогда, иначе журнал сам становится утечкой.

Отзыв доступа должен срабатывать сразу. В пультах собственника он действует на следующем же запросе: если у человека открыта вкладка, она теряет доступ при первом клике. Отзыв через «удалим аккаунт в конце месяца» не годится. Та же логика нужна для своих сотрудников, про это статья о доступах уволенного сотрудника.

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

Водяные знаки и ограничение экспорта

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

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

Как я это делаю

Порядок у меня такой.

1. Правила доступа на бумаге. Кто выдаёт пробу, на сколько, какие версии, кто продлевает и отзывает. Это решает заказчик, я только записываю и задаю неудобные вопросы.
2. Демоданные с контрольными суммами. Если в техзадании есть проверочные величины, я пишу тесты, которые их сверяют. Пока строка не сходится, выкладывать нечего.
3. Сквозной тест пути. Заявка, ручная выдача, активация, вход в разрешённую версию, попытка открыть запрещённую, отзыв. Плюс 2FA, подделка запросов и изоляция кабинетов разных организаций.
4. Журнал без секретов. Проверяю, что в логах нет паролей, токенов и полных ссылок-приглашений.
5. Запуск на сервере заказчика с ночными резервными копиями и проверкой восстановления.

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

Сколько стоит пробный кабинет

Отдельной строки «пробный доступ» в прайсе нет: это часть сайта или веб-приложения, считаю по объёму. Ориентиры из моего прайса:

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

Частые вопросы

Не отпугнёт ли ручная выдача клиентов?

Часть людей, которые хотели просто посмотреть, отсеется. Для B2B-продукта это скорее плюс: остаются те, кто готов назвать компанию. Важно отвечать на заявку быстро, поэтому уведомление менеджеру уходит сразу, а первый ответ может дать бот, как в кейсе с пультами.

Сколько дней давать на пробу?

Столько, сколько нужно, чтобы пройти один реальный сценарий: посмотреть отчёт, согласовать план, найти расхождение. В проекте с пультами это 7 суток плюс 72 часа на активацию ссылки. Продление делается из карточки, если клиент попросил.

Можно ли дать пробу на реальных данных клиента?

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

Хватит ли пароля без второго фактора?

Для пробного пользователя на 7 суток пароля с ограничением попыток обычно хватает. Для администратора, который выдаёт доступы, второй фактор обязателен.

Коротко о главном

• Демо B2B-продукта стоит выдавать персонально: заявка, решение администратора, одноразовая ссылка.
• Два срока: жизнь приглашения и длительность пробы. Оба считает сервер.
• Внутри только демоданные, которые сходятся по строкам и не лежат в публичных файлах.
• Журнал без паролей и токенов, отзыв срабатывает на следующем запросе.
• Водяные знаки и запрет выгрузки помогают как подпись и сдерживание, основная защита в контроле входа.

Если хотите показывать свой продукт без открытого демо, напишите мне в Telegram @chimitdorzhi с кодовым словом «ПРОБА». Разберём, кому и на сколько открывать доступ.