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