Kako automatizovati obaveštenja o pošiljkama: Okidači, kanali i šabloni u 6 koraka

Da biste automatizovali obaveštenja o pošiljkama, povežite događaje u vezi sa pošiljkom sa evidencijama porudžbina, definišite koje promene statusa zaslužuju poruku, izaberite dozvoljeni kanal za isporuku i dodajte šablon svakom okidaču. Zatim dodajte sprečavanje duplikata, upravljanje izuzecima i testiranje pre pokretanja. Šest koraka u nastavku pokazuje timovima za e-trgovinu kako da izgrade tok rada koji korisnicima pruža korisna ažuriranja bez slanja ponavljajućih ili obmanjujućih obaveštenja.

Ovaj vodič je namenjen trgovcima, timovima za operacije e-trgovine i programerima odgovornim za komunikaciju nakon kupovine. Preporučena početna tačka je mali skup pouzdanih obaveštenja: prihvatanje od strane prevoznika, pošiljka je poslata na isporuku, isporučeno i izuzeci koji zahtevaju akciju korisnika. Dodajte druge poruke samo kada odgovaraju na posebno pitanje korisnika.

1. Povežite događaje praćenja sa odgovarajućom porudžbinom i primaocem

Transportna etiketa, skeniranje kod prevoznika i obaveštenje korisniku predstavljaju različite stvari. Kreiranje etikete ne potvrđuje da je prevoznik primio paket. Vaša automatizacija treba da očuva tu razliku od samog početka.

Počnite tako što ćete identifikovati sistem koji će donositi odluke o obaveštenjima. To može biti tok obaveštenja vaše prodavnice, aplikacija za praćenje ili usluga povezana sa vašim sistemom za upravljanje porudžbinama. Dodelite jednog vlasnika svakoj vrsti poruke kako više sistema ne bi nezavisno slalo isto ažuriranje.

Dva praktična načina implementacije su:

• Podešavanje zasnovano na aplikaciji: Koristite aplikaciju za praćenje e-trgovine kada vaš tim želi da konfiguriše podržane događaje i poruke namenjene korisnicima bez izgradnje kompletne integracije. Za trgovce na Shopify platformi, 17TRACK listing aplikacije predstavlja relevantnu početnu tačku za procenu tokova praćenja pošiljaka i obaveštenja. Potvrdite konkretne okidače, kanale, opcije prilagođavanja i zahteve plana pre konfigurisanja pravila.
• Podešavanje zasnovano na API-ju: Koristite integraciju za praćenje kada događaji u vezi sa pošiljkom moraju da se prosleđuju postojećem sistemu za porudžbine ili prilagođenom toku poruka. 17TRACK Tracking API i njegova zvanična dokumentacija predstavljaju relevantne reference za implementaciju. Potvrdite mehanizam isporuke događaja, polja korisnog tereta, autentifikaciju i ponašanje pri ponovnom pokušaju za integraciju koju nameravate da koristite. Prijem podataka o praćenju i slanje poruka korisnicima odvojene su odgovornosti.

Bez obzira na izabrani način, povežite svaku pošiljku sa odgovarajućom porudžbinom i primaocem. Korisna interna evidencija sadrži:

• Referencu porudžbine i identifikator pošiljke.
• Broj za praćenje i identifikator prevoznika, kada su dostupni.
• Artikle uključene u tu pošiljku, naročito kod podeljenih porudžbina.
• Kontakt podatke korisnika, jezik, vremensku zonu i željene kanale.
• Poslednji prihvaćeni status pošiljke i vreme nastanka događaja.
• Istoriju obaveštenja, uključujući pošiljku na koju se svaka poruka odnosila.

Vreme nastanka događaja čuvajte odvojeno od vremena kada je vaš sistem primio ažuriranje. Odloženo skeniranje ne bi automatski trebalo da postane novo obaveštenje korisniku. Takođe sačuvajte originalni opis prevoznika pored normalizovanog statusa kako bi podrška mogla da ispita nejasne događaje.

2. Definišite okidače koji odražavaju značajne promene pošiljke

Okidač treba da predstavlja promenu relevantnu za korisnika, a ne svaki novi zapis praćenja. Više skeniranja u objektima može značiti isto — „u tranzitu“. Slanje obaveštenja za svako od njih stvara buku bez pomoći korisniku pri donošenju odluke.

Mapirajte dolazne događaje na mali skup razumljivih statusa. Sledeća tabela predstavlja predloženi tok rada, a ne univerzalni rečnik statusa svih prevoznika.

Okidač	Uslov za slanje	Svrha poruke
Etiketa kreirana	Opciono; razlikovati pripremu od preuzimanja pošiljke od strane prevoznika.	Objasniti da su detalji za praćenje spremni.
Prihvatanje od strane prevoznika	Podržani događaj ukazuje da je prevoznik primio paket.	Potvrditi da je pošiljka ušla u mrežu prevoznika.
U tranzitu	Opciono međustanje; potisnuti ponovljena rutinska skeniranja.	Pružiti značajan napredak, a ne prikaz skeniranja korak po korak.
Poslato na isporuku	Dolazni status izričito podržava ovo tumačenje.	Pomoći korisniku da se pripremi za prijem paketa.
Izuzetak pri isporuci	Utvrđen je značajan problem ili potrebna akcija.	Objasniti problem i sledeći koristan korak.
Isporučeno	Prevoznik je prijavio isporuku ove pošiljke.	Potvrditi prijavljeni ishod i pružiti način za pomoć.

Izuzecima upravljajte pažljivije nego rutinskim međustanjima. Neuspešan pokušaj isporuke, problem sa carinom, problem sa adresom i vraćanje pošiljaocu mogu zahtevati različita uputstva. Ako događaj ne objašnjava šta korisnik treba da uradi, nemojte izmišljati rešenje.

Za pravilo „nema nedavnog ažuriranja“ izaberite prag primeren usluzi i ruti, umesto primene jednog univerzalnog intervala. Nedostatak skeniranja nije dokaz da je paket izgubljen. Neizvesne slučajeve prosledite u interni red za proveru ili pošaljite neutralno ažuriranje koje tačno opisuje ono što je poznato.

Procenjene datume isporuke čuvajte odvojeno od statusa pošiljke. Procenu uključite samo kada imate pouzdan izvor, označite je kao procenu i izbegavajte zamenu nedostajućih podataka izračunatim obećanjem koje vaše poslovanje ne može da podrži.

3. Izaberite kanale i postavite pravila kontakta

Koristite kanal zato što odgovara poruci i željama korisnika, a ne samo zato što je dostupan. E-pošta je praktična početna tačka za detaljna ažuriranja. Neposredniji kanal može biti koristan za vremenski osetljivu akciju, ali samo tamo gde to dozvoljavaju saglasnost, pravila provajdera i lokalni zahtevi.

• E-pošta: Pogodna za kontekst porudžbine, linkove za praćenje, objašnjenja podeljenih pošiljaka i uputstva za podršku. Uključite verziju u običnom tekstu i proverite prikaz na mobilnim uređajima.
• SMS: Koristan za kratka obaveštenja koja zahtevaju akciju, tamo gde je dozvoljen. Identifikujte pošiljaoca, neka poruka bude usmerena i izbegavajte otkrivanje nepotrebnih informacija o porudžbini.
• Push obaveštenja: Odgovaraju kada korisnici koriste vašu aplikaciju i omogućili su obaveštenja. Povežite ih sa relevantnom pošiljkom, a ne sa generičkim početnim ekranom.
• Aplikacije za razmenu poruka: Razmotrite ih kada korisnici već koriste taj kanal i kada vaša implementacija ispunjava zahteve platforme u vezi sa dozvolama i porukama.
• Stranica za praćenje: Koristite je kao odredište za detaljne informacije. Ona dopunjuje odlazna obaveštenja, ali ne zamenjuje upozorenje kada korisnik treba da reaguje.

Dokumentujte odnos između kanala. Na primer, možete koristiti e-poštu za rutinska međustanja, a dozvoljeni mobilni kanal za problem sa isporukom koji zahteva akciju. Nemojte automatski slati svaki događaj kroz svaki dostupni kanal.

Postavite obradu perioda bez obaveštenja i rezervnu politiku. Privremeni neuspeh e-pošte ne bi trebalo automatski da odobri slanje SMS-a. Pre promene kanala proverite da li imate odgovarajuće kontakt podatke i dozvolu, kao i da drugi sistem već nije poslao poruku.

Ažuriranja o pošiljci neka ostanu operativna. Dodavanje promotivnog sadržaja može uticati na način na koji se poruka tretira prema važećim pravilima. U Sjedinjenim Državama, smernice FTC-a za CAN-SPAM objašnjavaju da je primarna svrha poruke važna kada se kombinuju komercijalni i transakcioni sadržaj. Nemojte pretpostaviti da je svaka poruka koja pominje porudžbinu izuzeta od zahteva za komercijalnu e-poštu.

4. Izgradite šablone sa jasnim rezervnim ponašanjem

Svaki šablon treba da odgovori na tri pitanja: Šta se dogodilo? Šta to znači za ovu pošiljku? Šta korisnik treba sledeće da uradi? Koristite uslovna polja kako bi nedostajući podaci nestali uredno, umesto da ostavljaju neispravne rezervisana mesta.

Primeri u nastavku predstavljaju početne šablone. Varijable u uglastim zagradama su ilustrativne i ne predstavljaju sintaksu šablona određene platforme.

E-poruka o prihvatanju od strane prevoznika

Naslov: Vaša pošiljka za porudžbinu [order_number] je na putu

Zdravo [first_name],

[carrier_name] je primio vašu pošiljku za porudžbinu [order_number]. Njen tok možete pratiti ovde: [tracking_link].

[Ako je dostupna pouzdana procena: Procenjena isporuka: [estimated_delivery_date]. Ova procena može da se promeni.]

[Ako je porudžbina podeljena: Ova pošiljka sadrži [shipment_items]. Ostali artikli iz vaše porudžbine imaće zasebna ažuriranja praćenja.]

Poruka „poslato na isporuku“

Prema najnovijem ažuriranju prevoznika, vaša pošiljka za porudžbinu [order_number] poslata je na isporuku. Proverite njen tok i sve dostupne detalje isporuke: [tracking_link].

Nemojte dodavati garantovano vreme dolaska osim ako vaše poslovanje ima čvrstu osnovu za takvo obećanje. „Poslato na isporuku“ je prijavljeni status, a ne garancija da će isporuka biti završena tog dana.

Poruka o izuzetku sa potvrđenim sledećim korakom

Naslov: Ažuriranje isporuke za porudžbinu [order_number]

Prevoznik je prijavio [plain_language_issue] za vašu pošiljku. [verified_next_step]. Najnovije detalje pogledajte ovde: [tracking_link]. Ako vam je potrebna pomoć, kontaktirajte nas na [support_link].

Ako sledeći korak nije potvrđen, zamenite tu rečenicu sledećom: „Još nemamo potvrđen sledeći korak. Proverite stranicu za praćenje radi ažuriranja ili kontaktirajte naš tim za podršku.“ Recite da vaš tim sprovodi istragu samo ako je provera zaista dodeljena.

E-poruka o isporuci

Naslov: Vaša pošiljka je označena kao isporučena

[carrier_name] je označio vašu pošiljku za porudžbinu [order_number] kao isporučenu dana [delivery_date]. Sve dostupne detalje isporuke pogledajte ovde: [tracking_link]. Ako ne možete da je pronađete, kontaktirajte nas na [support_link] kako bismo vam pomogli da proverite sledeće korake.

Za podeljene porudžbine koristite formulacije na nivou pošiljke. „Vaša porudžbina je stigla“ može biti obmanjujuće kada je drugi paket još u tranzitu. Ako ime prevoznika, datum ili ime korisnika nisu dostupni, koristite proverenu alternativnu rečenicu umesto prikazivanja praznog polja.

5. Dodajte zaštite od duplih, zastarelih i obmanjujućih poruka

Automatizacija zahteva evidenciju onoga što je već urađeno. Tok rada koji jednostavno šalje poruku svaki put kada događaj stigne može ponavljati obaveštenja nakon ponovljenih pokušaja ili isporučivati zastarele informacije nakon novijeg međustanja.

• Sprečite duplu obradu: Koristite stabilan identifikator događaja kada je dostupan. U suprotnom definišite ključ za uklanjanje duplikata na osnovu odgovarajućih polja, kao što su pošiljka, tip događaja i vreme nastanka događaja. Odvojeno beležite da li je odgovarajuće obaveštenje već zakazano ili poslato.
• Potisnite ponavljanje statusa: Više skeniranja mapiranih na isti status namenjen korisniku ne bi automatski trebalo da proizvodi više poruka.
• Proverite relevantnost događaja pre slanja: Ponovo procenite poruke u redu čekanja pre slanja. Potisnite staro upozorenje o tranzitu ako je u međuvremenu prijavljena isporuka.
• Pažljivo obrađujte ispravke: Sačuvajte originalnu istoriju događaja i proverite prividna vraćanja statusa. Nemojte pretpostaviti da je svaki kasnije pristigli događaj noviji ili tačniji.
• Bezbedno ponavljajte pokušaje: Razlikujte neuspešno slanje od nepoznatog ishoda. Tamo gde je podržano, koristite funkcije idempotentnosti provajdera kako biste smanjili verovatnoću da ponovni pokušaj kreira dodatnu poruku.
• Zaštitite uparivanje primaoca: Nikada ne povezujte pošiljku sa korisnikom samo na osnovu nepotvrđenog podudaranja broja za praćenje.
• Eskalirajte nerešene izuzetke: Dodelite operativnog vlasnika umesto da korisniku iznova šaljete isto upozorenje.

Za prilagođene integracije pratite dokumentovani pristup provajdera autentifikaciji, potvrđivanju događaja i ponovnim pokušajima. Evidencije obrade neka ostanu korisne, ali u njih nemojte kopirati nepotrebne lične podatke. Linkovi za praćenje takođe treba da izbegavaju otkrivanje porudžbina drugih korisnika ili informacija koje prevazilaze ono što je primaocu potrebno.

Korisna sekvenca obrade je: proverite događaj, identifikujte pošiljku, ažurirajte njeno stanje, proverite podobnost za obaveštenje, izaberite dozvoljeni kanal, generišite šablon, stavite poruku u red čekanja i zabeležite ishod. Ponovo proverite podobnost pri slanju ako poruka čeka u redu.

6. Testirajte kompletan tok, a zatim postepeno pokrenite sistem

Nemojte procenjivati tok rada samo na osnovu toga da li testna e-poruka izgleda ispravno. Testirajte čitav put od događaja u vezi sa pošiljkom do odredišta korisnika, uključujući slučajeve grešaka.

• Uobičajeni tok: Prihvatanje, tranzit, slanje na isporuku i isporuka proizvode predviđene poruke.
• Ponovljeni događaj: Ponovno reprodukovanje istog događaja ne stvara novo obaveštenje.
• Događaj van redosleda: Odloženo skeniranje tokom tranzita ne pokreće zastarelo upozorenje nakon isporuke.
• Podeljena porudžbina: Svaka poruka identifikuje odgovarajuću pošiljku i ne implicira da su svi artikli stigli.
• Nedostajuća polja: Nedostajuće ime, prevoznik, procena ili spisak artikala proizvode čitljiv rezervni tekst.
• Ograničenja kontakta: Tok rada poštuje željene kanale, pravila potiskivanja i konfigurisane periode bez obaveštenja.
• Neuspešna isporuka: Nevažeće adrese, greške provajdera i ponovljeni pokušaji proizvode sledljive ishode bez nekontrolisanog ponovnog slanja.
• Akcija korisnika: Svaki link za praćenje i podršku vodi na predviđeno odredište na mobilnom uređaju.

Počnite sa ograničenom grupom pošiljaka i pregledajte istoriju poruka zajedno sa istorijom praćenja. Omogućite osoblju podrške da vidi šta je korisnik primio. Održavajte kontrolu za pauziranje kako bi tim mogao da zaustavi neispravno pravilo bez onemogućavanja samog praćenja pošiljki.

Pratite podobnost za obaveštenja, pokušaje slanja, prihvatanje kod provajdera, greške, duplikate i kašnjenje između prijema događaja i slanja poruke. Prihvatanje kod provajdera ne potvrđuje da je korisnik pročitao poruku, a same stope otvaranja ne potvrđuju da je tok rada bio koristan.

Da biste procenili uticaj na korisnike, uporedite stope kontakata u vezi sa pošiljkama koristeći doslednu definiciju i uporedive grupe pošiljki. Uzmite u obzir promene u kombinaciji prevoznika, probleme sa isporukom i obim porudžbina pre nego što promenu pripišete obaveštenjima.

Česta pitanja

Da li treba poslati potvrdu slanja kada je etiketa kreirana?

Možete poslati ažuriranje o kreiranoj etiketi, ali ga opišite tačno. Recite da su detalji slanja spremni ili da se pošiljka priprema. Formulacije koje potvrđuju preuzimanje od strane prevoznika rezervišite za događaj koji to podržava.

Da li obaveštenja o pošiljkama mogu da funkcionišu bez API integracije?

Da. Tok rada zasnovan na aplikaciji može da obradi povezivanje i pravila obaveštavanja putem svog interfejsa. Proverite dostupne događaje, kanale, kontrole šablona i upravljanje izuzecima u izabranom podešavanju. Prilagođene integracije su primerenije kada postojeći sistemi zahtevaju specijalizovano usmeravanje ili logiku odlučivanja.

Koliko obaveštenja treba da primi svaka pošiljka?

Ne postoji univerzalan idealan broj. Počnite sa različitim, korisnim međustanjima i izuzecima koji zahtevaju akciju. Potisnite ponovljena skeniranja tokom tranzita i dodajte poruke samo kada pružaju informacije koje su korisniku potrebne.

Šta treba da se dogodi kada praćenje prestane da se ažurira?

Primeni pravilo za proveru primereno usluzi, umesto da proglasite pošiljku izgubljenom. Proverite poslednji događaj, procenjeni datum isporuke ako je dostupan i relevantni operativni proces. Pošaljite korisničko ažuriranje samo kada ono dodaje potvrđenu informaciju ili koristan sledeći korak.

Može li obaveštenje o isporuci automatski da zatvori slučaj podrške?

Skeniranje isporuke može da ažurira slučaj, ali ne bi trebalo automatski da reši korisničku prijavu da pošiljka nije primljena. Status isporuke prevoznika i problem korisnika tretirajte kao odvojene zapise, a zatim pratite svoj proces istrage.

Izvori

• 17TRACK Shopify listing aplikacije — referenca proizvoda za procenu podešavanja praćenja i obaveštavanja zasnovanog na aplikaciji.
• 17TRACK Tracking API — referenca proizvoda za integraciju praćenja zasnovanu na API-ju.
• 17TRACK API dokumentacija — referenca za implementaciju pri proveri podržanog ponašanja i zahteva integracije.
• FTC: Vodič za usklađenost poslovanja sa CAN-SPAM zakonom — smernice o komercijalnoj e-pošti i porukama koje kombinuju transakcioni i promotivni sadržaj.