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

Если заявки с сайта не приходят, почти всегда виноват не один сбой, а разрыв в цепочке «браузер посетителя → серверная обработка → сохранение → уведомление → CRM». Прежде чем что-то менять, нужно понять, на каком именно участке теряется обращение: форма не отправляется, отправляется, но не сохраняется, сохраняется, но письмо не уходит, или уходит, но не доходит до адресата. Ниже — порядок диагностики, таблица решений, сквозной чек-лист и учебный пример.

Задача бизнеса и границы диагностики

Задача звучит просто: посетитель заполнил форму, а менеджер должен получить обращение. Но между этими двумя событиями проходит несколько независимых систем, и каждая может отказать по своей причине. Поэтому первое, что стоит зафиксировать, — что именно считается «заявкой» в вашем случае: запись в базе сайта, письмо на почту, карточка в CRM или сообщение в мессенджере. От этого зависит, где искать потерю. Если считать заявкой только письмо, можно не заметить, что обращения на самом деле сохраняются, а страдает лишь уведомление.

Границы диагностики тоже важно очертить заранее. Техническая проверка отвечает на вопрос «доходит ли обращение и где оно останавливается». Она не отвечает на вопросы «достаточно ли трафика», «убедительно ли предложение» и «правильно ли настроена реклама». Если обращений нет вовсе, а форма технически исправна, это уже задача про спрос и конверсию, а не про доставку заявок. Смешивать эти две задачи в одной проверке нельзя: легко «починить» форму, которая и так работала, и не заметить настоящую причину.

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

Как устроен путь заявки от кнопки до CRM

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

Браузер и валидация

Посетитель заполняет поля, нажимает кнопку, и браузер проверяет данные. Здесь теряются обращения, если обязательное поле скрыто, если маска телефона не принимает введённый формат, если кнопка не срабатывает на мобильном или если сторонний скрипт (капча, аналитика, чат) не загрузился и заблокировал отправку. Внешне это выглядит как «нажал — ничего не произошло». Иногда форма молча не отправляется из-за конфликта двух скриптов на странице, и посетитель даже не понимает, что обращение не ушло.

Серверная обработка

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

Канал уведомлений

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

Передача в CRM

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

Первый шаг: разделить «заявок нет» и «заявки с сайта не приходят»

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

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

Проверка формы в браузере

Начинать удобнее с того, что видит посетитель.

Интерфейс и мобильная версия

Проверьте форму на телефоне и на компьютере: видны ли все поля, работает ли кнопка, появляется ли сообщение об успешной отправке. Часто форма «ломается» только на узких экранах, где кнопку перекрывает баннер или всплывающее окно. Отдельно проверьте, не блокирует ли отправку всплывающее согласие на обработку данных: если его нельзя закрыть или подтвердить, форма остаётся недоступной.

Валидация полей

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

Антиспам и сторонние скрипты

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

Проверка серверной обработки и сохранения

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

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

Почтовые уведомления: почему письма не приходят

Это самый частый участок потерь. Разберём его по шагам.

Настройки почтового события и шаблона

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

Что показывает результат отправки

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

Спам, репутация и доставка наружу

Даже успешно отправленное письмо может не дойти до адресата: его отсекает спам-фильтр получателя или почтовый сервер хостинга не отправляет письма наружу. По наблюдениям, письма с сайта иногда доходят до ящика на хостинге, но не уходят дальше, а отдельные почтовые сервисы фильтруют такие сообщения строже других. Проверяют это так: отправьте тестовое письмо на несколько разных ящиков и посмотрите, куда оно доходит, а куда нет. Если письма не уходят наружу, вопрос решают с администратором хостинга или настраивают отправку через отдельный почтовый сервис. Также стоит проверить, не мешает ли доставке включённое ускорение сайта — в обсуждениях встречается случай, когда отключение CDN возвращало работу писем.

Отправка через отдельный сервис

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

Передача заявок в CRM и сторонние сервисы

Если заявка сохраняется и письмо уходит, но в CRM её нет, ищите на участке интеграции. Проверьте, активны ли ключи доступа, не истёк ли срок их действия, доступен ли сервис получателя. Отдельно убедитесь, что формат передаваемых данных совпадает с ожидаемым: если в CRM изменили обязательное поле, часть заявок может отсекаться на её стороне. Хорошая практика — вести журнал передачи, чтобы видеть, дошла ли конкретная заявка до внешней системы. Без такого журнала спор «мы отправили — мы не получили» решить почти невозможно.

Таблица принятия решения

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

Учебный пример. Условная компания продаёт оборудование, сайт на Битрикс, форма «Запросить расчёт» отправляет письмо менеджеру и создаёт карточку в CRM. Руководитель замечает, что за неделю не пришло ни одной заявки, хотя реклама идёт.

Входные условия: форма с полями «имя», «телефон», «email»; уведомление настроено на почтовый ящик менеджера; заявки должны попадать в CRM. Доступны панель управления сайтом, журнал почтовых событий и тестовый ящик.

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

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

Этот пример показывает главное: «заявки не приходят» — почти всегда не одна причина, а несколько, и искать их нужно по цепочке, а не наугад. Данные компании и количество объектов здесь условные и приведены только для иллюстрации порядка действий.

Как проверить результат и принять работу

После исправлений работу принимают по наблюдаемому результату, а не по словам «должно работать». Ниже — сквозной чек-лист.

• Тестовая заявка отправляется с компьютера и с телефона, кнопка срабатывает, появляется сообщение об успехе.
• Тестовая заявка появляется в списке заявок сайта.
• Письмо-уведомление приходит на основной ящик получателя.
• Письмо приходит минимум на два разных почтовых сервиса.
• В журнале почтовых событий результат отправки — успешный.
• Карточка заявки появляется в CRM или другом внешнем сервисе.
• Тестовые заявки помечены и удалены, чтобы не мешать менеджеру.
• Проверено поведение формы при отключённой капче и при включённой.
• Зафиксировано, кто отвечает за каждый участок цепочки.
• Есть план действий на случай повторного сбоя.

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

Типичные ошибки и ограничения

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

Ограничения тоже нужно учитывать. Диагностика показывает, доходит ли обращение, но не объясняет, почему посетители не заполняют форму. Доставку писем на чужой почтовый сервер нельзя гарантировать полностью: даже при верных настройках фильтры получателя могут отсекать сообщения. Если форма собирает персональные данные, порядок их обработки и хранения стоит сверить с профильным специалистом — техническая проверка не заменяет юридическую.

Какие исходные данные подготовить для оценки

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

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