Путь заявки на сайте: как проверить цепочку от формы до менеджера

Когда заявка не дошла до менеджера, обычно начинается хаотичная проверка: кто-то смотрит почту, кто-то открывает CRM, кто-то просит программиста “проверить форму”. Проблема в том, что заявка проходит несколько этапов. На каждом из них она может потеряться.

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

Нарисовать цепочку заявки

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

Форма на сайте
→ JavaScript/AJAX
→ backend-обработчик
→ запись в базу
→ письмо менеджеру
→ CRM
→ уведомление
→ задача или звонок менеджера

В разных проектах цепочка может быть короче или длиннее. Главное — не проверять один кусок, когда проблема может быть в соседнем.

Проверить форму глазами пользователя

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

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

Иногда проблема видна сразу: кнопка не нажимается, поле телефона не заполняется, всплывающее окно закрывает кнопку или скрипт падает в браузере.

Проверить браузерные ошибки

Во вкладке Console не должно быть ошибок JavaScript, связанных с формой. Во вкладке Network нужно посмотреть, ушёл ли запрос и какой ответ вернул сервер.

Status Code: 200
Status Code: 400
Status Code: 403
Status Code: 500

Если запрос не ушёл, проблема на frontend. Если ушёл и вернул ошибку, нужно смотреть backend.

Сохраняется ли заявка на сайте

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

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

Письмо менеджеру

Если письмо не пришло, нужно проверить не только папку “Спам”. Важны SMTP-настройки, лог отправки, адрес получателя, шаблон письма и ограничения хостинга.

form_submit: success
mail_send: failed
smtp_error: authentication failed

Без логов понять это трудно. Поэтому для форм лучше фиксировать статус отправки письма.

CRM

Если заявка должна уходить в CRM, нужно проверить ответ CRM. Не “мы отправили”, а “CRM вернула ID лида или сделки”.

[
    'crm_status' => 'success',
    'crm_lead_id' => 12345,
]

Если CRM вернула ошибку, заявка должна остаться в статусе retry или failed, чтобы её можно было отправить повторно.

Уведомление менеджера

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

Чек-лист

1. Описать полный путь заявки.
2. Проверить форму на desktop и mobile.
3. Проверить Console и Network.
4. Проверить локальную запись заявки.
5. Проверить отправку письма и SMTP-лог.
6. Проверить ответ CRM и ID созданной сущности.
7. Проверить ответственного и уведомление менеджера.
8. Добавить статусы и логи, если их нет.

Заявки нельзя контролировать по принципу “вроде письма приходят”. Для бизнеса важен весь путь обращения. Если каждый этап оставляет понятный след, потерянные заявки перестают быть загадкой.