Kaip automatizuoti pranešimus apie siuntas: aktyvikliai, kanalai ir šablonai per 6 veiksmus

Norėdami automatizuoti siuntų pranešimus, susiekite siuntų įvykius su užsakymų įrašais, apibrėžkite, kurie būsenos pokyčiai verti pranešimo, pasirinkite leidžiamą pristatymo kanalą ir kiekvienam paleidikliui priskirkite šabloną. Prieš paleisdami sistemą taip pat pridėkite pasikartojančių pranešimų prevenciją, išimčių tvarkymą ir testavimą. Toliau pateikti šeši žingsniai parodo, kaip el. prekybos komandos gali sukurti darbo eigą, kuri klientams teikia naudingus atnaujinimus, nesiųsdama pasikartojančių ar klaidinančių įspėjimų.

Šis vadovas skirtas prekybininkams, el. prekybos operacijų komandoms ir kūrėjams, atsakingiems už komunikaciją po pirkimo. Rekomenduojama pradėti nuo nedidelio patikimų pranešimų rinkinio: vežėjo priėmimo, išsiuntimo pristatyti, pristatymo ir išimčių, dėl kurių klientas turi imtis veiksmų. Kitus pranešimus pridėkite tik tada, kai jie atsako į konkretų kliento klausimą.

1. Susiekite sekimo įvykius su tinkamu užsakymu ir gavėju

Siuntimo etiketė, vežėjo nuskaitymas ir kliento pranešimas yra skirtingi dalykai. Sukurta etiketė nepatvirtina, kad vežėjas gavo siuntinį. Automatizavimas nuo pat pradžių turi išlaikyti šį skirtumą.

Pirmiausia nustatykite sistemą, kuri priims sprendimus dėl pranešimų. Tai gali būti jūsų parduotuvės pranešimų darbo eiga, sekimo programa arba paslauga, prijungta prie užsakymų valdymo sistemos. Kiekvienam pranešimo tipui paskirkite vieną atsakingą sistemą, kad kelios sistemos nepriklausomai nesiųstų to paties atnaujinimo.

Yra du praktiški įgyvendinimo būdai:

• Programėlės pagrindu: Naudokite el. prekybos sekimo programėlę, kai jūsų komanda nori konfigūruoti palaikomus įvykius ir klientams skirtus pranešimus nekurdama visos integracijos. Shopify prekybininkams 17TRACK programėlės įrašas yra tinkama pradinė vieta vertinant siuntų sekimo ir pranešimų darbo eigas. Prieš konfigūruodami taisykles patvirtinkite konkrečius paleidiklius, kanalus, pritaikymo galimybes ir plano reikalavimus.
• API pagrindu: Naudokite sekimo integraciją, kai siuntų įvykiai turi būti perduodami į esamą užsakymų sistemą arba pasirinktinę pranešimų darbo eigą. 17TRACK Tracking API ir jos oficiali dokumentacija yra svarbūs įgyvendinimo šaltiniai. Patvirtinkite planuojamos naudoti integracijos įvykių pristatymo mechanizmą, duomenų laukus, autentifikavimą ir pakartotinių bandymų elgseną. Sekimo duomenų gavimas ir klientų pranešimų siuntimas yra atskiros atsakomybės.

Nesvarbu, kurį būdą pasirinksite, susiekite kiekvieną siuntą su tinkamu užsakymu ir gavėju. Naudingame vidiniame įraše turėtų būti:

• Užsakymo nuoroda ir siuntos identifikatorius.
• Sekimo numeris ir vežėjo identifikatorius, jei prieinamas.
• Šioje siuntoje esantys daiktai, ypač padalytų užsakymų atveju.
• Kliento kontaktiniai duomenys, kalba, laiko juosta ir kanalų nuostatos.
• Naujausia priimta siuntos būsena ir įvykio laikas.
• Pranešimų istorija, įskaitant tai, kuriai siuntai buvo skirtas kiekvienas pranešimas.

Įvykio laiką laikykite atskirai nuo laiko, kada jūsų sistema gavo atnaujinimą. Uždelstas nuskaitymas neturėtų automatiškai tapti nauju kliento įspėjimu. Taip pat išsaugokite pradinį vežėjo aprašą kartu su normalizuota būsena, kad pagalbos komanda galėtų ištirti neaiškius įvykius.

2. Apibrėžkite prasmingus siuntos pokyčius atspindinčius paleidiklius

Paleidiklis turi reikšti klientui svarbų pokytį, o ne kiekvieną naują sekimo įrašą. Keli nuskaitymai skirtinguose centruose gali reikšti tą patį – „gabenama“. Pranešimo siuntimas dėl kiekvieno iš jų sukuria triukšmą ir nepadeda klientui priimti sprendimo.

Gaunamus įvykius susiekite su nedideliu lengvai suprantamų būsenų rinkiniu. Toliau pateikta lentelė yra siūloma darbo eiga, o ne universalus vežėjų būsenų žodynas.

Išimtis tvarkykite atidžiau nei įprastus etapus. Nepavykęs pristatymas, muitinės problema, adreso klaida ir grąžinimas siuntėjui gali reikalauti skirtingų instrukcijų. Jei įvykis nepaaiškina, ką klientas turėtų daryti, nesugalvokite sprendimo.

Taikydami taisyklę „nėra naujausio atnaujinimo“, pasirinkite paslaugai ir maršrutui tinkamą ribą, o ne vieną universalų intervalą. Nuskaitymų trūkumas neįrodo, kad siuntinys prarastas. Neaiškius atvejus nukreipkite į vidinę peržiūros eilę arba išsiųskite neutralų atnaujinimą, tiksliai apibūdinantį tai, kas žinoma.

Numatomas pristatymo datas laikykite atskirai nuo siuntų būsenų. Įtraukite sąmatą tik tada, kai turite patikimą šaltinį, nurodykite, kad tai yra sąmata, ir nepakeiskite trūkstamų duomenų apskaičiuotu pažadu, kurio jūsų veikla negali užtikrinti.

3. Pasirinkite kanalus ir nustatykite kontaktavimo taisykles

Kanalą naudokite todėl, kad jis tinka pranešimui ir kliento nuostatoms, o ne vien todėl, kad yra prieinamas. El. paštas yra praktiškas atspirties taškas išsamiems atnaujinimams. Skubesnis kanalas gali būti naudingas atliekant laiko jautrumo reikalaujantį veiksmą, tačiau tik tada, kai tai leidžia sutikimas, teikėjo taisyklės ir vietos reikalavimai.

• El. paštas: Tinka užsakymo kontekstui, sekimo nuorodoms, padalytų siuntų paaiškinimams ir pagalbos instrukcijoms. Įtraukite paprasto teksto versiją ir patikrinkite išdėstymą mobiliajame įrenginyje.
• SMS: Naudinga trumpiems, veiksmų reikalaujantiems įspėjimams, kai leidžiama. Nurodykite siuntėją, išlaikykite žinutę koncentruotą ir neatskleiskite nereikalingos užsakymo informacijos.
• Stūmimo pranešimai: Tinka, kai klientai naudojasi jūsų programėle ir yra įjungę pranešimus. Nukreipkite į atitinkamą siuntą, o ne į bendrą pradžios ekraną.
• Žinučių programėlės: Apsvarstykite jas, kai klientai jau naudojasi tuo kanalu, o jūsų įgyvendinimas atitinka platformos leidimų ir pranešimų reikalavimus.
• Sekimo puslapis: Naudokite jį kaip išsamios informacijos vietą. Jis papildo siunčiamus pranešimus, tačiau nepakeičia įspėjimo, kai klientas turi imtis veiksmų.

Dokumentuokite kanalų tarpusavio ryšį. Pavyzdžiui, įprastiems etapams galite naudoti el. paštą, o veiksmų reikalaujančiai pristatymo problemai – leidžiamą mobilųjį kanalą. Automatiškai nesiųskite kiekvieno įvykio visais prieinamais kanalais.

Nustatykite tyliųjų valandų tvarkymą ir atsarginę politiką. Laikinas el. pašto sutrikimas neturėtų automatiškai suteikti leidimo siųsti SMS. Prieš keisdami kanalą patikrinkite, ar turite tinkamus kontaktinius duomenis ir leidimą bei ar kita sistema dar neišsiuntė pranešimo.

Siuntų atnaujinimai turi išlikti operaciniai. Reklaminio turinio pridėjimas gali paveikti tai, kaip pranešimas vertinamas pagal taikomas taisykles. Jungtinėse Valstijose FTC CAN-SPAM gairėse paaiškinama, kad svarbi pagrindinė pranešimo paskirtis, kai komercinis ir operacinis turinys sujungiami. Nemanykite, kad kiekvienam pranešimui, kuriame minimas užsakymas, netaikomi komercinio el. pašto reikalavimai.

4. Sukurkite šablonus su aiškiu atsarginiu elgesiu

Kiekvienas šablonas turėtų atsakyti į tris klausimus: Kas įvyko? Ką tai reiškia šiai siuntai? Ką klientas turėtų daryti toliau? Naudokite sąlyginius laukus, kad trūkstami duomenys būtų tvarkingai pašalinti ir neliktų sugadintų vietaženklių.

Toliau pateikti pavyzdžiai yra pradiniai šablonai. Laužtiniuose skliaustuose pateikti kintamieji yra iliustraciniai, o ne konkrečios platformos šablonų sintaksė.

El. laiškas apie vežėjo priimtą siuntą

Tema: Jūsų užsakymo [order_number] siunta jau pakeliui

Sveiki, [first_name],

[carrier_name] gavo jūsų užsakymo [order_number] siuntą. Jos eigą galite sekti čia: [tracking_link].

[Jei yra patikima sąmata: Numatomas pristatymas: [estimated_delivery_date]. Ši sąmata gali pasikeisti.]

[Jei užsakymas padalytas: Šioje siuntoje yra [shipment_items]. Apie kitus jūsų užsakymo daiktus bus pateikti atskiri sekimo atnaujinimai.]

Pranešimas apie išsiuntimą pristatyti

Remiantis naujausiu vežėjo atnaujinimu, jūsų užsakymo [order_number] siunta išsiųsta pristatyti. Patikrinkite jos eigą ir bet kokią prieinamą pristatymo informaciją: [tracking_link].

Nepridėkite garantuoto pristatymo laiko, nebent jūsų veikla turi tvirtą pagrindą tokiam pažadui. „Išsiųsta pristatyti“ yra nurodyta būsena, o ne garantija, kad pristatymas tą dieną bus baigtas.

Pranešimas apie išimtį su patvirtintu kitu veiksmu

Tema: Jūsų užsakymo [order_number] pristatymo atnaujinimas

Vežėjas pranešė apie [plain_language_issue] jūsų siuntai. [verified_next_step]. Naujausią informaciją peržiūrėkite čia: [tracking_link]. Jei reikia pagalbos, susisiekite su mumis adresu [support_link].

Jei kitas veiksmas nepatvirtintas, pakeiskite tą sakinį į: „Kol kas neturime patvirtinto kito veiksmo. Patikrinkite sekimo puslapį, ar nėra atnaujinimų, arba susisiekite su mūsų pagalbos komanda.“ Sakykite, kad jūsų komanda tiria problemą, tik jei peržiūra iš tikrųjų paskirta.

El. laiškas apie pristatymą

Tema: Jūsų siunta pažymėta kaip pristatyta

[carrier_name] pažymėjo, kad jūsų užsakymo [order_number] siunta pristatyta [delivery_date]. Bet kokią prieinamą pristatymo informaciją peržiūrėkite čia: [tracking_link]. Jei negalite jos rasti, susisiekite su mumis adresu [support_link], kad padėtume patikrinti tolesnius veiksmus.

Padalytų užsakymų atveju vartokite siuntos lygio formuluotes. „Jūsų užsakymas pristatytas“ gali klaidinti, jei kita siunta vis dar gabenama. Jei vežėjo pavadinimas, data arba kliento vardas neprieinamas, vietoj tuščio lauko naudokite patikrintą alternatyvų sakinį.

5. Apsaugokite nuo pasikartojančių, pasenusių ir klaidinančių pranešimų

Automatizavimui reikalingas įrašas apie tai, kas jau atlikta. Darbo eiga, kuri tiesiog siunčia pranešimą kiekvieną kartą gavusi įvykį, gali pakartoti įspėjimus po pakartotinių bandymų arba pateikti pasenusią informaciją po naujesnio etapo.

• Apsaugokite nuo pasikartojančio apdorojimo: Jei įmanoma, naudokite stabilų įvykio identifikatorių. Priešingu atveju nustatykite pasikartojimo šalinimo raktą iš tinkamų laukų, pavyzdžiui, siuntos, įvykio tipo ir įvykio laiko. Atskirai registruokite, ar susijęs pranešimas jau suplanuotas arba išsiųstas.
• Slopinkite būsenos pasikartojimą: Keli nuskaitymai, susieti su ta pačia klientui matoma būsena, neturėtų automatiškai sukurti kelių pranešimų.
• Prieš išsiųsdami patikrinkite įvykio aktualumą: Prieš siųsdami iš naujo įvertinkite eilėje esančius pranešimus. Slopinkite seną pranešimą apie gabenimą, jei vėliau pranešta apie pristatymą.
• Sąmoningai tvarkykite pataisymus: Išsaugokite pradinę įvykių istoriją ir peržiūrėkite tariamus būsenos regresus. Nemanykite, kad kiekvienas vėliau gautas įvykis yra naujesnis arba tikslesnis.
• Saugiai kartokite bandymus: Atskirti nepavykusį siuntimą nuo nežinomo rezultato. Jei palaikoma, naudokite teikėjo idempotentiškumo funkcijas, kad sumažintumėte tikimybę, jog pakartotinis bandymas sukurs kitą pranešimą.
• Apsaugokite gavėjo susiejimą: Niekada nesusiekite siuntos su klientu remdamiesi vien nepatvirtintu sekimo numerio sutapimu.
• Eskalaukite neišspręstas išimtis: Paskirkite operacinį atsakingą asmenį, o ne kartotinai siųskite klientui tą patį įspėjimą.

Pasirinktinėms integracijoms laikykitės dokumentuoto teikėjo požiūrio į autentifikavimą, įvykių patvirtinimą ir pakartotinius bandymus. Apdorojimo žurnalai turi būti naudingi, tačiau nekopijuokite į juos nereikalingų asmens duomenų. Sekimo nuorodos taip pat neturėtų atskleisti kitų klientų užsakymų ar daugiau informacijos, nei reikia gavėjui.

Naudinga apdorojimo seka yra tokia: patvirtinti įvykį, nustatyti siuntą, atnaujinti jos būseną, patikrinti tinkamumą pranešimui, pasirinkti leidžiamą kanalą, sugeneruoti šabloną, įtraukti pranešimą į eilę ir užregistruoti rezultatą. Jei pranešimas laukia eilėje, prieš išsiunčiant dar kartą patikrinkite jo tinkamumą.

6. Išbandykite visą kelią ir palaipsniui paleiskite sistemą

Nevertinkite darbo eigos vien pagal tai, ar bandomasis el. laiškas atrodo tinkamai. Išbandykite visą kelią nuo siuntos įvykio iki kliento, įskaitant nesėkmių atvejus.

• Įprastas kelias: Priėmimas, gabenimas, išsiuntimas pristatyti ir pristatymas sukuria numatytus pranešimus.
• Pasikartojantis įvykis: Pakartotinai paleidus tą patį įvykį nesukuriamas kitas pranešimas.
• Ne eilės tvarka gautas įvykis: Uždelstas gabenimo nuskaitymas nesukelia pasenusio įspėjimo po pristatymo.
• Padalytas užsakymas: Kiekvienas pranešimas nurodo tinkamą siuntą ir nesudaro įspūdžio, kad pristatytos visos prekės.
• Trūkstami laukai: Jei nėra vardo, vežėjo, sąmatos ar prekių sąrašo, pateikiamas įskaitomas atsarginis tekstas.
• Kontaktų apribojimai: Darbo eiga laikosi kanalų nuostatų, slopinimo taisyklių ir sukonfigūruotų tyliųjų valandų.
• Pristatymo nesėkmė: Neteisingi adresai, teikėjo klaidos ir pakartotiniai bandymai sukuria atsekamus rezultatus be nekontroliuojamo pakartotinio siuntimo.
• Kliento veiksmas: Kiekviena sekimo ir pagalbos nuoroda mobiliajame įrenginyje pasiekia numatytą vietą.

Pradėkite nuo ribotos siuntų grupės ir peržiūrėkite pranešimų istoriją kartu su sekimo istorija. Suteikite pagalbos darbuotojams galimybę matyti, ką gavo klientas. Palaikykite sustabdymo valdiklį, kad komanda galėtų sustabdyti klaidingą taisyklę neišjungdama paties siuntų sekimo.

Stebėkite pranešimo tinkamumą, siuntimo bandymus, teikėjo priėmimą, klaidas, pasikartojimus ir laiką nuo įvykio gavimo iki pranešimo išsiuntimo. Teikėjo priėmimas nepatvirtina, kad klientas perskaitė pranešimą, o vien atidarymo rodikliai neįrodo, kad darbo eiga buvo naudinga.

Norėdami įvertinti poveikį klientams, palyginkite su siuntomis susijusių kontaktų rodiklius naudodami nuoseklų apibrėžimą ir panašias siuntų grupes. Prieš priskirdami pokytį pranešimams, atsižvelkite į vežėjų derinio, pristatymo problemų ir užsakymų kiekio pokyčius.

DUK

Ar siuntimo patvirtinimą reikia siųsti sukūrus etiketę?

Galite išsiųsti atnaujinimą apie sukurtą etiketę, tačiau apibūdinkite jį tiksliai. Pasakykite, kad siuntimo duomenys paruošti arba siunta ruošiama. Formuluotę, patvirtinančią, kad vežėjas turi siuntą, naudokite tik tada, kai ją pagrindžia atitinkamas įvykis.

Ar siuntų pranešimai gali veikti be API integracijos?

Taip. Programėlės pagrindu veikianti darbo eiga gali tvarkyti ryšį ir pranešimų taisykles per savo sąsają. Patikrinkite pasirinktoje sąrankoje prieinamus įvykius, kanalus, šablonų valdiklius ir išimčių tvarkymą. Pasirinktinės integracijos tinkamesnės, kai esamoms sistemoms reikia specializuoto nukreipimo arba sprendimų logikos.

Kiek pranešimų turėtų gauti kiekviena siunta?

Nėra vieno idealaus skaičiaus. Pradėkite nuo aiškių, naudingų etapų ir veiksmų reikalaujančių išimčių. Slopinkite pasikartojančius gabenimo nuskaitymus ir pridėkite pranešimus tik tada, kai jie suteikia klientui reikalingą informaciją.

Kas turėtų nutikti, kai sekimas nustoja atsinaujinti?

Taikykite paslaugai tinkamą peržiūros taisyklę, o ne skelbkite, kad siunta prarasta. Patikrinkite paskutinį įvykį, jei įmanoma – pristatymo sąmatą, ir atitinkamą operacinį procesą. Klientui siųskite atnaujinimą tik tada, kai jis suteikia patikrintos informacijos arba naudingą kitą veiksmą.

Ar pranešimas apie pristatymą gali automatiškai uždaryti pagalbos atvejį?

Pristatymo nuskaitymas gali atnaujinti atvejį, tačiau neturėtų automatiškai išspręsti kliento pranešimo apie negautą siuntą. Vežėjo pristatymo būseną ir kliento problemą laikykite atskirais įrašais, tada laikykitės tyrimo proceso.

Šaltiniai

• 17TRACK Shopify programėlės įrašas — produkto šaltinis vertinant programėlės pagrindu veikiančią sekimo ir pranešimų sąranką.
• 17TRACK Tracking API — produkto šaltinis API pagrindu veikiančiai sekimo integracijai.
• 17TRACK API dokumentacija — įgyvendinimo šaltinis tikrinant palaikomą integracijos elgseną ir reikalavimus.
• FTC: CAN-SPAM įstatymo laikymosi vadovas verslui — gairės dėl komercinio el. pašto ir pranešimų, kuriuose derinamas operacinis bei reklaminis turinys.