Проверять нужно весь путь заявки: отправка формы → сохранение данных → передача → карточка CRM → назначение сотрудника. Сообщение «Спасибо» и письмо администратору подтверждают только отдельные части этого пути. Чтобы проверить доставку конкретного обращения, нужны идентификатор, время отправки и ссылка на результат в CRM.
Ниже — протокол для владельца сайта, маркетолога и администратора CRM. Продуктовые примеры относятся к Tilda и amoCRM; для другой платформы проверьте её журналы, правила повторной передачи и срок хранения обращений. Эта инструкция не обещает абсолютного отсутствия потерь: она помогает обнаружить разрыв и проверить восстановление.
Сначала опишите маршрут формы
Составьте список опубликованных форм: основная страница, страницы услуг, всплывающие окна, мобильные варианты и корзина, если она используется. Одинаковый внешний вид не означает одинаковую настройку. Для каждой формы запишите адрес страницы, идентификатор блока, получателя данных, место назначения в CRM и ответственного за исправления.
Выясните, где заявка сохраняется до передачи в CRM. Это может быть хранилище платформы сайта или отдельный обработчик. Если единственное место хранения — карточка CRM, при недоступности CRM восстановление потребует специального решения. Письмо с заявкой тоже нельзя считать гарантированной резервной копией без проверки его доставки и порядка обработки.
В Tilda после подключения сервиса его нужно выбрать в конкретном блоке формы и переопубликовать страницу. При отсутствии заявки в сервисе документация предлагает проверять журнал ошибок. Ошибки форм Tilda.
Как выполнить одну контрольную отправку
- Откройте опубликованную страницу в обычном браузере. Проверьте также телефон, если с него приходят обращения.
- Введите контролируемые контакты команды и уникальную отметку в комментарии, например «Тест доставки 06-01». Это учебное обозначение; не используйте реквизиты случайного клиента.
- Запишите время с часовым поясом, URL страницы, форму и ожидаемое место назначения в CRM.
- Отправьте форму один раз. Зафиксируйте показанный результат и найдите запись в журнале сайта или обработчика.
- Найдите обращение в CRM по тестовому контакту или отметке. Проверьте не только новую сделку, но и существующую карточку, «Неразобранное» либо другую настроенную область.
- Сверьте поля, источник, страницу, ответственного и дальнейшее действие менеджера. Сохраните ссылку на карточку и фактическое время появления.
Допустимую задержку согласуйте заранее с учётом выбранной интеграции. Нельзя считать заявку потерянной только потому, что её нет через секунду, но и бесконечное ожидание не является проверкой. Если установленный срок прошёл, начинайте поиск последней подтверждённой точки маршрута.
Почему заявки не попадают в CRM
Разбирайте один конкретный тест, а не меняйте все настройки одновременно.
- Нет подтверждения приёма на сайте. Проверьте обязательные поля, результат отправки, доступность обработчика и сообщения об ошибке. Не отправляйте форму многократно без фиксации попыток.
- Заявка сохранена, но передача завершилась ошибкой. Запишите текст ошибки. Возможные направления проверки — авторизация, доступность получателя, типы полей и действующие ограничения аккаунта.
- Передача отмечена успешной, но карточка не найдена. Уточните, что именно означает успех: приём промежуточным обработчиком или создание объекта CRM. Проверьте другой этап, ответственного, права просмотра и связь с существующим клиентом.
- Карточка есть, но менеджер её не обрабатывает. Доставка состоялась, однако нужно проверить распределение, доступ и следующий шаг. Эту проблему нельзя исправить повторной отправкой той же заявки.
В справке Tilda отдельно описаны ошибки авторизации amoCRM и несоответствия формата полей. Исправляйте причину по конкретному сообщению, затем повторяйте контролируемый тест. Не меняйте рабочие типы полей только ради исчезновения ошибки без проверки последствий для остальных интеграций. Справочник ошибок передачи.
Как проверить источник и страницу обращения
Согласуйте значения отдельно: страница отправки, название формы, рекламные метки и источник, который используется в отчёте. Страница отправки не обязательно совпадает со страницей первого входа. Источник первого визита и источник текущего обращения тоже могут различаться.
В описании интеграции Tilda с amoCRM указана передача страницы формы в поле REFERER. Но наличие этого поля не подтверждает правильную модель рекламной атрибуции. Подключение форм Tilda к amoCRM.
Сделайте отдельные тесты с заранее заданными UTM-метками и без них. Для перехода между страницами и повторного визита проверьте, какие значения реально сохраняются. Поведение зависит от настроек сайта, хранения меток и браузера; отсутствие метки нельзя автоматически заменять названием последней рекламной кампании.
В протоколе укажите ожидаемое и фактическое значение каждого поля. Если источник поступает в комментарий, а отчёт читает другое поле, данные формально переданы, но аналитика всё равно будет неверной.
Что делать при временной недоступности CRM
Для собственной интеграции рекомендуем разделить надёжное сохранение обращения и его отправку в CRM. Сначала обработчик сохраняет заявку с устойчивым идентификатором, затем передаёт её и фиксирует результат. При временном сбое заявка остаётся в очереди. Конкретную реализацию, защиту доступа и сроки хранения нужно согласовать с ответственным за систему.
Ограниченные повторы платформы не заменяют такую очередь. Например, документация Tilda Webhook требует ответа скрипта за пять секунд и описывает ещё две попытки с интервалом в минуту при неуспехе. Это условие конкретного способа подключения, а не обещание повторять доставку до восстановления CRM. Правила Tilda Webhook.
Ответ обработчика об успешном приёме должен следовать после надёжного сохранения, если используется очередь. Доставку в CRM подтверждайте отдельно. Если CRM создала карточку, но ответ потерялся, повтор не должен создавать ещё одну: используйте сохранённый идентификатор обращения и проверяемое правило повторной обработки. Подробности разобраны в статье о дублях из интеграции.
Ошибку формата или доступа не стоит повторять бесконечно. Её переводят в очередь разбора с уведомлением ответственному. После исправления обращение обрабатывают повторно с тем же идентификатором и проверяют результат.
Какие уведомления о сбое нужны
Назначьте владельца доставки и его заместителя. В уведомлении должны быть идентификатор обращения, форма, время, этап сбоя, краткая ошибка и ссылка на журнал. Не рассылайте полные контактные данные клиента всем участникам технического чата.
Проверяйте не только ошибки отдельных запросов, но и возраст старейшей заявки без подтверждённой доставки. Порог ожидания устанавливают по требованиям бизнеса и возможностям интеграции. Уведомление должно приходить туда, где его увидят и при недоступной CRM.
На тестовой среде либо отдельном согласованном маршруте смоделируйте отказ получателя. Убедитесь, что заявка сохранилась, сообщение о сбое дошло ответственному, а после восстановления появилась ровно одна нужная запись. Не отключайте рабочую CRM ради теста.
Протокол приёмки формы
Для каждой строки сохраните время, ID обращения, ожидаемый результат, фактический результат, ссылку на карточку и исполнителя исправления. «Не проверено» оставляйте отдельным статусом.
| Сценарий | Что подтвердить | Доказательство |
|---|---|---|
| Обычная отправка с компьютера и телефона | Обращение принято и дошло в настроенное место | Журнал приёма, время, карточка CRM |
| Разные формы и страницы | Подключён правильный получатель, различается контекст обращения | Форма, URL, назначенный сотрудник |
| Отправка с метками и без них | Источник заполнен по согласованному правилу | Сравнение ожидаемых и фактических полей |
| Повтор передачи того же обращения | Не появилась лишняя запись | Один ID обращения и результат повторной обработки |
| Новое обращение прежнего клиента | Новый запрос сохранён, история связана по принятой модели | Карточки и связи, а не только совпадение телефона |
| Отказ CRM и восстановление | Данные сохранены, ответственный уведомлён, доставка завершена | Состояния очереди до и после, уведомление, карточка |
После тестов настройте регулярную сверку принятых обращений и подтверждённых результатов. Сравнивайте по идентификаторам, а не только по числу сделок: повторный клиент и повтор доставки — разные случаи. Отсутствие обращений само по себе не доказывает сбой, поэтому полезен периодический контролируемый тест.
С заполненным протоколом можно разобрать стабильность передачи в рамках сопровождения CRM или определить объём интеграции сайта с amoCRM. Результат работы — подтверждённый маршрут, понятная обработка ошибок и проверенное восстановление, а не только успешная отправка одной формы.