Мониторинг транзакционных SMS помогает понять, что происходит с каждым уведомлением после оформления заказа: система создала сообщение, передала его SMS-шлюзу, оператор принял его и доставил получателю или вернул ошибку. В статье разберём, как организовать журнал событий, какие статусы фиксировать, зачем нужны вебхуки и как получать уведомления о сбоях без постоянного просмотра личного кабинета. В результате владелец небольшого интернет-магазина сможет быстрее находить проблемы с подтверждением заказа, оплатой и доставкой.
Зачем интернет-магазину журнал транзакционных SMS?
Транзакционное сообщение отправляется после конкретного действия клиента. Например, покупатель оформил заказ, оплатил товар, выбрал доставку или запросил код подтверждения. Если SMS не дошло, причина может находиться на любом участке цепочки: сайт не создал событие, интеграция не передала запрос, шлюз отклонил сообщение или оператор вернул статус ошибки.
Без журнала владелец видит только итог: клиент пишет, что не получил уведомление. Менеджер вручную проверяет заказ, разработчик ищет запись в логах, а точная причина теряется между системами. Журнал событий связывает заказ и сообщение в одну цепочку. В нём достаточно хранить технический идентификатор, время, номер заказа, тип уведомления, статус и текст ошибки.
Для малого бизнеса подойдёт таблица или готовый раздел мониторинга в сервисе SMS API. Главное, чтобы запись создавалась автоматически. Ручная отметка менеджера «SMS отправлено» не подтверждает доставку, потому что она показывает только факт действия сотрудника.
Какие поля добавить в журнал?
- Время создания. Когда интернет-магазин сформировал уведомление.
- Идентификатор заказа. По нему менеджер быстро находит нужную покупку.
- Тип сообщения. Подтверждение заказа, оплата, передача в доставку, готовность к выдаче или другой сценарий.
- Технический идентификатор SMS. Он помогает сопоставить запись магазина с записью SMS-шлюза.
- Текущий статус. Например, «создано», «отправлено», «доставлено», «не доставлено» или «ошибка».
- Код и описание ошибки. Одной надписи «сбой» мало: при повторной проверке нужен источник проблемы.
- Количество попыток. Так видно, сколько раз система отправляла одно и то же уведомление.
Номер телефона лучше не использовать как единственный ключ поиска. Один клиент может оформить несколько заказов, а одинаковое сообщение иногда запускается повторно. Связка «номер заказа плюс идентификатор SMS» даёт менеджеру точную картину.
Какие статусы нужно отслеживать?
Названия статусов зависят от SMS-платформы, но логику удобно разделить на несколько этапов. Сначала магазин создаёт сообщение и передаёт его через API. Затем шлюз принимает запрос и отправляет SMS оператору. После этого приходит результат доставки. Иногда система возвращает промежуточный статус, а окончательный результат появляется позже.
| Этап | Что означает | Что проверить при проблеме |
|---|---|---|
| Создано | Магазин сформировал уведомление | Сработал ли триггер заказа и заполнен ли номер получателя |
| Передано в API | Сайт отправил запрос SMS-шлюзу | Корректны ли API-ключ, адрес запроса и формат данных |
| Принято шлюзом | Система получила запрос и зарегистрировала SMS | Есть ли идентификатор сообщения и не отклонён ли текст |
| Доставлено | Оператор подтвердил доставку на телефон | Зафиксированы ли время и финальный статус |
| Не доставлено | Сообщение не дошло до получателя | Код ошибки, доступность номера и правила повторной попытки |
| Ошибка API | Запрос не прошёл обработку | Ответ сервера, лимиты, авторизацию и обязательные поля |
Статус «принято шлюзом» нельзя считать равным статусу «доставлено». Он подтверждает передачу сообщения в систему отправки, но не сообщает, прочитал ли клиент SMS и получил ли его телефон. Для контроля заказа нужен именно финальный результат доставки либо понятная ошибка.
Полезно разделить ошибки на временные и постоянные. Сбой соединения, недоступность сервиса или кратковременная ошибка шлюза допускают повторную отправку. Неверный номер, отсутствующий параметр или ошибка авторизации требуют исправления причины. Если повторять запрос без проверки, магазин рискует создать дубли уведомлений.
Как получать статусы через вебхуки?
Вебхук — это автоматическое уведомление от SMS-шлюза о результате обработки сообщения. Магазин передаёт запрос на отправку, получает идентификатор SMS, а затем принимает отдельное сообщение о смене статуса. Благодаря этому не приходится постоянно спрашивать сервис: «Доставлено ли SMS по этому идентификатору?»
Настройка обычно состоит из нескольких шагов. В панели SMS-сервиса указывают адрес, на который нужно принимать статусы. В интернет-магазине или подключённом конструкторе создают обработчик входящего уведомления. Он находит запись по идентификатору SMS и обновляет её статус. Если вебхук содержит код ошибки, система записывает его в журнал и передаёт событие в мониторинг.
- Создайте отдельный сценарий для каждого типа транзакционного сообщения.
- Передавайте в запросе внутренний идентификатор заказа и сохраняйте идентификатор SMS.
- Настройте обработку повторного вебхука, чтобы одна доставка не создавала две записи.
- Записывайте время получения статуса, а не только время отправки.
- Проверьте тестовый заказ с успешной доставкой и отдельный сценарий с ошибкой.
Если в магазине нет разработчика, можно начать с готовой интеграции или попросить специалиста один раз связать SMS API с журналом событий. После этого менеджер работает с понятными статусами, а не с техническими запросами. Для отдельных сценариев полезно изучить материал о том, как настроить SMS-цепочку статуса заказа в интернет-магазине.
Как настроить уведомления об ошибках?
Мониторинг становится практичным, когда он сам сообщает о проблеме. Уведомление можно отправлять ответственному сотруднику на электронную почту или в рабочий канал, если подключённый сервис это поддерживает. Сообщение должно содержать номер заказа, тип SMS, время сбоя, статус и понятное действие: проверить API-ключ, номер клиента или настройки повторной отправки.
Не стоит отправлять оповещение на каждый промежуточный статус. Иначе сотрудники получат поток технических сообщений и перестанут замечать важные события. Обычно достаточно реагировать на финальную ошибку доставки, несколько ошибок API подряд и отсутствие статуса за заданный период.
| Событие | Реакция системы | Действие сотрудника |
|---|---|---|
| Одна ошибка по номеру | Записать причину в журнал | Проверить данные заказа и связаться с клиентом другим способом |
| Повторяющаяся ошибка API | Отправить отдельное техническое уведомление | Проверить ключ, доступность API и последние изменения интеграции |
| Нет финального статуса | Пометить сообщение как требующее проверки | Сопоставить запись магазина с журналом SMS-шлюза |
| Несколько неудачных повторов | Остановить автоматические повторы | Разобрать причину, чтобы не отправлять клиенту дубли |
Для контроля работы интеграции задайте простой ежедневный отчёт: сколько сообщений создано, сколько передано, сколько доставлено и сколько завершилось ошибкой. Сравнение этих групп помогает заметить место сбоя. Если созданных сообщений больше, чем переданных в API, проблема находится на стороне магазина. Если API принимает запросы, но финальных статусов нет, нужно проверить вебхуки.
Какие ошибки чаще всего мешают мониторингу?
- Проверка только факта отправки. Запись «запрос выполнен» не подтверждает доставку SMS.
- Отсутствие идентификатора заказа. Без него менеджер тратит время на поиск нужного сообщения.
- Повторная отправка без ограничения. Один сбой превращается в несколько одинаковых SMS.
- Игнорирование вебхуков. Сайт знает только о принятии запроса, но не получает итоговый статус.
- Одинаковая реакция на все ошибки. Неверные данные и временный сбой требуют разных действий.
- Тестирование только успешного сценария. Интеграцию нужно проверять и на отказе API, и на недоставленном сообщении.
Начните с трёх полей: номер заказа, идентификатор SMS и текущий статус. Затем добавьте вебхуки, журнал ошибок и уведомление о повторяющихся сбоях. Если магазин уже использует CRM или CMS, интеграцию SMS API можно связать с существующими событиями заказа, чтобы менеджер видел историю уведомлений в одном месте. Такой порядок позволяет выстроить мониторинг постепенно и не покупать сложную систему до появления реальной потребности.
