За несколько лет разработки я разбирал десятки сайтов, где владелец жалуется: «не приходят заявки с сайта», хотя трафик есть, форма визуально отправляется, а письмо или лид в CRM так и не появляется. Причины почти всегда лежат в трёх зонах: сама форма и её скрипт, канал доставки - почта, Telegram, CRM, и фильтры, которые режут письма или сообщения как спам. Разберу по порядку, что чаще всего ломается на практике, и как проверить это за 15-20 минут, не дожидаясь, пока разработчик найдёт время.
Форма отправляется, а заявка не доходит: где рвётся цепочка
Первое, что проверяю на любом сайте с жалобой на пропавшие заявки - консоль браузера. Открываю форму, нажимаю F12, отправляю тестовую заявку и смотрю на ошибки красным текстом при сабмите.
На Tilda частая картина: клиент когда-то добавил кастомный скрипт для маски телефона, потом верстальщик добавил ещё один для валидации email на том же блоке, и они конфликтуют. Событие submit перехватывается дважды, форма показывает «Спасибо, заявка принята», а реальный POST-запрос до сервера Tilda не долетает - обработчик до него просто не доходит из-за ошибки в первом скрипте. Такие вещи чинятся быстро, но требуют разбора конкретного кода блока, а не общих советов.
На WordPress похожая история с плагинами форм: если на странице одновременно работают Contact Form 7 и форма из конструктора страниц, либо тема переопределяет обработчик отправки через свой JS, форма может визуально сбрасываться после клика, но AJAX-запрос вообще не уходит. Проверяется так же - консолью и вкладкой Network, где виден (или не виден) исходящий запрос.
Отдельно ловил случаи, когда форма отправляет данные на чужой домен (например, кастомный обработчик на отдельном сервере), а на сервере не настроены CORS-заголовки - браузер молча блокирует запрос, в консоли ошибка вида Blocked by CORS policy, пользователь её не видит.
Заявка ушла с сервера, но потерялась на почте
Если с формой всё в порядке и запрос доходит до сервера, следующая точка потери - доставка письма. Стандартная функция mail() на большинстве хостингов работает без гарантий: письмо уходит с IP хостинга, у которого нет настроенных SPF, DKIM и DMARC записей под домен сайта, и почтовые сервисы просто складывают его в спам или отклоняют вовсе.
По моим наблюдениям, из десяти сайтов, где уведомления идут через встроенную mail() без дополнительной настройки, три-четыре теряют часть писем уже в первый месяц - обычно это письма на корпоративные ящики с более строгими фильтрами, а не на обычную почту.
Лечится переводом отправки на нормальный SMTP с прописанными записями для домена - я обычно настраиваю это через Яндекс 360 или почтовый сервис клиента, если он уже есть, плюс проверяю DMARC-отчёты через пару недель, чтобы убедиться, что письма реально долетают, а не просто «отправлены» по логам сайта.
Ещё один частый случай - письмо доходит, но фильтр корпоративной почты клиента режет его как спам из-за формулировки темы или ссылок в теле письма. Проверяю это отправкой тестовой заявки на несколько разных почтовых сервисов сразу - если хотя бы на одном письмо падает в спам, разница обычно в настройках DKIM, а не в содержании письма.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Интеграции с CRM, эквайрингом и доставкой: где рвётся Tilda, WooCommerce, Т‑Банк и СДЭК
Когда форма и почта работают, а заявки всё равно не доходят до менеджера, смотрю на связку с CRM и внешними сервисами. Тут потери чаще всего на стороне вебхуков.
Типичный случай на Tilda - вебхук в AmoCRM или Bitrix24 настроен, но при смене токена доступа или истечении срока его действия перестаёт срабатывать без единого уведомления клиенту: заявки продолжают собираться в форме Tilda, но в CRM не попадают.
С эквайрингом Т‑Банка похожая логика: если сервер клиента живёт на просроченном SSL-сертификате или системное время сбилось на несколько минут, подпись callback-запроса не совпадает с ожидаемой, и уведомление об оплате отклоняется. Заказ в базе висит как неоплаченный, хотя деньги списаны, - менеджер его просто не видит в списке новых заявок.
На WooCommerce разбирался с пропажей примерно 15% заказов на одном интернет-магазине - причина оказалась в виджете расчёта доставки СДЭК: обращение к API занимало 8-10 секунд, часть покупателей закрывала вкладку оформления, не дождавшись расчёта стоимости, и заявка просто не создавалась. Решили заменой виджета на асинхронный расчёт с кэшированием тарифов по популярным городам.
Слишком жёсткая защита от ботов режет реальных клиентов
Отдельная категория потерь - перегретые настройки антиспам-защиты. Если капча требует пройти проверку прежде, чем форма отправится, а сама капча не грузится из-за блокировки скрипта корпоративным фаерволом клиента, человек просто уходит - и такая заявка никогда не появится в статистике, потому что до сервера она не доехала вообще.
Частая ошибка - жёсткий лимит запросов с одного IP-адреса. Если в офисе компании-клиента десять сотрудников сидят за одним внешним IP и кто-то из них случайно отправил форму дважды, лимит может временно заблокировать весь офис, включая реальных заказчиков, которые заходят с той же сети.
Вместо агрессивной капчи на каждый чих обычно ставлю скрытое honeypot-поле - невидимое пользователю поле формы, которое боты заполняют автоматически, а живой посетитель никогда не видит и не трогает. Плюс разумный лимит по IP с окном в несколько минут, а не жёсткую блокировку по факту второго запроса. Такая связка отсекает автоматический спам и не спотыкает живых людей на лишнем шаге.
Где чаще всего теряются заявки: сводная таблица по каналам
| Канал | Типичная причина потери | Как быстро проверить |
|---|---|---|
| Форма на сайте (Tilda, WordPress) | Конфликт скриптов, невалидный action, ошибка в обработчике | Тестовая отправка + консоль браузера (F12) |
| Email-уведомление | Нет SPF/DKIM/DMARC, письмо в спаме | Отправить тестовое письмо на 2-3 разных почтовых сервиса |
| CRM (AmoCRM, Bitrix24) | Просроченный токен, таймаут вебхука | Логи входящих вебхуков в самой CRM |
| Эквайринг (Т‑Банк и другие) | Несовпадение подписи callback, просроченный SSL | Тестовый платёж + лог callback-запроса |
| Доставка (СДЭК) | Долгий ответ API виджета расчёта | Замер времени ответа виджета в Network |
| Telegram-бот приёма заявок | Бот заблокирован пользователем, упал воркер aiogram | Логи бота + ручная команда /start |
Как проверить, что заявки правда теряются, а не просто нет трафика
Перед тем как что-то чинить, стоит убедиться, что проблема именно в потере заявок, а не в падении посетителей. Порядок действий, который использую сам:
- Ставлю цель в Яндекс.Метрике на клик по кнопке отправки формы - если цель срабатывает регулярно, а заявок в почте или CRM нет, значит теряются они уже после клика, на этапе доставки.
- Сверяю число сработавших целей с числом реальных лидов в CRM за неделю - если расхождение больше 10-15%, где-то в цепочке рвётся.
- Отправляю тестовую заявку сам себе минимум раз в неделю с разных устройств и браузеров - так ловятся регрессии после обновления темы, плагина или блока Tilda.
- Дублирую канал приёма - например, через Telegram-бота на aiogram, который параллельно с письмом кидает заявку в рабочий чат отдела продаж. Даже если письмо потеряется в спаме, заявка не пропадёт целиком.
Для дублирования и логирования заявок обычно собираю сценарий в n8n: вебхук с формы одновременно уходит на почту, в Telegram-чат и в таблицу на своём сервере - без иностранных облаков, если в заявке есть телефон и имя клиента. Часть таких сценариев уже готова и адаптируется под конкретную CRM за пару часов - можно посмотреть в библиотеке готовых скриптов и не собирать логику логирования лидов с нуля.
Как настроить приём заявок так, чтобы они больше не терялись
Когда причина найдена, дальше идёт обычная работа по устранению конкретной точки отказа:
- Развести конфликтующие скрипты форм на Tilda - простая правка блока стоит от 3 000 ₽, если проблема локализована в одном месте.
- Настроить SPF, DKIM и DMARC для домена и перевести отправку уведомлений на нормальный SMTP - обычно закрывается в рамках консультации или небольшой доработки.
- Продублировать канал приёма через Telegram-бота на aiogram - разработка от 30 000 ₽, либо через сценарий автоматизации в n8n - от 25 000 ₽.
- Переписать или починить интеграцию с CRM, эквайрингом и доставкой - комплексная интеграция для Tilda от 40 000 ₽, для кастомного бэкенда на Laravel - от 100 000 ₽.
- Настроить простой мониторинг: если за день при обычном трафике заявок ноль, алерт в Telegram должен прийти сразу, а не через неделю, когда клиент сам заметит тишину.
Если непонятно, с чего начать разбор именно в вашем случае, аудит формы, почты и интеграций на созвоне обычно находит причину за одну встречу - это можно сделать через консультацию.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Как понять, что заявки теряются, а не просто упал трафик?
Сравните данные Метрики с реальными заявками: поставьте цель на клик по кнопке отправки формы. Если цель срабатывает стабильно, а заявок в почте или CRM нет - теряются они уже после клика, на этапе доставки, а не на этапе привлечения посетителей.
Может ли блокировщик рекламы в браузере клиента мешать отправке формы?
Да, такое встречается. Некоторые блокировщики режут скрипты аналитики и заодно ломают обработчик формы, если оба подключены с одного домена или через один и тот же трекер. Проверяется просто - отправкой тестовой заявки с отключённым блокировщиком и со включённым для сравнения.
Стоит ли убирать капчу с формы, если из-за неё уходят реальные клиенты?
Полностью убирать не обязательно. Обычно эффективнее заменить агрессивную капчу на скрытое honeypot-поле и разумный лимит запросов с одного IP-адреса - так автоматический спам отсекается, а живой посетитель не спотыкается о лишний шаг перед отправкой.
Как быстро проверить, что письма с заявками не попадают в спам?
Отправьте тестовую заявку на несколько разных почтовых ящиков - обычную почту и корпоративную, если она есть. Если письмо оказалось в папке «Спам» хотя бы на одном сервисе, скорее всего не настроены SPF и DKIM для домена, и часть реальных заявок теряется точно так же.