Группа компаний в CRM: клиент один, юрлиц несколько

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

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

Один бренд не отменяет разных обязательств

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

ИИ добавляет соблазн быстро всё объединить: похожие названия, один домен, общая фамилия директора. Но совпадение — повод проверить связь, а не основание склеить реквизиты. Ошибка здесь не просто портит отчёт. Она способна поменять плательщика и содержание обязательств.

Связь сохраняет различия, слияние их уничтожает

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

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

Роли заказа важнее универсального поля «компания»

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

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

Общий объём покупок не означает общий кредитный лимит

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

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

Схема заказа из пяти вопросов вместо одной карточки на всё

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

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

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

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

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

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

Где доступ к общей группе может стать лишним доступом к чужой сделке

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

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

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

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

Шесть ситуаций: разводим плательщика, покупателя и место поставки

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

Похожие названия

В базе есть «Север Трейд» и «Север Торг» с разными реквизитами.

Ошибочный ход. Слить карточки по сходству слов.

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

Основание проверки. Реквизиты, домен и допустимый источник структуры отношений.

Признак корректного результата. Похожее название не заменяет проверенное основание.

Граница. Компании могут не иметь отношения друг к другу даже при одном брендовом слове.

Другой плательщик

Покупатель просит оформить оплату через связанную организацию.

Ошибочный ход. Поменять основную компанию во всех старых сделках.

Рабочее действие. Уточнить роли в текущем заказе и порядок оформления документов.

Основание проверки. Подтверждённые реквизиты и согласованная сторона договора.

Признак корректного результата. История старых заказов не меняется из-за нового платёжного маршрута.

Граница. Допустимость схемы и документы проверяют ответственные специалисты, а не агент по названию компании.

Поставка на объект

Юрлицо покупателя зарегистрировано в одном городе, товар нужен на стройплощадке.

Ошибочный ход. Считать юридический адрес адресом доставки.

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

Основание проверки. Подтверждённые условия доставки текущего заказа.

Признак корректного результата. Менеджеру понятны адресат документов и адресат логистического действия.

Граница. Адрес объекта может меняться и не должен автоматически становиться реквизитом компании.

Общий закупщик

Один контакт выбирает поставщика для нескольких участников группы.

Ошибочный ход. Разрешить этому контакту любые финансовые изменения по всем компаниям.

Рабочее действие. Сохранить область роли и проверять полномочия для конкретного действия.

Основание проверки. Подтверждение того, какие задачи контакт действительно согласует.

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

Граница. Участие в прошлой закупке не подтверждает бессрочные полномочия.

Групповой отчёт

Руководитель хочет общую сумму продаж по холдингу.

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

Рабочее действие. Задать уникальную сделку как единицу учёта и исключить повторное отображение.

Основание проверки. Идентификаторы заказов, платежей и выбранная дата признания показателя.

Признак корректного результата. Каждая продажа включена один раз по воспроизводимому правилу.

Граница. Оплаты и заказы нельзя смешивать в одной метрике без объяснения.

Разрыв связи

Компания вышла из группы или контакт больше не отвечает за закупки.

Ошибочный ход. Удалить связь так, будто её никогда не было.

Рабочее действие. Зафиксировать дату изменения и сохранить исторический контекст.

Основание проверки. Доступное подтверждение новых отношений.

Признак корректного результата. Новая работа использует актуальную структуру, старые документы остаются объяснимыми.

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

Рабочая матрица: группа компаний в crm

Как проверить общий отчёт, не удваивая выручку

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

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

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

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

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

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

В условной группе три компании. Компания А заключила два заказа на 100 000 и 150 000 рублей. Компания Б оплачивает второй заказ, а компания В принимает оба на объектах. Если все роли отображаются отдельными строками и суммы сложить без устранения повторов, отчёт легко покажет больше реальных 250 000 рублей заказов. Роль не создаёт новую продажу.

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

Ограничения: группа компаний crm

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

Проверка продукта: Цифра

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

Подробнее: Цифра — возможности и условия. О подходе к проверке результата — как 404ai работает с задачей компании.

Связанные вопросы

• История изменений сделки в CRM: кто поменял условия: разбираем авторство изменений и восстановление контекста.

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

Источники: группа компаний crm

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

• Microsoft: правила поиска дублей. Совпадения ищут по правилам, а не по одному общему слову. Связь компаний и тождество записей в статье сознательно разделены.

• Microsoft: лиды и связанные организации. Справка показывает создание и проверку связанных записей при квалификации. Это пример модели, а не обещание одинакового поведения всех CRM.

• Microsoft: аудит изменений данных. Изменение отношений и реквизитов полезно делать прослеживаемым. Конкретный состав истории зависит от настройки системы.