Интернет-магазин и CRM: какие данные заказа передавать и как проверить обмен

Где заканчивается передача заказа

Потерянные позиции заказа превращают удобную передачу с сайта в ручной разбор: менеджер видит сделку, но вынужден снова выяснять у покупателя состав, количество и цену. Заявка появилась, покупка потерялась. Чтобы исправить такую интеграцию интернет-магазина с CRM, системой ведения клиентов и продаж, нужно проследить один заказ до полной карточки и найти этап, на котором исчезли сведения или возник повтор.

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

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

Сначала связывают заказ и сделку

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

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

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

Товары передают как позиции заказа

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

В Битрикс24 метод сохранения товарных позиций позволяет передать название, цену и количество. Цена задаётся в валюте объекта CRM. Для заказчика отсюда следует требование: передаётся стоимость, по которой покупатель оформил именно этот заказ, а не текущая цена каталога на момент, когда сотрудник открыл сделку. Скидку учитывают по согласованному способу расчёта, чтобы не вычесть её повторно.

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

Откуда берётся неправильная сумма

Нулевая стоимость в CRM может возникнуть даже тогда, когда магазин отправил правильный товар: передача идентификатора изделия не означает, что система сама возьмёт цену, по которой оформлялась покупка. Итог сверяют по строкам. Документация Битрикс24 указывает, что у товарной позиции без переданной цены она равна 0, даже при связи с каталогом. У количества другое значение по умолчанию — 1. Эти особенности объясняют, почему узнаваемые названия в сделке ещё не говорят о корректном заказе.

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

Расчётный пример: две единицы по 1 000 рублей дают товарный итог 2 000 рублей. Если количество потерялось и осталось значение по умолчанию, строка покажет только половину этого итога. Такой пример помогает договориться о проверке арифметики, но для приёмки используют условия реального тестового заказа, включая применённую скидку и доставку. Их стоимость не добавляют второй раз в другом поле.

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

Изменение заказа не стирает работу продаж

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

Особого внимания требует изменение товарного набора. Метод crm.item.productrow.set заменяет все позиции переданным набором. Позиции, отсутствующие в новом списке, удаляются, а сумма объекта CRM пересчитывается. Поэтому передать одну изменённую строку как будто это полный заказ — плохое решение: остальные товары исчезнут. Такое поведение приведено в документации метода, а способ обновления выбирает исполнитель.

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

Кто получает заказ после создания

Заказ может исправно прийти в Битрикс24 и остаться без обработки, если он назначен технической учётной записи вместо сотрудника продаж: программа сохранила покупку, но ни один менеджер не увидел её среди своих новых дел. Принимать такую передачу рано. В справке создания сделки поле ASSIGNED_BY_ID задаёт ответственного, а при отсутствии значения используется пользователь, который вызвал метод. Это конкретное поведение API, поэтому назначение сотрудника описывают явно, а не выводят из того, кто подключал обмен.

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

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

Сбой одного шага требует продолжения обмена

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

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

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

Проверка на повторах и изменениях

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

• Первичная передача. В сделке есть номер покупки, точные исполнения товаров, количества и сумма. Заказ назначен тому, кто продолжит обработку.
• Повтор того же заказа. Нет второй покупки в CRM и повторной задачи на уже выполненное действие. Исходная запись остаётся связанной с сайтом.
• Изменение состава. Новый состав приходит в ту же сделку. Автоматическое обновление сохраняет те действия менеджера, которые компания решила не переписывать.
• Незавершённый этап. Исполнитель показывает остановку и продолжение. Сотрудник видит причину неполного заказа и путь к исправлению.

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

Разберите один заказ без помощи разработчика

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

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

Для разбора со ШТАБ ИТ по интеграции Битрикс24 подготовьте ссылку на сделку, номер заказа и описание расхождения, которое мешает сотруднику продолжить обработку. По ним можно отделить ошибку записи данных от правила работы продаж и определить объём доработки, вместо общего поручения сделать связь магазина с CRM надёжнее.