Как настроить SMS-уведомления о переносе доставки

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

Почему о переносе доставки нужно сообщать сразу?

Клиент планирует получение заказа по конкретной дате и интервалу. Если курьер или магазин меняет этот план, молчание быстро приводит к звонкам в поддержку, отменам и неудачным попыткам вручения. SMS доходит до телефона без входа в личный кабинет, поэтому подходит для короткого сообщения о факте изменения.

Для малого интернет-магазина достаточно начать с одного события: заказ получил статус «Доставка перенесена». В этот момент система отправляет клиенту новую дату, временной интервал и способ связи с магазином. Подробный разбор логики таких уведомлений приведён в материале как настроить SMS о задержке заказа и новой доставке.

Сообщение должно объяснять, что произошло с заказом и что делать дальше. Фраза «Доставка изменена» без даты оставляет клиента с тем же вопросом, который возник до отправки SMS. Минимальный набор данных выглядит так:

• номер заказа или его короткий идентификатор;
• новая дата доставки;
• новый временной интервал, если он изменился;
• ссылка или номер телефона для уточнения деталей;
• название магазина в начале или конце сообщения.

Какие сценарии переноса доставки подходят магазину?

Один шаблон на все случаи быстро становится неудобным. Перенос на несколько часов, перенос на другой день и необходимость согласовать новую дату требуют разных формулировок. Система может использовать отдельный шаблон для каждого события.

Пример для переноса на следующий день: «Магазин: доставка заказа №4582 перенесена на 27 августа, интервал 18:00–21:00. Уточнить детали: 8 XXX XXX XX XX». Такой текст сразу отвечает на главный вопрос клиента и не требует открывать сайт.

Если новая дата ещё неизвестна, не стоит подставлять приблизительное время. Лучше написать: «Заказ №4582 задерживается. Мы сообщим новую дату доставки до 18:00 26 августа. Телефон магазина: 8 XXX XXX XX XX». Обещание должно соответствовать реальному процессу: если сотрудник не контролирует срок, система не должна отправлять его автоматически.

Как связать магазин, CRM и SMS-сервис?

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

1. В магазине создайте отдельный статус «Перенос доставки».
2. Определите поля, которые меняет сотрудник: новая дата, интервал и комментарий.
3. Настройте передачу номера телефона, номера заказа и новых параметров доставки.
4. Создайте шаблон SMS с переменными вместо ручной вставки данных.
5. Передайте ответ сервиса обратно в CRM: принято, доставлено, не доставлено или ошибка.

В шаблоне лучше оставить только те переменные, которые система заполняет всегда. Если поле «новый интервал» иногда пустое, предусмотрите отдельный шаблон без него. Иначе клиент может получить текст с лишними символами, незаполненным значением или непонятным прочерком.

Для интеграции через API пригодятся защита от дублей и журнал событий. Например, сотрудник несколько раз открыл заказ и сохранил одну и ту же дату. Магазин должен проверить, отправлялось ли уведомление по этому изменению. В качестве ключа события можно использовать номер заказа, новый статус и время изменения.

Как не отправить клиенту несколько одинаковых SMS?

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

Для этого в журнале сохраняют идентификатор события, время запроса, текст или шаблон сообщения и статус отправки. Если API временно не ответил, запрос можно повторить, но с тем же уникальным идентификатором. При успешном принятии сообщения повторная попытка уже не нужна.

Как протестировать сценарий до запуска?

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

Проведите несколько последовательных проверок:

1. Поменяйте дату доставки и убедитесь, что SMS содержит новое значение.
2. Сохраните заказ повторно без изменений и проверьте отсутствие второго сообщения.
3. Очистите поле временного интервала и убедитесь, что сработал подходящий шаблон.
4. Передайте некорректный номер и проверьте, как система показывает ошибку.
5. Проверьте длинный номер заказа и текст на русском языке.
6. Сравните статус в SMS-сервисе с записью в магазине или CRM.

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

Типичные ошибки при переносе доставки

• Система отправляет SMS при любом сохранении заказа, даже если дата не менялась.
• В сообщении указывают старую дату из кэша или из другого поля заказа.
• Шаблон не объясняет, что клиенту делать после переноса.
• Сотрудник меняет дату вручную, но не меняет статус, который запускает отправку.
• Ошибки API не попадают в журнал, поэтому магазин узнаёт о проблеме только после жалобы клиента.
• Для задержки и переноса на другой день используют один текст, который подходит только для одного сценария.

Если магазин пока не готов к полной интеграции, начните с одного статуса и одного шаблона для переноса на конкретную дату. После тестов добавьте уведомление о задержке без новой даты и запрос на выбор интервала. Так настройка SMS API, транзакционных уведомлений и мониторинга остаётся управляемой даже при небольшом количестве технических ресурсов.