SMS-уведомления о возврате помогают интернет-магазину держать клиента в курсе каждого этапа: от регистрации заявки до перечисления денег. Для этого в магазине задают понятные статусы, связывают их с API SMS-шлюза и отправляют сообщение после каждого подтверждённого события. В статье разберём структуру сценария, тексты сообщений, защиту от дублей и контроль доставки. В результате клиент понимает, что происходит с возвратом, а сотрудники магазина реже отвечают на одинаковые вопросы вручную.
Какие статусы возврата нужно передавать клиенту?
Сначала опишите процесс возврата в виде последовательности событий. Названия статусов внутри системы могут быть техническими, но в SMS клиенту нужен обычный язык. Для небольшого интернет-магазина достаточно такой цепочки:
- Заявка на возврат получена.
- Магазин проверяет основание и данные заказа.
- Возврат одобрен или отклонён с объяснением причины.
- Товар поступил на проверку.
- Возврат принят.
- Деньги отправлены покупателю.
Не отправляйте сообщение при каждом внутреннем изменении карточки заказа. Например, переходы «назначен сотрудник» и «открыта задача бухгалтеру» клиенту обычно не помогают. Для SMS оставьте события, которые меняют ожидания покупателя: заявку зарегистрировали, товар получили, решение приняли, деньги отправили.
Полезно разделить статусы на обязательные и дополнительные. Обязательные показывают движение возврата, дополнительные нужны только в случае задержки или нехватки данных. Такой подход снижает число сообщений и не превращает уведомления в журнал действий сотрудников.
Как связать возврат с SMS через API?
Интеграция начинается с источника события. Им может быть интернет-магазин, CRM или отдельный модуль обработки возвратов. Когда сотрудник или система меняет статус, приложение передаёт в SMS-шлюз номер телефона, текст, идентификатор возврата и имя отправителя. Шлюз возвращает результат принятия запроса, а после отправки передаёт статус доставки.
Для обмена между магазином и сервисом рассылок часто используют вебхуки. Они позволяют передавать событие сразу после изменения статуса, без постоянной ручной проверки. Схему такого соединения удобно разобрать в материале «Вебхуки для SMS: как связать магазин, CRM и доставку».
У каждого возврата должен быть собственный идентификатор. Перед отправкой система проверяет, отправлялось ли уже сообщение для этого идентификатора и конкретного статуса. Если API повторит запрос после временной ошибки, клиент не получит два одинаковых SMS.
В запросе также стоит хранить шаблон и его версию. Тогда можно понять, какой текст ушёл покупателю, если сотрудник позже изменит шаблон. Для проверки технической части пригодится отдельный разбор причины дублей: «Почему SMS отправляется дважды: защита API и SMPP от дублей».
Какими должны быть тексты SMS о возврате?
Сообщение должно отвечать на три вопроса: что произошло, с каким заказом это связано и что делать дальше. Если от клиента ничего не требуется, так и напишите. Если магазин ждёт посылку, укажите способ передачи товара и канал для связи, который уже используется в компании.
| Событие | Пример текста | Действие клиента |
|---|---|---|
| Заявка получена | «Магазин получил заявку на возврат по заказу №4821. Проверим данные и сообщим о решении.» | Ждать решения |
| Нужны уточнения | «Для возврата по заказу №4821 нужны уточнения. Ответьте сотруднику магазина удобным способом.» | Предоставить данные |
| Возврат одобрен | «Возврат по заказу №4821 одобрен. Передайте товар способом, указанным в инструкции магазина.» | Передать товар |
| Товар получен | «Магазин получил товар по возврату №4821. После проверки сообщим о результате.» | Ждать проверки |
| Деньги отправлены | «Возврат по заказу №4821 оформлен. Деньги отправлены выбранным способом.» | Проверить поступление |
Номер заказа лучше показывать в коротком виде, который легко сравнить с письмом или личным кабинетом. Не перегружайте SMS длинным описанием товара, полным адресом и внутренними комментариями. Если клиенту нужна подробная инструкция, добавьте короткую ссылку на страницу возврата. Перед запуском проверьте длину сообщения: в рекомендациях по SMS-шаблонам часто ориентируются на предел 160 символов для одного сообщения, а длинный текст может разделиться на несколько частей (SMSblog.ru).
Сумму возврата указывайте только после того, как бухгалтерия или платёжный модуль подтвердили операцию. Формулировка «деньги возвращены» до фактической отправки создаёт лишние обращения. Для статуса «платёж инициирован» используйте отдельный текст: он сообщает о начале операции, но не обещает моментальное зачисление.
Как автоматизировать задержки и спорные возвраты?
Отдельно настройте сообщения для ситуаций, в которых процесс остановился. Например, магазин не получил товар, не хватает реквизитов или проверка занимает больше планового срока. Такое SMS должно объяснять причину и следующий шаг, иначе клиент увидит только отсутствие результата.
- Если посылка не поступила, сообщите, что возврат ожидает получения, и напомните способ передачи.
- Если не хватает данных, назовите конкретное поле или документ, который нужно уточнить.
- Если проверка завершилась отказом, укажите причину без внутреннего жаргона и предложите канал для вопроса.
- Если платёж вернулся с ошибкой, передайте обращение сотруднику и не отправляйте сообщение о завершённом возврате.
Для каждого исключения задайте срок повторной проверки. Система может напомнить сотруднику о зависшем возврате, но клиенту повторное SMS нужно отправлять только при появлении новой информации. Мониторинг транзакционных сообщений помогает видеть ошибки API, недоставленные SMS и события, которые не дошли до шлюза; практическая схема описана в материале «Как настроить мониторинг транзакционных SMS без программиста».
Какие ошибки мешают уведомлениям о возврате?
- Слишком общий текст. «Ваш запрос обрабатывается» не показывает, какой заказ имеется в виду и что будет дальше.
- Отправка из интерфейса сотрудника. Если сотрудник меняет статус, но не нажимает отдельную кнопку отправки, уведомление легко забыть.
- Повторная отправка после сбоя. Без уникального ключа повтор API создаёт дубли.
- Преждевременное сообщение о деньгах. Статус отправки платежа и фактическое зачисление нельзя смешивать.
- Один шаблон для всех событий. Клиенту сложно отличить заявку, одобрение и завершённый возврат.
Перед запуском проверьте сценарий на тестовом заказе. Создайте возврат, измените статусы по очереди, вызовите повтор запроса и убедитесь, что система сохраняет время отправки, ответ шлюза и итоговый статус доставки. Затем проверьте несколько вариантов номера заказа и текста, чтобы шаблон не ломался из-за подстановок.
3 шага, которые можно сделать на этой неделе:
- Составьте таблицу статусов возврата и оставьте в ней только события, понятные покупателю.
- Подготовьте отдельный шаблон для каждого события, добавив номер заказа и следующий шаг.
- Свяжите изменение статуса с API, включите защиту от дублей и настройте мониторинг доставки сообщений.
После этого возврат становится прозрачным для клиента: он получает сообщение в момент подтверждённого изменения, а магазин видит, на каком этапе возникла проблема. Для e-commerce такую схему можно подключить как отдельную интеграцию SMS API с транзакционными уведомлениями и отчётностью, без ручной отправки каждого сообщения.
