Многосайтовость в Битрикс24: один портал на несколько брендов и воронок

Зачем группе компаний единый портал

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

Вот типичные сценарии, где схема с одним порталом на несколько брендов реально работает:

• Группа компаний с разными брендами — каждый бренд в своей воронке, менеджеры не видят чужих клиентов.
• Холдинг с несколькими юрлицами — у каждого свои реквизиты в документах, но клиентская база общая, дублей нет.
• Управляющая компания + «дочки» — руководство видит всё целиком, директора «дочек» — только своё.
• Разные каналы продаж одного бренда — оптовые и розничные продажи в отдельных воронках. Нередко это даже удобнее, чем делить бренды.

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

Архитектура: что разделяется, что остаётся общим

Главный принцип: в Битрикс24 нет технических барьеров между брендами на уровне платформы. Разделение строится через права, воронки и поля. Вот как это выглядит на практике:

Элемент	Общее для всех брендов	Разделяется по брендам
Контакты и компании	Единая база (исключает дубли)	Поле «Бренд / направление» для сегментации
Воронки сделок	—	Отдельная воронка на каждый бренд/юрлицо
Роли и права	Администратор портала	Менеджеры видят только свои воронки
Шаблоны документов	—	Отдельные шаблоны с реквизитами каждого юрлица
Аналитика	Сводный дашборд для руководства	Срезы по каждому направлению
Интеграции (телефония, почта)	Единая телефония портала	Отдельные почтовые ящики per бренд

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

flowchart TD
    SITE1[Сайт Бренд А] --> B24[Битрикс24 — единый портал]
    SITE2[Сайт Бренд Б] --> B24
    PHONE[Телефония] --> B24
    B24 --> FUNNEL1[Воронка Бренд А]
    B24 --> FUNNEL2[Воронка Бренд Б]
    FUNNEL1 --> REPORT[Сводная аналитика руководства]
    FUNNEL2 --> REPORT
    FUNNEL1 --> MGRA[Менеджеры Бренд А]
    FUNNEL2 --> MGRB[Менеджеры Бренд Б]

Воронки под каждый бренд: логика настройки

Воронка — главный инструмент разделения процессов. По нашей практике, на каждое направление создаётся свой набор воронок. Стандартный комплект для одного бренда:

1. Воронка лидов — квалификация входящих обращений из всех подключённых каналов: сайт, телефония, мессенджеры. Подтверждённый интерес конвертируется в сделку, контакт и компанию.
2. Воронка основных продаж — уточнение требований, коммерческое предложение, согласование условий, договор, оплата.
3. Воронка исполнения обязательств — контроль после сделки: сборка, доставка, закрывающие документы.
4. Воронка повторных продаж — работа с клиентами, которые уже покупали; выявление новых потребностей.
5. Воронка отложенного спроса — те, кто пока не готов. Фиксируется дата следующего касания, чтобы контакт не потерялся в списке.

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

Права доступа и видимость данных

Разграничение доступа — самый чувствительный момент в таких проектах. Типовая схема ролей выглядит так:

• Менеджер бренда А — видит только сделки и лиды воронок бренда А, к воронкам бренда Б доступа нет.
• Руководитель направления — видит все сделки своего бренда, включая сделки подчинённых.
• Директор по продажам холдинга — видит воронки всех брендов и сводную аналитику.
• Администратор портала — полный доступ к настройкам; коммерческая информация при необходимости закрывается.

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

Есть один нюанс, который часто упускают: база контактов и компаний в CRM общая. Чтобы менеджер бренда А не видел клиентов бренда Б, ограничение ставится на уровне видимости карточек — «только свои» или «своего подразделения». Это стандартный механизм прав CRM, ничего сверхъестественного.

Поля карточек: общие и брендовые

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

Общие поля (для всей базы):

• Тип контрагента (клиент, партнёр, агент, подрядчик)
• Источник обращения и UTM-метка
• Ответственный менеджер
• История взаимодействий

Брендовые поля (в воронке конкретного направления):

• Поле «Бренд / юрлицо» — для фильтрации и аналитики
• Специфические параметры продукта или услуги
• Реквизиты для шаблонов документов — у каждого юрлица свои

О логике настройки полей подробнее — в статье пользовательские поля в Битрикс24. Если у брендов разные типы контрагентов или сложные связи между объектами, загляните также в связи между сущностями в Битрикс24.

Суммарно в одном проекте настраивается до 50 полей по всем воронкам. Поля, которые повторяются в разных воронках, считаются как одно.

Аналитика и отчёты по нескольким направлениям

Руководителю группы компаний нужны два уровня аналитики — и они устроены по-разному.

Сводный уровень (для холдинга):

• Количество новых лидов и сделок по всем брендам за период
• Конверсия по воронкам в разрезе брендов
• Общая выручка и её распределение по направлениям

Брендовый уровень (для директора направления):

• Воронка конверсии по стадиям своего бренда
• Активность менеджеров: звонки, задачи, сделки
• Просроченные сделки и лиды без касания

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

Типовые ошибки при настройке

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

1. Создают отдельные порталы вместо воронок. В итоге теряется единая база контрагентов и нет никакой возможности отследить клиентов, которые работали с несколькими брендами.

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

3. Смешивают поля разных воронок в одну карточку. Карточка сделки превращается в свалку из десятков нерелевантных полей. Лечится настройкой видимости полей по воронке.

4. Не фиксируют бренд в карточке контакта. Когда один человек покупает у двух брендов, без поля «направление» история взаимодействий превращается в кашу.

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

6. Не прописывают ТЗ до начала настройки. Архитектура для нескольких брендов сложнее типового внедрения. Без чёткого технического задания исполнитель и заказчик понимают задачу по-разному — и потом долго это расхлёбывают. О структуре такого документа — в статье структура ТЗ на доработку Битрикс24.

С чего начать внедрение

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

1. Зафиксировать список брендов/юрлиц и разобраться, какие процессы у них общие, а какие уникальные.
2. Описать структуру воронок для каждого направления — стадии, поля, ответственные роли.
3. Спроектировать матрицу прав — кто что видит на уровне менеджера, руководителя направления и директора холдинга.
4. Настроить базовые воронки и права, затем протестировать разграничение на реальных сценариях.
5. Подключить каналы коммуникаций — телефонию, почту, мессенджеры — с привязкой входящих к нужному бренду.
6. Настроить аналитику — срезы по каждому направлению и сводный дашборд для руководства.
7. Провести обучение раздельно по группам: менеджеры каждого бренда учатся своим воронкам, руководители — аналитике и контролю.