Как ограничить срок доставки SMS и не прислать устаревший текст

Как ограничить срок доставки SMS и не прислать устаревший текст

Задайте для каждого типа SMS момент, после которого сообщение теряет смысл, и настройте прекращение отправки на тех этапах, где это позволяет сервис. Одной проверки перед запросом к API недостаточно: уведомление может задержаться в очереди или уйти повторно после ошибки. В статье разберём, как связать срок доставки с событием, какие возможности уточнить у SMS-сервиса и как проверить настройку. Это поможет бизнесу в Беларуси сократить число уведомлений, которые приходят уже после отмены заказа, переноса записи или окончания действия кода.

Как определить, когда SMS становится устаревшим?

Начните с события, ради которого отправляете сообщение. У кода входа есть срок действия, у напоминания о записи — время визита, у уведомления о готовности заказа — актуальный статус заказа. Запишите для каждого сценария условие, после которого отправку нужно прекратить.

Полезно разделять срок действия самого сообщения и срок действия информации внутри него. Код можно отклонить на сайте после истечения его срока, но это само по себе не остановит SMS, которое уже находится в доставке. Клиент всё равно увидит код и попробует его ввести. Поэтому проверку кода на сайте и ограничение доставки настраивают отдельно.

  • Для кода входа привяжите срок отправки к сроку действия кода. Просроченный код система должна отклонять независимо от того, когда пришло SMS.
  • Для напоминания о записи задайте крайний момент отправки до визита. Если клиент перенёс запись, отмените старое задание.
  • Для статуса заказа проверяйте, соответствует ли текст текущему состоянию заказа. Сообщение «Заказ готов к выдаче» теряет смысл после отмены или выдачи.
  • Для уведомления о временном сбое прекращайте отправку после восстановления работы. Иначе клиент получит предупреждение, когда проблема уже решена.

Фраза «Отправить как можно быстрее» не задаёт срок. В задании разработчику лучше написать: «Перед отправкой проверить время визита и отменить напоминание, если визит уже начался». Здесь есть конкретное условие, которое можно проверить.

Что уточнить у SMS-сервиса перед настройкой срока доставки?

Узнайте, поддерживает ли сервис срок действия SMS, или validity period, и на каком участке доставки он работает. Название параметра, единицы времени и доступные значения зависят от API. Не переносите настройку из чужого примера без проверки документации.

Главный вопрос — что именно произойдёт после истечения срока. Сервис может прекратить попытки в собственной очереди, но границы его контроля нужно уточнить отдельно. Если сообщение уже передано дальше, возможность отмены зависит от следующего участника доставки. Обещать клиенту, что устаревшее SMS точно не появится на телефоне, без подтверждения этих условий нельзя.

  1. Уточните, от какого момента сервис считает срок: от события в вашей системе, приёма запроса или другого этапа.
  2. Проверьте, можно ли передать крайний момент доставки либо только длительность ожидания.
  3. Узнайте, действует ли ограничение после передачи сообщения оператору и можно ли отменить отправку.
  4. Выясните, какой статус получит сообщение после истечения срока и где его увидеть.
  5. Проверьте, что сервис делает с повторным запросом: сохраняет исходный срок или начинает отсчёт заново.

Если API принимает только длительность, рассчитывайте оставшееся время перед отправкой. Пока задание ждало в вашей системе, часть срока уже прошла. Передача полного интервала при каждом повторе сдвигает границу и продлевает жизнь старого уведомления.

При подключении информационных и транзакционных SMS через API включите эти вопросы в техническое задание вместе с шаблоном текста. Так менеджер и разработчик будут одинаково понимать, когда сообщение ещё нужно клиенту и что делать после истечения срока.

Как связать срок доставки с очередью и повторными попытками?

Проверяйте актуальность сообщения непосредственно перед запросом к SMS-сервису. Проверка только в момент создания задания оставляет пробел: пока очередь дойдёт до уведомления, клиент успеет отменить заказ или изменить запись.

Для каждого задания сохраните событие, крайний момент отправки и признак отмены. Перед отправкой система должна сверить их с текущим состоянием заказа или записи. Если событие больше не актуально, задание нужно завершить без обращения к SMS-сервису.

Отдельно настройте повторы после ошибок. При повторной попытке заново проверьте актуальность и оставшееся время. Если срок закончился, прекратите попытки. Не создавайте новое задание со свежим сроком только потому, что прежний запрос завершился ошибкой.

Очередь сама по себе бывает причиной задержки: большая партия сообщений, ограничение скорости запросов и повторы после временных ошибок отодвигают часть SMS. Поэтому при разборе задержек проверяйте не только ответ сервиса, но и время ожидания внутри своей системы (источник: mobizon.by, «Почему SMS не доходят клиентам в Беларуси: чек-лист»).

Предусмотрите и защиту от дублей. Повторный запрос по тому же событию не должен автоматически порождать ещё одно SMS. Если ответ на запрос потерялся, сначала проверьте судьбу предыдущей отправки доступным в сервисе способом. Порядок такой проверки разобран в материале как проверить недоставку SMS, если клиент не получил уведомление.

Как проверить, что устаревшие SMS перестают отправляться?

Проведите тест на отдельном сценарии до включения правила для всех уведомлений. Выберите сообщение, для которого легко определить актуальность, например напоминание о записи. Заранее зафиксируйте ожидаемое поведение системы при переносе и отмене визита.

  • Создайте задание, дождитесь истечения его срока и проверьте, что ваша система не отправила запрос к API.
  • Измените событие, пока задание находится в очереди. Убедитесь, что старый текст не ушёл после изменения.
  • Имитируйте временную ошибку в тестовой среде. Проверьте, что повторная попытка сохраняет исходную границу срока.
  • Проверьте обработку статуса истечения срока на стороне сервиса, если он поддерживает такой статус.
  • Сопоставьте время события, запроса и отчёта о доставке. Отметьте, на каком участке возникла задержка.

Отключённый телефон помогает проверить отдельный случай задержки, но одного такого теста недостаточно. Он не показывает все варианты работы очереди и повторных запросов. Проверяйте отдельно свою систему и поведение SMS-сервиса в пределах возможностей, которые описаны в его документации.

В отчёте разделяйте сообщения, которые ваша система отменила до отправки, и сообщения, срок которых закончился после приёма сервисом. Иначе отмена ненужного напоминания попадёт в общий список технических сбоев. Для настройки отчёта пригодится разбор метрик доставки SMS, которые влияют на клиентский опыт.

Рабочий результат теста — запись с исходным событием, крайним сроком и фактическим действием системы. По ней должно быть понятно, почему SMS отправилось, осталось в ожидании или было отменено.

Типичные ошибки при ограничении срока доставки SMS

  • Ограничивать только срок действия кода на сайте. Исправление: отдельно задать правила отправки SMS и проверить, где сервис умеет прекращать доставку.
  • Считать срок от каждой повторной попытки. Исправление: сохранить исходную границу и рассчитывать оставшееся время перед новым запросом.
  • Использовать один срок для всех шаблонов. Исправление: привязать границу к событию, например началу визита или окончанию действия кода.
  • Считать приём запроса подтверждением доставки. Исправление: проверять итоговый статус и отдельно учитывать сообщения, которые ещё ожидают доставки.
  • Обещать отмену SMS на любом этапе. Исправление: уточнить границы контроля у сервиса и описать их в техническом задании.

Текст тоже помогает снизить путаницу. Если уведомление связано со временем, укажите дату и время события там, где это нужно клиенту. Вместо оторванного от контекста «Ждём вас скоро» используйте шаблон с датой записи. Это не заменяет ограничение доставки, но позволяет понять, к какому визиту относится сообщение.

За ближайшую минуту откройте один действующий шаблон SMS и допишите рядом условие: «Прекратить отправку, когда…». Укажите конкретное событие или крайний момент — это первый пункт для настройки и проверки.