B2B-клиент в CRM: плательщик, площадка и история связей

Сначала определите вопрос каждого участника

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

В Microsoft Field Service различаются service account, получающий обслуживание, и billing account, которому направляются счета; один расчётный аккаунт может обслуживать несколько сервисных. Это подтверждает полезность разделения ролей, но не задаёт универсальную структуру вашей CRM. Microsoft: customer accounts.

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

Четыре записи и несколько отношений

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

Не обязательно создавать организацию на каждую комнату. Microsoft описывает functional locations как иерархию мест, например здания и помещения. Такая пространственная вложенность отвечает на вопрос «где находится объект», а не «кто оплачивает работу». Microsoft: functional locations.

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

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

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

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

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

Microsoft отдельно предупреждает: обновление общей информации аккаунта не обновляет существующие work orders, а отражается в будущих. Это поведение конкретного продукта, которое полезно проверить и в выбранной системе. Microsoft: изменение account information.

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

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

Все организации, суммы и правила ниже вымышлены. Рассматриваем шесть подтверждённых работ сентября без налогов и без оценки поступивших денег. Первоначально расчётная организация P указана для площадок A, B и C.

На A выполнены две работы на 6 000 и 4 000 рублей, всего 10 000. На C одна работа на 6 000. На B три работы: 3 000 до изменения, 2 000 после изменения по ранее подтверждённому заказу и 3 000 по новому заказу. Итого B: 3 000 + 2 000 + 3 000 = 8 000. Общая сумма: 10 000 + 8 000 + 6 000 = 24 000.

С 20 сентября для новых подтверждений площадки B действует организация Q. Учебные условия сохраняют P для уже подтверждённых заказов, пока нет отдельного согласованного изменения. Работа B на 2 000 подтверждена 18 сентября и выполнена 24 сентября: её плательщик остаётся P. Работа на 3 000 подтверждена 22 сентября: у неё Q.

По площадкам отчёт показывает A — 10 000, B — 8 000, C — 6 000. По зафиксированным плательщикам: P = 10 000 + 3 000 + 2 000 + 6 000 = 21 000; Q = 3 000. Оба разреза дают 24 000. Смена связи не создаёт новую работу и не увеличивает сумму.

Если пересчитать всю историю B по сегодняшнему плательщику, получится P — 16 000, Q — 8 000. Общий итог останется правильным, но 5 000 окажутся отнесены не по принятым условиям. Поэтому контроль только общего итога не обнаруживает ошибку принадлежности.

Какие поля нужны для воспроизводимой проверки

Сохраните небольшой обязательный набор:

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

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

Доступ и отчёты: где возникают скрытые ошибки

Местный управляющий B может иметь право видеть визиты B, но не расчёты других площадок P. Бухгалтер P может получать документы P, но не все технические фотографии. Проверяйте доступ по подтверждённой роли и области, отдельно от наличия связи в CRM.

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

Ещё одна ошибка возникает при соединении заказов с контактами. Если у B два контакта и каждый заказ повторится по обоим, его 8 000 превратятся в 16 000, а общий отчёт покажет 32 000 вместо 24 000. Суммируйте уникальные строки работ; список контактов добавляйте без размножения денежного факта.

Чек-лист приёмки

1. Один адрес с двумя площадками не объединяет их историю автоматически.
2. Заказ содержит площадку, плательщика и контакт нужной роли.
3. Смена плательщика с 20 сентября не меняет старые подтверждения молча.
4. Работа B на 2 000 остаётся у P по условиям примера.
5. Два разреза отчёта дают 24 000, а распределение P/Q — 21 000/3 000.
6. Два контакта B не удваивают суммы его работ.
7. Уволенный контакт не получает новые сообщения по закрытой роли.
8. Пользователь одной площадки не видит чужую историю через общий аккаунт.
9. Поздняя регистрация связи сохраняет фактическую дату действия.
10. Неоднозначный плательщик останавливает подготовку соответствующего документа до решения.

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

Частые вопросы

Можно оставить одну карточку на всю сеть?

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

Переезд офиса создаёт нового клиента?

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

Достаточно заменить плательщика у площадки?

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

Источники

• Microsoft: customer accounts — сервисная и расчётная роли, обновление будущих заказов.
• Microsoft: functional locations — пространственная иерархия.
• HubSpot: association labels — типизированные связи.

Проверено 9 октября 2026 года. Датированная схема и числовой пример являются учебными требованиями к процессу.