Вы настроили форму на Tilda, протестировали — всё работает. Через неделю клиенты жалуются, что вы не отвечаете. Открываете CRM — пусто. Знакомая ситуация? Мы сталкивались с этим десятки раз на проектах вебпоиск.рф. Причина обычно одна: цепочка «форма → CRM» где-то рвётся. Где именно — разберём в статье.
Автор: Григорий Федотов, основатель студии · Обновлено: 28.09.2026
Tilda сама по себе не отправляет заявки в CRM. Она лишь собирает данные и может передать их по вебхуку или через встроенные интеграции. Если этот мост настроен криво, заявки либо не доходят, либо приходят с пустыми полями, либо попадают в спам. Мы покажем, как выстроить надёжный приём заявок и не потерять ни одного лида.
Сразу договоримся о терминах, чтобы дальше не путаться. Вебхук — это HTTP-запрос, который Tilda шлёт на ваш URL, когда посетитель отправил форму. Запрос уходит с серверов Tilda, а не из браузера клиента. Это важно: если вы тестируете форму в режиме превью, вебхук может не уйти или уйти частично. Тестируйте только на опубликованной странице.
Вторая вещь, которую надо понять до настройки: Tilda не ждёт ответа вечно. Если ваш скрипт-приёмник отвечает дольше нескольких секунд, Tilda засчитает это как ошибку. Посетитель увидит галочку «спасибо», а заявка потеряется молча. Тихая потеря — самое опасное. Поэтому в любой схеме нужен дублирующий канал и логи.
Есть три основных пути: встроенные интеграции Tilda, сторонние сервисы-посредники и прямая отправка через вебхук. У каждого свои плюсы и подводные камни.
В настройках блока формы есть раздел «Сервисы». Там можно подключить популярные CRM: Битрикс24, amoCRM, RetailCRM, Salesforce и другие. Выбираете сервис, авторизуетесь, маппите поля — готово. Tilda сама отправляет данные. Это самый простой способ, но есть ограничения. Например, не все CRM представлены, а кастомизация полей ограничена. Если у вас нестандартная воронка, встроенной интеграции может не хватить.
Как это работает под капотом: Tilda хранит OAuth-токен вашей CRM и от её имени создаёт лид или контакт. Токен живёт не вечно и иногда слетает при смене пароля в CRM или отзыве доступа. Заявки в этот момент перестают приходить, а ошибок вам никто не показывает — просто тишина.
Типичная ошибка из практики: клиент полгода принимал заявки через встроенную интеграцию с amoCRM, потом сменил пароль администратора. Токен умер, лиды перестали создаваться. Обнаружили через две недели, когда менеджер заглянул в отчёт. Что делать вместо этого: раз в месяц открывайте настройки блока и смотрите статус подключения. Или сразу ставьте дублирование на почту — тогда провал в CRM заметите по письмам.
Эти ребята работают как универсальный переходник. Tilda отправляет вебхук в Zapier, тот передаёт данные в CRM. Плюс — можно строить сложные цепочки: добавить условие, отправить уведомление в Telegram, создать задачу. Минус — платно и требует времени на настройку. Если у вас много форм и сценариев, это оправдано.
Механика: посредник принимает вебхук, разбирает его по полям и уже своими силами дёргает API CRM. Между отправкой и созданием сделки появляется лаг — обычно секунды, иногда минуты при пиковой нагрузке. Плюс это ещё одно звено, которое может упасть. Если у посредника исчерпался лимит операций на тарифе, он просто перестанет обрабатывать запросы.
Типичная ошибка — рассчитывать на бесплатный тариф при потоке в сотни заявок в месяц. Лимиты кончаются в самый неподходящий момент, обычно в разгар рекламной кампании. Что делать: ставьте алерт на исчерпание квоты, а критичные формы ведите не через посредника, а напрямую.
Самый гибкий метод. Вы настраиваете в Tilda отправку данных на URL, который принимает ваш скрипт или CRM. CRM должна уметь принимать POST-запросы. Например, у Битрикс24 есть входящий вебхук, у amoCRM — тоже. Вы формируете JSON или query-параметры и отправляете. Этот способ требует минимальных знаний программирования, но даёт полный контроль. Мы часто используем его для нестандартных задач.
Здесь данные идут напрямую, без чужих серверов-посредников. Меньше звеньев — меньше точек отказа. Зато вся ответственность за формат и обработку ошибок на вас. Если принимающий скрипт упал, никто не переотправит запрос.
Типичная ошибка — оставить эндпоинт без защиты. URL вебхука утекает, и боты начинают слать туда мусор, засоряя CRM фейковыми лидами. Что делать: добавьте секретный параметр в URL, проверяйте его на приёме, ограничьте частоту запросов с одного IP.
| Метод | Плюсы | Минусы | Кому подходит |
|---|---|---|---|
| Встроенные интеграции Tilda | Быстро, без кода, поддержка популярных CRM | Ограниченный маппинг полей, не все CRM, уязвим к истечению токена | Новичкам, простые формы |
| Сторонние сервисы | Гибкие сценарии, много действий | Платная подписка, задержки, лимиты по тарифу | Сложные воронки, несколько сервисов |
| Прямой вебхук | Полный контроль, бесплатно, нет посредников | Нужны навыки, ручная настройка, защита на вас | Опытным пользователям, кастом |
Разберём процесс на примере прямой отправки через вебхук. Этот метод мы чаще всего используем в вебпоиск.рф, потому что он надёжен и не зависит от сторонних сервисов.
Убедитесь, что ваша CRM принимает входящие вебхуки. В Битрикс24 зайдите в «Разработчикам» → «Другое» → «Входящий вебхук». Создайте вебхук с правами на CRM. Скопируйте URL. В amoCRM аналогично: «Настройки» → «Интеграции» → «Создать интеграцию» → «Вебхук». Получите токен и URL.
Дайте вебхуку минимально необходимые права. Если он создаёт лиды, ему не нужен доступ к задачам и диску. Принцип простой: чем меньше прав, тем меньше ущерб, если URL утечёт. Сразу заведите отдельного пользователя под интеграцию — тогда в истории сделки будет видно, что запись создал робот, а не менеджер.
Типичная ошибка — использовать личный вебхук администратора. Уволился сотрудник, отозвали доступ — интеграция отвалилась. Что делать: технический пользователь с постоянным паролем и своим набором прав.
Добавьте блок формы (например, BF502). В настройках полей оставьте только те, что нужны: имя, телефон, email, комментарий. Не перегружайте. Убедитесь, что у каждого поля есть атрибут name — по нему вы будете маппить данные. Сохраните страницу и опубликуйте.
Имена полей пишите латиницей и без пробелов. `name`, `phone`, `email` — так их проще сопоставлять с полями CRM. Если оставить `Ваше имя` с пробелом, в JSON это превратится в неудобный ключ, и маппинг придётся городить через костыли. Автозаполнение телефона через маску помогает, но будьте готовы к тому, что часть людей введёт номер в свободном формате — принимающая сторона должна это переваривать.
Типичная ошибка — делать все поля обязательными. Каждое лишнее обязательное поле режет конверсию. Что делать: обязательными оставляйте одно-два, остальное — по желанию. Согласие на обработку данных оформляйте отдельным чекбоксом, если того требует политика.
В настройках формы найдите раздел «Отправка данных» → «Вебхук». Вставьте URL вашей CRM. Выберите метод POST. В поле «Данные» можно оставить пустым — Tilda отправит все поля формы. Но лучше явно указать нужные, чтобы не передавать лишнее. Формат — JSON.
Учтите: Tilda шлёт запрос с фиксированного набора серверных IP. Если ваш приёмник фильтрует трафик по белым спискам, эти адреса надо внести заранее. Список меняется, поэтому проверяйте его в справке Tilda перед тем, как закручивать гайки. Иначе получите 403 на всех заявках и снова тишину.
Типичная ошибка — ждать от Tilda подписи запроса. Её нет. Аутентификацию приёма делайте сами — через секретный токен в URL или заголовке. Что делать вместо этого: добавьте параметр вида `?key=длинная_строка` и на приёме сверяйте его.
В CRM создайте сценарий или робота, который ловит вебхук и создаёт сделку. В Битрикс24 это делается через бизнес-процессы или роботов. В amoCRM — через Digital Pipeline. Укажите, какие поля из запроса соответствуют каким полям сделки. Например, name → Имя контакта, phone → Телефон.
Порядок действий: сначала приходит вебхук, CRM разбирает его и создаёт сущность. Если какое-то обязательное поле пустое, сделка может не создаться — и запрос уйдёт в лог ошибок. Поэтому заранее решите, что делать с пустыми значениями: подставлять заглушку или складывать в отдельную папку «неразобранное». В Битрикс24 для этого есть штатная воронка.
Типичная ошибка — в один сценарий запихнуть всё: и создание сделки, и постановку задачи, и письмо клиенту. Упал один шаг — встала вся цепочка. Что делать: разбейте на короткие роботы и свяжите их последовательно, чтобы сбой одного не отменял остальные.
Заполните форму на опубликованной странице. Проверьте, появилась ли сделка в CRM. Если нет — смотрите логи. В Tilda можно включить отладку вебхука в настройках. В CRM проверьте журнал входящих запросов. Часто ошибка в неверном URL или в том, что CRM требует авторизацию.
Правильный тест — это не одна заявка, а серия из пяти-шести с разными данными: пустой телефон, длинное имя, эмодзи в комментарии, латиница в поле имени, отправка из мобильного браузера. Так вы ловите кодировки и валидацию, которые на одном идеальном кейсе не всплывут.
Типичная ошибка — тестировать из админки Tilda. Форма в редакторе ведёт себя иначе, чем на боевой странице. Что делать: только публичная ссылка, желательно с телефона и без входа в аккаунт.
Мы собрали грабли, на которые наступают чаще всего.
Каждую из этих ошибок мы встречали вживую, причём чаще всего в связке: сначала неверный URL, потом выясняется, что и поля не мапятся. Поэтому прогоняйте чек-лист сверху вниз, а не по одному пункту.
Пройдитесь по пунктам перед запуском трафика.
После настройки обязательно протестируйте всю цепочку. Сделайте несколько тестовых заявок с разными данными. Проверьте, как они выглядят в CRM: все ли поля заполнены, нет ли искажений. Если что-то не так, смотрите логи.
В Tilda есть встроенный отладчик вебхуков: в настройках формы включите «Отладка» и посмотрите ответ сервера. В CRM (например, Битрикс24) можно посмотреть журнал входящих вебхуков в разделе «Разработчикам». Если ответ 200 — данные приняты. Если 400 или 500 — ошибка на стороне CRM.
Читать коды ответов полезно не только ради «работает или нет». 400 обычно значит, что вы прислали не то, что ждёт приёмник — не хватает поля, неверный тип, битая кодировка. 401 и 403 — вопросы авторизации: токен слетел или IP не в белом списке. 429 — вас притормаживают по частоте, значит, где-то дублируются запросы. 500 — падает принимающая сторона, тут уже не ваша зона ответственности, но заявку надо сохранить.
Совет: настройте мониторинг. Например, чтобы при ошибке вебхука вам приходило уведомление в Telegram. Это можно сделать через тот же Zapier или простым скриптом.
Ещё один приём, который мы используем на проектах, — «теневой приём». Все заявки параллельно падают в простую таблицу или в отдельный почтовый ящик, независимо от CRM. Стоит недорого, а при разборе инцидентов спасает: видно, что посетитель форму отправил, а в CRM она не доехала. Это же помогает при спорах с клиентом, который уверяет, что оставлял заявку.
Бывает, что всё настроено, но заявки не доходят. Причины могут быть на стороне хостинга Tilda, CRM или сети. Вот план действий.
Если ничего не помогает, обратитесь в поддержку Tilda или CRM. Но в 90% случаев проблема решается проверкой URL и маппинга полей.
Отдельно про лаги. Иногда заявки не теряются, а приходят позже — через минуты или часы. Это происходит при перегрузке посредника или самого приёмника: запросы копятся в очереди и переотправляются с задержкой. Менеджер видит «пусто» и звонит клиенту с опозданием, а тот уже ушёл к конкурентам. Если задержки регулярные — упрощайте схему, убирайте лишние звенья.
Выбор CRM — отдельная головная боль. Вот краткие рекомендации.
Мы в вебпоиск.рф часто комбинируем: Tilda + amoCRM для лидогенерации, Tilda + RetailCRM для e-commerce. Главное — чтобы CRM принимала вебхуки и вы могли настроить поля.
Перед выбором ответьте себе на три вопроса. Сколько человек будет работать с лидами? Если один-два — тяжёлая экосистема избыточна. Нужны ли заказы и склад? Если да, лидовая CRM не подойдёт, берите RetailCRM или аналог. Есть ли свой программист? Если нет, берите то, где интеграций и готовых решений больше.
Отдельно про миграцию. Переезд с одной CRM на другую — это не «нажать кнопочку». История заявок, дубли контактов, потерянные атрибуты — всё это вылезает в самый неподходящий момент. Если планируете переезд, делайте его в спокойный период и с двойным приёмом заявок на первое время.
Когда базовый приём настроен, имеет смысл подумать о росте. Рано или поздно форм станет больше — на разных лендингах, в квизах, в попапах. Держать для каждой отдельный вебхук неудобно, и вы начнёте терять, где что настроено.
Мы решаем это так: один приёмник, который принимает заявки от всех форм, а внутри раскидывает их по нужным воронкам на основе источника. В вебхук Tilda передаём скрытое поле со slug-страницы или utm-метку — по нему и происходит маршрутизация. Такой подход требует чуть больше работы на старте, но окупается, когда проект разрастается.
Второе направление — обратная связь. Мало принять заявку, надо быстро её обработать. Настройте автописьмо клиенту с номером обращения и короткое SLA-уведомление менеджеру. Заявка, на которую не ответили за час, часто уже не заявка.
И третье — регулярный аудит. Раз в квартал прогоняйте чек-лист заново. Интеграции стареют: обновляются API, меняются тарифы, уходят люди, которые всё настраивали. То, что работало полгода назад, может тихо отвалиться вчера. Считайте это техобслуживанием — скучным, но дешевле потерянных клиентов.
Настройка приёма заявок из Tilda в CRM — процесс не сложный, но требует внимания к деталям. Если сделать всё по шагам и протестировать, заявки не будут теряться. Помните: лучше потратить час на настройку, чем потом терять клиентов. Удачи!
Зависит от задач: для простых воронок хватит встроенной CRM Tilda, для командной работы — Битрикс24, amoCRM или RetailCRM. Главное — чтобы CRM умела принимать вебхуки или имела готовый модуль интеграции. Мы обычно смотрим на количество пользователей, нужные отчёты и бюджет.
Да, если использовать готовые интеграции через сервисы вроде Zapier, Make или модули в маркетплейсе Tilda. Но для нестандартных полей или сложной логики всё равно придётся немного поработать с кодом или обратиться к специалисту. Мы в таких случаях настраиваем вебхук вручную — это надёжнее.
Сначала проверьте, проходит ли тестовая заявка: заполните форму и посмотрите, появляется ли запись в CRM. Если нет — проверьте настройки вебхука, права доступа и логи. Часто проблема в неверном URL или в том, что CRM не принимает данные из-за несовпадения полей.
Включите капчу (reCAPTCHA или hCaptcha) в настройках блока формы. Дополнительно можно добавить скрытое поле-ловушку и проверку на стороне сервера. Ещё помогает ограничение по времени заполнения — боты обычно отправляют форму мгновенно.
Да, это полезно как резервный канал. Если интеграция даст сбой, вы хотя бы увидите письмо и сможете вручную занести данные. Настройте отправку на отдельный ящик и добавьте правило в почтовом клиенте, чтобы не терять такие письма.
Оставьте контакт — пришлём расчёт и предложим решение под вашу задачу. Ни к чему не обязывает.
Без навязчивых звонков · Смета бесплатно · Оплата поэтапно по договору
или позвоните: +7 (495) 487-44-70