Владелец будущего сервиса говорит: «Пусть клиент платит каждый месяц и пользуется программой». Эта формулировка скрывает несколько процессов. Нужно определить, когда начинается период, что происходит при задержке оплаты, как меняется тариф и что именно означает отмена.
SaaS — программный продукт, которым клиент пользуется как сервисом. Подписка задаёт коммерческие условия доступа, но не сводится к банковской операции. Платёж может быть успешным, подписка — отменённой на будущий период, а текущий доступ — ещё действующим. Если объединить всё в один признак «оплачено», система быстро начнёт ошибаться.
Разделите три объекта
Платёж описывает конкретную попытку перечисления средств и её результат. Неизвестный результат, отказ и подтверждённое поступление нельзя трактовать одинаково.
Подписка описывает выбранный тариф, период и намерение продолжать обслуживание. Она может существовать до первой оплаты или сохраняться после прекращения доступа для истории.
Право доступа определяет, какие возможности разрешены организации или пользователю сейчас. Оно может зависеть от тарифа, срока, отдельного согласованного исключения и других правил продукта.
Такое разделение помогает отвечать на вопросы поддержки. «Почему функция закрыта?» и «Почему не прошёл платёж?» — разные вопросы, даже если возникли одновременно.
Начните с правил продукта, а не с платёжного модуля
До выбора технического решения опишите единицу продажи. Клиент покупает доступ для организации, места сотрудников, число операций или сочетание нескольких ограничений?
Для первой версии полезна простая и объяснимая модель. Например, один тариф для компании с определённым набором функций. Но простота должна соответствовать реальной покупке: если клиенты платят за фактический объём, замена этой модели фиксированным доступом требует отдельной проверки.
Укажите, что считается периодом. Календарный месяц и тридцать суток — разные условия. Если начало приходится на конец месяца, должно быть заранее определено правило следующей даты. Пользовательские даты и серверные отметки также должны однозначно соответствовать друг другу.
Условный пример: сервис для небольших агентств
Рассмотрим вымышленный сервис подготовки клиентских отчётов. Компания покупает доступ для пяти сотрудников на тридцать суток. Для примера считаем, что период начинается после подтверждения первой оплаты; конкретные цены здесь не задаются.
Руководитель создаёт организацию и выбирает тариф. Пока исход платежа неизвестен, система показывает ожидание. После подтверждения доступ открывается на согласованный период, а повторное сообщение о том же платеже не добавляет ещё тридцать суток.
За несколько дней до окончания клиент видит дату завершения и способ продления. Если он отключил будущее продление, текущий оплаченный период продолжается. По его окончании применяется заранее объяснённое ограничение доступа.
Этот пример показывает решения для первой версии, а не готовые правила для любого сервиса.
Что решить о пробном доступе
Пробный период нужен не каждому продукту. Если без настройки и сопровождения пользователь не получает ценности, бесплатная регистрация может создавать поток вопросов вместо проверки полезности.
Если проба предусмотрена, зафиксируйте:
- кто получает её и к какой организации она относится;
- какие возможности доступны;
- с какого события начинается срок;
- что происходит с созданными данными после завершения;
- как осуществляется переход на оплаченный доступ;
- как обрабатывается повторная регистрация той же компании.
Не нужно автоматически удалять рабочие материалы в момент окончания пробы. Сроки хранения, доступ к результатам и порядок завершения обслуживания определяются отдельно. В интерфейсе важно объяснить их до того, как пользователь вложит время в работу.
Неуспешное продление: сначала установите факт
Отсутствие подтверждения не всегда означает отказ. Сообщение могло задержаться, обработка — продолжаться, соединение — оборваться. Система должна иметь способ уточнить состояние операции и не запускать новые списания бесконтрольно.
Для подтверждённого отказа нужен продуктовый сценарий. Возможны уведомление, ограниченный период для исправления способа оплаты или прекращение отдельных функций. Конкретный выбор зависит от услуги и договорённостей; универсальной безопасной задержки нет.
В условном сервисе можно разрешить просмотр готовых отчётов, но временно закрыть создание новых. Такое разделение сначала согласуют как правило продукта, затем проверяют технически. Нельзя обещать его клиентам, пока оно не реализовано и не испытано.
Смена тарифа требует отдельной логики
Клиент увеличил команду с пяти до восьми человек. Что произойдёт с текущим периодом? Новые места открываются сразу или со следующего периода? Нужен ли дополнительный расчёт? Как обрабатывается уменьшение числа мест?
Для первой версии допустимо оставить смену тарифа через сотрудника поддержки, если процедура понятна и её объём посилен. Но сотрудник должен фиксировать решение в системе, а не менять несколько несвязанных признаков вручную.
Уменьшение лимита особенно важно проверить. Если в организации уже восемь активных сотрудников, переход на пять мест не должен случайно отключать владельца или выбирать пользователей без объяснения. Нужен согласованный порядок освобождения мест либо отложенного изменения.
Когда достаточно готового решения
Готовый сервис управления подписками может закрыть стандартные периоды, тарифы, уведомления и связь с платёжным провайдером. Проверьте его на конкретных исключениях и условиях доступности для вашего бизнеса.
При этом он не обязательно управляет всеми правами внутри вашего приложения. Нужно определить, где хранится источник истины о тарифе и как приложение узнаёт об изменении. Потеря связи между компонентами не должна создавать произвольные права.
Заказная логика становится нужна, если тариф зависит от сложного потребления, договорных условий организации или особых сценариев обслуживания. Разрабатывать собственный платёжный процесс целиком только ради индивидуального доступа обычно не требуется: границы компонентов выбирают отдельно.
Проверки перед первой продажей
Подготовьте сценарии обычного платежа, задержанного подтверждения, повторного уведомления, отказа, отмены будущего продления и смены тарифа. Для каждого укажите ожидаемую дату доступа и доступные функции.
Дополнительно проверьте ручное исключение поддержки. Оно должно иметь автора, причину и срок; бессрочная временная уступка создаёт расхождения между фактическим обслуживанием и условиями подписки.
Журнал изменений помогает объяснить, почему клиент получил или потерял возможность. Но он не заменяет корректных правил: историю ошибочного отключения всё равно придётся разбирать.
Сверяйте коммерческое состояние и доступ
Даже при корректной обработке отдельных событий полезна периодическая сверка. Она ищет расхождения: подтверждённый оплаченный период без доступа, открытые функции после истечения разрешения или два разных состояния одной операции.
Для каждого расхождения нужен ответственный и понятный способ исправления. Автоматическое исправление допустимо только там, где правило однозначно; спорный случай лучше отправить на разбор с сохранением истории.
Подготовьте для поддержки короткую карточку: организация, тариф, действующий период, последняя операция, причина текущего ограничения и доступное следующее действие. Сотрудник сможет объяснить ситуацию без прямого редактирования технических таблиц.
Проверьте также задержку между подтверждением оплаты и обновлением интерфейса. Пользователь должен видеть понятное ожидание, а не пытаться платить повторно из-за отсутствия мгновенного изменения экрана. Это отдельный сценарий приёмки, который стоит воспроизвести заранее.
Чеклист владельца SaaS
- Определены единица продажи, период и начало доступа.
- Платёж, подписка и разрешения имеют отдельные состояния.
- Повторное событие не создаёт повторный оплаченный период.
- Неизвестный исход операции отличим от отказа.
- Отмена будущего продления не смешана с немедленным прекращением.
- Согласованы поведение данных и функций после завершения срока.
- Смена тарифа проверена на уже занятом лимите.
- Поддержка понимает, какие изменения может вносить.
С ExtentLab можно обсудить эти правила на примере одного тарифа и нескольких исключений. Такой разговор помогает определить состав первой версии SaaS и оценивать конкретные сценарии, а не абстрактную «подписку под ключ».