Как настроить SMS о задержке заказа и новой доставке

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

Какие данные нужны для SMS о задержке заказа?

Автоматизация начинается с события в системе заказов. Например, менеджер меняет статус на «Доставка задерживается», перевозчик передаёт новый прогноз или склад отмечает, что заказ не готов к передаче. После этого система собирает данные для сообщения и передаёт их в SMS-сервис через API.

Минимальный набор полей выглядит так:

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

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

Для интернет-магазина Беларуси дата должна быть понятной в местном формате: например, «24 августа» или «24.08». Если доставка возможна в течение дня, укажите интервал. Номер заказа должен совпадать с тем, который видит покупатель в письме, личном кабинете или чеке.

Как написать SMS, чтобы клиент понял ситуацию?

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

Базовый шаблон:

«{Имя}, заказ №{номер} задерживается. Новая дата доставки: {дата}, {интервал}. Следующий статус: {ссылка}. Вопросы: {контакт}».

Если магазин пока не получил точную дату, текст можно построить иначе:

«{Имя}, доставка заказа №{номер} переносится. Мы уточняем новый срок и сообщим его до {дата или время}. Статус заказа: {ссылка}.»

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

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

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

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

Для одного заказа удобно использовать цепочку из нескольких статусов:

1. «Заказ задерживается» — отправляется после фиксации проблемы.
2. «Новая дата подтверждена» — содержит дату и интервал доставки.
3. «Заказ передан в доставку» — сообщает, что заказ снова движется.
4. «Доставка сегодня» — отправляется только при наличии подтверждённого времени.

Каждый статус должен запускать отдельное событие. Если сотрудник несколько раз сохраняет одну и ту же карточку заказа, система не должна отправлять одинаковое SMS повторно. Для этого в интеграции хранят идентификатор события: например, «заказ 4815 плюс статус delay_confirmed». При повторном запросе система проверяет идентификатор и пропускает дубль. Практические причины повторной отправки и способы защиты разобраны в материале почему SMS отправляется дважды и как защитить API от дублей.

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

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

В запросе обычно передают номер телефона, текст, внутренний ID заказа и уникальный ID события. Ответ сервиса сохраняют рядом с заказом. Если SMS не ушло, менеджер получает понятную причину: неверный номер, превышение лимита, ошибка соединения или временная недоступность канала.

При интеграции через API проверьте четыре сценария:

• заказ получил статус задержки впервые;
• статус сохранили повторно;
• новая дата доставки изменилась;
• SMS-сервис вернул ошибку.

Для команды без отдельного разработчика полезно заранее описать события и поля в таблице. Например: «delay_created» запускает первое уведомление, «delivery_date_changed» запускает обновление, «delivered» закрывает ожидание доставки. Такой список помогает быстро согласовать настройку API и не смешивать сервисные уведомления с рекламными сообщениями.

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

Какие ошибки чаще всего портят сценарий?

• Нет новой даты. Сообщение сообщает о задержке, но не объясняет, что делать дальше. Если срок неизвестен, укажите время следующего обновления.
• Один статус запускает несколько SMS. Повторное сохранение карточки или повторный webhook создают дубли. Используйте уникальный ID события.
• В тексте остаются технические поля. Клиент видит «delivery_status_7» вместо нормального объяснения. Перед отправкой настройте шаблон с понятными подписями.
• Ссылка ведёт на ошибку. Проверьте её с мобильного устройства и убедитесь, что заказ находится без лишних действий.
• Менеджер не видит результат отправки. Статус SMS нужно возвращать в CRM, иначе сотрудник не знает, дошло ли уведомление.
• Нет отдельного тестового заказа. Сценарий проверяют на реальном покупателе, и ошибка становится частью клиентского опыта. Сначала используйте тестовый номер и тестовые статусы.

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

Сначала создайте несколько тестовых заказов с разными именами, датами и интервалами. Проверьте длину текста, отображение кириллицы, ссылку и корректность номера заказа. Затем повторите один и тот же запрос и убедитесь, что второе SMS не создаётся.

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

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