Новый тариф без нового релиза: что заложить в SaaS до запуска

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

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

Привет, я Антон Фокин, CEO Qtim. Мы проектируем SaaS-платформы и заранее разделяем каталог тарифов, доступ к функциям, учёт потребления и расчёты. В статье разберу, какие решения нужны до первой оплаты, чтобы новый тариф без нового релиза стал нормальным продуктовым сценарием.

Название тарифа редко отвечает на технический вопрос. «Business» может включать 50 пользователей, расширенную аналитику, SSO и хранение данных в течение года. Через месяц состав поменяется, а часть клиентов останется на старых условиях.

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

Доступ к функциям лучше хранить отдельно от названия плана. Связка выглядит так:

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

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

Фраза «до 10 000 операций в месяц» выглядит готовым правилом, хотя сначала нужно определить саму операцию. Считается ли повторный запрос второй операцией, как учитывать отменённую обработку, в каком часовом поясе начинается месяц и когда пользователь увидит обновлённый остаток?

Для тарификации по потреблению нужен отдельный поток событий. Минимальный набор полей:

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

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

В исследовании ChartMogul и ProductLed среди 200 B2B-продуктов 57% использовали бесплатный пробный период, а у 62% из них он длился 14 дней. Медианная конверсия из бесплатного доступа в оплату составила 8%. Эти цифры описывают выборку и не задают норматив для любого SaaS.

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

Пробный период требует собственной модели состояний. Система должна знать:

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

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

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

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

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

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

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

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

Поэтому до разработки стоит зафиксировать единицу ценности и состояния подписки, а затем строить вокруг них каталог, права и биллинг.

Чтобы проверить эту границу до запуска, разберём вашу модель монетизации и заложим тарифы, лимиты, пробный период и переходы в архитектуру SaaS-платформы.