Тарифы, лимиты и пробный период в SaaS: что заложить в архитектуру до запуска
Продакт переносит расширенную аналитику из тарифа Pro в Business. В таблице это одна строка. В продукте выясняется, что проверка тарифа живёт в интерфейсе, API, фоновых задачах и кабинете поддержки. Изменение на лендинге занимает час, а выпуск новой версии растягивается на недели.
Так появляется дорогая зависимость: каждое решение о монетизации становится задачей разработки. Команда медленнее проверяет гипотезы, пользователи получают разные права в разных частях сервиса, а поддержка разбирается, почему оплата прошла, но функция всё ещё закрыта.
В Qtim мы проектируем SaaS-платформы и заранее разделяем каталог тарифов, доступ к функциям, учёт потребления и расчёты. В статье разберу, какие решения нужны до первой оплаты, чтобы новый тариф без нового релиза стал нормальным продуктовым сценарием.
Тариф — это версия правил, которую продукт должен помнить
Название тарифа редко отвечает на технический вопрос. «Business» может включать 50 пользователей, расширенную аналитику, SSO и хранение данных в течение года. Через месяц состав поменяется, а часть клиентов останется на старых условиях.
Поэтому системе нужен каталог продуктов и цен с версиями. У каждой версии есть период действия, валюта, расчётный интервал, набор прав и правила лимитов. Подписка клиента ссылается на конкретную версию. Обновление публичного тарифа не должно задним числом менять уже оплаченные условия.
Доступ к функциям лучше хранить отдельно от названия плана. Связка выглядит так:
Клиентский контур → подписка → версия тарифа → права → лимиты → фактический доступ.
Такой подход используют и готовые биллинговые платформы. Например, Stripe связывает продукты с правами и обновляет активные права клиента по событиям подписки. Для собственной системы принцип тот же: модуль аналитики спрашивает, доступен ли ему конкретное право, и не знает, как маркетинг назвал пакет на лендинге.
Есть обратная сторона. Появляется ещё один слой данных, который нужно синхронизировать. Зато правила лежат в одном месте, их можно версионировать, тестировать и менять без поиска десятков условий в коде.
Лимит начинается с события, которое можно пересчитать
Фраза «до 10 000 операций в месяц» выглядит готовым правилом. На деле сначала нужно определить операцию. Повторный запрос считается второй операцией? Что делать с отменённой обработкой? В каком часовом поясе начинается месяц? Когда пользователь увидит обновлённый остаток?
Для тарификации по потреблению нужен отдельный поток событий. Минимальный набор полей:
идентификатор клиентского контура;
тип измеряемого действия;
значение и единица измерения;
время события;
уникальный ключ для защиты от повторной записи;
версия правила, по которому событие будет рассчитано.
Stripe описывает похожий жизненный цикл для тарификации по потреблению: приём событий, агрегация, расчёт и контроль порогов. Актуальная сумма может обновляться асинхронно. Поэтому экран пользователя, биллинговая база и платёжный провайдер нельзя считать одной системой с мгновенно одинаковыми данными.
Отдельное решение касается самого ограничения. Жёсткий лимит блокирует действие. Мягкий разрешает превышение и создаёт доплату. Информационный только предупреждает. Для одной функции могут действовать разные режимы: API останавливается на пороге, хранилище даёт короткий запас, а число сотрудников переводит клиента на следующий пакет.
Рекомендации Microsoft по мультитенантным системам связывают учёт потребления с двумя задачами: понять себестоимость обслуживания каждого клиентского контура и корректно выставить счёт. Облачная инфраструктура часто не даёт готовой разбивки по клиентам. Значит, единицу потребления и способ её записи нужно выбрать в архитектуре продукта.
14 дней ничего не говорят без момента первой ценности
В исследовании ChartMogul и ProductLed среди 200 B2B-продуктов 57% использовали бесплатный пробный период, а у 62% из них он длился 14 дней. Медианная конверсия из бесплатного доступа в оплату составила 8%. Эти цифры описывают выборку и не задают норматив для любого SaaS.
Длительность стоит считать от пути пользователя до первой ценности. Сервис аналитики может показать результат после подключения источника и импорта данных. Корпоративная платформа ждёт приглашения коллег, настройки ролей и согласования безопасности. Одинаковые 14 дней дают этим продуктам разный шанс на активацию.
Пробный период требует собственной модели состояний. Система должна знать:
когда пробный доступ начался и закончится;
какие функции и лимиты действуют в этот период;
нужна ли платёжная карта;
что произойдёт после окончания: оплата, пауза, ограниченный режим или отмена;
можно ли продлить доступ и кто имеет на это право.
До запуска полезно зафиксировать события аналитики: регистрация, начало пробного периода, ключевое действие, достижение первой ценности, ввод платёжных данных, оплата и отмена. Тогда команда увидит, где заканчивается интерес и начинается трение. Одна конверсия в оплату этого не объяснит.
Апгрейд занимает секунды, последствия живут весь расчётный период
Кнопка «Перейти на Business» запускает цепочку решений. Права можно выдать сразу, а доплату рассчитать пропорционально оставшимся дням. Понижение тарифа чаще вступает в силу со следующего периода, чтобы не отбирать уже оплаченный доступ. Просроченный платёж может включить льготный срок, затем ограниченный режим и только потом блокировку.
Эти переходы лучше описать как явные состояния и события. Подписка активирована. Тариф изменён. Счёт оплачен. Платёж отклонён. Подписка поставлена на паузу. Период завершён. Обработчики получают события повторно, поэтому операции выдачи прав и начисления должны быть идемпотентными.
Особенно опасно смешивать платёжный статус и доступ. Платёжный провайдер отвечает за деньги, а продукт решает, что пользователь может делать прямо сейчас. Между ними всегда возможна задержка, повторная доставка вебхука или временная ошибка. Нужны журнал событий, повторные попытки и регулярная сверка подписок, счетов и активных прав.
Так работает ScanWow — платформа 3D-моделей, которую мы разработали. Тариф задаёт месячный лимит скачиваний и набор прав, а PayPal передаёт статусы платежей через вебхуки. Если пользователь отключает автопродление, доступ сохраняется до конца оплаченного периода, после чего аккаунт автоматически возвращается на Free.
Поддержке тоже нужен интерфейс для этой модели. Сотрудник должен видеть версию тарифа, использованный лимит, историю переходов и причину текущего ограничения. Возможность выдать временное право или кредит требует срока действия, автора изменения и записи в журнале. Иначе помощь одному клиенту превращается в бессрочное исключение.
Пять решений, которые нужны до первой оплаты
Единица ценности. За что клиент готов платить: место сотрудника, документ, обработанную операцию, объём данных или результат вычисления.
Версия тарифа. Какие цены, интервалы, права и лимиты действуют вместе, когда версия вступает в силу и что происходит со старыми подписками.
Модель доступа. Где хранится набор прав и какой сервис принимает окончательное решение о доступе.
Переходы. Как работают пробный период, апгрейд, понижение, пауза, просрочка, отмена и возврат.
Проверка. Какие события попадут в аналитику и аудит, как система сверяет расчёты и что увидит поддержка при расхождении.
Этот список не требует заранее угадать идеальную цену. Он создаёт точки, в которых цену и упаковку можно менять без переписывания продукта. На старте достаточно одной рабочей модели, но её границы должны быть явными.
Новый тариф без нового релиза
Продакт снова переносит аналитику из Pro в Business. Теперь он создаёт новую версию тарифа и назначает дату действия. Система обновляет права по событию, сохраняет старые условия для действующих клиентов и показывает поддержке историю изменения. Команда разработки подключается только при изменении самого продуктового механизма.
Правило простое: сначала определите единицу ценности и состояния подписки, затем проектируйте каталог тарифов, права и биллинг вокруг них.
Мы можем разобрать вашу модель монетизации и заложить тарифы, лимиты, пробный период и переходы в архитектуру SaaS-платформы. Обсудить SaaS-проект с нами.
