Как интернет-магазину избежать повторных SMS о заказе при сбоях CRM?

Чтобы покупатель не получил два одинаковых SMS о заказе, магазин должен связать каждое уведомление с конкретным событием в CRM и сохранять задачу на отправку до обращения к SMS-сервису. Если сервис вовремя не ответил, результат нужно проверить: запрос уже мог пройти. Ниже — порядок для владельца магазина и разработчика: как отличить новое изменение заказа от повтора, что делать при сбое и какие сценарии испытать перед запуском. Опубликовано 8 ноября 2026 года.

Откуда берутся повторные SMS о заказе?

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

Есть и другой сценарий. Сайт повторно передал в CRM обновление заказа, либо сотрудник сохранил карточку после изменения доставки. Если каждое такое обновление запускает новое SMS, покупатель снова получит тот же текст. Поэтому сначала выясните, где возник повтор: при передаче события в CRM или при запросе к SMS-сервису. Для этого в истории отправки нужны время события, его причина и результат запроса.

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

Как CRM отличит новое событие от повторной обработки?

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

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

CRM должна записать задачу на отправку до вызова SMS-сервиса и разрешить только одну задачу с таким ключом. Это правило нужно закрепить в хранилище задач: проверка «поищем, потом создадим» не спасает, если два процесса работают одновременно. Оба успеют проверить список и решат, что задачи ещё нет.

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

Что делать, если SMS-сервис не ответил?

Тайм-аут означает, что CRM не получила ответ вовремя. Судьба сообщения пока неизвестна. Автоматическая повторная отправка в этот момент создаёт риск дубля; поэтому задача должна получить статус «результат неизвестен», а не сразу вернуться в очередь.

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

Если ни безопасного повтора, ни подходящего поиска нет, оставьте задачу на проверку сотруднику. В карточке спорной отправки покажите заказ, текст SMS, время запроса, известный ответ сервиса и следующее доступное действие. Сотрудник сможет проверить статус, не разбирая технический журнал вместе с разработчиком. Похожий разбор сбоя для записей клиентов есть в статье на isalon.by; для магазина вместо записи на услугу нужно сверять состояние заказа и доставки.

Перед любой новой попыткой проверьте, актуален ли текст. Пока CRM выясняла результат, покупатель мог отменить заказ, а сотрудник — назначить другую дату доставки. SMS со старым интервалом отправлять уже нельзя. Если новая дата пока неизвестна, лучше сообщить, что магазин пришлёт следующий статус отдельным уведомлением, чем обещать неподтверждённое время (smsinfo.by).

Отдельно различайте статусы «сервис принял запрос» и «SMS доставлено». Первый подтверждает работу сервиса с запросом, но не получение сообщения покупателем. Если отчёт о доставке не пришёл, это тоже не повод автоматически отправлять тот же текст ещё раз: значение статусов нужно сверить с документацией сервиса.

Что проверить перед запуском уведомлений?

Составьте для разработчика несколько тестов на одном заказе. В каждом тесте смотрите не только на SMS у получателя, но и на историю задачи в CRM: какой ключ она получила, менялся ли статус и появилось ли ответственное лицо, если результат остался неизвестным.

• Сервис принял запрос, но CRM не получила ответ. Проверьте, что повтор не ушёл автоматически, а задача получила статус «результат неизвестен».
• Сайт или CRM дважды передали одно изменение заказа. В истории должна остаться одна задача на SMS.
• Два процесса одновременно получили событие о переносе доставки. Проверьте, что они не создали две задачи с одним ключом.
• Заказ отменили, пока CRM выясняла судьбу SMS. Система не должна отправлять устаревшее уведомление после проверки.

Если магазин передаёт сведения о доставке из CRM в другие системы, проследите, какое событие меняет статус заказа и запускает уведомление. В частности, при передаче заказов в Белпочту из CRM полезно заранее определить, какие изменения предназначены покупателю, а какие нужны только сотрудникам. Иначе техническое обновление карточки легко принять за повод отправить ещё одно SMS.

Такие проверки удобно включить в задачу на автоматизацию процессов: исполнителю нужен не общий запрос «убрать дубли», а список событий, статусов и ожидаемых действий при сбое. После запуска сотруднику достаточно видеть спорные задачи в отдельном списке, а разработчику — историю ключей и запросов.

Какие ошибки чаще всего оставляют дубли в системе?

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

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