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