Биллинг SaaS по сотрудникам: что считать оплачиваемым местом

Биллинг SaaS по сотрудникам начинается с определения оплачиваемого места: купленная лицензия, активированный участник или другая явно согласованная единица. Затем нужно установить момент изменения количества и правило расчёта периода. Текущий список пользователей не заменяет историю начислений, а отключение сотрудника не должно оставлять неопределённость о доступе и оплате.

Что именно продаёт продукт

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

В документации Stripe по количеству подписки per-seat licensing описано через количество единиц и цену единицы. Это механизм расчёта, а определение того, кто занимает место в вашем сервисе, остаётся задачей продукта. Не переносите технический параметр quantity прямо из числа строк таблицы пользователей без выбранного правила.

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

Состояние лицензии и доступ сотрудника

Таблица показывает вопросы к собственной модели. Ответы в ней нужно уточнить по принятым условиям продукта; это не универсальный порядок начисления всем SaaS и не описание обязательного возврата средств.

Перерасчёт в середине периода — отдельное правило

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

В руководстве Stripe о prorations изменение количества рассматривается среди событий перерасчёта. Это поведение конкретной системы и её настроек, а не универсальная обязанность любого поставщика. Для собственной реализации нужны понятные условия и проверяемая формула, согласованные до начисления.

Учебный расчёт с изменением количества

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

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

Счёт должен объясняться журналом событий

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

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

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

Проверки до запуска оплаты

1. Определите оплачиваемую единицу и события начала и окончания её учёта. Отдельно перечислите роли и состояния, которые требуют исключений.
2. Зафиксируйте период, момент применения изменения и формулу. Укажите порядок округления и обработки уменьшения без универсальных обещаний возврата.
3. Подготовьте учебный журнал добавлений, отключений и замен. Посчитайте ожидаемый результат независимо от программы.
4. Проверьте счёт по этому журналу и согласованному состоянию подписки. Текущий список участников должен объясняться отдельно от прошлых начислений.
5. Испытайте повтор уведомления, одновременное изменение количества и запоздалое подтверждение оплаты. Не отправляйте реальные платежи ради демонстрации.
6. Примите экран владельца и диагностику поддержки: количество, занятость, применение изменения и основание каждой коррекции должны быть понятны.

Что показывать клиенту перед изменением

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

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