Почему не приходят заявки с сайта: причины и пошаговая проверка

На сайте сохраняется посещаемость, работает реклама, пользователи просматривают услуги и товары, но количество обращений внезапно сокращается или заявки исчезают совсем.

Первая реакция — искать проблему в рекламе, SEO, сезонности или снижении спроса. Но причина может находиться на самом сайте: посетители продолжают отправлять формы, однако обращения не сохраняются, не передаются в CRM или не доходят до сотрудников.

Проблема особенно опасна тем, что внешне форма может работать нормально. Пользователь видит сообщение «Заявка успешно отправлена» и уверен, что компания получила его обращение. Менеджеры при этом ничего не видят, а бизнес теряет потенциального клиента.

Разберём, как определить, на каком этапе пропадают заявки, проверить формы, почтовые уведомления, SMTP, Битрикс24, amoCRM и цели аналитики.

Сначала определите: заявки пропали или снизился трафик

Отсутствие обращений не всегда означает техническую неисправность. Сначала нужно понять, продолжают ли пользователи приходить на сайт.

Откройте Яндекс Метрику или другую систему аналитики и сравните два одинаковых периода, например последние семь дней с предыдущей неделей. Проверьте:

• количество посетителей и визитов;
• переходы из поисковых систем;
• посещения из рекламы;
• просмотры основных страниц услуг и товаров;
• количество достижений целей;
• конверсию посетителей в обращение.

Если вместе с заявками снизилась посещаемость, причину следует искать в рекламе, поисковых позициях, сезонности или технической доступности сайта.

Если посещаемость осталась на прежнем уровне, а количество обращений резко сократилось, необходимо проверять формы, аналитику, передачу данных в CRM и доставку уведомлений.

Быстрая диагностика: где могут пропадать заявки

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

По внешним признакам можно приблизительно определить место неисправности:

• кнопка отправки не работает — возможна ошибка JavaScript, валидации или капчи;
• форма показывает ошибку — проблема может находиться в обработчике формы, сервере или подключённом API;
• появляется сообщение об успешной отправке, но заявки нигде нет — обработчик сообщает об успехе, не проверяя фактическое сохранение данных;
• заявка есть в административной панели, но письма нет — нужно проверять почтовое событие, SMTP и доставку;
• письмо приходит, но в CRM ничего не создаётся — вероятна ошибка интеграции с Битрикс24 или amoCRM;
• заявка есть в CRM, но менеджер не получил уведомление — проблема может быть в почте или автоматизации внутри CRM;
• заявки фактически поступают, но аналитика показывает ноль конверсий — неправильно настроены цели Яндекс Метрики.

Как самостоятельно проверить формы на сайте

Шаг 1. Отправьте тестовую заявку

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

Обратите внимание:

• активна ли кнопка отправки;
• показываются ли ошибки при неправильном заполнении полей;
• проходит ли проверка согласия на обработку персональных данных;
• появляется ли сообщение об успешной отправке;
• приходит ли автоматический ответ пользователю;
• появляется ли обращение в административной панели сайта;
• создаётся ли лид или сделка в CRM;
• приходит ли уведомление менеджеру;
• фиксируется ли достижение цели в Яндекс Метрике.

Важно: сообщение «Заявка успешно отправлена» ещё не доказывает, что письмо доставлено или данные переданы в CRM. Оно может означать только то, что сайт получил запрос от браузера.

Шаг 2. Проверьте все формы

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

Отдельно проверьте:

• заказ обратного звонка;
• форму заявки на услугу;
• форму в карточке товара;
• оформление заказа в интернет-магазине;
• форму быстрого заказа;
• форму с прикреплением файла;
• заявку из всплывающего окна;
• формы на посадочных страницах;
• подписку на рассылку;
• переходы в мессенджеры и заказ звонка.

Каждую форму желательно проверить на компьютере и смартфоне, а также в нескольких браузерах. Иногда отправке мешают мобильная вёрстка, блокировщик рекламы, ошибки JavaScript, капча или обязательное поле, которое пользователь не видит.

Шаг 3. Сравните дату последней заявки с изменениями на сайте

Определите, когда именно прекратились обращения. Затем вспомните, что происходило с сайтом в этот период:

• обновлялась CMS или отдельный модуль;
• вносились изменения в шаблон;
• сайт переносили на другой сервер;
• менялась версия PHP;
• перенастраивалась корпоративная почта;
• менялся пароль почтового ящика;
• обновлялись DNS-записи домена;
• изменялась интеграция с CRM;
• подключалась новая капча или защита от спама.

Если заявки прекратились сразу после конкретного изменения, это значительно сужает область поиска.

Шаг 4. Проверьте административную панель и CRM

Если сайт сохраняет заполненные формы в административной панели, проверьте последние записи. Для интернет-магазина также нужно посмотреть список заказов.

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

Нужна помощь с диагностикой?

Не хотите искать проблему самостоятельно?

Проверю все формы сайта, сохранение заявок, отправку писем, SMTP, передачу в Битрикс24 или amoCRM и фиксацию целей в Яндекс Метрике.

Проверить формы и доставку заявок →

Форма показывает успешную отправку, но письма нет

Это одна из самых распространённых ситуаций. Пользователь нажимает кнопку, видит сообщение об успехе, но менеджер не получает уведомление.

Причина в том, что отправка формы и доставка письма — разные этапы. Сайт может успешно принять данные и запустить почтовое событие, но это не означает, что письмо прошло через почтовый сервер и попало в ящик получателя.

Возможные причины:

• сайт не создаёт почтовое событие;
• для события не найден или отключён почтовый шаблон;
• в шаблоне указан неправильный адрес получателя;
• SMTP-сервер отклоняет авторизацию;
• изменился пароль почтового ящика или пароль приложения;
• закончился лимит отправки писем;
• почтовый сервер временно недоступен;
• письмо отклоняется из-за неправильного адреса отправителя;
• сообщение попадает в очередь, но не отправляется;
• принимающий сервер блокирует или отклоняет письмо.

Чтобы определить точную причину, недостаточно несколько раз отправить форму. Нужно проверить создание почтового события и посмотреть ответ SMTP-сервера или записи в почтовом логе.

Заявки есть в административной панели, но нет на почте

Если обращения сохраняются в административной панели, значит пользовательские данные дошли до сайта. Обработчик формы выполнил хотя бы часть своей задачи, поэтому искать проблему в вёрстке или кнопке отправки уже не нужно.

Дальше проверяется цепочка:

1. создалось ли почтовое событие;
2. привязан ли к нему активный почтовый шаблон;
3. правильно ли указан адрес получателя;
4. попало ли письмо в очередь отправки;
5. принял ли его SMTP-сервер;
6. доставлено ли сообщение принимающему серверу;
7. не было ли письмо отправлено в спам.

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

Почему письма с сайта попадают в спам

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

Чаще всего это происходит по следующим причинам:

• письмо отправляется от имени чужого домена;
• адрес в поле From не совпадает с учётной записью SMTP;
• для домена не настроены SPF и DKIM;
• DMARC запрещает обработку писем, не прошедших проверку;
• у IP-адреса сервера плохая репутация;
• с одного адреса отправляется слишком много сообщений;
• в письме присутствуют подозрительные ссылки или вложения;
• письма часто возвращаются из-за несуществующих получателей;
• получатели отмечали предыдущие сообщения как спам.

Отправлять письма от имени посетителя, подставляя его адрес в поле From, не рекомендуется. Безопаснее отправлять уведомление от корпоративного адреса на собственном домене, а email клиента передавать в поле Reply-To.

Проверка SMTP, SPF, DKIM и DMARC

SMTP

SMTP используется для авторизованной отправки писем через почтовый сервис. Во время проверки нужно убедиться, что правильно указаны:

• адрес SMTP-сервера;
• порт подключения;
• тип шифрования;
• имя пользователя;
• пароль или пароль приложения;
• адрес отправителя;
• допустимый объём и частота отправки.

Если SMTP возвращает ошибку, её текст обычно указывает направление поиска: неправильные данные для авторизации, временная блокировка, превышение лимита, запрещённый отправитель или проблема с TLS-соединением.

SPF

SPF — это DNS-запись, которая указывает, какие серверы имеют право отправлять письма от имени домена. Если сервер сайта не разрешён в SPF, почтовые сервисы могут относиться к таким письмам с недоверием.

DKIM

DKIM добавляет к письму цифровую подпись. Принимающий сервер проверяет её с помощью открытого ключа, опубликованного в DNS домена. Корректная подпись подтверждает, что письмо действительно отправлено разрешённым сервисом и не было изменено по дороге.

DMARC

DMARC определяет, что делать с письмами, которые не прошли проверку SPF или DKIM. Слишком строгая политика при неправильной настройке способна привести к отклонению легальных уведомлений с сайта.

Одного наличия записей в DNS недостаточно. Важно, чтобы они соответствовали почтовому сервису, через который сайт фактически отправляет сообщения.

После обновления 1С-Битрикс перестали приходить уведомления

Если проблема появилась после обновления 1С-Битрикс, необходимо проверить не только почтовый сервер, но и работу компонентов, шаблонов и обработчиков событий.

Возможные причины:

• обновился стандартный компонент, а его шаблон содержал устаревшие доработки;
• возникла PHP-ошибка в обработчике формы;
• изменилось поведение AJAX-отправки;
• перестал вызываться пользовательский обработчик события;
• почтовое событие создаётся с неправильными параметрами;
• отключён или удалён почтовый шаблон;
• после обновления изменилась версия PHP или настройки сервера;
• не выполняются агенты или задания cron;
• модуль SMTP оказался несовместим с новой версией;
• ошибка скрывается из-за выключенного журналирования.

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

Если сайт использует доработанные компоненты или нестандартную отправку, может потребоваться доработка сайта на 1С-Битрикс.

Как проверить почтовые события и серверные логи

Почтовое событие содержит данные, на основании которых Битрикс формирует письмо: адрес получателя, тему, содержимое заявки и другие поля.

Во время диагностики необходимо проверить:

• создаётся ли событие после отправки формы;
• соответствует ли его тип нужному почтовому шаблону;
• активен ли шаблон;
• привязан ли шаблон к текущему сайту;
• заполнены ли обязательные поля;
• корректно ли подставляются адреса отправителя и получателя;
• не остаётся ли событие в очереди;
• не возникает ли ошибка во время формирования письма.

Если Битрикс сформировал письмо, дальнейшую судьбу сообщения следует искать в логах почтового сервера. В зависимости от конфигурации это могут быть логи Exim, Postfix, SMTP-модуля или внешнего почтового сервиса.

Логи позволяют увидеть:

• было ли выполнено подключение к SMTP;
• принял ли сервер имя пользователя и пароль;
• какой ответ был получен после отправки;
• не поставлено ли письмо в очередь;
• не вернул ли сервер временную ошибку;
• не отклонил ли получатель адрес отправителя;
• не было ли сообщение возвращено после доставки.

Без логов приходится строить предположения. С логами обычно можно точно определить этап, на котором остановилось письмо.

Если проблема связана не с обработчиком формы, а с конфигурацией PHP, заданиями cron, DNS, SMTP или почтовой службой Exim/Postfix, может потребоваться настройка сервера для сайта. Правильная серверная конфигурация обеспечивает стабильную отправку уведомлений, выполнение фоновых заданий и сохранение технических логов для диагностики.

Письмо приходит, но заявка не создаётся в CRM

Почтовое уведомление и передача данных в CRM часто работают независимо. Поэтому письмо может успешно приходить менеджеру, а лид или сделка в Битрикс24 либо amoCRM не создаётся.

Причиной может быть:

• удалён или заблокирован вебхук;
• истёк срок действия токена доступа;
• изменились права пользователя интеграции;
• переименовано или удалено пользовательское поле;
• в CRM появилось новое обязательное поле;
• неверно указана воронка или стадия сделки;
• CRM отклоняет запрос из-за неправильного формата данных;
• превышен лимит запросов к API;
• ошибка возникает в промежуточном сервисе интеграции;
• данные передаются, но создаются в другом направлении или у другого ответственного.

Во время проверки нужно отправить тестовую заявку и посмотреть ответ API. Если CRM вернула ошибку, её необходимо сохранять в журнале, а не скрывать за сообщением об успешной отправке.

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

Почему нельзя хранить заявки только в электронной почте

Электронное письмо должно быть уведомлением, а не единственным местом хранения обращения. Письмо может попасть в спам, задержаться, быть случайно удалено или не отправиться из-за временной ошибки.

Если данные формы нигде больше не сохраняются, восстановить потерянную заявку будет невозможно.

Минимально надёжная схема выглядит так:

1. сайт принимает и проверяет данные;
2. заявка сохраняется в базе данных или административной панели;
3. данные передаются в CRM;
4. менеджер получает уведомление;
5. результат отправки и ответ CRM записываются в журнал.

Даже если почта или CRM временно недоступны, сохранённую заявку можно отправить повторно после устранения неисправности.

Как организовать резервное сохранение заявок

Чтобы не потерять обращения при сбое одного из сервисов, рекомендуется использовать несколько уровней защиты:

• сохранять каждую заявку в базе данных сайта;
• передавать обращение в Битрикс24 или другую CRM;
• отправлять уведомление на корпоративную почту;
• при необходимости дублировать уведомление в Telegram;
• записывать результат отправки в технический журнал;
• повторять передачу при временной ошибке CRM или SMTP;
• уведомлять ответственного сотрудника о сбоях интеграции.

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

Как настроить автоматический мониторинг форм

Ручная проверка помогает найти уже возникшую проблему, но не защищает от повторного сбоя. Если сайт регулярно получает заявки, работоспособность ключевых форм желательно контролировать автоматически.

Система мониторинга может по расписанию:

• открывать нужную страницу;
• заполнять специальную тестовую форму;
• проверять ответ сервера;
• убеждаться, что запись появилась в базе сайта;
• контролировать передачу данных в CRM;
• проверять доставку уведомления;
• сообщать об ошибке в Telegram или по резервной почте.

Для тестовых обращений лучше использовать отдельный адрес и специальную метку. Это позволит автоматически исключать их из аналитики и не засорять рабочую воронку CRM.

Кроме форм, полезно контролировать доступность сайта, срок действия SSL-сертификата, ошибки сервера и выполнение фоновых заданий.

Как избежать потери заявок в будущем

Проверять формы только после жалобы клиента — ненадёжный подход. Контроль должен выполняться регулярно и после каждого существенного изменения на сайте.

Рекомендуется:

• тестировать формы после обновления CMS, шаблона и модулей;
• проверять отправку после переноса сайта или изменения версии PHP;
• контролировать срок действия паролей и токенов интеграций;
• проверять SPF, DKIM и DMARC после изменения почтового сервиса;
• хранить заявки в административной панели или CRM;
• настроить резервные уведомления;
• вести журналы ошибок SMTP и API;
• отслеживать резкое снижение конверсий в Яндекс Метрике;
• периодически проводить аудит сайта;
• назначить сотрудника, который контролирует получение и обработку обращений.

Чек-лист: что проверить, если перестали приходить заявки

1. Сравнить посещаемость и конверсию с предыдущим периодом.
2. Отправить тестовые заявки из всех основных форм.
3. Проверить формы на компьютере и смартфоне.
4. Убедиться, что обращения сохраняются в административной панели.
5. Проверить создание лидов или сделок в CRM.
6. Посмотреть достижение целей в Яндекс Метрике.
7. Проверить папку «Спам» и правила обработки входящих писем.
8. Проверить почтовые события и шаблоны.
9. Проверить подключение к SMTP и пароль приложения.
10. Посмотреть серверные почтовые логи.
11. Проверить SPF, DKIM и DMARC.
12. Сопоставить дату сбоя с обновлениями и изменениями на сайте.
13. Настроить резервное сохранение заявок.
14. Подключить автоматический мониторинг ключевых форм.

Итоги

Если с сайта перестали приходить заявки, не стоит сразу увеличивать рекламный бюджет или полностью менять продвижение. Сначала нужно определить, действительно ли снизилось количество обращений или сайт перестал их принимать и передавать.

Проверьте всю цепочку: форму, сохранение данных, почтовые события, SMTP, доставку письма, интеграцию с CRM и цели аналитики. Сообщение об успешной отправке на сайте не гарантирует, что менеджер получил обращение.

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