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