Интеграция сайта с CRM: как проверить, что заявки доходят
Neaptide · 7 сентября 2026 г. · 6 мин чтения
Как проверить интеграцию сайта с CRM: передачу полей и источника заявки, повторные отправки и работу при сбоях. Учебный пример и список проверок перед запуском.
В этой статье
Сообщение «Спасибо, заявка отправлена» не подтверждает, что обращение появилось в CRM. Перед приёмкой сайта проверьте весь процесс: заявка сохранилась, в CRM появилась запись, назначен ответственный менеджер. Если обработка остановилась, сотрудник, который следит за интеграцией, должен видеть причину сбоя.
Интеграция передаёт данные из формы сайта в CRM и выполняет согласованные действия: создаёт обращение, связывает его с контактом и назначает сотрудника. Для этого можно использовать форму самой CRM, модуль системы управления сайтом или собственное подключение через API. Способ зависит от того, как должны обрабатываться ваши заявки.
Договоритесь, что значит «заявка принята»
Сайт сохранил обращение, CRM подтвердила запись, менеджер получил задачу — это три разных этапа. Письмо или уведомление в Telegram может дополнять этот процесс, но не доказывает, что запись в CRM создана.
Если CRM временно недоступна, сайт может принять заявку в надёжное хранилище для последующей доставки. Тогда посетителю уместно сообщить, что обращение получено. Если сохранить его не удалось, показывать успех нельзя: нужен понятный способ повторить попытку или связаться иначе. Не обещайте конкретный срок ответа, пока он не согласован с отделом продаж.
Когда достаточно готового подключения
Сначала проверьте форму самой CRM или готовый модуль для вашей CMS. Если они передают нужные поля, направляют заявки нужным сотрудникам и восстанавливают отправку после ошибок, отдельная разработка может не понадобиться. Попросите показать эти возможности на тестовых заявках.
Очередь позволяет сначала сохранить обращение, а обработать его позже, например после восстановления CRM. При этом кто-то должен следить за накопившимися заявками и ошибками. Для небольшого стабильного потока отдельный сервис очередей может быть избыточным. Обсуждайте с разработчиком ожидаемую работу системы и стоимость её обслуживания.
Какие данные передавать вместе с телефоном
Составьте таблицу: поле формы, данные, которые добавляет сайт, и соответствующее поле в CRM. Обычно передают текст обращения, выбранную услугу, адрес страницы, идентификатор формы, время отправки и доступные сведения об источнике перехода. Проверьте обязательные поля и допустимые значения в CRM: произвольный текст из формы может не подходить для поля с фиксированным списком вариантов.
Решите, какой источник перехода сохранять: первый известный, относящийся к текущему обращению или оба. Отсутствие UTM-меток не доказывает прямой заход на сайт — источник может быть просто неизвестен. Это нужно честно отражать в отчёте.
Разделите данные для менеджера и технические сведения для поиска ошибок. Ключи доступа к CRM должны храниться на сервере. Журнал ошибок не должен быть доступен всем сотрудникам, особенно если в нём есть данные клиентов.
Повторная доставка и новый запрос — разные случаи
Рассмотрим учебный пример. Сайт сохранил обращение S-104, а CRM создала для него запись C-208. Но подтверждение от CRM не дошло, и сайт зафиксировал тайм-аут — истечение времени ожидания ответа. Если просто повторить команду создания записи, в CRM может появиться дубль.
Для повторной отправки используйте тот же идентификатор обращения. Способ защиты от дублей зависит от API конкретной CRM. Это может быть встроенная идемпотентность — обработка повторных запросов как одного действия — или отдельно разработанный механизм сопоставления записей. Простого поиска перед созданием недостаточно: два запроса могут прийти одновременно. Тайм-аут также не означает, что CRM не успела сохранить данные.
Если на следующий день тот же клиент просит рассчитать другую услугу, это уже новое обращение S-105. Его можно связать с существующим контактом, но содержание запроса нужно сохранить по правилам отдела продаж. Удаляя все обращения с одинаковым телефоном как дубли, вы потеряете часть реальных заявок.
Проверьте интеграцию при сбоях
Пройдите сценарии из таблицы на тестовой версии сайта для каждой формы, в том числе во всплывающих окнах и на других языках. Записывайте идентификатор заявки и результат: это поможет проследить одно обращение во всех системах. Таблица описывает ожидаемое поведение, а не результаты испытаний конкретной CRM.
| Сценарий | Что проверить |
|---|---|
| Обычная заявка | Верные поля, источник, карточка и ответственный. |
| CRM временно недоступна | Заявка сохранена; статус ожидания виден; доставка возобновляется. |
| Тайм-аут после записи | Повтор не создаёт второе обращение; результат можно сверить по ID. |
| Неверное обязательное поле | Ошибка видна оператору; бесконечных повторов без исправления нет. |
| Новый запрос с тем же телефоном | Содержание нового запроса сохранено по согласованному правилу. |
| Нет UTM | Неизвестный источник не заменён придуманной кампанией. |
Получите инструкции по контролю и восстановлению работы
При передаче проекта запросите таблицу соответствия полей, правила обработки повторных обращений и инструкцию по просмотру ошибок. Назначьте ответственного за сбои и согласуйте, как быстро заявки должны доходить до CRM. Попросите также показать, как после исправления ошибки возобновить обработку, не создавая дубли.
Количество новых сделок не всегда равно количеству принятых заявок: часть обращений добавляют к существующим контактам или сделкам. Сверяйте заявки по идентификаторам и статусам доставки, отдельно учитывая тесты, спам и отложенную обработку. События аналитики «нажал отправить» для такой проверки недостаточно.
Чтобы обсудить интеграцию с Neaptide в рамках веб-проекта, пришлите адрес сайта, название CRM, список форм и пример нужной карточки без персональных данных. Опишите правила повторных обращений и укажите сотрудника отдела продаж, который будет проверять результат. Эти сведения помогут оценить объём работ.