Магазин на 1С-Битрикс генерирует заявки и заказы, но менеджеры продают в amoCRM — и между этими двумя мирами постоянно теряются данные. Клиент оставил заявку в форме, а она осела в письме на почте; оформил заказ, а менеджер узнал о нём из выгрузки в конце дня. Каждый такой разрыв — это остывший лид, забытый заказ и невозможность честно посчитать, какая реклама приносит деньги.
Эта статья — практическое руководство по тому, как связать интернет-магазин на 1С-Битрикс с amoCRM так, чтобы лиды из форм и заказы попадали в воронку автоматически, без дублей и потерь. Разберём модель данных, REST API, дедупликацию, очередь обмена и типичные грабли. Настройку связки под ваши процессы мы закрываем услугой интеграции с amoCRM, RetailCRM и Мегапланом.
Коротко
- Связь строят через REST API amoCRM и обработчики событий Битрикса (формы, заказы) — синхронно отправлять данные в момент оформления нельзя.
- Из форм создают сделку в «Неразобранном», заказ — сделку в нужном этапе воронки с составом, суммой и доставкой.
- Контакты обязательно дедуплицируют по нормализованному телефону и e-mail, иначе воронка засоряется дублями.
- Обмен идёт через очередь с повторами, а UTM-метки и источник кладут в поля сделки для сквозной аналитики.
Зачем магазину на Битрикс отдельная amoCRM
1С-Битрикс хорошо ведёт каталог, заказы и обмен с 1С, но его встроенная CRM (в редакции с CRM) — не единственный вариант для отдела продаж. amoCRM выигрывает там, где важна лёгкая воронка, телефония, мессенджеры и работа менеджеров «в один экран». Поэтому распространённая архитектура такая: витрина и оформление заказа — на Битриксе, а продажи и коммуникации — в amoCRM.
Проблема в том, что по умолчанию эти системы ничего не знают друг о друге. Интеграция закрывает разрыв: каждая заявка и каждый заказ автоматически становятся сделкой с контактом, менеджер видит их в реальном времени, а руководитель — сквозную картину от клика до выручки. Если вы ещё выбираете между встроенной CRM и amoCRM, полезно прочитать разбор amoCRM против Битрикс24 CRM.
Что именно передаём: лиды, заказы, статусы
Прежде чем писать код, договоритесь, какие события сайта должны попадать в amoCRM и во что именно превращаться. Обычно это три потока данных.
- Лиды из форм. Обратный звонок, вопрос, заявка на подбор, форма в карточке товара — создают сделку в статусе «Неразобранное» или на первом этапе воронки.
- Заказы магазина. Оформленный заказ становится сделкой с составом, суммой, способом доставки и оплаты, привязанной к контакту покупателя.
- Изменения статусов. Смена статуса заказа в Битриксе (оплачен, отгружен, отменён) двигает сделку по воронке — и, при двусторонней связи, наоборот.
Чёткая карта «событие сайта → объект amoCRM → этап воронки → поля» экономит потом дни доработок. Её стоит согласовать с руководителем продаж до начала работ, потому что именно он знает, как устроена воронка.
Как устроена связь по REST API
Технически интеграция опирается на REST API amoCRM и события 1С-Битрикс. Со стороны Битрикса ловят нужные события: отправку веб-формы, а также события модуля продаж вроде сохранения заказа. Со стороны amoCRM — принимают вебхуки на изменения сделок.
- Авторизация. amoCRM использует OAuth 2.0: интеграция получает access- и refresh-токены, токен доступа нужно вовремя обновлять по расписанию.
- Отправка данных. Сайт шлёт POST-запросы к методам создания контактов и сделок, передавая поля в нужном формате.
- Приём вебхуков. amoCRM дёргает ваш URL при изменении сделки; отдельный скрипт принимает и обрабатывает событие.
- Логирование. Каждый запрос и ответ пишут в лог, чтобы разбирать сбои, а не гадать, «дошла ли сделка».
Логику обмена лучше вынести в отдельный сервисный класс на D7 и не размазывать по шаблонам компонентов — так её проще тестировать и поддерживать. Про грамотную работу с данными в ядре мы писали в статье про D7 и ORM в 1С-Битрикс, а про безопасную настройку приёма вебхуков — в материале про REST, вебхуки и безопасность.
Модель данных: контакт, сделка, поля
Ключевое решение интеграции — как разложить данные заказа по объектам amoCRM. Базовая модель проста: покупатель становится контактом, заказ или заявка — сделкой, а всё остальное живёт в полях сделки и контакта.
| Данные сайта | Объект amoCRM | Куда кладём |
|---|---|---|
| Имя, телефон, e-mail | Контакт | Стандартные поля контакта |
| Номер и сумма заказа | Сделка | Название и бюджет сделки |
| Состав заказа | Сделка | Примечание или товары |
| Доставка и оплата | Сделка | Кастомные поля |
| UTM и источник | Сделка | Кастомные поля источника |
| Комментарий клиента | Сделка | Примечание |
Кастомные поля создают в amoCRM заранее и запоминают их идентификаторы — интеграция обращается к полям по ID, а не по названию. Если поле переименуют, обмен не сломается; если удалят — сломается, поэтому набор полей фиксируют на старте.
Дедупликация контактов по телефону и почте
Самая частая боль «сырой» интеграции — воронка, забитая дублями: один и тот же клиент при каждом заказе создаёт новый контакт. Через месяц менеджер не понимает, кто перед ним, а аналитика по клиентам ломается.
Правильный алгоритм — искать контакт перед созданием:
- Нормализуйте контакты. Телефон приводят к единому формату (только цифры, единый код страны), e-mail — к нижнему регистру и без пробелов.
- Ищите совпадение. По нормализованному телефону и почте запрашивают контакт в amoCRM.
- Привязывайте или создавайте. Нашли — сделку вешают на существующий контакт; не нашли — создают новый.
- Обновляйте аккуратно. Если у контакта не было e-mail, а теперь появился, поле дополняют, не затирая существующие данные.
Передача заказа: состав, сумма, доставка
Заявка из формы — это минимум данных, а вот заказ несёт полную информацию, и её важно передать так, чтобы менеджеру не пришлось лезть в админку Битрикса. В сделку кладут:
- Состав заказа. Список позиций с артикулом, названием, количеством и ценой — в примечании или как товары сделки.
- Итоговую сумму. В бюджет сделки идёт итог заказа с учётом скидок и доставки.
- Способ доставки и оплаты. В отдельные поля — чтобы фильтровать сделки и строить отчёты.
- Промокод и скидку. Если применялись — для аналитики по акциям.
- Ссылку на заказ в админке. Быстрый переход к заказу в Битриксе прямо из карточки сделки.
Событие сохранения заказа удобно ловить обработчиком модуля продаж и формировать из него полезную нагрузку для amoCRM. Если у вас несколько источников заказов (сайт, маркетплейсы, телефон), логичнее свести их в единую CRM — про такой сценарий мы рассказываем в услуге поддержки интеграций с CRM.
Двусторонняя синхронизация статусов
Односторонний обмен «сайт → amoCRM» покрывает большинство задач, но иногда нужен и обратный поток. Если менеджеры ведут заказ в amoCRM, смена этапа сделки должна отражаться на статусе заказа в Битриксе — и наоборот.
Обратную связь реализуют через вебхуки amoCRM: при смене статуса сделки CRM дёргает ваш обработчик, который находит соответствующий заказ и меняет его статус. Ключевой момент — карта соответствия этапов воронки и статусов заказа. Её составляют явно, а не «на глаз», иначе оплаченная сделка окажется в статусе «Новый», и никто не поймёт, где заказ на самом деле.
Очередь и надёжность обмена
Нельзя отправлять данные в amoCRM прямо в момент, когда клиент нажимает «Оформить заказ». Если API ответит с задержкой или ошибкой, покупатель увидит зависшую форму или потеряет заказ — это прямой удар по конверсии. Обмен должен быть асинхронным.
- Очередь событий. Событие (новый заказ, новая заявка) складывают в таблицу-очередь, а клиенту сразу показывают успех.
- Фоновая отправка. Агент Битрикса или отдельный процесс разбирает очередь и шлёт данные в amoCRM.
- Повторные попытки. Если запрос упал, событие возвращают в очередь с задержкой и пробуют снова.
- Лимиты API. amoCRM ограничивает частоту запросов — отправку throttle-ят, чтобы не упереться в лимит.
Стабильность обмена зависит и от инфраструктуры: агенты, cron и фоновые процессы должны надёжно работать. Про правильную настройку окружения мы писали в статье про хостинг и инфраструктуру BitrixVM.
UTM-метки и сквозная аналитика
Интеграция с amoCRM — это ещё и фундамент сквозной аналитики. Чтобы понимать, какая реклама приносит выручку, а не просто заявки, вместе с лидом передают маркетинговый контекст.
- UTM-метки. source, medium, campaign, content, term — из URL первого визита, сохранённые в куках.
- Источник и страница входа. Откуда пришёл посетитель и с какой страницы оформил заказ.
- Идентификаторы аналитики. client_id систем веб-аналитики — чтобы связать сделку с сессией.
Эти данные кладут в кастомные поля сделки. Тогда в amoCRM видно, что заказ на крупную сумму пришёл из конкретной кампании, и рекламный бюджет распределяется по фактической выручке. Если структура интеграции сложная и требует собственного модуля, стоит посмотреть, как устроена разработка модуля под Битрикс.
Пошаговый план внедрения
- Соберите карту событий. Какие формы и заказы, в какой этап воронки, с какими полями — согласуйте с отделом продаж.
- Заведите поля в amoCRM. Кастомные поля сделки и контакта под доставку, оплату, UTM, ссылку на заказ.
- Настройте авторизацию. OAuth-приложение, токены и их автоматическое обновление.
- Реализуйте отправку лидов. Обработчики форм создают сделки с дедупликацией контакта.
- Подключите заказы. Событие сохранения заказа формирует сделку с составом и суммой.
- Добавьте очередь и повторы. Асинхронный обмен с логами и повторными попытками.
- Настройте вебхуки статусов. Если нужна двусторонняя связь — карта этапов и защита от эха.
- Протестируйте на реальных данных. Разные формы, повторные клиенты, отмены, сбои API.
Частые ошибки интеграции
- Синхронная отправка в момент заказа. API тормозит — клиент видит зависшую форму и уходит.
- Нет дедупликации. Каждый заказ плодит новый контакт, воронка засоряется дублями.
- Ненормализованные телефоны. Один клиент превращается в несколько контактов с разной историей.
- Обращение к полям по названию. Поле переименовали — обмен молча кладёт данные не туда.
- Нет логов. Сделка не дошла, а разобраться нечем — «где-то потерялось».
- Игнор лимитов API. При всплеске заказов интеграция упирается в лимит и часть данных теряется.
- Двусторонняя связь без защиты от эха. Статусы зацикливаются и мигают сами по себе.
- Токены не обновляются. Через сутки авторизация протухает, и обмен молча останавливается.
Чек-лист перед запуском
- Карта событий и воронки согласована. Известно, какое событие в какой этап и с какими полями идёт.
- Дедупликация работает. Повторный клиент привязывается к существующему контакту.
- Нормализация настроена. Телефон и e-mail приводятся к единому виду до поиска.
- Обмен асинхронный. События идут через очередь с повторами, оформление заказа не зависит от amoCRM.
- Поля заполняются по ID. Состав, сумма, доставка, UTM попадают в правильные поля.
- Токены обновляются автоматически. Авторизация не протухает.
- Логи включены. Каждый обмен виден, сбои разбираются.
- Протестировано на боевых сценариях. Повторные клиенты, отмены, недоступность API проверены.
Вывод
Интеграция магазина на 1С-Битрикс с amoCRM окупается тем, что ни одна заявка и ни один заказ не теряются: они автоматически становятся сделками в воронке, менеджер видит их сразу, а руководитель считает выручку по каналам. Но качество этой связки — не в самом факте обмена, а в деталях: дедупликации контактов, нормализации данных, асинхронной очереди и точной карте полей и статусов.
Соберите интеграцию как надёжный сервис, а не как «скрипт, который дёргает API из формы», — с логами, повторами и защитой от дублей. Тогда amoCRM станет честным зеркалом продаж, а не свалкой лидов. А если процессы сложные и меняются, доверьте настройку и сопровождение команде: мы помогаем и на этапе внедрения, и в дальнейшей поддержке интеграций с CRM, включая при необходимости переход на RetailCRM, если бизнесу нужна товарная CRM.
