SMS-статусы доставки связывают интернет-магазин, службу доставки и покупателя в одну цепочку. После изменения заказа система сама отправляет сообщение: заказ принят, передан в доставку, прибыл в пункт выдачи или готов к получению. В статье разберём, какие статусы нужны, как передавать их из CRM или сайта и что проверить перед запуском. Такой сценарий подходит микро-, малому и среднему бизнесу Беларуси, который принимает заказы через сайт, форму или интернет-магазин.
Зачем интернет-магазину автоматические статусы доставки?
Без автоматизации менеджер вручную проверяет кабинет службы доставки, копирует номер отправления, пишет клиенту и меняет этап заказа в CRM. При потоке 30–40 заказов в день на такие действия может уходить несколько часов, а каждый заказ проходит один и тот же цикл (IBZ Source). Ошибка в одном символе номера телефона или накладной приводит к пропущенному сообщению.
Автоматическая схема убирает повторяющийся перенос данных. Интернет-магазин передаёт заказ перевозчику, получает идентификатор отправления, а затем принимает обновления по его статусу. Клиент видит, что происходит с покупкой, без звонка менеджеру.
Для бизнеса в Беларуси это особенно полезно, когда заказы идут из разных городов: например, из Минска в Брест, Гомель, Гродно или небольшой населённый пункт. Менеджеру не приходится отдельно объяснять каждому покупателю, дошла ли посылка до пункта выдачи.
Какие SMS-статусы нужны покупателю?
Статусы стоит выбирать по действиям клиента. Если сообщение не помогает понять, что делать дальше, его лучше не отправлять. Базовая последовательность выглядит так:
| Этап заказа | Что получает клиент | Зачем отправлять SMS |
|---|---|---|
| Заказ принят | Номер заказа и краткое подтверждение | Покупатель понимает, что заявка зарегистрирована |
| Заказ передан в доставку | Название службы и номер отправления | Клиент получает данные для отслеживания |
| Заказ прибыл в пункт выдачи | Адрес пункта и срок хранения, если он передан системой доставки | Покупатель может забрать отправление |
| Курьер получил заказ | Информация о переходе заказа к курьеру | Клиент понимает, что доставка перешла на следующий этап |
| Доставка перенесена | Новая дата или просьба связаться с магазином | Снижается неопределённость по заказу |
| Заказ выдан или доставлен | Подтверждение завершения доставки | В CRM можно закрыть заказ и запустить следующий сервисный сценарий |
Необязательно отправлять сообщение на каждое техническое изменение. Например, внутренний статус «создана накладная» не всегда нужен покупателю. Для начала достаточно четырёх событий: принятие заказа, передача в доставку, прибытие и завершение.
Как связать сайт, CRM и службу доставки?
Сначала опишите путь заказа на бумаге. Зафиксируйте, где появляется заказ, в какой системе хранится телефон клиента, где создаётся отправление и откуда магазин получает новый статус. Если один этап выполняет менеджер вручную, его нужно либо автоматизировать, либо оставить как контрольную точку.
Обычно интеграция состоит из нескольких частей:
- Сайт или форма передают в CRM номер заказа, состав покупки, адрес и контактный номер.
- CRM создаёт заказ в системе службы доставки или передаёт данные через готовый модуль.
- Служба доставки возвращает номер отправления и изменения статуса.
- Интеграционный сценарий сопоставляет статус с шаблоном SMS.
- Сервис уведомлений отправляет сообщение, а результат доставки фиксируется в журнале.
В статье про SMS и Viber-уведомления о статусе заказа можно сравнить варианты каналов для разных этапов. Для информационных событий SMS удобно оставить основным каналом, если сообщение связано с уже оформленным заказом: код, статус, адрес или инструкция по получению.
Если сайт работает на конструкторе, проверьте, умеет ли его модуль доставки передавать полный набор статусов. В материалах об интеграции интернет-магазинов со службой доставки описывается типичная проблема: виджет может считать только часть тарифов, а заказ не попадает в кабинет перевозчика без дополнительной настройки (IBZ Source). Поэтому тестировать нужно не только форму расчёта, но и весь путь от оформления до SMS.
Как написать SMS о статусе заказа?
Сообщение должно отвечать на три вопроса: какой заказ изменился, что произошло и какое действие доступно клиенту. Текст лучше собирать из переменных, чтобы номер заказа, город, адрес и ссылка на отслеживание подставлялись автоматически.
Пример подтверждения:
«Заказ №{{номер}} принят. Мы сообщим, когда он будет передан в доставку».
Пример передачи перевозчику:
«Заказ №{{номер}} передан в доставку. Номер отправления: {{трек-номер}}».
Пример прибытия:
«Заказ №{{номер}} прибыл в пункт выдачи: {{адрес}}. Заберите его по графику пункта».
Пример переноса:
«Доставка заказа №{{номер}} перенесена. Новая дата: {{дата}}. Если дата не подходит, ответьте магазину».
Не помещайте в одно SMS историю заказа, рекламное предложение и несколько инструкций. Покупатель должен сразу увидеть нужное действие. Персонализация здесь означает подстановку данных конкретной покупки: номера заказа, имени, адреса или даты, если эти значения уже есть в системе. Такой подход описан в материале о персонализации SMS (IBZ Source).
Что проверить перед запуском автоматизации?
Сначала создайте тестовый заказ и проведите его по всем этапам. Для проверки используйте отдельный номер, чтобы увидеть фактический текст, порядок отправки и время появления сообщения. Затем повторите тест с отменой или переносом доставки.
- Проверьте, что один статус не запускает два одинаковых SMS.
- Сверьте номер заказа и номер отправления в сообщении с данными CRM.
- Убедитесь, что отменённый заказ не отправляет SMS о прибытии.
- Проверьте, что при временной ошибке интеграция не теряет обновление.
- Определите, кто видит журнал отправки и разбирает недоставленные сообщения.
- Согласуйте формулировки статусов с менеджерами, которые общаются с клиентами.
Отдельно проверьте переходы между похожими статусами. Служба доставки может прислать несколько технических событий, которые для покупателя означают одно и то же: посылка принята на сортировке, отправлена из сортировочного центра, прибыла в город. В SMS достаточно одного понятного этапа, иначе клиент получит серию сообщений без нового действия.
Какие ошибки чаще всего ломают цепочку уведомлений?
- Статус меняют вручную в двух системах. CRM показывает одно состояние, кабинет доставки другое, поэтому SMS уходит с задержкой или повторяется.
- В шаблоне нет номера заказа. Клиенту приходится угадывать, к какой покупке относится уведомление.
- Тестируют только успешную доставку. Сценарии отмены, возврата и переноса остаются без правил.
- Передают в SMS внутренние названия. Формулировка «shipment_in_transit» понятна системе, но не покупателю.
- Не предусмотрена ручная корректировка. Если адрес изменился после оформления, менеджер должен иметь способ обновить данные до следующего статуса.
Для небольшого магазина разумно начинать с короткой цепочки и четырёх основных событий. После первой недели работы можно посмотреть журнал отправок: какие статусы приходят, где возникают дубли и на каком этапе менеджеры вмешиваются вручную. Затем добавляют только те правила, которые закрывают конкретную проблему в заказах.
3 шага, которые можно сделать на этой неделе:
- Записать все статусы заказа от оформления до получения и оставить в клиентской коммуникации только понятные события.
- Связать каждое событие с одним шаблоном SMS и переменными номера заказа, отправления, даты или адреса.
- Провести тестовый заказ, проверить повторные статусы, отмену и перенос, затем передать схему интегратору или настроить её в используемой CRM.
