Як автоматизувати сповіщення про відправлення: тригери, канали та шаблони у 6 кроків

Щоб автоматизувати сповіщення про відправлення, підключіть події відправлення до записів замовлень, визначте, які зміни статусу потребують повідомлення, виберіть дозволений канал доставки та додайте шаблон до кожного тригера. Потім перед запуском додайте захист від дублювання, обробку винятків і тестування. Нижче наведено шість кроків, які покажуть командам електронної комерції, як створити робочий процес, що надає клієнтам корисні оновлення, не надсилаючи повторюваних або оманливих сповіщень.

Цей посібник призначений для продавців, операційних команд електронної комерції та розробників, відповідальних за комунікацію після покупки. Рекомендована відправна точка — невеликий набір надійних сповіщень: прийняття перевізником, передача кур’єру для доставки, доставлено та винятки, що потребують дій клієнта. Додавайте інші повідомлення лише тоді, коли вони відповідають на окреме запитання клієнта.

1. Підключіть події відстеження до правильного замовлення й отримувача

Транспортна накладна, сканування перевізником і сповіщення клієнта — це різні речі. Створення накладної не означає, що перевізник отримав посилку. Ваша автоматизація має з самого початку зберігати цю відмінність.

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

Є два практичні способи реалізації:

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

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

• Посилання на замовлення та ідентифікатор відправлення.
• Номер відстеження та ідентифікатор перевізника, якщо доступні.
• Товари, що входять до цього відправлення, особливо для розділених замовлень.
• Контактні дані клієнта, мову, часовий пояс і налаштування каналів.
• Останній прийнятий статус відправлення та час виникнення події.
• Історію сповіщень, зокрема інформацію про те, якого відправлення стосувалося кожне повідомлення.

Зберігайте час виникнення події окремо від часу отримання оновлення вашою системою. Затримане сканування не має автоматично ставати новим сповіщенням для клієнта. Також зберігайте оригінальний опис перевізника разом із нормалізованим статусом, щоб служба підтримки могла досліджувати неоднозначні події.

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. Перевірте весь шлях, а потім поступово запускайте систему

Не оцінюйте робочий процес лише за тим, чи правильно виглядає тестовий електронний лист. Перевірте весь шлях від події відправлення до місця призначення клієнта, включно з випадками помилок.

• Звичайний шлях: Прийняття, рух, передача для доставки та доставка створюють передбачені повідомлення.
• Повторна подія: Повторне відтворення тієї самої події не створює нового сповіщення.
• Подія не за порядком: Затримане сканування під час руху не запускає застаріле сповіщення після доставки.
• Розділене замовлення: Кожне повідомлення визначає правильне відправлення і не створює враження, що прибули всі товари.
• Відсутні поля: Відсутність імені, перевізника, оцінки або списку товарів створює зрозумілий резервний текст.
• Обмеження контактів: Робочий процес дотримується налаштувань каналів, правил придушення та налаштованих тихих годин.
• Помилка доставки: Недійсні адреси, помилки провайдера та повторні спроби створюють відстежувані результати без неконтрольованих повторних надсилань.
• Дія клієнта: Кожне посилання на відстеження та підтримку веде на потрібне місце на мобільному пристрої.

Почніть з обмеженої групи відправлень і переглядайте історію повідомлень разом з історією відстеження. Надайте співробітникам служби підтримки можливість бачити, що отримав клієнт. Збережіть елемент паузи, щоб команда могла зупинити несправне правило, не вимикаючи саме відстеження відправлень.

Відстежуйте право на сповіщення, спроби надсилання, прийняття провайдером, помилки, дублікати та затримку між отриманням події й надсиланням повідомлення. Прийняття провайдером не означає, що клієнт прочитав повідомлення, а самі показники відкриття не доводять, що робочий процес був корисним.

Щоб оцінити вплив на клієнтів, порівнюйте частоту звернень, пов’язаних із відправленнями, використовуючи послідовне визначення та зіставні групи відправлень. Перед тим як пов’язувати зміну зі сповіщеннями, врахуйте зміни у складі перевізників, проблеми з доставкою та обсяг замовлень.

FAQ

Чи слід надсилати підтвердження відправлення, коли створено накладну?

Ви можете надіслати оновлення про створення накладної, але описуйте його точно. Скажіть, що дані доставки готові або відправлення готується. Формулювання, яке підтверджує отримання посилки перевізником, використовуйте лише для події, що це підтверджує.

Чи можуть сповіщення про відправлення працювати без інтеграції API?

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

Скільки сповіщень має отримувати кожне відправлення?

Універсальної ідеальної кількості не існує. Почніть із чітких, корисних етапів і винятків, що потребують дії. Придушуйте повторні сканування під час руху та додавайте повідомлення лише тоді, коли вони надають потрібну клієнту інформацію.

Що має відбуватися, коли відстеження припиняє оновлюватися?

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

Чи може сповіщення про доставку автоматично закрити звернення до служби підтримки?

Сканування доставки може оновити звернення, але не має автоматично вирішувати повідомлення клієнта про неотримання. Розглядайте статус доставки перевізника та проблему клієнта як окремі записи, а потім дотримуйтеся процесу перевірки.

Джерела

• Сторінка застосунку 17TRACK для Shopify — довідковий матеріал для оцінювання налаштування відстеження та сповіщень на основі застосунку.
• 17TRACK Tracking API — довідковий матеріал для інтеграції відстеження на основі API.
• Документація 17TRACK API — довідковий матеріал для перевірки підтримуваної поведінки та вимог інтеграції.
• FTC: посібник із дотримання CAN-SPAM для бізнесу — рекомендації щодо комерційної електронної пошти та повідомлень, що поєднують транзакційний і рекламний вміст.