Зачем группе компаний единый портал
Когда в холдинге несколько юридических лиц или торговых марок, соблазн заводить отдельный Битрикс24 на каждое направление понятен. Но это создаёт дублирование затрат на лицензии, разрозненные базы контрагентов и невозможность видеть сводную аналитику. Единый портал с грамотной архитектурой снимает эти проблемы.
Типичные сценарии, при которых используют многосайтовую схему:
- Группа компаний с разными брендами — каждый бренд работает в своей воронке, менеджеры не видят чужих клиентов.
- Холдинг с несколькими юрлицами — разные реквизиты в документах, но единая клиентская база для исключения дублей.
- Управляющая компания + «дочки» — руководство видит сводную картину, директора «дочек» — только своё направление.
- Разные каналы продаж одного бренда — например, оптовые и розничные продажи разведены в отдельные воронки.
Перед стартом архитектурных решений полезно пройти аудит текущего портала — это помогает выявить, что уже настроено и что мешает масштабированию.
Архитектура: что разделяется, что остаётся общим
Ключевой принцип: в одном портале Битрикс24 разделение достигается не техническими барьерами платформы, а настройкой прав, воронок и полей. Ниже — типовое разграничение.
| Элемент | Общее для всех брендов | Разделяется по брендам |
|---|---|---|
| Контакты и компании | Единая база (исключает дубли) | Поле «Бренд / направление» для сегментации |
| Воронки сделок | — | Отдельная воронка на каждый бренд/юрлицо |
| Роли и права | Администратор портала | Менеджеры видят только свои воронки |
| Шаблоны документов | — | Отдельные шаблоны с реквизитами каждого юрлица |
| Аналитика | Сводный дашборд для руководства | Срезы по каждому направлению |
| Интеграции (телефония, почта) | Единая телефония портала | Отдельные почтовые ящики per бренд |
На схеме ниже показано, как входящий трафик от нескольких брендов попадает в единый портал, расходится по воронкам и собирается в сводной аналитике для руководства холдинга.
flowchart TD
SITE1[Сайт Бренд А] --> B24[Битрикс24 — единый портал]
SITE2[Сайт Бренд Б] --> B24
PHONE[Телефония] --> B24
B24 --> FUNNEL1[Воронка Бренд А]
B24 --> FUNNEL2[Воронка Бренд Б]
FUNNEL1 --> REPORT[Сводная аналитика руководства]
FUNNEL2 --> REPORT
FUNNEL1 --> MGRA[Менеджеры Бренд А]
FUNNEL2 --> MGRB[Менеджеры Бренд Б]
Воронки под каждый бренд: логика настройки
Воронка — главный инструмент разделения процессов. В типовом проекте для группы компаний на каждое направление создаётся свой набор воронок. По нашему опыту, стандартный набор для одного бренда выглядит так:
- Воронка лидов — квалификация всех входящих обращений из интегрированных каналов (сайт, телефония, мессенджеры). При подтверждении интереса лид конвертируется в сделку, контакт и компанию.
- Воронка основных продаж — уточнение требований, формирование коммерческого предложения, согласование условий, подписание договора, получение оплаты.
- Воронка исполнения обязательств — контроль выполнения после сделки: сборка, доставка, закрывающие документы.
- Воронка повторных продаж — работа с клиентами, которые уже совершили покупку, выявление новых потребностей.
- Воронка отложенного спроса — клиенты, которые временно не готовы к сделке; фиксируется дата следующего касания, чтобы контакт не потерялся.
Если у брендов схожая логика продаж, воронки могут быть устроены идентично — только с разными ответственными и настройками автоматизации. Подробнее об автоматизации в воронках читайте в статье про роботы и триггеры в воронке Битрикс24.
Права доступа и видимость данных
Разграничение доступа — самая чувствительная часть настройки для группы компаний. Типовая схема ролей:
- Менеджер бренда А — видит только сделки и лиды воронок бренда А, не имеет доступа к воронкам бренда Б.
- Руководитель направления — видит все сделки своего бренда, включая сделки подчинённых.
- Директор по продажам холдинга — видит воронки всех брендов, сводную аналитику.
- Администратор портала — полный доступ к настройкам, без доступа к коммерческой информации (при необходимости).
Для ограничения доступа к сделкам, контактам и лидам в зависимости от роли настраиваются права пользователей — отдельно для каждой группы: менеджеры, руководители, администраторы.
Важный нюанс: база контактов и компаний в CRM Битрикс24 общая. Чтобы менеджер бренда А не видел клиентов бренда Б, ограничение выставляется на уровне видимости карточек — «только свои» или «своего подразделения». Это стандартный механизм прав CRM.
Поля карточек: общие и брендовые
Пользовательские поля в карточках — ещё один уровень разделения. Для группы компаний типично настраивать:
Общие поля (для всей базы): - Тип контрагента (клиент, партнёр, агент, подрядчик) - Источник обращения и UTM-метка - Ответственный менеджер - История взаимодействий
Брендовые поля (в воронке конкретного направления): - Поле «Бренд / юрлицо» — для фильтрации и аналитики - Специфические параметры продукта или услуги - Реквизиты для шаблонов документов (у каждого юрлица свои)
Подробнее о логике настройки полей — в статье пользовательские поля в Битрикс24. Если у брендов разные типы контрагентов или сложные связи между объектами, стоит также изучить связи между сущностями в Битрикс24.
Стандартно в одном проекте настраивается до 50 полей суммарно для всех воронок — поля, которые повторяются в разных воронках, считаются как одно.
Аналитика и отчёты по нескольким направлениям
Руководителю группы компаний нужны два уровня аналитики:
Сводный уровень (для холдинга): - Количество новых лидов и сделок по всем брендам за период - Конверсия по воронкам в разрезе брендов - Общая выручка и распределение по направлениям
Брендовый уровень (для директора направления): - Воронка конверсии по стадиям своего бренда - Активность менеджеров: звонки, задачи, сделки - Просроченные сделки и лиды без касания
Для разграничения отчётов используется фильтрация по воронке, ответственному подразделению или полю «Бренд». Дашборды настраиваются отдельно для каждой роли — руководитель видит свой набор срезов, менеджер — только личные показатели. Подробнее о возможностях — в статье отчёты и дашборды в Битрикс24.
Типовые ошибки при настройке
По нашему опыту, при реализации схемы «один портал — несколько брендов» чаще всего допускают следующие ошибки:
-
Создают отдельные порталы вместо воронок. Теряется единая база контрагентов, невозможно отследить клиентов, которые взаимодействовали с несколькими брендами.
-
Не разграничивают права на старте. Менеджеры видят чужие сделки, данные конкурирующих направлений доступны всем — это создаёт конфликты и утечку информации.
-
Смешивают поля разных воронок в одну карточку. Карточка сделки превращается в «мусорную кучу» из десятков нерелевантных полей. Решение — настраивать видимость полей по воронке.
-
Не фиксируют бренд в карточке контакта. Когда один человек покупает у двух брендов, без поля «направление» история взаимодействий перемешивается.
-
Откладывают настройку аналитики. Руководство несколько месяцев работает «вслепую», потому что отчёты по направлениям настроили только после накопления данных.
-
Не прописывают ТЗ до начала настройки. Архитектура для нескольких брендов сложнее типового внедрения — без чёткого технического задания исполнитель и заказчик понимают задачу по-разному. О структуре такого документа — в статье структура ТЗ на доработку Битрикс24.
С чего начать внедрение
Последовательность для группы компаний, которая внедряет единый портал:
- Зафиксировать список брендов/юрлиц и определить, какие процессы у них общие, а какие уникальные.
- Описать структуру воронок для каждого направления — стадии, поля, ответственные роли.
- Спроектировать матрицу прав — кто что видит на уровне менеджер / руководитель направления / директор холдинга.
- Настроить базовые воронки и права, затем протестировать разграничение на реальных сценариях.
- Подключить каналы коммуникаций — телефонию, почту, мессенджеры — с привязкой входящих обращений к нужному бренду.
- Настроить аналитику — срезы по каждому направлению и сводный дашборд для руководства.
- Провести обучение раздельно по группам: менеджеры каждого бренда обучаются своим воронкам, руководители — аналитике и контролю.