Как автоматизировать уведомления об отправке: триггеры, каналы и шаблоны за 6 шагов

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

Это руководство предназначено для продавцов, операционных команд электронной коммерции и разработчиков, отвечающих за коммуникацию после покупки. Рекомендуется начать с небольшого набора надёжных уведомлений: принятие перевозчиком, передача курьеру для доставки, доставлено и исключения, требующие действий клиента. Добавляйте другие сообщения только тогда, когда они отвечают на отдельный вопрос клиента.

1. Свяжите события отслеживания с правильным заказом и получателем

Транспортная этикетка, сканирование перевозчиком и уведомление клиента — это разные вещи. Создание этикетки не означает, что перевозчик получил посылку. Автоматизация должна с самого начала сохранять это различие.

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

Есть два практических способа реализации:

• Настройка на основе приложения: используйте приложение для отслеживания электронной коммерции, если ваша команда хочет настроить поддерживаемые события и сообщения для клиентов без создания всей интеграции с нуля. Для продавцов Shopify релевантной отправной точкой для оценки рабочих процессов отслеживания отправлений и уведомлений является список приложений 17TRACK. Перед настройкой правил подтвердите конкретные триггеры, каналы, возможности кастомизации и требования тарифного плана.
• Настройка на основе API: используйте интеграцию отслеживания, если события отправлений должны поступать в существующую систему заказов или пользовательский рабочий процесс обмена сообщениями. 17TRACK Tracking API и его официальная документация являются релевантными справочными материалами для реализации. Подтвердите механизм доставки событий, поля полезной нагрузки, аутентификацию и поведение при повторных попытках для планируемой интеграции. Получение данных отслеживания и отправка сообщений клиентам — это отдельные обязанности.

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

• Номер заказа и идентификатор отправления.
• Номер отслеживания и идентификатор перевозчика, если доступны.
• Товары, входящие в это отправление, особенно для разделённых заказов.
• Контактные данные клиента, язык, часовой пояс и предпочтения по каналам.
• Последний принятый статус отправления и время возникновения события.
• Историю уведомлений, включая указание, какого отправления касалось каждое сообщение.

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

2. Определите триггеры, отражающие значимые изменения статуса отправления

Триггер должен представлять изменение, важное для клиента, а не каждую новую запись отслеживания. Несколько сканирований на объектах перевозчика могут означать одно и то же — «в пути». Отправка уведомления по каждому из них создаёт информационный шум и не помогает клиенту принять решение.

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

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

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

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

3. Выберите каналы и установите правила контакта

Используйте канал потому, что он подходит сообщению и предпочтениям клиента, а не просто потому, что он доступен. Электронная почта — практичная отправная точка для подробных обновлений. Более оперативный канал может быть полезен для срочного действия, но только если это разрешено согласием клиента, правилами провайдера и местными требованиями.

• Электронная почта: подходит для контекста заказа, ссылок отслеживания, объяснений разделённых отправлений и инструкций службы поддержки. Добавляйте версию в виде обычного текста и проверяйте отображение на мобильных устройствах.
• SMS: полезны для коротких уведомлений, требующих действия, если это разрешено. Указывайте отправителя, сохраняйте фокус сообщения и не раскрывайте лишнюю информацию о заказе.
• Push-уведомления: подходят, когда клиенты используют ваше приложение и включили уведомления. Ссылайтесь на соответствующее отправление, а не на общую главную страницу.
• Приложения для обмена сообщениями: рассматривайте их, если клиенты уже используют этот канал, а ваша реализация соответствует требованиям платформы к разрешениям и сообщениям.
• Страница отслеживания: используйте её как подробный источник информации. Она дополняет исходящие уведомления, но не заменяет их, когда клиенту необходимо действовать.

Документируйте взаимосвязь между каналами. Например, можно использовать электронную почту для стандартных этапов, а разрешённый мобильный канал — для проблемы доставки, требующей действия. Не отправляйте автоматически каждое событие через все доступные каналы.

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

Сохраняйте операционный характер обновлений об отправлении. Добавление рекламного контента может повлиять на то, как сообщение рассматривается в соответствии с применимыми правилами. В США руководство FTC по CAN-SPAM объясняет, что основное назначение сообщения имеет значение, когда коммерческий и транзакционный контент объединены. Не следует предполагать, что каждое сообщение с упоминанием заказа освобождено от требований к коммерческой электронной почте.

4. Создайте шаблоны с понятным резервным поведением

Каждый шаблон должен отвечать на три вопроса: что произошло? Что это означает для данного отправления? Что клиенту следует сделать дальше? Используйте условные поля, чтобы отсутствующие данные корректно исчезали, а не оставляли повреждённые заполнители.

Примеры ниже являются стартовыми шаблонами. Переменные в квадратных скобках приведены для иллюстрации и не представляют синтаксис шаблонов конкретной платформы.

Письмо о принятии перевозчиком

Тема: Ваше отправление по заказу [order_number] уже в пути

Здравствуйте, [first_name]!

[carrier_name] получил ваше отправление по заказу [order_number]. Вы можете отслеживать его продвижение здесь: [tracking_link].

[Если доступна надёжная оценка: Предполагаемая дата доставки: [estimated_delivery_date]. Эта оценка может измениться.]

[Если заказ разделён: Это отправление содержит: [shipment_items]. Для остальных товаров вашего заказа будут доступны отдельные обновления отслеживания.]

Сообщение о передаче курьеру для доставки

Согласно последнему обновлению перевозчика, ваше отправление по заказу [order_number] передано курьеру для доставки. Проверьте его продвижение и доступные сведения о доставке: [tracking_link].

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

Сообщение об исключении с подтверждённым следующим шагом

Тема: Обновление доставки по заказу [order_number]

Перевозчик сообщил о следующей проблеме с вашим отправлением: [plain_language_issue]. [verified_next_step]. Последние сведения доступны здесь: [tracking_link]. Если вам нужна помощь, свяжитесь с нами: [support_link].

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

Письмо о доставке

Тема: Ваше отправление отмечено как доставленное

[carrier_name] отметил ваше отправление по заказу [order_number] как доставленное [delivery_date]. Доступные сведения о доставке можно посмотреть здесь: [tracking_link]. Если вы не можете его найти, свяжитесь с нами по адресу [support_link], чтобы мы помогли определить дальнейшие шаги.

Для разделённых заказов используйте формулировки на уровне отправления. Фраза «Ваш заказ доставлен» может вводить в заблуждение, если другая посылка всё ещё находится в пути. Если имя перевозчика, дата или имя клиента недоступны, используйте проверенное альтернативное предложение вместо отображения пустого поля.

5. Добавьте защиту от дублирующихся, устаревших и вводящих в заблуждение сообщений

Автоматизации необходима запись уже выполненных действий. Рабочий процесс, который просто отправляет сообщение при поступлении события, может повторять уведомления после повторных попыток или доставлять устаревшие новости после нового этапа.

• Предотвращайте повторную обработку: используйте стабильный идентификатор события, если он доступен. В противном случае определите ключ дедупликации на основе подходящих полей, например отправления, типа события и времени его возникновения. Отдельно записывайте, было ли соответствующее уведомление запланировано или отправлено.
• Подавляйте повторение статусов: несколько сканирований, сопоставленных с одним и тем же клиентским статусом, не должны автоматически создавать несколько сообщений.
• Проверяйте актуальность события перед отправкой: повторно оценивайте сообщения в очереди перед отправкой. Подавляйте старое уведомление «в пути», если после этого была зафиксирована доставка.
• Обрабатывайте исправления намеренно: сохраняйте исходную историю событий и проверяйте кажущиеся отклонения назад. Не предполагайте, что каждое поступившее позже событие является более новым или более точным.
• Безопасно выполняйте повторные попытки: отличайте неудачную отправку от неизвестного результата. Если поддерживается, используйте функции идемпотентности провайдера, чтобы снизить вероятность создания дополнительного сообщения при повторной попытке.
• Защищайте сопоставление получателя: никогда не связывайте отправление с клиентом только на основании непроверенного совпадения номера отслеживания.
• Эскалируйте нерешённые исключения: назначайте ответственного сотрудника вместо многократной отправки клиенту одного и того же предупреждения.

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

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

6. Протестируйте весь путь, затем запускайте постепенно

Не оценивайте рабочий процесс только по тому, правильно ли выглядит тестовое письмо. Тестируйте полный путь от события отправления до конечного пункта назначения клиента, включая сценарии с ошибками.

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

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

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

Чтобы оценить влияние на клиентов, сравнивайте частоту обращений, связанных с отправлениями, используя единое определение и сопоставимые группы отправлений. Перед тем как связывать изменение с уведомлениями, учитывайте изменения в составе перевозчиков, проблемы доставки и объём заказов.

Часто задаваемые вопросы

Следует ли отправлять подтверждение отправки при создании этикетки?

Вы можете отправить обновление о создании этикетки, но описывайте его точно. Укажите, что данные доставки готовы или что отправление подготавливается. Формулировку, подтверждающую получение перевозчиком, используйте только для события, которое это подтверждает.

Могут ли уведомления об отправлениях работать без интеграции API?

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

Сколько уведомлений должно получать каждое отправление?

Универсального идеального количества не существует. Начните с отдельных полезных этапов и исключений, требующих действий. Подавляйте повторные сканирования в пути и добавляйте сообщения только тогда, когда они предоставляют необходимую клиенту информацию.

Что должно происходить, если отслеживание перестало обновляться?

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

Может ли уведомление о доставке автоматически закрыть обращение в службу поддержки?

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

Источники

• 17TRACK Shopify app listing — справочная информация о продукте для оценки отслеживания и уведомлений на основе приложения.
• 17TRACK Tracking API — справочная информация о продукте для интеграции отслеживания на основе API.
• 17TRACK API documentation — справочный материал по реализации для проверки поддерживаемого поведения и требований интеграции.
• FTC: CAN-SPAM Act compliance guide for business — руководство по коммерческой электронной почте и сообщениям, объединяющим транзакционный и рекламный контент.