Kako avtomatizirati obvestila o pošiljkah: sprožilci, kanali in predloge v 6 korakih

Za avtomatizacijo obvestil o pošiljkah povežite dogodke pošiljke z zapisi naročil, določite, katere spremembe statusa zahtevajo sporočilo, izberite dovoljen kanal za dostavo in vsakemu sprožilcu dodajte predlogo. Pred uvedbo dodajte še preprečevanje dvojnikov, obravnavo izjem in testiranje. Spodnjih šest korakov ekipam v e-trgovini pokaže, kako zgraditi delovni tok, ki strankam zagotavlja koristne posodobitve, ne da bi pošiljal ponavljajoča ali zavajajoča opozorila.

Ta vodnik je namenjen trgovcem, ekipam za e-poslovanje in razvijalcem, odgovornim za komunikacijo po nakupu. Priporočena začetna točka je majhen nabor zanesljivih obvestil: sprejem s strani prevoznika, pošiljka v dostavi, dostavljeno in izjeme, ki zahtevajo ukrepanje stranke. Druga sporočila dodajte le, če odgovarjajo na ločeno vprašanje stranke.

1. Povežite dogodke sledenja s pravim naročilom in prejemnikom

Odpremna nalepka, skeniranje prevoznika in obvestilo stranki so različne stvari. Ustvarjanje nalepke ne pomeni, da je prevoznik paket prejel. Vaša avtomatizacija mora to razliko ohraniti od samega začetka.

Najprej določite sistem, ki bo upravljal odločitve o obvestilih. To je lahko delovni tok obvestil vaše trgovine, aplikacija za sledenje ali storitev, povezana z vašim sistemom za upravljanje naročil. Vsaki vrsti sporočila določite enega odgovornega lastnika, da več sistemov ne bi neodvisno poslalo iste posodobitve.

Dve praktični poti izvedbe sta:

• Namestitev na osnovi aplikacije: Uporabite aplikacijo za sledenje v e-trgovini, kadar želi vaša ekipa konfigurirati podprte dogodke in sporočila za stranke, ne da bi zgradila celotno integracijo. Za trgovce Shopify je seznam aplikacije 17TRACK ustrezna začetna točka za ocenjevanje potekov sledenja pošiljkam in obvestil. Pred konfiguracijo pravil potrdite konkretne sprožilce, kanale, možnosti prilagajanja in zahteve paketa.
• Namestitev na osnovi API-ja: Uporabite integracijo sledenja, kadar morajo dogodki pošiljk napajati obstoječi sistem naročil ali potek sporočanja po meri. API za sledenje 17TRACK in njegova uradna dokumentacija sta ustrezna vira za izvedbo. Za integracijo, ki jo nameravate uporabiti, potrdite mehanizem dostave dogodkov, polja podatkovnega paketa, preverjanje pristnosti in vedenje pri ponovnih poskusih. Prejemanje podatkov o sledenju in pošiljanje sporočil strankam sta ločeni odgovornosti.

Ne glede na izbrano pot vsako pošiljko povežite s pravim naročilom in prejemnikom. Koristen interni zapis vsebuje:

• Referenco naročila in identifikator pošiljke.
• Številko za sledenje in identifikator prevoznika, če sta na voljo.
• Izdelke, vključene v pošiljko, zlasti pri deljenih naročilih.
• Kontaktne podatke stranke, jezik, časovni pas in prednostne kanale.
• Najnovejši sprejeti status pošiljke in čas nastanka dogodka.
• Zgodovino obvestil, vključno s podatkom, na katero pošiljko se je nanašalo posamezno sporočilo.

Čas nastanka dogodka hranite ločeno od časa, ko je vaš sistem prejel posodobitev. Zakasnjeno skeniranje ne sme samodejno postati novo opozorilo za stranko. Poleg normaliziranega statusa ohranite tudi izvirni opis prevoznika, da lahko podpora razišče dvoumne dogodke.

2. Določite sprožilce, ki odražajo pomembne spremembe pošiljke

Sprožilec mora predstavljati spremembo, pomembno za stranko, ne vsakega novega zapisa sledenja. Več skeniranj v objektih lahko pomeni isto: »v tranzitu«. Obvestilo za vsako od njih ustvarja hrup, ne da bi stranki pomagalo pri odločitvi.

Dohodne dogodke preslikajte v majhen nabor razumljivih statusov. Naslednja tabela je predlagan potek, ne univerzalni slovar statusov prevoznikov.

Izjeme obravnavajte previdneje kot rutinske mejnike. Neuspešen poskus dostave, carinska težava, težava z naslovom in vračilo pošiljatelju lahko zahtevajo različna navodila. Če dogodek ne pojasni, kaj mora stranka storiti, si rešitve ne izmišljajte.

Pri pravilu »brez nedavne posodobitve« izberite prag, primeren za storitev in pot, namesto da uporabite enoten interval. Pomanjkanje skeniranj ni dokaz, da je paket izgubljen. Negotove primere usmerite v interno čakalno vrsto za pregled ali pošljite nevtralno posodobitev, ki natančno opisuje znano stanje.

Predvidene datume dostave hranite ločeno od statusov pošiljke. Oceno vključite le, če imate zanesljiv vir, jo označite kot oceno in manjkajočih podatkov ne nadomeščajte z izračunano obljubo, ki je vaše poslovanje ne more podpreti.

3. Izberite kanale in določite pravila za stike

Kanal uporabite zato, ker ustreza sporočilu in željam stranke, ne zgolj zato, ker je na voljo. E-pošta je praktična začetna točka za podrobne posodobitve. Bolj neposreden kanal je lahko koristen za časovno občutljivo dejanje, vendar le, če to dovoljujejo soglasje, pravila ponudnika in lokalne zahteve.

• E-pošta: Primerna za kontekst naročila, povezave za sledenje, pojasnila deljenih pošiljk in navodila za podporo. Vključite različico z navadnim besedilom in preverite prikaz na mobilnih napravah.
• SMS: Uporaben za kratka, izvedljiva opozorila, kjer je dovoljen. Navedite pošiljatelja, sporočilo naj bo osredotočeno in ne razkrivajte nepotrebnih podatkov o naročilu.
• Potisna obvestila: Primerna, ko stranke uporabljajo vašo aplikacijo in so omogočile obvestila. Povežite jih z ustrezno pošiljko, ne s splošnim začetnim zaslonom.
• Aplikacije za sporočanje: Upoštevajte jih, ko stranke kanal že uporabljajo in vaša izvedba izpolnjuje zahteve platforme glede dovoljenj in sporočil.
• Stran za sledenje: Uporabite jo kot podroben referenčni cilj. Dopolnjuje odhodna obvestila, vendar ne nadomešča opozorila, kadar mora stranka ukrepati.

Dokumentirajte razmerje med kanali. E-pošto lahko na primer uporabite za rutinske mejnike, dovoljen mobilni kanal pa za izvedljivo težavo pri dostavi. Vsakega dogodka ne pošiljajte samodejno prek vseh razpoložljivih kanalov.

Določite obravnavo tihih ur in rezervno politiko. Začasna napaka pri e-pošti ne sme samodejno dovoliti SMS-a. Pred preklopom kanalov preverite, ali imate ustrezne kontaktne podatke in dovoljenje ter ali drug sistem sporočila že ni poslal.

Posodobitve pošiljk naj ostanejo operativne. Dodajanje promocijske vsebine lahko vpliva na obravnavo sporočila v skladu z veljavnimi pravili. V Združenih državah smernice FTC glede CAN-SPAM pojasnjujejo, da je glavni namen sporočila pomemben, kadar se združita komercialna in transakcijska vsebina. Ne domnevajte, da je vsako sporočilo, ki omenja naročilo, izvzeto iz zahtev za komercialno e-pošto.

4. Ustvarite predloge z jasnim rezervnim vedenjem

Vsaka predloga mora odgovoriti na tri vprašanja: Kaj se je zgodilo? Kaj to pomeni za to pošiljko? Kaj naj stranka stori naslednje? Uporabite pogojna polja, da manjkajoči podatki čisto izginejo, namesto da bi pustili pokvarjene nadomestne oznake.

Spodnji primeri so začetne predloge. Spremenljivke v oglatih oklepajih so ilustrativne in ne predstavljajo sintakse predlog določene platforme.

E-pošta o sprejemu s strani prevoznika

Zadeva: Vaša pošiljka za naročilo [order_number] je na poti

Pozdravljeni, [first_name],

[carrier_name] je prejel vašo pošiljko za naročilo [order_number]. Njenemu napredku lahko sledite tukaj: [tracking_link].

[Če je na voljo zanesljiva ocena: Predvidena dostava: [estimated_delivery_date]. Ta ocena se lahko spremeni.]

[Če je naročilo razdeljeno: Ta pošiljka vsebuje [shipment_items]. Za druge izdelke v naročilu boste prejeli ločene posodobitve sledenja.]

Sporočilo o pošiljki v dostavi

Glede na najnovejšo posodobitev prevoznika je vaša pošiljka za naročilo [order_number] v dostavi. Preverite njen napredek in morebitne podrobnosti dostave: [tracking_link].

Ne dodajajte zagotovljenega časa prihoda, razen če ima vaše poslovanje trdno podlago za takšno obljubo. »V dostavi« je sporočeni status, ne zagotovilo, da bo dostava zaključena še isti dan.

Sporočilo o izjemi s potrjenim naslednjim korakom

Zadeva: Posodobitev dostave za naročilo [order_number]

Prevoznik je za vašo pošiljko prijavil [plain_language_issue]. [verified_next_step]. Najnovejše podrobnosti si oglejte tukaj: [tracking_link]. Če potrebujete pomoč, nas kontaktirajte na [support_link].

Če naslednji korak ni potrjen, ta stavek zamenjajte z: »Potrjenega naslednjega koraka še nimamo. Za posodobitve preverite stran za sledenje ali se obrnite na našo ekipo za podporo.« Navedite, da vaša ekipa zadevo preiskuje, samo če je bil pregled dejansko dodeljen.

E-pošta o dostavi

Zadeva: Vaša pošiljka je označena kot dostavljena

[carrier_name] je vašo pošiljko za naročilo [order_number] označil kot dostavljeno dne [delivery_date]. Morebitne podrobnosti dostave si oglejte tukaj: [tracking_link]. Če je ne morete najti, nas kontaktirajte na [support_link], da vam pomagamo preveriti naslednje korake.

Pri deljenih naročilih uporabljajte izraze na ravni pošiljke. »Vaše naročilo je prispelo« je lahko zavajajoče, če je drug paket še vedno v tranzitu. Če ime prevoznika, datum ali ime stranke ni na voljo, uporabite preizkušen nadomestni stavek, namesto da prikažete prazno polje.

5. Dodajte zaščite pred podvojenimi, zastarelimi in zavajajočimi sporočili

Avtomatizacija potrebuje zapis o tem, kaj je že izvedla. Delovni tok, ki preprosto pošlje sporočilo vsakič, ko prispe dogodek, lahko po ponovnih poskusih ponovi opozorila ali po novejšem mejniku dostavi zastarele informacije.

• Preprečite dvojno obdelavo: Kjer je na voljo, uporabite stabilni identifikator dogodka. Sicer določite ključ za odstranjevanje dvojnikov iz ustreznih polj, kot so pošiljka, vrsta dogodka in čas nastanka dogodka. Ločeno zabeležite, ali je bilo povezano obvestilo že načrtovano ali poslano.
• Zadržite ponavljanje statusa: Več skeniranj, preslikanih v isti status za stranko, ne sme samodejno ustvariti več sporočil.
• Pred odpremo preverite pomembnost dogodka: Pred pošiljanjem ponovno ovrednotite sporočila v čakalni vrsti. Zadržite staro opozorilo o tranzitu, če je bila medtem prijavljena dostava.
• Popravke obravnavajte premišljeno: Ohranite izvirno zgodovino dogodkov in preglejte navidezne nazadovanja. Ne domnevajte, da je vsak pozneje prispeli dogodek novejši ali natančnejši.
• Varno izvajajte ponovne poskuse: Ločite neuspešno pošiljanje od neznanega izida. Kjer je podprto, uporabite funkcije idempotentnosti ponudnika, da zmanjšate možnost, da ponovni poskus ustvari dodatno sporočilo.
• Zaščitite ujemanje prejemnika: Pošiljke nikoli ne povežite s stranko samo na podlagi nepreverjenega ujemanja številke za sledenje.
• Nerešene izjeme eskalirajte: Določite operativnega lastnika, namesto da stranki vedno znova pošiljate isto opozorilo.

Pri integracijah po meri upoštevajte dokumentirani pristop ponudnika k preverjanju pristnosti, potrditvi dogodkov in ponovnim poskusom. Dnevniki obdelave naj ostanejo uporabni, vendar vanje ne kopirajte nepotrebnih osebnih podatkov. Povezave za sledenje prav tako ne smejo razkrivati naročil ali podatkov drugih strank, razen tistega, kar prejemnik potrebuje.

Koristno zaporedje obdelave je: preverite dogodek, določite pošiljko, posodobite njeno stanje, preverite upravičenost do obvestila, izberite dovoljen kanal, izrišite predlogo, uvrstite sporočilo v čakalno vrsto in zabeležite izid. Če sporočilo čaka v čakalni vrsti, upravičenost ponovno preverite ob odpremi.

6. Preizkusite celotno pot, nato postopoma uvedite rešitev

Delovnega toka ne ocenjujte samo po tem, ali je testna e-pošta videti pravilno. Preizkusite celotno pot od dogodka pošiljke do cilja pri stranki, vključno s primeri napak.

• Običajna pot: Sprejem, tranzit, dostava in dostavljeno ustvarijo predvidena sporočila.
• Ponovljen dogodek: Ponovno predvajanje istega dogodka ne ustvari novega obvestila.
• Dogodek v napačnem vrstnem redu: Zakasnjeno skeniranje v tranzitu po dostavi ne sproži zastarelega opozorila.
• Deljeno naročilo: Vsako sporočilo določa pravilno pošiljko in ne nakazuje, da so prispeli vsi izdelki.
• Manjkajoča polja: Manjkajoče ime, prevoznik, ocena ali seznam izdelkov ustvari berljivo nadomestno besedilo.
• Omejitve stikov: Delovni tok upošteva prednostne kanale, pravila zadržanja in konfigurirane tihe ure.
• Napaka pri dostavi: Neveljavni naslovi, napake ponudnika in ponovni poskusi ustvarijo sledljive izide brez nenadzorovanega ponovnega pošiljanja.
• Dejanje stranke: Vsaka povezava za sledenje in podporo na mobilnih napravah vodi do predvidenega cilja.

Začnite z omejeno skupino pošiljk in preglejte zgodovino sporočil skupaj z zgodovino sledenja. Osebju za podporo omogočite vpogled v to, kaj je stranka prejela. Ohranite možnost zaustavitve, da lahko ekipa ustavi napačno pravilo, ne da bi onemogočila samo sledenje pošiljkam.

Spremljajte upravičenost do obvestil, poskuse pošiljanja, sprejem pri ponudniku, napake, dvojnike in zamik med prejemom dogodka ter odpremo sporočila. Sprejem pri ponudniku ne dokazuje, da je stranka sporočilo prebrala, stopnje odpiranja pa same po sebi ne dokazujejo, da je delovni tok pomagal.

Za oceno vpliva na stranke primerjajte stopnje stikov, povezanih s pošiljkami, z dosledno opredelitvijo in primerljivimi skupinami pošiljk. Pred pripisom spremembe obvestilom upoštevajte spremembe v sestavi prevoznikov, težave pri dostavi in obseg naročil.

Pogosta vprašanja

Ali je treba potrditev pošiljanja poslati ob ustvarjanju nalepke?

Posodobitev o ustvarjeni nalepki lahko pošljete, vendar jo opišite natančno. Navedite, da so podatki o pošiljanju pripravljeni ali da se pošiljka pripravlja. Besedilo, ki potrjuje prevzem s strani prevoznika, uporabite šele pri dogodku, ki to podpira.

Ali lahko obvestila o pošiljkah delujejo brez integracije API?

Da. Delovni tok na osnovi aplikacije lahko povezavo in pravila obvestil upravlja prek svojega vmesnika. Preverite dogodke, kanale, nadzor predlog in obravnavo izjem, ki so na voljo v izbrani namestitvi. Integracije po meri so primernejše, ko obstoječi sistemi zahtevajo specializirano usmerjanje ali logiko odločanja.

Koliko obvestil naj prejme posamezna pošiljka?

Univerzalnega idealnega števila ni. Začnite z ločenimi, koristnimi mejniki in izvedljivimi izjemami. Zadržite ponavljajoča se skeniranja v tranzitu in dodajte sporočila le, kadar zagotavljajo informacije, ki jih stranka potrebuje.

Kaj se mora zgoditi, ko se sledenje preneha posodabljati?

Uporabite pravilo za pregled, primerno storitvi, namesto da pošiljko razglasite za izgubljeno. Preverite zadnji dogodek, predvideno dostavo, če je na voljo, in ustrezen operativni postopek. Posodobitev stranki pošljite le, če dodaja preverjene informacije ali koristen naslednji korak.

Ali lahko obvestilo o dostavi samodejno zapre primer podpore?

Skeniranje dostave lahko posodobi primer, vendar ne sme samodejno rešiti strankine prijave, da pošiljke ni prejela. Status dostave prevoznika in težavo stranke obravnavajte kot ločena zapisa, nato pa upoštevajte svoj preiskovalni postopek.

Viri

• Seznam aplikacije 17TRACK Shopify — referenca izdelka za ocenjevanje sledenja in obvestil na osnovi aplikacije.
• API za sledenje 17TRACK — referenca izdelka za integracijo sledenja na osnovi API-ja.
• Dokumentacija API-ja 17TRACK — referenca za izvedbo pri preverjanju podprtega vedenja in zahtev integracije.
• FTC: Vodnik za podjetja o skladnosti z zakonom CAN-SPAM — smernice o komercialni e-pošti in sporočilih, ki združujejo transakcijsko in promocijsko vsebino.