На сайте появилось сообщение «Заявка отправлена», но менеджер не нашёл её в CRM. Или после повторной отправки возникли две сделки. Чтобы избежать таких ситуаций, недостаточно подключить форму и увидеть одну тестовую запись. Нужно определить, где сохраняется обращение, как подтверждается доставка и что происходит при сбое.
В Гуси-Лебеди мы предлагаем проверять интеграцию сайта с CRM по всему пути заявки. Разберём способы подключения, карту полей, повторы, ошибки и сверку. Пример в статье условный: посетитель запрашивает расчёт, сайт принимает обращение и передаёт его менеджеру через CRM.
Как выбрать способ интеграции сайта с CRM
Интеграция сайта с CRM связывает действия на сайте с объектами и процессами системы учёта клиентов. Это может быть передача заявки, создание сделки, обновление контакта или получение статуса заказа. Сначала опишите нужное поведение, затем выбирайте способ подключения.
- Встроенная CRM-форма. Проверьте поля, оформление, источник обращения и зависимость от внешнего скрипта.
- Модуль CMS. Уточните совместимость с версией сайта, доступные настройки и журнал доставки.
- Коннектор между сервисами. Опишите ограничения, стоимость эксплуатации и действия при сбое самого коннектора.
- Собственная интеграция через API. Согласуйте авторизацию, обработку ошибок, обновления и сопровождение.
Для каждой схемы задайте одинаковые вопросы: где остаётся неотправленное обращение, кто видит ошибку и как повторить доставку? Готовый модуль может оказаться подходящим решением, если его поведение соответствует вашим сценариям. Собственная разработка не становится надёжной автоматически.
В задании на подключение CRM и API-интеграций фиксируйте ожидаемый результат. Пункт «передавать заявки» необходимо раскрыть: какие объекты создавать, как связывать их между собой и кому назначать обработку. Для оценки понадобятся также доступы, ограничения API и описание действующих форм.
Какие данные передавать и как связать объекты
Контакт, компания, обращение и сделка имеют разное назначение. Один клиент может сделать несколько самостоятельных запросов. Поэтому найденный телефон не означает, что новое обращение нужно стереть или присоединить к давно закрытой сделке. Эти правила определяются процессом продаж.
Составьте карту полей: название на сайте, поле CRM, формат, обязательность, источник и правило обновления. Для услуги можно передавать стабильный код справочника, а не только подпись в форме. Если менеджер исправляет данные в CRM, определите, какие из них сайт имеет право обновить позже.
| Поле условной заявки | Назначение | Правило |
|---|---|---|
| request_id | Связь обращения между системами | Не меняется при повторе доставки |
| service_code | Выбранная услуга | Проверяется по справочнику |
| contact_phone | Контакт для связи | Проверяется формат; не доказывает личность |
| source_snapshot | Наблюдаемый источник обращения | Сохраняется на момент заявки |
| crm_id | Связь с созданным объектом | Фиксируется после подтверждения |
Служебные значения проверяйте на сервере. Скрытое поле браузера нельзя считать достоверным только потому, что оно не показано посетителю. Особенно это касается цены, чужого заказа, ответственного сотрудника и статуса сделки.
Правила источников опишите отдельно: первая известная точка контакта, переход перед обращением или несколько полей. Сохраняйте только наблюдаемые данные. Если UTM-метки отсутствуют, не подставляйте рекламную кампанию по догадке. Имена полей и правила обновления закрепите в техническом задании.
Как разделить принятие заявки и доставку в CRM
Если форма ждёт прямого ответа CRM, её работа зависит от доступности внешней системы. При тайм-ауте посетитель может увидеть ошибку, хотя сделка уже создана. Другой вариант: сайт надёжно сохраняет обращение и задание на передачу, а отдельный обработчик доставляет данные.
Для такой схемы согласуйте состояния: принято на сайте, ожидает доставки, подтверждено в CRM, требует разбора. Пользователю сообщайте то, что система действительно знает. «Обращение принято» не означает, что менеджер уже прочитал его.
Запись заявки и задания на отправку не должны расходиться. Например, для реляционной базы можно проектировать их сохранение в одной транзакции. Конкретную реализацию выбирают по инфраструктуре. Если нужен отдельный обработчик, очередь и сверка, это стоит включить в объём backend-разработки и последующего сопровождения.
Предусмотрите владельца недоставленных обращений. Он должен видеть причину, возраст записи и доступное действие. Письмо разработчику без номера заявки и состояния доставки затрудняет разбор. После исправления очередь необходимо проверить, чтобы старые записи не остались незамеченными.
Как отличить повтор доставки от нового обращения
Повтор одного события не должен автоматически создавать новую сделку. Для этого сохраняют неизменный идентификатор обращения и результат обработки. Это основа идемпотентного поведения: повторная обработка того же события не добавляет ещё один бизнес-результат.
Новое обращение того же человека является другой ситуацией. Клиент может запросить расчёт новой услуги или сделать следующий заказ. Правило «такой телефон уже есть, значит заявку игнорируем» способно потерять полезный запрос. Сопоставление контактов и учёт доставки нужно проектировать отдельно.
В документации Битрикс24 по дубликатам описан поиск лидов, контактов и компаний по телефону и почте. Такой поиск помогает выбрать существующий объект, но не заменяет идентификатор события вашего обмена.
Если ответ о создании потерялся, результат неизвестен. Слепой повтор способен создать дубль. Если API поддерживает ключ идемпотентности, применяйте его по контракту. Иначе нужна согласованная схема внешнего идентификатора, сериализации обработки и сверки. Предварительный поиск не гарантирует отсутствие дублей при одновременных запросах или задержке появления объекта в поиске.
Неоднозначный результат должен попадать в разбор, а не скрываться под статусом «успешно». Храните связь обращения и объекта CRM, чтобы специалист мог принять решение, не создавая запись заново наугад.
Что делать с ошибками API и авторизации
Ошибки требуют разных действий. Временный сетевой сбой можно повторять по согласованной политике. Неверное обязательное поле нужно исправить. Ограничение частоты требует контроля скорости отправки, а ошибка доступа проверки полномочий и действующей авторизации.
| Ситуация | Действие | Что контролировать |
|---|---|---|
| Временная недоступность | Ограниченные повторы с увеличением задержки | Возраст ожидающих обращений |
| Превышение лимита | Снизить темп по контракту API | Общую нагрузку обработчиков |
| Неверные данные | Передать запись на исправление | Причину и ответственного |
| Ошибка авторизации | Проверить доступ и обновление токена | Оповещение и восстановление |
| Потеря ответа о создании | Сверить результат до повторного создания | Связь по идентификатору |
Ограничения конкретной CRM проверяйте в официальном контракте. Например, рекомендации amoCRM для API описывают ответы при превышении частоты и проблемах с токеном. Не переносите настройки одного сервиса на другой без проверки.
Секреты интеграции храните в защищённой серверной части. Ключ с правом доступа к клиентской базе не должен находиться в публичном JavaScript. Ограничьте полномочия необходимыми операциями. Входящие уведомления проверяйте предусмотренным сервисом способом.
В журнале сохраняйте идентификатор обращения, попытку, время, категорию ответа и внешний ID. Не записывайте секретный адрес вебхука и полный набор персональных данных без необходимости. Для диагностики важнее возможность связать события.
Как принять интеграцию и находить потери после запуска
Одна успешно созданная сделка подтверждает только один сценарий. В согласованном тестовом окружении проверьте повтор отправки, недоступность CRM, неверное поле, потерю ответа и восстановление доставки. Используйте тестовые записи, которые можно отличить от реальных обращений.
- Сопоставьте значения формы с полями и ответственным в CRM.
- Проверьте, что повтор доставки не создаёт независимое обращение.
- Проверьте, что новый запрос существующего клиента сохраняется согласно правилам.
- Убедитесь, что ошибка видна ответственному и запись можно обработать после исправления.
- Проверьте сохранение источника и связь по идентификатору.
После запуска сверяйте принятые обращения с подтверждёнными связями CRM. Общие количества недостаточны: потеря одних записей и дубли других способны дать одинаковый итоговый счётчик. Сверка по request_id показывает конкретные расхождения.
Следите за возрастом ожидающих событий и записями с неизвестным результатом. Порог оповещения выбирайте под процесс продаж. Отсутствие сообщений об ошибке не доказывает, что все обращения доставлены.
Если интеграция участвует в сквозной аналитике, проверьте статусы и источники отдельно. Рабочая передача заявки ещё не подтверждает корректный отчёт о продажах. Мы предлагаем принимать API-интеграцию по согласованным сценариям и сохранять доказательства проверки, чтобы её можно было сопровождать после запуска.