Куда пропадают заявки с сайта: путь от формы до ответа

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

Эта статья начинается после клика по кнопке. Если обращений вообще мало, сначала пройдите общий разбор «Почему сайт не приносит заявок»: там отдельно проверяются трафик, предложение, цена, телефон и скорость.

Где именно может оборваться заявка

У фразы «форма работает» нет одного простого доказательства. Каждый этап подтверждает только свою часть пути.

Этап	Что может сломаться	Чем подтвердить
Форма в браузере	кнопка зависла, ошибка спряталась, человек не понял результат	после отправки виден успех или конкретная ошибка
Сервер	данные не прошли проверку, запрос завершился ошибкой	сервер вернул успешный ответ только после обработки
Хранилище	база недоступна, запись не создалась	у заявки есть карточка и идентификатор в базе или CRM
Уведомления	письмо попало в спам, бот потерял доступ к чату	пришли сигналы по двум разным транспортам
Работа с заявкой	уведомление увидели, но никто не взял обращение	назначен ответственный и меняется статус
Ответ клиенту	адрес ошибочный или обещанный срок прошёл	клиент получил подтверждение и живой ответ

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

Почему надпись «Спасибо» ничего не доказывает

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

Успех стоит показывать после постоянного сохранения заявки. Тогда остаются три отдельных состояния, которые можно проверить:

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

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

Почему письмо не должно быть единственным хранилищем

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

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

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

Как этот путь устроен на моём сайте

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

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

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

Отдельный вопрос — какие данные вообще можно собирать и как фиксировать согласие. Он разобран в статье «Согласие на обработку данных»; здесь речь только о технической доставке уже заполненной формы.

Как проверить всю цепочку одной заявкой

Используйте собственные контактные данные и заметную метку вроде ТЕСТ-ФОРМЫ-11-09. Не берите чужую почту и не маскируйте тест под реального клиента.

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

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

Что доказывает автоматический тест

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

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

Что достаточно малому бизнесу

Покупать CRM только ради слова «CRM» не обязательно. Для небольшого потока достаточно пяти вещей:

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

У подрядчика стоит спросить не «форма работает?», а где хранится запись, что произойдёт при отказе почты, кто увидит необработанную заявку и как весь путь проверяется после релиза. Остальные вопросы до предоплаты собраны в статье «Как проверить подрядчика».

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

Коротко

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

Частые вопросы

Надпись «Заявка отправлена» гарантирует, что письмо пришло?

Нет. Она может подтверждать только тот этап, после которого сайт решил показать успех. Правильная минимальная граница — запись уже сохранена. Доставку письма и второго уведомления проверяют отдельно.

Нужна ли CRM, если заявок немного?

Не обязательно. Нужна постоянная очередь, где обращение не зависит от одного почтового ящика и имеет хотя бы статус «новая» или «в работе». Это может быть небольшая админка сайта; CRM нужна, когда появляются несколько менеджеров, этапы сделки и связанные задачи.

Достаточно ли почты и Telegram без базы?

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

Может ли автоматический аудит проверить доставку заявки?

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