После смены сайта или CRM проверьте SMS-уведомления по всей цепочке: событие должно возникнуть, система — передать сообщение провайдеру, а клиент — получить понятный текст. Одной проверки в личном кабинете недостаточно: статус отправки не всегда подтверждает, что сообщение появилось на телефоне. Сверьте настройки, пройдите ключевые сценарии на тестовых номерах и проверьте отчёты. Так вы найдёте сбои до того, как покупатель пропустит подтверждение заказа или напоминание о записи.
Что проверить в первую очередь после переезда?
Начните с перечня событий, которые запускают SMS. Например, оформление заказа, изменение его статуса, запись на приём или готовность покупки к выдаче. Для каждого события запишите, кто его создаёт: сайт, CRM или сотрудник вручную.
Затем проверьте связь с сервисом отправки. Если новая система обращается к API, сверьте адрес запроса, учётные данные и поля, из которых собирается сообщение. Отдельно посмотрите, передаётся ли номер телефона в нужном формате, а событие не отправляется повторно после обновления страницы или повторного сохранения карточки.
Если подключение настраивал разработчик, попросите его показать журнал запросов: в нём видно, отправила ли система команду и какой ответ получила. Для небольшого проекта полезно заранее определить, кто проверяет эти записи при сбое. Подробнее о вариантах подключения можно прочитать в материале о выборе между SMPP и HTTP API для небольшой SMS-интеграции.
Как протестировать SMS по сценариям?
Проверьте не только отправку тестового текста, но и события, которые запускают сообщение. Создайте тестовый заказ и пройдите его до нужного статуса. Для записи проверьте создание, перенос и отмену, если для них предусмотрены отдельные уведомления.
Для каждого сценария зафиксируйте ожидаемый результат: какое событие запускает SMS, на какой номер оно уходит и какой текст должен прийти. После теста сравните фактическое сообщение с этим списком. Так проще заметить, например, что уведомление пришло, но в нём указан старый статус заказа.
- Проверьте номер отправителя и его отображение на телефоне.
- Сверьте имя клиента, время записи, статус заказа и другие подставляемые данные.
- Проверьте ссылку в сообщении, если она ведёт на страницу заказа или записи.
- Повторите тест после изменения статуса и убедитесь, что клиент не получил дубликат.
- Проверьте, что сбой отправки виден сотруднику, который сможет на него отреагировать.
Записывайте результат каждого теста в таблицу: сценарий, номер тестового получателя, время запуска, текст и статус в отчёте. Для проверки достаточно пройти путь одного заказа от создания до завершения и отдельно проверить одно напоминание о записи.
Что показывают отчёты провайдера?
Отчёт помогает понять, на каком этапе остановилось сообщение. Сопоставьте время события в CRM со временем передачи SMS и статусом, который показывает сервис. Если CRM записала событие, но в отчёте нет попытки отправки, ищите проблему в настройке триггера или интеграции. Если попытка есть, но статус неуспешный, проверьте ответ сервиса и причину отказа, если она указана.
Статус в отчёте описывает результат на стороне системы отправки. Он сам по себе не подтверждает, что клиент прочитал SMS. Поэтому при тестировании сверяйте данные из трёх мест: карточку заказа или записи, журнал интеграции и отчёт провайдера. Если статусы трудно сопоставить, попросите технического специалиста связать запись события с идентификатором сообщения.
В личном кабинете удобно просматривать отправки и отчёты, а API помогает передавать сообщения из сайта или CRM автоматически. При выборе частоты уведомлений учитывайте, какие события нужны клиенту и когда они происходят. Подход к планированию описан в материале о времени и частоте SMS для клиентов малого бизнеса.
Какие ошибки мешают проверке?
- Проверяют только кнопку тестовой отправки, но не событие в CRM.
- Используют реальный номер клиента вместо отдельного тестового номера.
- Не проверяют поля, подставляемые в текст, и отправляют сообщение с пустым именем или неверным временем.
- Считают любой успешный статус доказательством получения SMS на телефоне.
- Не проверяют повторную отправку при повторном сохранении заказа.
После каждого изменения сайта или CRM повторяйте тесты по затронутым сценариям. Сначала проверьте один заказ и одну запись, затем просмотрите журналы и отчёт провайдера. Если все три источника показывают ожидаемый результат, уведомления можно вернуть в рабочий режим; результаты теста сохраните, чтобы использовать их при следующем обновлении.
