Архитектура продукта для self-serve и корпоративных клиентов, которая остаётся гибкой

Почему смешанные типы клиентов нагружают продукт

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

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

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

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

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

Простой пример показывает, как быстро это происходит. Стартап добавляет SSO для одного крупного клиента. Затем тот же клиент просит правила ролей, журналы аудита и управление постепенным развёртыванием. По отдельности эти запросы не странные, но вместе они могут искривить продукт, если исходная структура была рассчитана только на быстрый self-serve.

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

Выберите общие правила до того, как добавлять исключения

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

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

Держите одну основную модель аккаунтов и рабочих пространств. Маленький self-serve клиент и крупный корпоративный покупатель могут жить в одной структуре, даже если кому‑то нужны дополнительные согласования или условия контракта. Это избавит вас от разработки отдельного кода для "обычных" и "особых" пользователей — такое разделение почти всегда осложняет систему.

Простое правило помогает: структура продукта — в приложении. Особые условия — в настройках или админ‑конфиге. Заметки от продаж не должны управлять ежедневными операциями, а обещания в контракте не должны переписывать логику планов.

Последняя часть важнее, чем многие думают. Лимиты планов принадлежат продукту: места (seats), проекты, хранилище, использование API и доступ к функциям. Обещания в контракте относятся к соглашению: кастомная выставка счетов, сроки отклика, проверка безопасности или помощь при миграции. Если команды смешивают эти две вещи, ломается биллинг, поддержка путается, и никто не понимает — нужен код или достаточно настройки.

Если клиент получает что‑то необычное, храните это там, где продукт и команда могут это прочитать: настройка, флаг или запись политики подойдут. Записка в CRM, переписка в Slack или чья‑то память — нет.

Нарисуйте четыре области, где проявляется сложность

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

Шаблон обычно проявляется в четырёх областях.

Регистрация и первое использование — первые. Запишите каждый путь от создания аккаунта до полезной первой сессии. Включите self-serve регистрацию, триалы, приглашения по инвайту, онбординг с участием продаж, админ‑одобрение, настройку SSO и любую ручную работу, которую команда ещё делает.

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

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

Правила доступа — четвёртая область. Пометьте, какие права меняются в зависимости от размера команды, роли или контракта. Маленьким командам нужны простые роли admin и member. Крупные аккаунты часто просят права по отделам, правила согласования, журналы аудита или ограничения по рабочим пространствам.

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

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

Настройте всё шаг за шагом

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

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

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

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

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

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

Хорошая архитектура часто выглядит скучно. Это обычно хороший знак. Простые системы легче поддерживать, проще объяснить и гораздо труднее сломать одной категорией клиентов.

Стройте онбординг слоями

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

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

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

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

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

Держите биллинг гибким, но аккуратным

Биллинг обычно ломается раньше продукта. Команда начинает с простой оплаты картой для self-serve, затем добавляет счёта, годовые контракты, кредиты, кастомные скидки и плату за использование для крупных клиентов. Если каждая сделка получает собственную логику, финансы тратят часы на исправление крайних случаев, а поддержка не может уверенно объяснить счёт.

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

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

Условия контрактов нужно обрабатывать так же. Поддержка и финансы должны видеть даты продления, условия оплаты, детали purchase order, правила скидок и согласованные лимиты без прочёсывания почты. Если клиент говорит "у нас Net 30 и лимит по использованию", команда должна подтвердить это за секунды.

Избегайте кастомных веток биллинга

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

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

Команды, которые это делают правильно, держат биллинг скучным. Это и есть цель.

Используйте правила доступа, которые растягиваются

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

Простая настройка часто начинается с нескольких ролей:

• Admin управляет биллингом, безопасностью и членами команды.
• Manager меняет настройки для своей группы.
• Editor выполняет повседневную работу.
• Viewer читает данные, но не вносит изменения.

Такие названия понятны сразу. Имена прав должны быть так же прозрачны: "Экспорт отчётов", "пригласить коллег", "утвердить счёт" — эти метки объясняют, что произойдёт. Расплывчатые ярлыки вроде "advanced access" или "power user" только путают.

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

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

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

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

Простой пример с двумя путями клиентов

Представьте двух клиентов, пришедших в один день. Один — дизайн‑студия из пяти человек. Другой — компания на 700 человек, которая хочет контролируемый пилот перед развёртыванием.

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

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

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

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

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

Ошибки, которые делают команды на раннем этапе

Частая ошибка — считать одну большую сделку новым стандартом для всех. Переговоры просят ручные одобрения, кастомные даты выставления счетов, дополнительные роли и отдельный путь поддержки. Команда соглашается и встраивает эти правила в основной продукт. Через месяц новые self-serve пользователи видят экраны и шаги, которые им не нужны.

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

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

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

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

Быстрая проверка перед добавлением ещё одного исключения

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

Перед утверждением спецкейса задайте пять честных вопросов:

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

Если на два или более вопроса ответ "нет", остановитесь и пересмотрите. Скорее всего вам не нужна быстрая заплатка, а чистое правило в продукте.

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

Эта проверка занимает десять минут и может сэкономить недели уборки позже.

Следующие шаги к гибкому продукту

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

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

Простая сортировка помогает. Оставьте повторяющиеся кейсы, которые стоит превратить в продуктовые правила. Редкие случаи могут оставаться ручными. Объедините дубликаты с разными формулировками. Уберите исключения, связанные со старыми клиентами или устаревшими тарифами.

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

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

Если команда продолжает спорить об одном и том же, внешний обзор поможет. Oleg Sotnikov делится таким fractional CTO и работой по архитектуре продукта через oleg.is, обычно помогая командам отделять правила, которые принадлежат продукту, от того, что остаётся процессом команды.

Цель проста: меньше одноразовых обещаний, меньше скрытых правил и продукт, который команда может объяснить на одной встрече.