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