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

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

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

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

Права и лимиты должны жить отдельно от названия плана

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

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

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

1. Клиентский контур → подписка → версия тарифа → права → лимиты → фактический доступ.

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

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

Лимит начинается с события, которое можно пересчитать

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

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

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

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

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

14 дней ничего не говорят без момента первой ценности

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

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

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

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

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

Апгрейд занимает секунды, последствия живут весь расчётный период

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

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

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

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

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

Пять решений, которые нужны до первой оплаты

1. Единица ценности. За что клиент готов платить: место сотрудника, документ, обработанную операцию, объём данных или результат вычисления.
2. Версия тарифа. Какие цены, интервалы, права и лимиты действуют вместе, когда версия вступает в силу и что происходит со старыми подписками.
3. Модель доступа. Где хранится набор прав и какой сервис принимает окончательное решение о доступе.
4. Переходы. Как работают пробный период, апгрейд, понижение, пауза, просрочка, отмена и возврат.
5. Проверка. Какие события попадут в аналитику и аудит, как система сверяет расчёты и что увидит поддержка при расхождении.

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

Где заканчивается настройка и начинается разработка

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

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

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