После переноса сайта на новый хостинг проверьте путь SMS от события до телефона клиента. Работающий сайт не гарантирует, что уведомления доходят: интеграция могла потерять настройки, фоновые задачи остаться на старом сервере, а шаблоны сбросить поля. Начните с тестового заказа или события, сверьте записи сайта с отчётом сервиса отправки и проверьте текст на телефоне. Так вы найдёте сбой до того, как клиент начнёт ждать подтверждение.
Что сохранить перед переносом
Попросите специалиста сохранить вместе с сайтом настройки интеграции: адрес подключения к сервису, учётные данные, шаблоны сообщений и правила запуска уведомлений. Отдельно зафиксируйте, какие события обрабатывает сам сайт, а какие приходят из CRM или системы доставки. Иначе будет трудно понять, на каком участке пропала SMS.
Запишите также расписание фоновых задач. Сайт может отправлять уведомления не сразу при изменении статуса, а через задачу по расписанию. Если на новом хостинге задача не запущена, уведомления зависнут. Если задача работает одновременно на старом и новом сервере, клиент получит дубликаты.
Менять DNS лучше после проверки сайта на новом хостинге. Этот порядок помогает обнаружить сбой до переключения трафика (Web-Puls, «Проверка сайта после переноса»). На новом хостинге сверьте параметры подключения с сохранёнными настройками. Убедитесь, что сайт использует нужные учётные данные и собирает запрос из актуальных полей заказа или формы.
Как пройти тестовый сценарий от события до телефона
Создайте тестовый заказ, заявку или другое событие на номер, к которому у вас есть доступ. Пройдите обычный путь клиента: оформление, смену статуса, готовность к выдаче или передачу в доставку. Для каждого события заранее запишите ожидаемый текст и момент отправки. Если сайт сообщает о доставке после обновления статуса перевозчиком, проверьте и этот переход.
Проверяйте содержание на телефоне. Имя отправителя, номер заказа, статус и ссылка должны относиться к тестовому заказу. Откройте ссылку: после переезда она не должна вести на старый адрес или недоступную страницу. Затем повторно сохраните заказ без изменения статуса и посмотрите, не пришёл ли дубликат.
Записывайте результат каждого теста в короткую таблицу: событие, время, номер тестового получателя, ожидаемый текст, фактический текст и статус отправки. Если CRM тоже участвует в цепочке, сопоставьте её запись с записью сайта. Для дополнительной проверки сценариев после смены инфраструктуры можно воспользоваться чек-листом в статье на inrb.by.
Как понять, на каком участке пропала SMS
Сравните записи в админке сайта, журнал запросов к сервису отправки и отчёт самого сервиса. Попросите разработчика показать код ответа на запрос и идентификатор сообщения: по нему проще найти одну отправку среди остальных. Проверьте, возвращает ли сервис финальный статус доставки, поскольку ответ на запрос и результат доставки описывают разные этапы.
| Что видно при проверке | Где искать причину | Следующее действие |
|---|---|---|
| Статус события изменился, запроса на отправку нет | Правило запуска SMS, фоновая задача или связь с CRM | Повторить событие и проверить журнал сайта |
| Запрос есть, сервис вернул ошибку | Адрес подключения, доступ или формат данных | Сверить запрос и код ответа с настройками интеграции |
| Сервис принял запрос, финального статуса нет | Получение отчётов о доставке | Найти сообщение по идентификатору и проверить обновление статуса |
| Отчёт показывает доставку, текст неверный | Шаблон SMS и поля заказа | Сравнить сообщение с карточкой тестового заказа |
Статус доставки сам по себе не показывает, прочитал ли клиент сообщение. При проверке важно увидеть SMS на тестовом телефоне и сравнить её с заказом. Если сбой возник только после смены хостинга, специалисту по инфраструктуре пригодятся время события, журнал запросов и идентификатор сообщения: с ними он проверит настройки сервера без догадок о том, какое уведомление пропало.
Типичные ошибки при проверке
- Отправляют произвольную тестовую SMS и не проверяют событие заказа. Запустите уведомление через обычное действие клиента или сотрудника.
- Смотрят только на успешный ответ сервиса. Дождитесь финального статуса и проверьте текст на тестовом телефоне.
- Не проверяют повторную отправку. Сохраните заказ ещё раз и убедитесь, что новая SMS не появилась.
- Тестируют до переключения DNS, но не после него. Повторите основные сценарии на адресе, который уже открывают клиенты.
- Не сверяют шаблоны с фактическим текстом. Переменные в шаблоне могли потерять привязку к полям заказа.
- Проверяют только один сценарий. Пройдите хотя бы три типичных события: новый заказ, смену статуса, готовность к выдаче.
Откройте настройки уведомлений сайта и выпишите одно событие для первого теста — например, подтверждение нового заказа. Если после проверки обнаружите, что интеграция работает нестабильно или требует настройки, посмотрите чек-лист для смены сайта или CRM. Для международных отправок есть отдельный чек-лист проверки SMS-сценариев за границей.
Три шага, которые можно сделать сегодня:
- Попросите специалиста сохранить настройки интеграции и расписание фоновых задач вместе с копией сайта.
- Создайте тестовое событие на новом хостинге до переключения DNS и сверьте текст на телефоне с шаблоном.
- Запишите результаты проверки в таблицу: событие, ожидаемый текст, фактический текст и статус отправки.
