Если не приходят заявки с сайта, сначала нужно отделить отсутствие обращений от сбоя доставки. Рабочая страница и кнопка «Отправить» не доказывают, что письмо дошло до почты или обращение появилось в CRM. Даже сообщение «Спасибо, заявка отправлена» может показывать лишь результат работы интерфейса.
Ниже — проверка одного контрольного обращения от формы до сотрудника. Она помогает найти участок, на котором теряется передача. Если недоступен весь сайт, начать лучше с проверки домена, сертификата и хостинга.
Подготовьте одно безопасное контрольное обращение
Назначьте человека, который отправляет тест, и сотрудника, который проверяет получение. Заранее выясните, куда должна приходить именно эта форма: в общий ящик, конкретному менеджеру, в CRM или сразу в несколько мест. Форма в подвале и форма на странице услуги могут иметь разные настройки.
Для учебного примера используем метку B40-CHECK-01 и текст «Контрольная проверка формы. Это тестовое обращение, отвечать клиенту не нужно». В реальной проверке выберите свою уникальную метку. Не используйте данные настоящего клиента.
Если обязательны телефон или почта, берите только согласованные контакты компании, которыми вы управляете. Случайный номер или выдуманный адрес могут принадлежать постороннему человеку. До отправки согласуйте обработку теста: он не должен запускать нежелательный звонок, рассылку или другие действия автоматизации.
Зафиксируйте:
- время отправки с часовым поясом;
- страницу и расположение формы;
- устройство и браузер;
- контрольную метку;
- ожидаемого получателя и канал;
- сообщение, которое показал сайт после нажатия кнопки.
Отправьте форму один раз. Если она зависла, не нажимайте кнопку многократно: сначала проверьте, не было ли обращение уже принято. Повтор может создать дубликат, даже когда браузер не получил ответ.
Проверка на тестовой копии сайта полезна для логики формы, но не подтверждает доставку в рабочий ящик. У копии могут быть другие настройки почты, очереди и CRM. Для проверки рабочего маршрута нужен согласованный единичный тест на действующем сайте.
Ищите последнее подтверждённое действие
Не у каждого сайта есть очередь или CRM. Выпишите фактический маршрут вашей формы и проверяйте только его. Почта и CRM могут быть независимыми ветками: успех одной не подтверждает успех другой.
| Участок | Что подтверждает прохождение | Что ещё не доказано |
|---|---|---|
| Браузер | Запрос формы появился в сетевом журнале | Сервер принял и сохранил обращение |
| Приложение | Найдены обработка запроса и результат сохранения либо передачи | Фоновая задача выполнилась |
| Очередь, если используется | Найдены задача и результат её выполнения | Адресат получил письмо или запись CRM |
| Почтовая отправка | Зафиксирован ответ почтового сервера или сервиса | Письмо находится во входящих сотрудника |
| CRM, если используется | Получен идентификатор и найдена соответствующая запись | Ответственный видит её в своём рабочем списке |
| Сотрудник | Подтвердил получение именно контрольного обращения | Остальные формы и маршруты также работают |
Если информации об этапе нет, это неопределённость, а не доказательство ошибки именно там. Запись «письмо сформировано» тоже не равна записи «передано почтовому серверу».
Браузер: кнопка нажата, а запрос был?
При проверке со специалистом откройте инструменты разработчика и вкладку Network до отправки. В ней видны сетевые запросы, их HTTP-статусы и ответы. Для обычной формы запрос может быть переходом страницы, для формы с JavaScript — отдельным запросом Fetch/XHR.
Если запрос не появился, проверьте видимые ошибки обязательных полей и работу кнопки. Специалист также смотрит ошибки JavaScript. Полезно записать конкретное действие: например, «после заполнения обязательных полей кнопка остаётся неактивной», а не просто «форма сломалась». Вопросы состава полей и подсказок разобраны отдельно в статье о понятной форме заявки.
Если запрос появился, нужно изучить статус и содержимое ответа. В JavaScript вызов fetch не считает любой ответ сервера успешной обработкой: он может завершиться получением ответа с HTTP-ошибкой. Код формы должен проверять результат, прежде чем показывать успех. Возможен и обратный случай: сервер принял обращение, но браузер не смог обработать ответ.
Не отключайте защиту формы или проверку обязательных полей ради успешного теста. Это изменит проверяемый сценарий. Снимок экрана с видимым сообщением обычно полезнее владельцу, чем самостоятельное редактирование запросов.
Сервер: запрос дошёл, но что сделало приложение?
Специалист ищет контрольную метку, время и идентификатор запроса в журналах приложения. Нужно установить, какой обработчик сработал, прошла ли проверка данных и чем закончилась передача дальше. Факт открытия страницы в журнале веб-сервера не отвечает на эти вопросы.
Причина может быть в настройках адресата, ошибке обработчика или отклонённых данных. Если форма отвечает общей фразой об успехе даже после сбоя, необходимо исправить и сам сбой, и неверное сообщение. Иначе владелец продолжит получать ложный сигнал о работоспособности.
Отдельно спросите, сохраняет ли сайт обращение до отправки уведомления. Если единственная копия существует только в письме, при недоступной почте может не остаться записи для повторной обработки. Сохранение обращения и учёт результата доставки — возможная доработка, состав которой определяют после изучения сайта.
Очередь: задача записана, но выполнена ли она?
Некоторые приложения передают письмо или обращение в CRM через очередь — список задач, которые выполняются отдельным фоновым процессом. Ответ пользователю может появиться раньше результата этой работы.
Например, в Laravel специалист проверяет, запущен ли обработчик нужного подключения и нужной очереди, нет ли задержки или завершившихся с ошибкой задач. Работники очереди могут быть долгоживущими процессами; после выпуска изменений важно проверить, используют ли они актуальный код. Наличие процесса само по себе не доказывает, что он обрабатывает именно очередь заявок.
Для контрольного обращения нужны идентификатор задачи, её состояние и результат попытки. Пароли подключения и содержимое всех задач владельцу для этого не требуются.
Не просите «повторить всю очередь» без разбора. Некоторые задачи могли уже передать письмо или создать запись в CRM, а сбой произошёл позже. Перед повтором специалист должен выяснить результат предыдущей попытки и риск дубликата. Начните с одной выбранной задачи.
Почта: отправка, доставка и входящие — разные проверки
Сначала выясните, какой транспорт действительно используется. Для примера: почтовый драйвер log в Laravel записывает письма в журнал вместо отправки. Такая запись может быть полезна при разработке, но она не подтверждает доставку на действующем сайте.
При реальной отправке попросите найти идентификатор сообщения и результат передачи почтовому сервису. По SMTP положительный ответ после передачи всего сообщения означает, что принимающий сервер взял ответственность за дальнейшую доставку. Этим сервером может быть промежуточный узел. Такой ответ не подтверждает появление письма во входящих или прочтение сотрудником.
Дальше проверьте доступные события почтового сервиса: ожидание, отклонение, дальнейшую передачу. Значение статуса «доставлено» нужно уточнять в документации конкретного сервиса. Сотрудник ищет метку во всех папках: входящих, спаме, архиве; администратор при необходимости проверяет карантин, правила обработки и переадресацию. Убедитесь, что проверяется тот ящик, который настроен для формы.
Если письма с сайта не доходят или попадают в спам, специалист проверяет адрес отправителя и почтовую аутентификацию:
- SPF — разрешён ли используемый отправляющий сервер для домена;
- DKIM — подписывает ли сервис письмо от имени настроенного домена;
- DMARC — согласован ли домен видимого отправителя с проверяемыми доменами.
Точные требования зависят от получателя и сервиса отправки. Даже корректная аутентификация не гарантирует попадание во входящие.
Практическое решение для формы — отправлять уведомление от адреса на настроенном домене компании, а проверенный адрес посетителя использовать для ответа через Reply-To. Подстановка произвольного адреса посетителя в From может нарушить проверку подлинности отправителя. Значения этих полей должен безопасно формировать сервер, а не собирать их из непроверенной строки.
CRM: запрос отправлен, а запись найдена?
Если сайт передаёт обращения напрямую в CRM, отсутствие письма может быть отдельной проблемой уведомления. Сначала найдите результат операции CRM: успешное создание, отказ или неизвестный исход из-за обрыва связи.
В качестве конкретного примера: метод создания лида в Битрикс24 возвращает идентификатор созданного лида в поле result. Он также может вернуть ошибку, в том числе при отсутствии права на создание. Для других CRM проверяют контракт их собственного метода. Название метода или факт сетевого вызова не подтверждают создание записи.
После успешного ответа найдите запись по идентификатору. Проверьте тип записи, ответственного, стадию и доступ сотрудника. Обращение может существовать, но не попадать под фильтр текущего списка или быть назначено другому человеку.
Если ответ интеграции не получен, не создавайте обращение повторно вслепую. Сначала поищите уже созданную запись по контрольной метке или предусмотренному идентификатору. Финальное подтверждение — сотрудник видит нужную запись и понимает, что должен с ней сделать.
Учебный разбор: интерфейс работает, очередь остановлена
Это вымышленная ситуация для объяснения проверки, а не случай клиента Студии Вебирус.
Контрольная форма показала сообщение об успехе. В приложении нашлась сохранённая запись с меткой B40-CHECK-01. Для неё была создана задача отправки письма, но задача оставалась ожидающей. Почтовый сервис не содержал события об этом сообщении. Проверка фонового процесса показала, что нужная очередь не обрабатывается.
На этом этапе изменение SPF или поиск письма в спаме не устраняют найденную причину: задача ещё не передала сообщение в почтовый транспорт. Сначала специалист восстанавливает обработку нужной очереди и проверяет выбранное обращение. После выполнения задачи он сверяет почтовый результат, а сотрудник подтверждает получение метки.
Если после этого письмо отклонено или попало в спам, появился следующий подтверждённый участок для диагностики. Исправление очереди не даёт оснований объявлять весь маршрут проверенным.
Что передать специалисту без персональных данных и секретов
Для первого разбора достаточно страницы и названия формы, времени с часовым поясом, контрольной метки, устройства и браузера, текста видимой ошибки, ожидаемого маршрута и последнего подтверждённого этапа. Добавьте сведения о недавних изменениях: переносе сайта, обновлении формы, смене почтового сервиса или настройке CRM. Это ориентиры для проверки, а не готовые причины.
Попросите ответ в конкретном виде: «Обращение сохранено; задача ожидает выполнения; почтовой передачи ещё не было». Фраза «с нашей стороны всё отправлено» без указания этапа не позволяет продолжить диагностику.
Не публикуйте журнал целиком, файл окружения, ключи API, пароли SMTP, адрес вебхука CRM, cookies или токены авторизации. Полный сетевой журнал браузера тоже может содержать чувствительные данные. Для передачи специалисту используйте защищённый канал и только нужный фрагмент; для публичного обсуждения удалите личные сведения и секреты.
Для текущих клиентских обращений согласуйте временный рабочий канал связи. Если на сайте уже хранится журнал заявок, ответственный может сверить его с почтой или CRM через разрешённый доступ. Если такого журнала нет, не обещайте восстановить все потерянные обращения: наличие пригодных данных ещё нужно установить.
Когда проверку можно считать завершённой
После исправления выполните новый согласованный единичный тест с новой меткой. Убедитесь, что сотрудник получил именно его по ожидаемому маршруту, а повторной записи или письма не появилось. Если изменялись общие настройки, отдельно проверьте затронутые формы; не делайте массовую тестовую рассылку.
Попросите зафиксировать причину, выполненное исправление, подтверждения прохождения и оставшиеся ограничения. Один успешный тест подтверждает этот сценарий в момент проверки. Он не доказывает, что сбоя не было раньше, что восстановлены все обращения или что проблема никогда не повторится.
Ограниченное исправление после диагностики можно обсудить как доработку сайта. Если нужны регулярные проверки и обработка возникающих задач, условия обсуждают в рамках технической поддержки сайтов. Чужой сайт принимают после диагностики; подходящий объём работ определяют по его состоянию и технологии.
