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

За да автоматизирате известията за пратки, свържете събитията за пратките със записите за поръчките си, определете кои промени в статуса заслужават съобщение, изберете разрешен канал за доставка и прикрепете шаблон към всеки тригер. След това добавете защита от дублиране, обработка на изключения и тестване, преди да стартирате. Шестте стъпки по-долу показват на екипите за електронна търговия как да изградят работен процес, който предоставя полезни актуализации на клиентите, без да изпраща повтарящи се или подвеждащи известия.

Това ръководство е предназначено за търговци, екипи по операциите в електронната търговия и разработчици, отговорни за комуникацията след покупка. Препоръчителната отправна точка е малък набор от надеждни известия: приемане от превозвача, пратката е извън склада за доставка, доставено и изключения, които изискват действие от клиента. Добавяйте други съобщения само когато отговарят на отделен въпрос на клиента.

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

Товарителницата, сканирането от превозвача и известието до клиента са различни неща. Създаването на товарителница не доказва, че превозвачът е получил пратката. Автоматизацията ви трябва да запази това разграничение още от самото начало.

Започнете, като определите системата, която ще управлява решенията за известията. Това може да бъде работният процес за известия във вашия магазин, приложение за проследяване или услуга, свързана със системата ви за управление на поръчки. Определете един собственик за всеки тип съобщение, така че няколко системи да не изпращат независимо едно и също обновление.

Двата практични подхода за внедряване са:

• Настройка чрез приложение: Използвайте приложение за проследяване за електронна търговия, когато екипът ви иска да конфигурира поддържани събития и клиентски съобщения, без да изгражда цялата интеграция. За търговци в Shopify списъкът на приложенията на приложението 17TRACK е подходяща отправна точка за оценка на работните процеси за проследяване на пратки и известия. Потвърдете конкретните тригери, канали, възможности за персонализиране и изискванията на плана, преди да конфигурирате правилата си.
• Настройка чрез API: Използвайте интеграция за проследяване, когато събитията за пратките трябва да се подават към съществуваща система за поръчки или персонализиран работен процес за съобщения. Tracking API на 17TRACK и неговата официална документация са подходящи справочници за внедряване. Потвърдете механизма за доставка на събития, полетата в 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. Тествайте целия път, след което стартирайте постепенно

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

• Нормален път: Приемането, транзитът, изпращането за доставка и доставката генерират предвидените съобщения.
• Повторено събитие: Повторното възпроизвеждане на същото събитие не създава ново известие.
• Събитие извън реда: Забавено сканиране по време на транзит не задейства остаряло известие след доставката.
• Разделена поръчка: Всяко съобщение идентифицира правилната пратка и не внушава, че всички артикули са пристигнали.
• Липсващи полета: Липсващо име, превозвач, прогноза или списък с артикули генерира четим резервен текст.
• Ограничения за контакт: Работният процес спазва предпочитанията за канали, правилата за потискане и конфигурираните тихи часове.
• Неуспешна доставка: Невалидни адреси, грешки на доставчика и повторни опити генерират проследими резултати без неконтролирано повторно изпращане.
• Действие от клиента: Всяка връзка за проследяване и поддръжка води до предвидената дестинация на мобилно устройство.

Започнете с ограничена група пратки и преглеждайте историята на съобщенията заедно с историята на проследяването. Дайте на служителите от поддръжката възможност да виждат какво е получил клиентът. Поддържайте контрол за пауза, така че екипът да може да спре дефектно правило, без да деактивира самото проследяване на пратките.

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

За да оцените въздействието върху клиентите, сравнявайте нивата на контакт, свързан с пратки, като използвате последователно определение и съпоставими групи пратки. Вземайте предвид промените в състава на превозвачите, проблемите с доставките и обема на поръчките, преди да припишете промяната на известията.

Често задавани въпроси

Трябва ли да се изпрати потвърждение за изпращане, когато е създадена товарителницата?

Можете да изпратите обновление за създадена товарителница, но го опишете точно. Кажете, че данните за доставката са готови или че пратката се подготвя. Запазете формулировката, потвърждаваща притежанието от превозвача, за събитие, което го подкрепя.

Могат ли известията за пратки да работят без интеграция чрез API?

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

Колко известия трябва да получава всяка пратка?

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

Какво трябва да се случи, когато проследяването спре да се актуализира?

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

Може ли известие за доставена пратка автоматично да затвори случай в поддръжката?

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

Източници

• Приложение 17TRACK в Shopify — справочник за оценка на настройка за проследяване и известия чрез приложение.
• Tracking API на 17TRACK — справочник за интеграция за проследяване чрез API.
• Документация на API на 17TRACK — справочник за внедряване при проверка на поддържаното поведение и изискванията на интеграцията.
• FTC: Ръководство за съответствие с CAN-SPAM за бизнеса — насоки за търговски имейли и съобщения, комбиниращи транзакционно и промоционално съдържание.