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