«Тут почти стандартно, пара нюансов»: как эта фраза убивает экономику подписки

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

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

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

Задача в статусе «готово», а деньги всё ещё тратит

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

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

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

Три числа, по которым видно, что маржа уже под давлением

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

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

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

Правило: тариф, роль и отчёт меняются без релиза

Главный тест простой: запрос повторяется у нескольких клиентов одного сегмента или завязан на внутренний процесс одной компании?

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

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

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

Один договор тормозит всех: цена непродуманной архитектуры

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

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

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

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

Пока тарифы зашиты в код, каждая упаковка — это релиз

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

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

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

В Qtim при разработке SaaS-платформ мы раскладываем продукт на такие слои: работа нескольких компаний в одной системе, подписки и оплата, роли и права доступа, самостоятельный запуск клиента, интеграции, админ-панель, продуктовая аналитика и инфраструктура.

Поддержка работает вслепую — и каждый тикет превращается в расследование

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

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

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

Иногда правильный ответ клиенту — «нет»

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

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

Вместо размытого «посмотрим» лучше предложить понятный вариант: вынести запрос в отдельный проект с ценой поддержки, поставить в роадмап, если сценарий повторяется у сегмента, или оформить платный кастом с границами, SLA и сроком пересмотра. Так отказ перестаёт выглядеть упрямством и становится нормальным разговором о том, что продукт сможет поддерживать через год.

Начните с карты исключений — на ней сразу видно, где течёт маржа

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

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

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

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