SMS-уведомления о заказах с маркетплейсов настраивают через связку площадки, магазина или CRM и SMS API. Сначала система получает событие, затем проверяет статус заказа и отправляет подходящий шаблон: о создании, оплате, сборке, передаче в доставку или готовности к выдаче. В статье разберём структуру такого сценария, необходимые данные, защиту от дублей и контроль доставки, чтобы владелец небольшого интернет-магазина понимал, что именно нужно подключить.
Какие события нужно передавать из маркетплейса?
Начните с карты статусов. У каждой площадки свои названия этапов, поэтому в SMS-сценарии лучше использовать понятные бизнес-состояния: заказ создан, оплата подтверждена, заказ собирается, передан в доставку, прибыл в пункт выдачи, отменён или возвращён.
Для каждого события зафиксируйте четыре поля:
- какой статус пришёл из маркетплейса;
- какое сообщение нужно отправить;
- кому передать данные, например покупателю или сотруднику магазина;
- что делать при повторной передаче одного и того же события.
Пример карты может выглядеть так: статус «оплачен» запускает подтверждение заказа, «передан перевозчику» отправляет информацию о доставке, а «готов к выдаче» сообщает клиенту, что заказ можно забрать. Если маркетплейс не передаёт отдельный статус, его не стоит имитировать в SMS: клиент должен получать только подтверждённую информацию.
Техническую связь между магазином, CRM и доставкой часто строят через вебхуки. Такой подход позволяет передавать событие сразу после изменения статуса, не проверяя заказ вручную через Excel или административную панель. Подробно архитектура описана в материале про вебхуки для SMS, магазина, CRM и доставки.
Как выглядит цепочка SMS от оформления до доставки?
Рабочий сценарий состоит из нескольких последовательных шагов. Маркетплейс или внутренняя система фиксирует изменение заказа и отправляет его в интеграцию. Интеграция определяет нужный шаблон, подставляет данные и передаёт запрос в SMS API. После этого сервис возвращает технический идентификатор сообщения и статус отправки.
- Оформление заказа. Система получает номер заказа, телефон клиента и время создания. Если площадка уже сама информирует покупателя, повторное SMS не отправляют.
- Подтверждение оплаты. Сообщение можно использовать, если магазин отвечает за оплату или получает отдельное подтверждение. В тексте укажите номер заказа и следующий шаг.
- Сборка. Клиенту сообщают, что заказ принят в работу. Этот этап особенно полезен, когда между оплатой и передачей в доставку проходит время.
- Передача в доставку. В SMS указывают номер заказа, перевозчика или способ получения, если эти данные доступны, и ссылку на страницу отслеживания.
- Готовность к выдаче. Для самовывоза сообщение отправляют после фактического поступления заказа в пункт выдачи, а не сразу после создания накладной.
- Отмена или возврат. Клиент получает информацию о результате обработки заказа. Для возврата полезно указать, куда обращаться по следующему вопросу.
В тексте сообщения оставляйте только данные, которые помогают понять ситуацию. Например: «Заказ №4812 передан в доставку. Следите за статусом: ссылка». Длинное описание товара, внутренние комментарии менеджера и несколько ссылок в один SMS не нужны.
Какие данные нужны для персонального уведомления?
Минимальный набор зависит от события, но обычно интеграция работает с номером заказа, телефоном, статусом, названием магазина и ссылкой на карточку заказа. Для доставки добавляются номер отправления или ссылка на отслеживание. Если у клиента несколько заказов, номер в сообщении помогает не перепутать их.
| Событие | Данные в SMS | Практический смысл |
|---|---|---|
| Заказ создан | Номер заказа, название магазина | Клиент понимает, что заявка принята |
| Оплата подтверждена | Номер заказа, следующий этап | Снижается неопределённость после оплаты |
| Передан в доставку | Номер заказа, ссылка на отслеживание | Покупатель видит, где искать актуальный статус |
| Готов к выдаче | Номер заказа, адрес или название точки, срок хранения | Клиент получает инструкцию для получения |
| Отмена или возврат | Номер заказа, причина или способ связи | Покупатель понимает, что произошло дальше |
Переменные нужно проверять до отправки. Если в заказе нет ссылки, шаблон не должен содержать пустой адрес. Если отсутствует срок хранения, его нельзя подставлять из общего текста без проверки: условия могут различаться для разных способов получения.
Как защитить клиента от повторных SMS?
Повторная отправка возникает, когда маркетплейс несколько раз передаёт одно событие или интеграция повторяет запрос после задержки ответа. Для защиты создайте уникальный ключ сообщения: например, сочетание номера заказа и статуса. Перед отправкой система проверяет, отправлялся ли такой ключ раньше.
Отдельно храните результат обработки: «создано», «передано провайдеру», «доставлено», «ошибка». Если API не ответил, запрос можно повторить по правилам очереди. Если SMS уже передано провайдеру, повторять его без проверки не стоит.
Для каждого типа сообщения задайте приоритет. Подтверждение оплаты и информация о готовности к выдаче обычно важнее рекламного предложения. При сбое интеграции сервисные уведомления должны попадать в очередь первыми, а второстепенные сообщения можно временно отложить.
Контроль статусов нужен и после отправки. В отчёте полезно видеть время события, номер заказа, тип SMS, результат API и финальный статус доставки. Практический чек-лист мониторинга транзакционных сообщений собран в материале о контроле доставки сервисных SMS.
Какие шаблоны подходят для основных статусов?
Шаблон должен отвечать на один вопрос клиента: что произошло с заказом и что делать дальше. Название магазина лучше ставить в начале, а ссылку использовать только там, где она ведёт на понятную страницу.
- Создание: «Заказ №{номер} принят магазином. Мы сообщим, когда он перейдёт на следующий этап».
- Оплата: «Оплата заказа №{номер} подтверждена. Заказ передан на сборку».
- Доставка: «Заказ №{номер} передан в доставку. Статус: {ссылка}».
- Готовность: «Заказ №{номер} готов к получению. Адрес: {точка}. Возьмите документ, если он нужен для выдачи».
- Отмена: «Заказ №{номер} отменён. Если нужна проверка причины, ответьте менеджеру через форму поддержки».
Перед запуском проверьте сообщения на реальных тестовых заказах. Отдельно протестируйте кириллицу, длинные номера, пустые переменные и ссылку. Короткий текст снижает риск того, что сообщение разобьётся на несколько частей; в материалах о шаблонах SMS часто используют ориентир до 160 символов, но фактическую длину лучше проверять в конкретном сервисе.
Какие ошибки чаще всего ломают сценарий?
- Отправка SMS на каждый технический статус без карты клиентских событий. Покупатель получает несколько сообщений об одном этапе.
- Отсутствие защиты от дублей. Один повторный webhook запускает вторую отправку.
- Подстановка данных до проверки. В сообщении появляются пустые скобки, неверный номер или нерабочая ссылка.
- Смешивание сервисных и рекламных задач. Информация о доставке теряется среди предложений магазина.
- Отсутствие журнала ошибок. Менеджер видит заказ в системе, но не понимает, почему SMS не ушло.
- Тестирование только успешного пути. После запуска обнаруживаются проблемы с отменой, возвратом или повторным запросом.
Для небольшого магазина разумно начать с четырёх событий: заказ создан, оплата подтверждена, передан в доставку и готов к выдаче. Затем добавить отмену, возврат и отдельные правила для разных способов получения. Интеграция SMS API, транзакционные уведомления и мониторинг должны описываться в одной схеме, чтобы менеджер видел не только отправку, но и результат.
3 шага, которые можно сделать на этой неделе:
- Составить таблицу статусов маркетплейса и понятных клиентских событий.
- Подготовить по одному короткому шаблону для оплаты, доставки, выдачи и отмены.
- Проверить вебхуки, защиту от дублей и отчёт по статусам на тестовых заказах.
