Посетитель видит сообщение об успешной отправке формы, а менеджер не находит заявку. Повторное подключение всех сервисов наугад затрудняет диагностику: исходное состояние теряется, причина остается неизвестной.
Проверяйте путь последовательно: опубликованная форма → прием данных на стороне сайта → отправка в интеграцию → запись в amoCRM → доступ ответственного. На каждом участке нужно отдельное подтверждение. Так можно отличить проблему формы от ошибки доступа или поиска.
Создайте один узнаваемый тест
Используйте согласованный тестовый контакт и уникальную фразу в описании, например «Проверка формы, сценарий А». Запишите время отправки и адрес страницы. Проверяйте опубликованную страницу, а не только редактор: настройки могли сохраниться без публикации.
Не отправляйте десятки повторов подряд. Одна прослеживаемая заявка полезнее множества одинаковых карточек. Если тест затрагивает рабочую CRM, заранее обозначьте его сотрудникам и не используйте случайные чужие телефоны.
Проверьте подключение именно этой формы
Убедитесь, что сервис amoCRM подключен в настройках сайта, выбран в нужном блоке формы и изменения опубликованы. Сверьте аккаунт, воронку и ответственного. Порядок подключения и обновления старого способа авторизации описан в инструкции Tilda.
Если соединение недавно меняли, не передавайте коды доступа в переписку или публичные журналы. Проверку авторизации выполняет уполномоченный администратор через предусмотренный сервисом интерфейс.
Локализуйте ошибку
| Наблюдение | Что проверить следующим |
|---|---|
| Форма не подтверждает отправку | Обязательные поля, ошибку браузера, доступность страницы |
| Данные есть на стороне сайта, но нет результата интеграции | Выбранный приемник и ошибку отправки |
| Запись найдена администратором | Этап, ответственного и права менеджера |
| Сделка есть, контакт пустой | Имена полей и их соответствие |
| Заявка есть, источник потерян | Путь UTM и правила записи атрибуции |
Эта таблица — порядок диагностики, а не утверждение о единственной причине каждого симптома. Например, заявку могли создать в другом аккаунте или затем изменить автоматизацией.
Учебный пример: проблема оказалась в маршруте
На лендинге две формы. Верхняя отправляет данные в amoCRM, нижняя сохранила старый набор приемников. Проверка верхней формы проходит, и команда считает интеграцию исправной. Клиенты продолжают пользоваться нижней.
Чтобы найти такую ошибку, составьте список всех форм и проверьте каждую отдельно. У результата должен быть адрес страницы и конкретный блок. Общая отметка «сайт проверен» не позволяет воспроизвести проверку.
Проверьте содержимое и повтор
Откройте полученную запись и сравните имя, контакт и описание задачи с исходной отправкой. Затем проверьте пять меток: utm_source, utm_medium, utm_campaign, utm_term, utm_content. Если человек перешел между страницами перед отправкой, исходная атрибуция не должна бесконтрольно заменяться внутренним переходом.
Повтор технического события и новый заказ — разные случаи. Для интеграции необходимо согласовать правило распознавания повторов. Простое объединение всех заявок по телефону может скрыть отдельные продажи. Подробнее — в разборе дублей сделок.
Когда подключение считается проверенным
Если нужна общая карта каналов, начните с маршрута заявки до менеджера.
Разобрать потерю заявок
Укажите адрес формы, время последнего замеченного сбоя и ожидаемый результат. Обсудим диагностику интеграции Tilda и amoCRM. Клиентские данные и доступы через форму обращения отправлять не нужно.