Сначала выберите способ интеграции
Для популярных CRM используйте штатный коннектор Tilda, если он покрывает задачу. Платформа имеет отдельные интеграции с amoCRM и Битрикс24. Для собственной системы или промежуточного сервиса подходит webhook.
Чем меньше промежуточных звеньев, тем легче диагностировать потерянную заявку.
Путь заявки от формы до CRM
Составьте карту полей
До подключения запишите, что форма отправляет и куда это должно попасть:
| Форма | CRM |
|---|---|
| name | Имя контакта |
| phone | Телефон |
| comment | Комментарий / примечание |
| utm_* | поля источника |
| page_url | страница заявки |
Для нескольких форм добавьте идентификатор формы или услуги. Иначе менеджер увидит новый лид без понимания, откуда он пришел.
Штатная интеграция
Подключите CRM в настройках форм Tilda, авторизуйте нужный аккаунт и выберите приемник данных для конкретной формы. После этого обязательно перепубликуйте страницы и отправьте реальную тестовую заявку.
Не ограничивайтесь уведомлением форма отправлена. Откройте CRM и проверьте каждое поле.
Webhook для собственной логики
Tilda может отправлять данные формы POST-запросом на ваш URL. По инструкции платформы endpoint должен отвечать корректным HTTP-ответом, работать по HTTPS и обрабатывать запрос достаточно быстро; при ошибках предусмотрены повторные попытки. Актуальные детали есть в документации Tilda Webhook.
Webhook удобен, когда нужно нормализовать телефон, дополнить данные, отправить лид в несколько систем или реализовать собственную дедупликацию.
Передавайте источник заявки
Если маркетинг использует UTM, сохраняйте параметры вместе с лидом. Для длинного цикла сделки данные должны пережить переход из аналитики в CRM, иначе через месяц будет невозможно связать продажу с кампанией.
Единая схема UTM описана в статье как размечать рекламные ссылки.
Продумайте дубли
Один пользователь может отправить две формы или сначала позвонить, а затем оставить email. Решите, создает ли CRM новый контакт, новую сделку или обновляет существующий объект. Это бизнес-логика, а не настройка дизайна формы.
Что делать при ошибке доставки
Заявка не должна исчезать бесследно. Используйте резервный приемник данных или уведомление, если это возможно в вашем процессе. На собственной webhook-интеграции логируйте запросы и ответы без лишнего хранения чувствительных данных.
Если endpoint периодически отвечает 500 или таймаутом, исправляйте причину, а не рассчитывайте на повторные попытки как постоянный механизм.
Чек-лист теста
- отправьте форму с десктопа;
- проверьте CRM;
- сверьте телефон, email и комментарий;
- проверьте источник и URL страницы;
- повторите с мобильного;
- проверьте вторую форму сайта;
- отправьте заявку с UTM;
- убедитесь, что менеджер получил уведомление;
- проверьте цель аналитики.
Передавайте только нужные данные
Не собирайте и не отправляйте в CRM поля на всякий случай. Состав формы и дальнейшая обработка должны соответствовать реальному процессу и документам сайта.
Заявка считается доставленной только в конечной системе
У формы есть несколько точек отказа: браузер пользователя, Tilda, приемщик данных, промежуточный webhook, CRM и уведомление менеджеру. Зеленое сообщение на странице подтверждает только часть пути. Для критичных лидов нужен контроль конечной записи.
| Этап | Что логировать или проверять |
|---|---|
| Форма | Успешное клиентское событие без сохранения лишних чувствительных данных |
| Tilda | Факт приема заявки в доступных инструментах проекта |
| Webhook | HTTP-статус, время ответа, идентификатор запроса |
| CRM | Создан правильный контакт или лид, поля не потеряны |
| Уведомление | Ответственный действительно получил сигнал |
Карта полей должна быть контрактом
Для каждой формы храните таблицу source field - destination field - тип - обязательность - пример. Например, phone должен попадать в телефон, а не в комментарий; page_url - в служебное поле; utm_source - в источник лида. Если поле переименовывается на сайте, карта сразу показывает, что нужно обновить в интеграции.
Для нескольких услуг добавьте стабильный идентификатор услуги, а не полагайтесь только на заголовок страницы. Это помогает CRM-автоматизации пережить редакционные изменения сайта.
Проверяйте интеграцию после изменений
Замена формы, клонирование страницы, изменение CRM-воронки или webhook могут нарушить маршрут. Добавьте тест заявки в релизный чек-лист сайта.
Кому должны принадлежать интеграции
CRM, почта и webhook не должны зависеть только от личного аккаунта временного подрядчика. Перед передачей проекта проверьте владельцев интеграций, рабочие токены и доступы. Если сотрудник уйдет, заявки не должны остановиться вместе с его учетной записью.
Отделяйте техническую доставку от качества лида
Если CRM получает спам, это не всегда проблема интеграции. Добавьте подходящую защиту формы, но не ставьте настолько агрессивные фильтры, чтобы терять реальные обращения. Отслеживайте долю спама и источник отдельно.
Как заметить поломку раньше клиента
Для критичной формы полезен регулярный тестовый лид или автоматический мониторинг endpoint. Минимум - назначить ответственного, который сравнивает число заявок в CRM и уведомлениях. Резкое обнуление конверсий при обычном трафике должно становиться сигналом для проверки.
Проверьте типы данных
Телефон лучше передавать как телефон, email - в соответствующее поле, а согласия и служебные признаки - отдельно. Если вся информация склеивается в один комментарий, CRM теряет возможность поиска, дедупликации и автоматизации.
После изменения формы тестируйте карту полей заново
Переименование input или клонирование формы может изменить передаваемый набор данных. Особенно внимательно проверяйте скрытые поля, UTM и идентификатор услуги. Визуально форма при этом может выглядеть совершенно нормально.
Источник истины - реальная заявка в CRM
Красивое сообщение об успехе не подтверждает доставку. Интеграция закончена только после проверки полного пути от браузера до нужной сущности CRM и аналитики.
На проектах с большим числом лид-форм такую схему лучше проектировать вместе с целями аналитики, чтобы CRM и Метрика считали одно и то же действие согласованно.
