Я считаю SaaS готовым к новому сегменту, когда правила не переписывают для каждого клиента

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

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

Новый сегмент не обязан работать как старый

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

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

Я начинаю с вопроса не «каких функций им не хватает?», а «какое решение эта компания должна принять иначе?». Он сразу отсекает косметические пожелания. Новый логотип, другой порядок колонок или свой шаблон письма могут быть настройкой. Другое бизнес-правило — уже повод понять, является ли оно общим для сегмента, управляемым параметром или честной индивидуальной доработкой.

Четыре места, где продукт обычно трещит

Первое место — словарь. Один и тот же термин часто скрывает разные вещи. «Заказ» может быть заявкой клиента, внутренним запросом на закупку или этапом производства. Если продукт заставляет всех пользоваться одним словом, но не объясняет смысл, отчёты быстро начинают спорить сами с собой. Перед расширением полезно выписать десять ключевых слов и спросить у новой команды, что каждое из них запускает в реальном рабочем дне.

Второе — роли. Не название должности, а право принять решение. У нового сегмента может быть такой же «менеджер», но он не может менять цену, закрывать обращение или видеть договор. Когда роли придуманы вокруг привычной оргструктуры первого клиента, вторая компания получает либо лишние доступы, либо бесконечные просьбы «сделайте за меня». Принцип работы с доступами вокруг операций здесь особенно полезен: сначала назвать действие и его риск, потом уже выдавать права.

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

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

Проверка на «контрастного клиента»

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

Важно не превращать встречу в сбор пожеланий. Полезнее сортировать наблюдения в три корзины.

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

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

Цена непонятного варианта

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

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

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

Как не обидеть клиента честным «не сейчас»

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

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

Не путать масштабирование с копированием

Бывает соблазн сделать отдельную версию для нового сегмента. Иногда это честное решение: например, если меняются регуляторные требования или сама экономика работы. Но чаще отдельная ветка появляется слишком рано и быстро превращается в две системы, которые нельзя обновлять спокойно.

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

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

Что я проверяю до следующего сегмента

Мне достаточно короткого списка. Можно ли объяснить ключевые статусы без слов «у этого клиента особый случай»? Понятно ли, кто меняет каждое важное правило? Есть ли у настройки название, владелец и безопасный путь назад? Способен ли новый пользователь завершить один рабочий сценарий без чата с внедренцем? И наконец: сможем ли мы поддержать это изменение после следующего релиза, не вспоминая вручную, где оно спрятано?

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