Проблемы сайта после обновления: как восстановить приём заявок

Сначала проверьте путь одной заявки

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

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

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

Зафиксируйте изменения и сохраните новые данные

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

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

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

Определите, где обрывается отправка

Код HTTP 500 означает, что сервер встретил ошибку при обработке запроса. По одному этому коду нельзя определить причину: разработчику нужен журнал приложения. Успешный HTTP-ответ тоже не всегда доказывает доставку в CRM: приложение может принять заявку для последующей обработки.

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

Проверьте телефоны, вложения и мобильную форму

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

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

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

Отделите кеш от неисправной версии

После выпуска браузер может получить несовместимую комбинацию старых и новых файлов. Сравните поведение в обычном окне и в новом профиле браузера. Если результаты различаются, это повод проверить кеш браузера, CDN и service worker, если он используется.

Веб-приложение с service worker самостоятельно управляет частью кешированных ресурсов. Простая перезагрузка страницы может не заменить все такие ресурсы. Разработчик должен проверить обновление кеша и совместимость старой открытой вкладки с новым сервером.

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

Восстановите доставку без двойных обращений

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

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

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

Как принять исправление у подрядчика

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

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

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

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

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

Сайт открывается. Значит ли это, что заявки работают?

Нет. Нужно проверить отправку формы, сохранение данных и появление обращения в системе, с которой работают менеджеры.

Нужно ли сразу откатывать базу?

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

Что означает ошибка 500?

Сервер не смог выполнить запрос из-за внутренней ошибки. Точную причину ищут в журнале приложения по времени и идентификатору запроса.

Почему тест проходит у разработчика, но не у клиента?

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

Как проверить, что заявка дошла до CRM?

Найдите тестовую метку в карточке CRM и сверьте контакты, комментарий и ответственного. Одного сообщения на сайте недостаточно.

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

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