Начните с тестового заказа и пройдите весь путь до SMS на своём телефоне. Перед запуском сервисных уведомлений проверьте событие отправки, текст, номер получателя и итоговый статус доставки. Отдельно испытайте отмену заказа, повторное нажатие кнопки и временный сбой связи с SMS-сервисом. Такой чек-лист поможет малому бизнесу в Беларуси проверить уведомления без рассылки клиентам и понять, что исправить до запуска: условия отправки, шаблон сообщения или обмен данными между системами.
Какие сценарии проверить в первую очередь?
Выберите одно уведомление, после которого клиент должен что-то сделать: забрать заказ, прийти за техникой из ремонта или подтвердить новое время доставки. Для первого теста достаточно одного сценария. Остальные добавляйте после того, как проверите весь путь сообщения.
Запишите условие отправки так, чтобы сотрудник и разработчик понимали его одинаково. «Сообщать о готовности» слишком расплывчато. Точнее: «Отправить SMS, когда сотрудник перевёл заказ в статус “Готов к выдаче” и проверил место получения».
- Назовите событие: заказ готов к выдаче, время доставки изменилось или ремонт завершён.
- Определите источник события: действие сотрудника либо изменение статуса заказа.
- Укажите условия, при которых SMS отправлять нельзя: заказ отменён, уже выдан или ещё не готов.
- Опишите ожидаемый результат: какое сообщение должно прийти и что клиент сделает после него.
Особенно внимательно проверьте отмену и выдачу заказа. Уведомление о готовности теряет смысл, если покупатель уже забрал товар. В рекомендациях для пунктов выдачи отдельно отмечают проверку актуального состояния заказа перед отправкой и отдельное сообщение, если срок хранения изменился (smsinfo.by).
Если проверяете уведомления об ошибках, заранее разделите причины. Сбой сайта, неуспешная оплата и перенос доставки требуют разных текстов. Для этого пригодится разбор настройки SMS при сбое сайта, оплаты или доставки.
Как проверить текст SMS на реальном телефоне?
Отправьте себе сообщение через тот же шаблон, который будет работать после запуска. Ручной текст из личного кабинета не проверит, правильно ли система подставляет номер заказа, время и адрес. Для теста создайте вымышленный заказ, который сотрудники смогут отличить от рабочего.
Пример шаблона для проверки: «Заказ {номер} готов к выдаче. Забрать: {адрес}. Работаем: {часы}. Вопросы: {телефон}». Затем откройте SMS на телефоне и проверьте каждое поле. В сообщении не должно остаться фигурных скобок, пустого адреса или внутренних названий статусов.
- Понятно, кто пишет: имя отправителя или название бизнеса в тексте помогают узнать отправителя.
- Есть конкретный статус: «готов к выдаче» вместо расплывчатого «заказ обработан».
- Клиент видит следующий шаг: куда прийти, как подтвердить перенос или с кем связаться.
- Переменные не ломают текст: длинный адрес и название услуги остаются понятными.
- Ссылка, если она нужна, открывает нужную страницу на телефоне без доступа сотрудника.
Проверьте и сообщение, в котором необязательное поле пустое. Если время получения ещё не согласовано, шаблон должен предложить способ его уточнить. Фраза «Ожидаем вас в {время}» в таком случае не подходит.
В уведомлении о задержке оставьте причину, новый ориентир и способ изменить договорённость. Предложение купить что-то ещё отвлекает от проблемы. Такой же принцип рекомендуют для сообщений о сбое доставки: при переносе объяснить, как выбрать другое время или отменить заказ, и убрать рекламу из уведомления (smsinfo.by).
Как проверить интеграцию по API и доставку SMS?
API — это способ, которым сайт или рабочая программа передаёт SMS-сервису команду на отправку. Попросите разработчика показать результат на одном тестовом заказе: какое событие запустило отправку, какой текст ушёл и какой статус вернулся. Владельцу бизнеса достаточно сверить эти сведения с сообщением на телефоне.
Разделяйте приём команды и доставку. Ответ SMS-сервиса о том, что он принял запрос, ещё не подтверждает получение сообщения телефоном. Статус доставки тоже не означает, что человек прочитал SMS. Поэтому проверка включает и сведения в сервисе, и фактическое сообщение на тестовом устройстве.
- Запустите нужное событие в тестовом заказе и убедитесь, что система создала запрос на отправку.
- Сверьте номер получателя и итоговый текст с теми, которые ожидали увидеть.
- Проверьте ответ сервиса: он принял сообщение или вернул ошибку.
- Дождитесь итогового статуса и сопоставьте его с SMS на телефоне.
- Передайте то же событие повторно и проверьте, что клиенту не уходит ненужный дубль.
Номер проверьте в формате, который принимает ваш SMS-сервис. Ошибочный формат номера, настройки шлюза и фильтрация у операторов указаны среди причин проблем с доставкой транзакционных сообщений в Беларуси (smsinfo.by). Если SMS не пришло, сначала посмотрите причину в отчёте, затем исправляйте конкретную настройку.
Отдельно попросите разработчика смоделировать ситуацию, когда система не получила ответ на запрос. Перед повторной отправкой она должна проверить судьбу первого сообщения доступным способом. Иначе клиент рискует получить одинаковые SMS, хотя сотрудник нажал кнопку только один раз.
Как понять, что уведомления готовы к запуску?
Проведите проверку без настоящих получателей: направляйте тестовые сообщения только на телефоны сотрудников, которые участвуют в проверке. Убедитесь, что тестовый заказ не запускает другие уведомления по рабочей цепочке. Затем проверьте отмену, изменение времени и временную недоступность SMS-сервиса.
Для каждого испытания достаточно короткой записи: действие, ожидаемый результат, фактический результат, исправление. Например: «Отменили заказ до отправки; SMS о готовности не должно уйти; сообщение не отправлено». Так видно, какой сценарий уже работает и какой нужно повторить после исправления.
Для уведомлений об оплате проверьте, что текст соответствует подтверждённому состоянию заказа. Если система ещё уточняет результат платежа, сообщение не должно уверенно объявлять его неуспешным и предлагать заплатить снова. Отдельные условия для такого сценария разобраны в статье о том, как настроить SMS о сбое оплаты и незавершённом заказе.
Перед запуском назначьте ответственного за ошибки доставки. Ему нужен доступ к результатам отправок и понятный порядок действий: проверить причину, исправить номер или настройку, решить вопрос с повтором. Также определите, кто отключит проблемный шаблон, если клиентам начнут приходить неверные сообщения.
Интеграцию по API и мониторинг доставки проверяйте вместе: корректный запрос без контроля результата оставляет часть пути невидимой. На sms&go эти задачи относятся к сервисным уведомлениям. При настройке конкретного сценария полезно сразу уточнить, где смотреть статусы и как система сообщает об ошибках.
Типичные ошибки перед запуском сервисных SMS
- Проверяют только ручную отправку. Исправление: запустить сообщение через реальное изменение статуса тестового заказа.
- Принимают успешный ответ API за доставку. Исправление: сверить итоговый статус и сообщение на телефоне.
- Повторяют отправку после любой ошибки. Исправление: сначала выяснить, принял ли сервис предыдущий запрос.
- Отправляют устаревшее уведомление после отмены или выдачи. Исправление: повторно проверять состояние заказа перед отправкой.
- Не назначают ответственного за сбои. Исправление: определить сотрудника, который проверяет ошибки и передаёт технические причины разработчику.
Сейчас выберите одно уведомление и за минуту запишите точное событие, после которого оно должно уходить клиенту.
