Как не отправить SMS «Заказ готов» после отмены заказа

Проверьте текущий статус заказа перед передачей SMS в шлюз и удалите уведомление из очереди, если заказ уже отменён. Чтобы сообщение «Заказ готов» не ушло по старому событию, свяжите его с конкретным изменением заказа, ограничьте срок ожидания и исключите повторную отправку. Ниже разберём, какие правила передать разработчику и как проверить результат. Такая настройка подходит интернет-магазину, мастерской или другому малому бизнесу в Беларуси, где клиент получает сервисные SMS о готовности заказа.

Почему SMS о готовности приходит после отмены?

Причина часто в том, что система отдельно меняет статус заказа и отдельно отправляет уведомление. Сотрудник отмечает готовность, программа ставит SMS в очередь, а затем клиент отменяет заказ. Очередь продолжает выполнять прежнее поручение, если никто не проверяет, актуально ли оно.

Очередь — это список задач, которые программа выполняет по мере возможности. Она помогает пережить временный сбой связи со шлюзом, но сама по себе ничего не знает об отмене заказа. Вот почему простого правила «при статусе “Готов” отправить SMS» недостаточно.

Для начала найдите место, где программа создаёт задачу на отправку. Уточните у разработчика: сохраняет ли она только текст и номер телефона или также связь с заказом? Без этой связи программа не сможет проверить актуальность сообщения перед отправкой.

Такая проверка нужна и в других сервисных сценариях. Если вы только выстраиваете уведомления, начните с общей схемы транзакционных SMS для микробизнеса Беларуси, а затем добавьте правила для каждого статуса.

Что проверять непосредственно перед отправкой SMS?

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

1. Свяжите задачу с заказом. Сохраните его идентификатор, чтобы программа могла открыть актуальную запись.
2. Задайте условие отправки. Например, SMS о готовности разрешено только пока заказ доступен для получения.
3. Свяжите задачу с конкретным изменением статуса. Так программа отличит текущую готовность от предыдущей.
4. Проверьте, не отправляли ли уже уведомление об этом изменении. Повторная обработка той же задачи не должна создавать новое SMS.
5. При отмене заказа снимайте ожидающие задачи с отправки. При этом сохраните проверку перед шлюзом на случай, если задача уже начала выполняться.

Связь с конкретным изменением особенно важна, когда статус возвращается назад. Например, заказ отметили готовым, затем отправили на доработку и снова подготовили к выдаче. Старая задача не должна ожить только потому, что в карточке опять стоит «Готов». Разработчик может различать такие события по версии записи или отдельному идентификатору события.

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

Как ограничить срок доставки и что делать с повторами?

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

Срок доставки в настройках шлюза часто называют TTL или периодом действительности. Проверьте документацию своего подключения: поддерживает ли шлюз этот параметр, в каких единицах его принимает и с какого момента отсчитывает. Не предполагайте, что одинаковое название означает одинаковое поведение у разных сервисов.

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

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

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

Не считайте ответ «принято шлюзом» подтверждением доставки клиенту. Для разбора задержек полезно отдельно смотреть результат запроса и статус доставки. Порядок такой проверки есть в статье о недоставке SMS, если клиент не получил уведомление.

Можно ли остановить SMS, которое шлюз уже принял?

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

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

В тексте укажите номер заказа и понятное действие. Например: «Заказ №… готов к выдаче. Перед поездкой проверьте актуальный статус в личном кабинете». Такой вариант подходит, если у клиента есть доступ к актуальному статусу. Если его нет, не добавляйте эту фразу ради подстраховки.

Проверьте настройку на тестовом заказе: сначала отметьте готовность, затем отмените заказ до передачи SMS в шлюз. В журнале должна появиться причина пропуска, а запрос на отправку не должен уйти. После этого отдельно проверьте повторную обработку той же задачи и возврат заказа на доработку.

При настройке через API передайте разработчику условия отправки, причины пропуска и правила повтора одним заданием. Это позволит проверить всю цепочку: от изменения заказа до ответа шлюза.

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

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

За две минуты добавьте в задачу разработчику проверяемое условие: «Если заказ отменён до передачи SMS в шлюз, программа пропускает уведомление “Заказ готов” и записывает причину в журнал».