Как устроен SaaS-сервис: клиенты-организации, тарифы и подписка — что продумать до разработки

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

Эта статья — об устройстве SaaS. Как выбрать сценарий для первой версии и не построить лишнего, мы разбирали отдельно в статье «MVP или полная версия». Здесь — то, что отличает сервис по подписке от любого другого веб-приложения.

Что такое SaaS простыми словами?

SaaS (software as a service, «программа как услуга») — модель, при которой клиент не покупает и не устанавливает программу, а платит за доступ к ней. Сервис работает на сервере владельца, клиент заходит через браузер, данные хранятся там же. Обновления получают все клиенты одновременно.

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

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

Что	Система для одной компании	SaaS-сервис
Кто регистрируется	Сотрудников заводит администратор	Организация регистрируется сама и приглашает своих людей
Данные	Одна общая база одной компании	Данные каждой организации отделены от остальных
Роли	Роли внутри одной структуры	Два уровня: роли владельца сервиса и роли внутри каждой организации
Деньги	Оплата разработки и сервера	Тарифы, лимиты, подписка, счета и чеки клиентам
Обновления	Выкладываются, когда удобно одной компании	Одно обновление сразу у всех клиентов — выкладывать нужно без простоя
Поддержка	Свой ИТ-отдел или подрядчик	Служба поддержки клиентов и админка владельца сервиса

Чем SaaS отличается от системы для одной компании?

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

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

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

Способ	Как устроено	Плюсы	Минусы
Общая база, метка организации	Все клиенты в одних таблицах, у каждой записи поле «организация»	Дешевле в разработке и обслуживании, просто считать общую аналитику	Одна забытая проверка в запросе — и клиент видит чужие данные
Отдельная схема на клиента	Одна база, но у каждой организации свой набор таблиц	Изоляция строже, проще выгрузить данные одного клиента	Сложнее обновлять структуру: миграции идут по всем схемам
Отдельная база на клиента	У каждой организации своя база данных	Сильная изоляция, отдельное резервное копирование и перенос	Больше ресурсов сервера и автоматизации на каждого нового клиента

Как разделить данные клиентов?

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

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

Отдельная база на клиента оправдана, когда клиенты крупные, данные чувствительные или клиенты прямо требуют изоляции и отдельных копий. Так устроен «СтройОко» — SaaS строительного контроля: архитектура мультитенантная, у каждой компании своя изолированная база данных. Цена такого решения — автоматизация: создание базы при регистрации, миграции и резервные копии должны идти по всем базам сами.

Что проверить у любого способа:

• Файлы. Документы и фото клиентов тоже должны быть разделены: ссылка на файл одной организации не должна открываться у другой.
• Поиск и отчёты. Самое частое место утечек — общий поиск и выгрузки, где фильтр по организации забыли.
• Удаление клиента. Что происходит с данными, когда организация уходит: срок хранения, выгрузка по запросу, окончательное удаление.
• Персональные данные. Если клиенты загружают в сервис данные своих сотрудников или покупателей, вы обрабатываете их по поручению клиента. Такое поручение оформляется договором с перечнем действий и обязанностью соблюдать конфиденциальность и меры защиты (ч. 3 ст. 6 и ст. 19 152-ФЗ). Пункт о поручении обычно включают в оферту сервиса.

Тарифы, лимиты и подписка

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

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

Что заложить в модель подписки:

• Единица тарификации. За что платит клиент: за пользователя, за объект, за объём, фиксированно за организацию. От этого зависит, что сервис считает и показывает в счёте.
• Период и смена тарифа. Месяц или год, что происходит при переходе на тариф выше посреди периода: доплата за остаток дней или новый тариф со следующего периода.
• Превышение лимита. Мягкое (предупреждение и предложение сменить тариф) или жёсткое (кнопка «создать» недоступна). Для B2B мягкий вариант обычно спокойнее: клиент не застревает посреди рабочего дня.
• Неоплата. Сколько дней отсрочки, когда кабинет переходит в режим «только чтение», когда блокируется, сколько хранятся данные после блокировки. Данные клиента не удаляют в день просрочки.
• Пробный период. Срок, ограничения на время пробы, нужна ли карта при регистрации и что происходит в последний день: напоминание, переход на бесплатный тариф или блокировка.

Теперь об оплате. Компании-клиенты чаще всего платят по счёту: сервис выставляет счёт на тариф, бухгалтерия оплачивает, после поступления доступ продлевается. Для малого бизнеса и частных клиентов удобнее автоплатёж с карты. У платёжных сервисов это отдельная функция: например, в ЮKassa способ оплаты сохраняется только после согласия пользователя, ему нужно заранее объяснить периодичность списаний и способ отказа, а для боевого магазина автоплатежи включают через менеджера (документация ЮKassa). Отключение автоплатежа делается на стороне вашего сервиса, поэтому кнопка «Отключить автопродление» в кабинете — обязательный элемент, а не опция. На каждое списание нужен чек — как устроена онлайн-касса, мы разбирали в статье о приёме оплаты и 54-ФЗ.

Что войдёт в первую версию SaaS?

В первую версию входит один ключевой сценарий, ради которого клиент платит, и минимальная «обвязка» SaaS: регистрация организации, приглашение сотрудников, роли, разделение данных, тарифы с лимитами и способ оплаты. Без обвязки получится демо, а не сервис; без сценария — биллинг, которым не за что платить.

Чек-лист первой версии:

1. Регистрация организации и вход. Почта и пароль или вход по телефону; восстановление доступа. Если думаете о входе по номеру, посчитайте стоимость сообщений заранее — о ней статья про вход по SMS или звонку.
2. Приглашение сотрудников и роли. Владелец аккаунта, администратор, сотрудник. Больше ролей добавите, когда о них попросят клиенты.
3. Ключевой сценарий. То, за что клиент платит: учёт заявок, запись, отчёт, документ. Один сценарий, доведённый до конца.
4. Онбординг. Что видит новый клиент в первые десять минут: пример данных или пошаговая подсказка до первого полезного результата. Пустой кабинет без подсказки — частая причина, по которой пробный период заканчивается ничем.
5. Тарифы и подписка. Тарифы как данные, лимиты, пробный период, режим при неоплате, счёт или автоплатёж.
6. Админка владельца сервиса. Список организаций, их тариф и статус оплаты, ручное продление, вход в кабинет клиента для поддержки.
7. Уведомления. Письма о регистрации, приглашении, окончании пробного периода, неудачном списании.
8. События для метрик. Сервис записывает регистрацию, первую оплату, смену тарифа, отказ. Без этого через три месяца нечем ответить на вопрос «работает ли продукт».

Метрики, которые стоит считать с первого месяца: MRR — регулярная выручка за месяц по всем действующим подпискам (условно 40 клиентов по 3 000 рублей — 120 000 рублей MRR), отток — доля клиентов, которые не продлили подписку за месяц, конверсия пробного периода в оплату и число организаций, которые реально работали в сервисе на этой неделе. Отток важнее числа регистраций: если каждый месяц уходит заметная доля клиентов, рост регистраций его не перекроет.

Такой состав совпадает с базой тарифа «Веб-приложение / SaaS» студии Roboweb: от 160 000 ₽ и от 10 дней — личные кабинеты и роли, база данных и API, дашборды и таблицы, регистрация и вход, приём оплаты (ЮKassa/CloudPayments или аналог) и учёт транзакций, 1–2 внешние интеграции, деплой на сервер. Юридические документы (оферта, политика) и подключение эквайринга от вашего юрлица в цену не входят. Сложная логика биллинга — пересчёт при смене тарифа посреди периода, оплата за фактическое потребление — увеличивает объём и считается после брифа. Полный состав тарифа и что за доплату — на странице цен.

Работа идёт по типовому договору: 50 % предоплаты, 50 % по акту, на приёмку — 5 рабочих дней, до 2 раундов правок на прототипе и до 2 на сборке, 14 дней бесплатной поддержки после запуска и гарантия 30 календарных дней с даты акта. Дальше сервис развивается по абонентке — от 7 900 ₽ в месяц — или разово по задачам.

Из-за каких ошибок SaaS переписывают?

Чаще всего — из-за решений, принятых «на потом»: систему сначала делают для одной компании, а потом пытаются продавать другим; тарифы прописывают в коде; проверку доступа к данным разносят по экранам. Каждая из этих ошибок дёшево исправляется на бумаге и дорого — в работающем продукте с клиентами.

• Нет понятия «организация». Пользователи есть, компаний нет. Чтобы продать сервис второму клиенту, приходится добавлять организацию во все таблицы и все запросы. Когда продукт выводят в SaaS, нередко проще переписать его, чем латать: так, «СтройОко» мы переписали целиком — новый фронтенд и бэкенд — и вывели в SaaS с регистрацией компаний.
• Проверка доступа в интерфейсе, а не на сервере. Кнопку спрятали, а запрос к данным другой организации сервер выполняет. Это не ошибка дизайна, это утечка.
• Тарифы в коде. Каждая скидка, акция и индивидуальные условия — задача разработчику и новая выкладка.
• Нет режима неоплаты. Доступ либо есть, либо данные исчезли. Клиент, который просто забыл оплатить счёт, уходит навсегда.
• Нет админки владельца. Чтобы продлить клиенту доступ или посмотреть его тариф, приходится просить разработчика поправить базу вручную.
• Обновления с простоем. У системы одной компании можно выкладываться ночью. У SaaS ночь одного клиента — рабочий день другого, а каждое обновление касается всех сразу.

Когда SaaS вам не нужен?

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

Ещё несколько случаев, когда стоит остановиться:

• Нет клиента, готового платить. Если вы не поговорили хотя бы с несколькими компаниями, которые готовы платить за ваш сценарий, начните с прототипа или ручной услуги, а не с биллинга.
• Клиентов будет пять, и каждый хочет своё. Это заказная разработка под каждого, а не SaaS. Общий продукт работает, когда клиенты готовы принять одинаковые правила.
• Готовый сервис закрывает задачу. Если на рынке есть сервис, который делает то же самое, а ваше отличие — в настройках, а не в продукте, дешевле подписаться и настроить.
• Нужен кабинет для своих клиентов. Если клиенты заходят посмотреть заказы и документы у вас, а не работают в своём пространстве, — это личный кабинет, и о нём отдельная статья «Личный кабинет клиента: что должно быть внутри».

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

Короткие ответы на частые вопросы

Что такое SaaS-сервис простыми словами?

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

Можно ли сделать SaaS из системы, написанной для одной компании?

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

Нужно ли сразу делать оплату картой в SaaS?

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

Сколько стоит разработка SaaS-сервиса?

В студии Roboweb тариф «Веб-приложение / SaaS» — от 160 000 ₽ и от 10 дней: кабинеты и роли, база данных и API, приём оплаты и 1–2 интеграции. Итоговую цену первой версии считаем после брифа и фиксируем в договоре.

Какие метрики SaaS считать с первого месяца?

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

Услуги и кейсы по теме: веб-приложения и SaaS · кейс СтройОко · цены и сроки