При частичной отгрузке интернет-магазин отправляет клиенту отдельные SMS по каждой посылке и один понятный итоговый статус по заказу. Для этого в CRM или CMS нужно разделить события заказа и отправлений, передавать их через API и не дублировать уже отправленные сообщения. В статье разберём структуру статусов, примеры текстов, логику автоматизации и ошибки, из-за которых клиент получает противоречивые уведомления.
Почему частичную отгрузку нужно показывать отдельными статусами?
Один заказ может состоять из товаров, которые находятся на разных складах. Часть позиций уже собрана, а остальные ещё ожидают комплектации. Если система отправит только сообщение «Заказ передан в доставку», клиент не поймёт, какие товары приехали и когда ждать остальные.
SMS здесь выполняет сервисную задачу: подтверждает событие, которого покупатель ждёт. Подтверждение заказа, изменение статуса доставки и чек об оплате относятся к уведомлениям, привязанным к конкретному действию клиента. Такие сообщения обычно читают сразу после получения, поэтому в них особенно важны точность статуса и понятный следующий шаг.
Логику лучше строить на двух уровнях:
- статус всего заказа: например, «частично отгружен»;
- статус каждой посылки: «собрана», «передана в доставку», «готова к выдаче» или «доставлена».
Например, заказ содержит четыре товара. Два товара магазин отправил сегодня, один будет готов завтра, а последний сняли из заказа из-за отсутствия. Клиенту нужны три разных факта: какая часть уже едет, когда появится следующая посылка и что произошло с недоступной позицией. Один общий статус эту информацию не заменит.
Для управления статусами можно взять за основу отдельную SMS-цепочку статуса заказа в интернет-магазине, а затем добавить в неё события нескольких отправлений.
Какие SMS отправлять на каждом этапе частичной отгрузки?
Сообщение должно отвечать на три вопроса: что произошло, какая часть заказа затронута и что клиенту делать дальше. В текст стоит подставлять номер заказа, номер отправления, состав посылки и ссылку на страницу отслеживания, если она предусмотрена системой.
| Событие | Что получает клиент | Пример SMS |
|---|---|---|
| Заказ подтверждён | Магазин принял заказ и начал обработку | Заказ №4582 принят. Мы сообщим, когда товары будут готовы к отправке. |
| Часть товаров собрана | Готов состав первой посылки | Заказ №4582 частично собран. Отправляем: куртку и перчатки. Остальные товары сообщим отдельным статусом. |
| Первая посылка передана в доставку | Появился номер отправления и срок | Посылка по заказу №4582 передана в доставку. Отправление 4582-1. Статус: ссылка. |
| Вторая часть готова | Сформирована следующая посылка | Вторая часть заказа №4582 готова к отправке. Отправим её отдельной посылкой. |
| Все части отправлены | Заказ полностью передан в доставку | Все товары из заказа №4582 отправлены. Проверьте статусы посылок: ссылка. |
| Часть товара недоступна | Нужно согласовать замену, возврат или отмену позиции | Товар «Рюкзак» из заказа №4582 временно недоступен. Свяжитесь с магазином, чтобы выбрать решение. |
Для первой SMS после частичной комплектации достаточно назвать товары. Если список длинный, лучше указать количество позиций и вывести полный состав на странице заказа. Клиенту будет проще разобраться, если номер отправления всегда имеет одинаковый формат: например, основной номер заказа с суффиксом «-1», «-2».
Сообщение о полной отгрузке отправляйте только после события, которое подтверждает передачу последней части. Проверка должна учитывать все отправления, а не только последнюю созданную запись. Иначе клиент получит фразу «заказ отправлен полностью», хотя одна позиция всё ещё находится на складе.
Как связать SMS с событиями в CRM или интернет-магазине?
Сначала определите, какая система считается источником правды. Это может быть CMS магазина, CRM или складской модуль. Именно она должна передавать в SMS API новые события. Сервис отправки отвечает за доставку и отчётность, но не должен самостоятельно угадывать, изменилась ли комплектация заказа.
Для каждого события передавайте отдельный набор полей:
- идентификатор заказа;
- идентификатор отправления;
- телефон получателя;
- текущий статус заказа;
- статус конкретной посылки;
- список товаров или краткое описание части заказа;
- номер отправления и ссылка на отслеживание;
- уникальный идентификатор события.
Уникальный идентификатор нужен для защиты от повторов. Если CRM повторно отправит один и тот же запрос после сбоя связи, API проверит идентификатор и не создаст вторую SMS. Для этого события «первая посылка передана» и «вторая посылка передана» должны иметь разные идентификаторы, даже если они относятся к одному заказу.
Какая последовательность событий нужна?
Практичная схема выглядит так: заказ принят, часть собрана, отправление создано, отправление передано в доставку, следующая часть собрана, второе отправление создано, все части отправлены. Названия можно адаптировать под вашу CRM, но смысл событий должен оставаться однозначным.
Не связывайте отправку SMS только с изменением общего статуса заказа. При частичной отгрузке общий статус часто меняется с «в работе» на «частично отгружен» один раз, а посылок может быть несколько. Триггер должен срабатывать при создании или изменении каждой записи отправления.
Перед подключением API полезно составить таблицу соответствий:
| Событие в системе | Условие отправки | SMS |
|---|---|---|
| Создано первое отправление | В отправлении есть хотя бы один товар | Уведомление о первой части заказа |
| Изменён статус отправления | Статус изменился с «собрано» на «передано» | Сообщение о передаче в доставку |
| Создано новое отправление | У него есть собственный номер | Уведомление о следующей части |
| Все отправления завершены | У каждой части финальный статус | Сообщение о полной отгрузке или завершении заказа |
После этого разработчику проще настроить вебхук или периодическую передачу событий. Для бизнеса без технического специалиста такую схему обычно оформляют как задачу на интеграцию SMS API: отдельно описывают статусы, переменные шаблона и правила повторной отправки.
Как избежать дублей и противоречивых уведомлений?
Сервисные SMS теряют смысл, если клиент получает пять сообщений об одной и той же посылке. Перед отправкой проверяйте, было ли такое событие успешно принято API. Статус «запрос создан» не всегда означает, что сообщение доставлено, поэтому в отчётности нужно различать отправку, доставку и ошибку.
Для каждого шаблона задайте собственный триггер. Например, SMS «заказ передан в доставку» отправляет только переход в этот статус. Повторное сохранение карточки заказа, изменение комментария менеджера или обновление состава товара не должны запускать тот же шаблон.
Если магазин изменил состав посылки после создания отправления, система должна выбрать одно правило: обновить существующее событие до отправки SMS или отправить отдельное уточнение. Молчаливое изменение данных приведёт к ситуации, когда в SMS указан один товар, а в посылке оказывается другой.
Что проверять перед запуском?
- Создаётся ли отдельный идентификатор для каждой посылки?
- Можно ли понять из SMS, к какому заказу и отправлению она относится?
- Не отправляется ли сообщение при каждом сохранении заказа?
- Что происходит, если API временно недоступен?
- Кто получает уведомление при отмене одной части заказа?
- Есть ли отчёт по статусам отправки и доставки?
Тестируйте минимум четыре сценария: один заказ с одной посылкой, заказ с двумя посылками, задержку второй части и отмену позиции. Для теста с двумя отправлениями проверьте порядок сообщений: сначала должна появиться информация о первой посылке, затем сообщение о второй, а финальный статус отправится после проверки всех частей.
Какие ошибки встречаются при частичной комплектации?
- Один статус на весь заказ. Клиент не понимает, какие товары уже отправлены. Храните статусы заказа и посылок отдельно.
- Номер заказа вместо номера отправления. При двух посылках покупатель не сможет отличить одну доставку от другой. Добавляйте идентификатор каждой части.
- Слишком подробный текст. Длинный список товаров затрудняет чтение. Оставьте в SMS краткий состав и ссылку на подробности.
- Повторная отправка после сбоя. Система создаёт дубль при повторе API-запроса. Используйте уникальный идентификатор события.
- Финальный статус отправляется слишком рано. Проверяйте завершение всех отправлений, включая те, которые ещё собираются.
- Нет мониторинга ошибок. Без отчёта менеджер не видит, какое уведомление не ушло. Настройте журнал запросов и статусов доставки.
Частичную отгрузку удобно автоматизировать, когда магазин передаёт в API не только номер заказа, но и отдельные события по каждой посылке. Начните с небольшой схемы: первая отправка, вторая отправка, полная отгрузка и отмена позиции. Затем добавьте шаблоны, защиту от дублей и мониторинг. Так SMS-интеграция поддерживает реальный путь заказа и сообщает клиенту ровно о том изменении, которое произошло.
