Разделите три разных события
Посетитель нажал кнопку. Сервер принял обращение. В CRM — системе учёта клиентов — появилась карточка, которую видит ответственный. Это разные события, и каждое требует подтверждения.
Сообщение «Спасибо, заявка отправлена» иногда появляется сразу после нажатия. Посетитель уверен, что компания получила данные, хотя передача могла завершиться ошибкой. Проверьте, на каком основании сайт сообщает об успехе.
Если обращение сначала сохраняется на стороне сайта, а затем передаётся в CRM, статус должен отражать это: заявка принята и ожидает передачи либо уже доставлена. Эти состояния должны быть доступны ответственному за интеграцию.
Проследите путь одной заявки целиком
Создайте согласованное тестовое обращение с узнаваемым обозначением и пройдите весь маршрут. Проверьте телефон, услугу, комментарий, источник, выбранное время и ответственного.
В официальной документации Битрикс24 создание элемента CRM включает проверку прав и обязательных полей. Изменение поля или прав подключения может нарушить прежнюю настройку. Проверять нужно конкретную систему.
Полезно связывать технический идентификатор обращения с идентификатором созданной карточки. Это помогает восстановить путь заявки без поиска по переписке и без записи лишних персональных данных в журналы.
Проверьте результат операции
Запрос может получить ответ сервера и всё равно не выполнить нужное действие. Документация браузерного метода fetch поясняет: ответ с кодом ошибки сам по себе не всегда прерывает выполнение программы. Статус нужно проверить явно.
Затем проверяется результат операции по правилам CRM: создана ли нужная запись, вернулся ли её идентификатор, нет ли сообщения об ошибке. Уведомление менеджеру проверяется отдельно от создания карточки.
Для приёмки попросите показать заявку в рабочей системе и поведение при сбое. Одного скриншота формы с зелёной галочкой недостаточно.
Предусмотрите повторную доставку без дублей
Связь может оборваться после создания карточки, но до получения подтверждения сайтом. Слепой повтор способен создать вторую запись. Запрет повторов может оставить обращение без доставки.
Для каждого отправления нужен устойчивый идентификатор и проверка состояния. Временные ошибки повторяют по согласованным правилам; ошибки полей и прав требуют исправления причины. Когда исход попытки неизвестен, сначала нужно установить, была ли создана запись.
Не считайте любые обращения с одним телефоном дублями: один клиент может оставить две разные заявки. Защита от повторного нажатия и объединение клиентской истории решают разные задачи.
Назначьте владельца процесса
Исправная интеграция не помогает, если карточка попадает в забытую воронку или назначается отсутствующему сотруднику. Согласуйте, кто принимает обращения, когда проверяет их и кто узнаёт о техническом сбое.
После изменения формы, обязательных полей, прав или этапов CRM повторяйте контрольный маршрут. Для критичного потока полезна периодическая тестовая заявка с явной маркировкой: её нельзя смешивать с реальными обращениями в отчётах.
Сравнивайте количество принятых и доставленных заявок, разбирайте расхождения. Храните только нужные данные с согласованными сроками и доступом. Работа интеграции должна оставаться понятной и после передачи проекта.