White-label SaaS для партнёров: как заказать один продукт под разными брендами

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

Когда бизнесу нужен сервис под брендами партнёров?

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

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

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

Что должно оставаться общим, а что можно менять?

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

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

Запрос партнёра	Общее для продукта	Настройка партнёра	Проверка
Свой логотип и цвета	Компоненты и расположение действий	Изображения и допустимая палитра	Длинное название не скрывает кнопку
Свой адрес сервиса	Один порядок входа и восстановления	Подтверждённый домен	Письмо возвращает в нужный бренд
Другие названия разделов	Смысл данных и операций	Согласованный словарь терминов	Название совпадает в экране и выгрузке
Отключить модуль	Проверка доступа к модулю	Набор разрешённых функций	Прямая ссылка тоже закрыта
Свой порядок согласования	Механизм переходов	Только предусмотренные варианты	Нельзя включить противоречивую цепочку
Получать отдельные обновления	Общая поддерживаемая версия	Согласованная очередь включения	Нет неизвестной версии без владельца

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

• 01Общее ядро

  Смысл операций, модель данных и поддерживаемая версия продукта.

• 02Оформление и термины

  Логотип, палитра и согласованный словарь в допустимых границах.

• 03Домены и модули

  Подтверждённый адрес сервиса и набор разрешённых функций.

• 04Бизнес-правила

  Только заранее предусмотренные варианты и понятные последствия изменения.

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

Как устроить компании и пользователей внутри партнёрской версии?

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

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

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

Как подключать домены и не путать письма разных брендов?

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

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

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

Как дать партнёру настройки и сохранить управляемый продукт?

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

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

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

Как обновлять продукт сразу для нескольких брендов?

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

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

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

Кто отвечает за поддержку и отключение партнёра?

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

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

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

Что оставить в первой версии white-label сервиса?

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

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

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

Из чего складывается стоимость разработки?

Цена зависит от глубины различий между партнёрами, числа пользовательских ролей, внешних подключений и требований к отдельному размещению. Ориентир Roboweb по тарифу разработки веб-приложений — от 160 000 ₽ и от 10 дней для компактной первой версии. Это не оценка всей партнёрской платформы по одному названию. Точный срок фиксируется в договоре в рабочих днях и отсчитывается с поступления предоплаты и передачи исходных материалов.

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

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

Что подготовить, чтобы получить предметную оценку?

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

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

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

Чем white-label отличается от обычного SaaS?

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

Нужно ли делать отдельную копию кода каждому партнёру?

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

Можно ли разрешить партнёру менять любые экраны?

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

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

Ориентир веб-приложения Roboweb — от 160 000 ₽ и от 10 дней для компактной первой версии. Домены партнёров, особые процессы и порядок обновлений оцениваются по согласованному объёму.

Как подготовиться к оценке?

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

Услуги и кейсы по теме: разработка веб-приложений и SaaS · личные кабинеты партнёров и клиентов