Главная › Блог › Что ответить клиенту: «с формы на сайте не приходят письма»

Что ответить клиенту: «с формы на сайте не приходят письма»

3 сентября 2026 · 5 мин чтения

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

Поэтому в ответах на такую жалобу есть особенность: кроме «принять и починить», нужно честно отработать вопрос «сколько потеряно» — он прозвучит обязательно.

Коротко

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

Первый ответ — сразу

Здравствуйте! Понял, разбираюсь прямо сейчас — это приоритет. Два вопроса, чтобы ускорить: на какой адрес должны приходить заявки и когда пришла последняя, которую вы точно видели? Через 20 минут напишу, что нашёл.

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

Чего не писать: «форма работает, я проверял» — отправка формы и доставка письма это два разных события, и жалоба почти всегда именно про второе.

Десять минут на проверку: где теряется письмо

Путь заявки состоит из четырёх звеньев, рвётся обычно одно:

Форма отправляется? Заполнить самому на сайте клиента. Если после нажатия — ошибка или вечный спиннер, дальше можно не идти: чинить фронт.
Сервер отправляет письмо? Самое частое место разрыва. PHP-функция mail() на shared-хостинге, смена пароля SMTP, истёкший ключ почтового сервиса — форма честно говорит «спасибо», а письмо умирает внутри. В логах хостинга это видно; снаружи — нет.
Письмо доходит, но в спам? Проверить папку спама на ящике приёма — банально, но это каждый третий случай. Особенно после смены домена, DKIM/SPF-записей или почтового сервиса.
Письмо доходит на другой ящик? Форму когда-то настраивали на адрес секретаря, секретарь уволился, ящик переполнен или удалён. Никто не помнит.

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

Второй ответ — по результату

Сценарий 1: сломалась отправка с сервера (частый):

Нашёл: с 28 августа сервер не может отправлять почту — на хостинге сменили настройки SMTP [или: истёк ключ почтового сервиса]. Форма при этом выглядела рабочей, поэтому никто не заметил. Уже чиню, заявки за период с 28-го можно достать из базы сайта — они сохранились, сейчас выгружу и пришлю списком.

Фраза про «достать из базы» — золотая: большинство форм пишут заявки в базу параллельно с письмом, и «потерянные» заявки часто можно вернуть. Проверьте это раньше, чем клиент спросит.

Сценарий 2: письма уходят в спам:

Проверил: письма отправляются и доходят, но попадают в папку «Спам» на вашем ящике — посмотрите, там должны быть заявки за последние дни. Причина — [сменился почтовый сервис / нет DKIM-записи у домена]. Сегодня настрою подписи для домена, чтобы письма проходили во «Входящие», и отправлю контрольную заявку.

Сценарий 3: письма шли на мёртвый ящик:

Выяснил: форма настроена на адрес info@…, который не проверяется с июля. Заявки там, ничего не потеряно — пересылаю их вам сейчас и меняю адрес приёма на актуальный. Подскажите, какой поставить основным и нужен ли дублирующий?

После починки — закрыть петлю и застраховаться

Готово: заявки снова приходят на [адрес], тестовая дошла за 40 секунд. Найденные заявки за период сбоя выслал отдельным письмом — их [N]. Чтобы такое не повторилось незаметно, я включил постоянную проверку доставки: система каждые несколько часов отправляет тестовую заявку через форму и проверяет, что письмо дошло. Если цепочка порвётся снова — я узнаю в тот же час, а не через неделю.

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

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

Клиент требует компенсацию за потерянные заявки. Что отвечать? Сначала факты: период сбоя, сколько заявок удалось восстановить из базы, сколько безвозвратно. Разговор о компенсации на цифрах идёт спокойнее, чем на эмоциях. И отдельно честно: если поддержка была разовой, а не абонентской, — механизма, который бы заметил сбой, просто не существовало; это аргумент не для спора, а для перевода на постоянную поддержку.

Как убедиться, что починилось навсегда? Никак — почтовая цепочка рвётся снаружи: хостинг меняет политику, почтовый сервис — тарифы, регистратор — DNS. Поэтому единственный честный ответ — постоянная сквозная проверка доставки, а не разовая починка.

Форма отправляется, письмо приходит, но клиент всё равно говорит «заявок нет». Значит, упали не письма, а сами заявки: трафик, реклама, конверсия формы. Это другой разговор — начните с графика посещаемости страницы с формой за месяц.