Разделите весь путь заявки на четыре этапа
Сообщение «Спасибо, заявка отправлена» ещё не показывает, где находится обращение. Оно могло появиться после отправки запроса из браузера, после записи в базу или после попытки передать письмо. Для диагностики важно знать, какое событие действительно подтверждает интерфейс.
| Этап | Что нужно подтвердить | Чего это ещё не доказывает |
|---|---|---|
| Браузер | Запрос дошёл до обработчика и получен ответ | Обращение записано в рабочую систему |
| Сохранение | Есть запись с теми же полями и временем | Уведомление доставлено сотруднику |
| Почтовый транспорт | Сервис принял письмо без ошибки | Письмо оказалось во входящих |
| Обработка | Сотрудник увидел обращение и взял его в работу | Клиент получил ответ и задача решена |
Как провести безопасную техническую проверку
Выберите один проблемный адрес и зафиксируйте время проверки. Используйте вымышленные данные и заранее согласованный тестовый режим, который не создаёт реальный заказ и не запускает оплату. Не отправляйте рабочие пароли и не просите клиента повторно передавать чувствительные сведения для воспроизведения ошибки.
- Проверьте обязательные поля и понятность сообщений об ошибке.
- Отправьте одну тестовую заявку и сохраните показанный результат.
- Найдите запись в базе, CRM или закрытом журнале по тестовой отметке.
- Проверьте статус уведомления отдельно от самой записи.
- Уберите свою техническую запись в предусмотренном порядке после проверки.
Если записи нет в системе
Проверьте, вызывает ли кнопка нужный обработчик и что происходит при ошибке сервера. Возможны конфликт скриптов, устаревший токен формы, блокировка защитой хостинга, ошибка валидации или неудачная запись. Причину нужно устанавливать по ответу и журналу конкретной попытки, а не по внешнему виду кнопки.
Особенно важно проверить повторный клик и временную потерю связи. Если пользователь не получил подтверждение и нажал ещё раз, система должна различать повтор одного обращения и новую заявку. Уникальный идентификатор попытки помогает избежать нескольких одинаковых записей.
Если запись есть, но письма нет
Не начинайте с изменения полей формы наугад. Сначала выясните, был ли вызов отправки, какой транспорт использован и есть ли ошибка. Затем отдельно проверяйте почтовый ящик, папку спама и доступные журналы доставки. Успешная передача письма не исключает дальнейшую фильтрацию получателем.
Это различие прямо отмечено в документации WordPress для wp_mail(): успешный возврат функции подтверждает обработку запроса используемым способом отправки, а не получение письма адресатом.
Если обращение сохранено независимо от письма, сотрудник сможет найти его при сбое уведомлений. У такого раздела должны быть ограниченные права доступа; публиковать контакты клиентов в открытом журнале нельзя.
Что записать в результат проверки
| Поле проверки | Пример безопасной записи |
|---|---|
| Страница | Адрес формы без приватных параметров |
| Время | Дата и время одной тестовой отправки |
| Браузер | Компьютер или телефон, версия браузера |
| Интерфейс | Текст подтверждения либо ошибки |
| Хранение | Есть ли соответствующая тестовая запись |
| Уведомление | Принято транспортом, ошибка либо не проверялось |
| Итог | Подтверждённая причина, исправление и повторная проверка |
Не копируйте в общий отчёт тело реальной заявки, токены и настройки с паролями. Для воспроизведения обычно достаточно технических признаков. Если письмо не найдено, так и укажите: отсутствие ошибки транспорта не заменяет проверку входящих.
Какой результат требовать после исправления
Повторите исходный сценарий, затем проверьте незаполненные поля, ошибку связи и повторную отправку. Интерфейс не должен подтверждать действие, которое система не выполнила. Необязательное текстовое поле само по себе не объясняет потерю письма: это определяется реализацией и ответом обработчика.
Диагностика и поддержка сайта → · Надёжная передача заявок в CRM →