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