Интеграция интернет-магазина с Битрикс24: заказы без дублей и ручного переноса

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

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

Определите, какую работу менеджера должна убрать интеграция

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

Распределите обязанности систем. Например, CRM хранит коммуникацию и согласование, сайт — корзину и кабинет, учёт — остатки и отгрузку. Запишите источник каждого поля и разрешённое направление изменения.

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

Готовый коннектор и индивидуальная разработка

У Битрикс24 есть штатная интеграция с магазинами на «1С-Битрикс: Управление сайтом» и приложения для других платформ. Проверяйте конкретное решение и тариф: набор передаваемых полей, направление обмена и возможности изменения заказа различаются. Само присутствие названия CMS в каталоге приложений не подтверждает ваш сценарий.

В официальной инструкции штатного подключения отдельно указано: изменение стадии сделки в CRM не возвращает изменение в магазин. Поэтому обещание «подключим двусторонний обмен» требует собственного описания. Где-то достаточно получать заказы в CRM, а где-то обратная передача адреса или согласованного состава становится самостоятельной задачей.

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

Что видно в штатном мастере подключения

В инструкции мастера показаны период первого импорта, ответственный и доступность сделок. По этим настройкам определите, какие старые заказы попадут в CRM и кто сможет их видеть. Вид экрана сверяйте с используемой версией портала.

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

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

Одна сделка должна сохранять состав заказа

В условном заказе два товара по 4 200 ₽, скидка 600 ₽ и доставка 450 ₽ дают 8 250 ₽. Передайте в CRM позиции, количество, скидку и доставку отдельными данными — они понадобятся при изменении состава.

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

Как избежать дублей контактов и сделок

Повтор HTTP-запроса не означает новый заказ. Если CRM обработала создание, но ответ потерялся, следующий запрос должен связаться с уже созданным объектом. Устойчивый внешний номер и журнал операций помогают восстановить связь. Проверка состоит именно в искусственном обрыве ответа, а не в обычном повторном открытии карточки.

Один покупатель может сделать несколько заказов. Объединение сделок только по телефону уничтожит этот смысл. Обратная крайность — создавать новый контакт на каждую покупку — раздробит историю. Согласуйте отдельно идентификатор заказа и правила определения клиента.

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

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

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

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

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

Матрица изменений вместо общей «синхронизации статусов»

Для условного заказа WEB-1042 согласуйте четыре действия менеджера из таблицы ниже. Если коннектор не поддерживает нужное обратное изменение, включите его доработку в оценку отдельно.

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

Задержка обмена и сбои должны быть заметны

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

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

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

Как проверить работу менеджера и аналитику

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

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

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

Какие сценарии включить в приёмку и смету

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

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

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

Если складской контур находится в МоемСкладе, используйте отдельный набор проверок обмена заказами и остатками. Приёмка CRM не заменяет проверку резерва, отгрузки и учётных документов.

Таблица приёмки и подготовка к обсуждению

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

Для оценки в CAPS подготовьте магазин, название подключения и одну ручную операцию, которую нужно убрать. Если заказ теряется, добавьте время и обезличенное описание. По ним определим объём диагностики и первую задачу.