Как разделить роли участников заказа в CRM

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

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

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

Храните роли внутри заказа

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

В официальной модели Shopify отдельно представлены клиент заказа, платёжный адрес и адрес доставки. Это пример того, что сведения о заказе изначально могут относиться к разным ролям; наличие адреса доставки не доказывает, что он описывает покупателя.

Если источник передаёт только одно поле customer, уточните его смысл. Это авторизованный аккаунт, контакт для уведомлений, владелец карты лояльности или человек, названный кассиром? Разные источники могут использовать одинаковое имя поля для разных участников.

Выберите адресата для каждого сценария

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

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

Сохраните факты и ограничьте выводы об интересах

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

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

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

Не умножайте выручку на число участников

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

Для клиентской экономики выберите правило: например, вклад заказа относится к аккаунту покупателя, а связь с организацией используется для отдельной B2B-аналитики. Если нужны распределённые показатели, коэффициенты распределения и итоговая сумма должны быть явно согласованы.

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

Условный пример корпоративного подарка

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

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

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

Не превращайте роль в постоянное свойство человека

Сегодня человек получает подарок, завтра покупает сам, а в третьем заказе оплачивает покупку родственника. Поэтому роль хранится в связи с конкретным заказом, а не в единственном поле профиля «тип клиента — получатель».

Минимальная запись участника может содержать ID заказа, код роли, идентификатор участника, источник подтверждения и контакты для этой задачи. Если участник неизвестен как самостоятельный клиент, не нужно придумывать ему постоянный ID человека из телефона доставки.

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

Что добавить в контракт данных

Контракт данных — договорённость о смысле полей и правилах их передачи между системами. Для заказа он должен описывать ID, роли, контакты каждой роли, происхождение сведений, разрешённые задачи использования и правила изменения участников.

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

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

Источники

Shopify. Order. GraphQL Admin API. Поля customer, billingAddress, shippingAddress, displayFinancialStatus и displayFulfillmentStatus. Версия 2026-07. Проверено 22.09.2026.