Настройка форм на Тильде: куда уходят заявки и как перестать их терять

Настройка форм на Тильде кажется делом на пять минут: перетащил блок, указал почту в настройках, опубликовал страницу. На практике я регулярно вижу проекты, где форма годами отправляет заявки на email, который никто не проверяет, или на ящик, у которого сломался домен и письма молча улетают в спам. Разберу, куда Тильда реально отправляет данные из форм, где чаще всего рвётся цепочка и как настроить приём заявок так, чтобы ни одна не потерялась.

Куда Тильда отправляет заявки после отправки формы

По умолчанию у блока формы есть вкладка «Куда отправлять данные» в настройках блока. Там можно включить сразу несколько получателей: email, CRM Тильды (раздел «Заявки» в личном кабинете), Telegram-бот, вебхук на внешний адрес, интеграции через Zapier или Albato, а также передачу цели в Яндекс.Метрику или Google Analytics.

Проблема в том, что галочка «Email» стоит почти у всех сайтов, а остальные каналы часто не включены вообще. Получается одна точка отказа: если почтовый сервер клиента отмечает письма Тильды как спам, если ящик переполнен или если человек, ответственный за заявки, уволился и не оставил доступ, заявки продолжают приходить, просто их никто не видит.

В разделе «Заявки» на Тильде данные хранятся и без подключения почты, но туда мало кто заглядывает регулярно, особенно если сайт ведёт агентство, а заявки должен обрабатывать отдел продаж клиента без доступа к панели Тильды.

Настройка приёма заявок: почта, CRM и телефония

Первое, что проверяю на новом проекте: сколько email-адресов указано в настройках формы и актуальны ли они. Лучше добавить два-три адреса через запятую, включая личный ящик руководителя отдела продаж, а не только общий info@.

Дальше смотрю домен отправителя. Тильда отправляет письма со своего технического адреса, и если у почтового сервиса клиента (особенно корпоративного, на своём домене) настроены жёсткие SPF или DKIM правила, письма от Тильды могут улетать в спам пачками. Отдельно эта проблема проявляется у сайтов на Яндекс 360 и Mail для бизнеса: письма от форм проверяю в первую очередь в папке «Спам», а не в основной, если клиент жалуется, что заявок нет.

Для интеграции с телефонией и CRM у Тильды есть готовые модули: amoCRM, Bitrix24, RetailCRM, Мегаплан. Их хватает для простых сценариев, когда достаточно создать сделку с данными из формы. Как только логика сложнее, например нужно проверить клиента по базе, посчитать стоимость доставки через СДЭК или создать платёж в Т‑Банк эквайринге прямо из формы, готовых блоков уже не хватает, и тут работает кастомный скрипт или вебхук.

Частые причины, по которым заявки не доходят

За несколько лет работы с формами на Тильде я собрал список причин, которые встречаются чаще всего. Свёл их в таблицу, чтобы было проще сверить со своим сайтом.

Один из проектов, с которым разбирался, три недели терял заявки именно из-за спам-фильтра: домен клиента получил низкую репутацию из-за рассылок другого отдела, и все письма от Тильды автоматически улетали в спам. Форма работала исправно, заявки копились в CRM Тильды, но отдел продаж об этом не знал, потому что ориентировался только на почту.

Интеграция форм Тильды с CRM и мессенджерами

Штатные интеграции Тильды закрывают базовый сценарий: заявка попала в форму, ушла в CRM как новая сделка. Для розницы и услуг этого обычно достаточно. Но если нужно, например, сразу считать зону доставки, применять промокод с ограничением по количеству использований или уведомлять менеджера в Telegram через бота на aiogram с деталями заказа, приходится писать кастомный скрипт, который слушает событие отправки формы через Tilda API и обрабатывает данные по своей логике.

Часто такие интеграции собираю через связку: форма отправляет данные на вебхук, n8n принимает их, обогащает информацией (например, статусом клиента из CRM или расчётом доставки), и уже потом раскладывает по нужным каналам, будь то amoCRM, Telegram-канал отдела продаж или таблица для бухгалтерии. Такой подход даёт видимость каждого шага: если заявка потерялась, видно, на каком именно этапе сценария это произошло, а не гадаешь между Тильдой и почтой.

Если нужна именно такая интеграция форм под конкретный процесс продаж, обычно смотрю на это как на доработку форм Тильды под задачу клиента, а не типовую настройку из коробки.

Резервный канал приёма заявок: не полагайтесь на одну точку отказа

После пары случаев с потерянными заявками я взял за правило настраивать минимум два независимых канала на каждом сайте: email плюс Telegram-бот или email плюс запись в CRM с автоматическим уведомлением. Если один канал ляжет, будь то спам-фильтр, сбой почтового сервиса или человеческий фактор, второй продолжит работать.

Для сайтов с большим потоком заявок дополнительно веду лог всех отправок через вебхук в базу данных на сервере в России, а не в Google Sheets или Airtable. Это не только вопрос удобства, но и требование 152-ФЗ по локализации персональных данных: если форма собирает телефон и имя клиента, эти данные должны храниться на серверах в РФ.

Простой чек-лист для проверки резервирования:

• Указано минимум два email получателя из разных почтовых доменов
• Подключено уведомление в Telegram или мессенджер отдела продаж
• Раз в квартал кто-то вручную отправляет тестовую заявку и проверяет, что она дошла всеми каналами
• Вебхук, если используется, логирует ошибки, а не просто откидывает их молча

Смежные настройки форм: промокоды, зоны доставки и валюта

Настройка форм на Тильде редко существует отдельно от остальной логики заказа. Промокоды в Tilda из коробки ограничены: нельзя гибко настроить лимит использований на одного клиента или привязать скидку к сумме заказа, поэтому для интернет-магазинов с активными акциями обычно ставлю кастомный скрипт, который добавляет эти проверки поверх стандартной формы.

То же с зонами доставки: если у клиента доставка зависит от района или расстояния, а не фиксированной суммы, стандартная форма Тильды такую логику не считает, и это тоже дорабатывается отдельно. Для магазинов, которые продают в нескольких валютах или работают с НДС по разным ставкам, аналогично нужна отдельная логика расчёта прямо в форме, а не после оформления заказа.

Часть таких задач уже решена в виде готовых модулей: ограничение промокодов, расчёт зон доставки, конвертер валют и расчёт налогов для Tilda можно посмотреть в библиотеке готовых скриптов для Тильды, если не хочется собирать логику с нуля под конкретный проект.

Частые вопросы

Как проверить, что заявки с Тильды точно доходят?

Отправьте тестовую заявку через саму форму на сайте, а не через админку, и проверьте все каналы: email (включая папку «Спам»), CRM, Telegram, если он подключён. Делать это стоит не разово при запуске сайта, а раз в месяц-два, потому что интеграции с CRM могут отвалиться после смены пароля или истечения токена без явного уведомления.

Почему заявки Тильды попадают в спам?

Чаще всего дело в репутации домена получателя или агрессивных спам-фильтрах корпоративной почты. Тильда отправляет письма со своего технического адреса, и почтовые сервисы иногда помечают такие письма как массовую рассылку. Помогает добавление адреса Тильды в белый список почтового сервиса и параллельная настройка уведомлений в Telegram как резервного канала.

Можно ли настроить отправку заявок в Telegram без программиста?

Да, у Тильды есть встроенная интеграция с Telegram-ботом в настройках блока формы, и подключается она за 5-10 минут через токен бота из BotFather. Для простого уведомления «пришла новая заявка» этого достаточно. Если нужна логика сложнее, например разные боты для разных городов или фильтрация заявок по сумме заказа, тут уже потребуется кастомный скрипт поверх стандартной интеграции.

Что делать, если Тильда перестала отправлять заявки на почту?

Сначала проверьте раздел «Заявки» в личном кабинете Тильды: если данные там есть, форма работает исправно, а проблема в доставке письма. Проверьте адрес получателя на опечатки, папку «Спам» и настройки фильтров почтового сервиса. Если заявок нет и там, скорее всего сломалась сама форма или её интеграция, и стоит проверить настройки блока и подключённые вебхуки.