Tehnološki sklop po nakupu: sledenje, vračila, podpora in kako se povezujejo

Tehnološki sklop po nakupu povezuje sledenje pošiljkam, upravljanje vračil, podporo strankam ter sisteme, ki hranijo zapise o naročilih in plačilih. Za ekipe e-trgovine cilj ni nakup ločene aplikacije za vsako nalogo. Cilj je omogočiti, da se dogodki dostave, zahteve strank in odločitve o vračilih premikajo med sistemi, ne da bi se izgubil kontekst ali sprožila nasprotujoča si dejanja.

Ta vodnik pojasnjuje, za kaj naj bo odgovorna posamezna plast, kako naj informacije tečejo med njimi in kako preizkusiti povezave, preden razširite sklop. Najbolj uporabno izhodišče je ena sama pot stranke: naročilo je odposlano, nekaj se spremeni, stranka potrebuje pomoč in nekdo se mora odločiti, kaj se zgodi naslednje.

Gradite okoli odgovornosti, ne seznama aplikacij

Orodje za sledenje lahko poroča o napredku pošiljke, vendar posodobitev pošiljke ni popoln zapis naročila. Portal za vračila lahko zbere zahtevo, vendar ta zahteva ni dokaz, da je bilo vračilo izvedeno. Agent podpore lahko odobri izjemo, vendar mora odločitev še vedno prispeti do sistema, ki jo izvede.

Te razlike so pomembne, ker lahko povezani sistemi prikazujejo iste informacije, ne da bi imeli enaka pooblastila za njihovo spreminjanje. Določite avtoritativen sistem za vsak zapis, drugi sistemi pa naj se nanj sklicujejo.

To je priporočeni model lastništva, ne zahteva po uporabi petih ločenih izdelkov. Ena platforma lahko pokriva več odgovornosti. Preizkus je, ali ima vsako pomembno stanje jasnega lastnika in ali lahko drugi sistemi razlikujejo med zahtevanim dejanjem in dokončanim dejanjem.

Sledenje naj pojasni napredek pošiljke, ne da bi sprejemalo komercialne odločitve

Plast sledenja povezuje dejavnost prevoznika z naročilom stranke. Strankam mora pomagati razumeti, kje je njihov paket, zaposlenim pa prepoznati, kdaj pošiljka potrebuje pozornost. Pri poštnih dostavah je sledenje pošiljkam en del te plasti vidljivosti; širša arhitektura mora upoštevati tudi naročila z več paketi ali različnimi prevozniki.

Naročila in pošiljke modelirajte ločeno. Naročilo z dvema paketoma ima lahko en paket že dostavljen, drugi pa je še na poti. Če celotno naročilo označite kot dostavljeno po prvem dogodku dostave, lahko ustvarite zavajajoča obvestila, napačne odgovore podpore in nejasnosti glede tega, kateri izdelki so upravičeni do vračila.

Ohranite izvirni dogodek skupaj s poenostavljenim stanjem

Stanje, namenjeno strankam, kot je »v tranzitu«, je lažje razumeti kot tok dogodkov prevoznika. Ekipe podpore lahko za preiskavo težave še vedno potrebujejo izvirno besedilo dogodka, lokacijo in časovni žig. Kjer je mogoče, ohranite oba pogleda ter razlikujte med tem, kdaj prevoznik sporoči, da se je dogodek zgodil, in tem, kdaj ga je prejel vaš sistem.

Izjema pri sledenju bi morala običajno sprožiti pregled ali opredeljen delovni tok, ne pa samodejno odobriti vračila. Zamuda, poskus dostave in paket, označen kot dostavljen, vendar neprejet, zahtevajo različna dejanja. Rešitev morata določiti politika trgovca in postopek preiskave.

Določite odgovornost za obvestila

Odločite, kateri sistem pošilja posamezno sporočilo. Če platforma za e-trgovino, aplikacija za sledenje in avtomatizacija podpore vsi pošiljajo posodobitve dostave, lahko stranka prejme podvojena ali neskladna sporočila. Vzdržujte zemljevid obvestil, ki določa sprožilec, pošiljatelja, občinstvo, pogoje za preprečitev pošiljanja in ciljno povezavo.

Sporočilo o zamudi pošiljke na primer ne sme obljubljati zamenjave, razen če je bila zamenjava dejansko odobrena. Njegov namen je lahko zgolj pojasniti najnovejše stanje in ponuditi pot do pomoči.

Vračila potrebujejo kontekst na ravni izdelka in ločeno finančno stanje

Vračilo se začne z izdelkom in odločitvijo na podlagi pravilnika, ne zgolj s sledilno številko. Plast vračil mora vedeti, kaj je bilo kupljeno, katere količine je še mogoče vrniti in ali prejšnje vračilo ali povračilo že vpliva na zahtevo.

Pred uvedbo avtomatizacije določite dogodke, ki premikajo vračilo naprej. Praktični delovni tok lahko razlikuje med oddano zahtevo, odobreno zahtevo, predano pošiljko, prejeto pošiljko, dokončanim pregledom in zahtevanim povračilom. Dejanske stopnje naj ustrezajo načinu delovanja podjetja.

Teh stopenj ne združite v eno samo oznako »vrnjeno«. Dogodek dostave prevoznika za povratno pošiljko sam po sebi ne dokazuje, da je skladiščno osebje pregledalo njeno vsebino. Prav tako zahteva za povračilo ne dokazuje, da je plačilni sistem povračilo uspešno obdelal.

• Pri delnih vračilih: izmenjujte identifikatorje in količine postavk, ne le skupnega zneska naročila.
• Pri zamenjavah: določite, kdo rezervira zalogo, ustvari nadomestno naročilo in obravnava morebitno razliko v ceni.
• Pri predčasnih povračilih: določite kvalificirani dogodek, preverjanja tveganja, pristojnost za odobritev in postopek za izjeme.
• Pri izjemah od pravilnika: zabeležite, kdo je izjemo odobril in katero nadaljnje dejanje dovoljuje.

Upravičenost določite na podlagi objavljenega pravilnika in veljavnih obveznosti. Konfiguracija programske opreme mora te odločitve izvajati, ne pa tiho postati pravilnik sama po sebi.

Podpora je odločitvena plast za izjeme

Delovno okolje podpore mora združiti dovolj konteksta za rešitev primera, ne da bi morali agenti naročilo rekonstruirati v več nadzornih ploščah. To ne pomeni kopiranja vsakega zapisa v vsak zahtevek.

Uporabna plošča naročila vključuje povezave s pošiljkami, najnovejše pomembne dogodke sledenja, odprta vračila, rezultate povračil in prejšnje odločitve. Prikazati mora tudi, kdaj so bile informacije nazadnje posodobljene. Staro stanje brez časovnega žiga je lahko videti aktualno in agenta privede do napačnega nasveta.

Dostop za branje ločite od dovoljenj za dejanja. Mnogi agenti bodo morda morali videti zgodovino povračil, manj pa jih mora imeti pooblastilo za izvedbo povračila ali preklic upravičenosti do vračila. Dejanja, ki vplivajo na denar ali zalogo, morajo imeti revizijsko sled in zaščitne ukrepe pred ponovitvami.

Primere usmerjajte glede na zahtevano delo. Pošiljka brez nedavnega premika morda potrebuje logistično preiskavo. Zavrnjena plačilna transakcija za povračilo morda potrebuje plačilne operacije. Vračilo z nepričakovano vsebino morda potrebuje pregled skladišča. Kategorija zahtevka je uporabna le, če vodi do imenovanega lastnika in naslednjega koraka.

Kako se sistemi povezujejo: sledite eni izjemi od začetka do konca

Predstavljajte si naročilo z dvema izdelkoma, poslanima v ločenih paketih. En paket prispe, pri drugem pa pride do izjeme pri dostavi. Stranka stopi v stik s podporo in pozneje vrne dostavljeni izdelek.

1. Sistem naročil ustvari povezave. Vsaka postavka je povezana s pravilno pošiljko. Podpora vidi, da nedostavljeni izdelek ni v dostavljenem paketu.
2. Plast sledenja prejme izjemo. Ohrani referenco pošiljke in podrobnosti dogodka. Delovni tok ustvari ali posodobi preiskavo, namesto da bi celotno naročilo obravnaval kot izgubljeno.
3. Podpora pregleda primer. Agent preveri ustrezno pošiljko in zabeleži dogovorjeni naslednji korak. Če je zamenjava odobrena, sistem naročil prejme ločeno navodilo za njeno ustvarjanje.
4. Stranka zahteva vračilo dostavljenega izdelka. Sistem vračil preveri izdelek in količino glede na naročilo in obstoječo dejavnost vračil.
5. Skladišče prejme in pregleda vračilo. Rezultat pregleda je pripet zapisu vračila in ni sklepan zgolj na podlagi sledenja paketu.
6. Finančni delovni tok izvede odobreno rešitev. Rezultat povračila se zapiše nazaj, da podpora in pogled vračila, namenjen stranki, ne zamenjata odobritve z dokončanjem.

Povezave so uspešne, ko vsak udeleženec vidi enak rezultat, ne da bi smel prepisovati zapise zunaj svoje odgovornosti.

Podrobnosti integracije, ki jih je treba preizkusiti, ne pa domnevati na podlagi prodajne predstavitve

Skupni identifikatorji in ujemanje zapisov

Za povezovanje naročil, postavk, pošiljk, vračil in zahtevkov uporabite stabilne notranje identifikatorje. Ne zanašajte se samo na e-poštni naslov ali prikazano številko naročila. Pravila ujemanja morajo upoštevati, da se sledilne številke razlagajo v kontekstu prevoznika in da ima stranka lahko več aktivnih naročil.

Pošiljanje dogodkov in usklajevanje

Kjer je podprto, lahko spletni kavlji obvestijo prejemni sistem, ko pride do dogodka. To ne odpravi potrebe po obravnavi manjkajočih, zakasnjenih, ponovljenih ali neurejenih sporočil. Preverite, kako se neuspešne dostave ponovno poskusijo in kako lahko ekipa po izpadu obnovi dogodke.

Ponavljajočo obdelavo naredite varno. Če na primer isto odobritev vračila prejmete dvakrat, to ne sme izdati dveh povračil. Opravilo za usklajevanje mora pomembne zapise tudi primerjati med sistemi, da zgrešeno obvestilo ne bi trajno zaustavilo vračila ali povračila.

Preverjanje pristnosti in meje podatkov o strankah

Poizvedba o sledenju, zahteva za vračilo in povračilo, ki ga izda agent, potrebujejo različne ravni dostopa. Odločite, kako stranke dokazujejo, da si lahko ogledajo ali spremenijo naročilo, kako se dodeljujejo dovoljenja zaposlenim in katere osebne podatke posamezna povezana aplikacija dejansko potrebuje.

Med uvedbo preverite preverjanje pristnosti spletnih kavljev, shranjevanje poverilnic, preklic dostopa, nastavitve hrambe in revizijske dnevnike. Izogibajte se kopiranju celotnih zapisov strank v dnevnike, kadar zadostuje notranja referenca.

Kam se 17TRACK umešča v arhitekturo

Pri ocenjevanju, usmerjenem v 17TRACK, začnite z vstopno točko izdelka, ki ustreza delu. Spletno mesto za sledenje za potrošnike je pomembno za individualno iskanje pošiljk. Trgovci, ki ocenjujejo aplikacijo za sledenje naročilom, si lahko ogledajo vnos 17TRACK v Shopifyju. Ekipe, ki načrtujejo povezavo po meri, lahko pregledajo informacije o Tracking API in dokumentacijo API. Zahteve glede vračil sodijo v ločen pregled izdelka 17RETURNS.

To so ustrezne poti za ocenjevanje, ne dokaz, da je vsaka povezava iz tega vodnika na voljo že takoj. Potrdite konkretna podatkovna polja, podprte delovne tokove, dovoljenja in komercialne pogoje za izdelek, ki ga nameravate uporabiti. Ne domnevajte, da izbira povezanih izdelkov samodejno sinhronizira zahtevke podpore, preglede skladišča ali rezultate plačil.

Uvedite najmanjši delovni tok, ki odpravi dejansko vrzel

Začnite z najdražjim predajanjem v obstoječem delovanju. Če agenti večkrat ročno preverjajo stanje pošiljke, dajte prednost kontekstu sledenja v podpori. Če stranke ne morejo ugotoviti, ali je bilo vračilo prejeto ali povrnjeno, dajte prednost povezavi od vračila prek skladišča do plačila.

Pred nakupom nove aplikacije preglejte zmogljivosti, ki so že na voljo v vaši komercialni platformi in sistemu podpore. Specializirano orodje dodajte, ko rešuje opredeljeno vrzel, in preverite celoten delovni tok, namesto da ga ocenjujete samo na podlagi strani, namenjene strankam.

Uporaben sprejemni preizkus mora vključevati:

• Naročilo, razdeljeno na več pošiljk.
• Posodobitev sledenja, ki prispe po novejšem dogodku.
• Ponovljen dogodek, ki ne sme ponoviti finančnega dejanja.
• Delno vračilo s prejšnjim povračilom pri istem naročilu.
• Neuspešno povračilo, ki ostane vidno podpori.
• Začasni izpad integracije, ki mu sledi obnovitev.
• Ročna izjema, ki z zabeleženim razlogom preglasi običajni delovni tok.

Vsakemu neuspešnemu preizkusu dodelite lastnika in določite, kako bodo zaposleni delali, ko integracija ne bo na voljo. Ročna nadomestna možnost je del zasnove, ne priznanje, da je avtomatizacija odpovedala.

Merite rezultate med predajanji

Spremljajte število stikov, povezanih z dostavo, na odposlano naročilo, čas obdelave vračila, nerešene napake integracije ter čas med odobritvijo povračila in potrjeno izvedbo. Vsako metriko natančno opredelite. Ločite na primer čas prehoda vračila od časa obdelave v skladišču, da lahko odgovorna ekipa ukrepa na podlagi rezultata.

Kjer je mogoče, primerjajte podobna obdobja in skupine strank. Zmanjšanje števila stikov s podporo ni samodejno izboljšanje, če so stranke hkrati izgubile dostop do pomoči. Ukrepe učinkovitosti povežite z nerešenimi primeri, ponovljenimi stiki in dokazi, da so stranke prejele pravilno rešitev.

Pogosta vprašanja

Ali majhne trgovine potrebujejo ločena orodja za sledenje, vračila in podporo?

Ne. Začnite z razpoložljivimi zmogljivostmi in prepoznanimi operativnimi težavami. Ločena orodja postanejo uporabna, ko trenutna nastavitev ne more zagotoviti zadostne vidljivosti, nadzora pravilnikov ali zanesljivih predaj. Več aplikacij brez jasnega lastništva lahko poveča ročno delo.

Ali naj dogodki sledenja samodejno sprožijo povračila?

Samo v izrecno odobrenem delovnem toku z ustreznimi preverjanji. Dogodki pošiljke opisujejo premikanje ali dejavnost dostave; ni nujno, da dokazujejo upravičenost do povračila. Sprožilni dogodek, odločitev o odobritvi in finančno izvedbo ohranite ločene.

Ali povezava API zadostuje za sodelovanje dveh orodij?

Ne. Povezava potrebuje tudi združljive identifikatorje, preslikavo polj, dovoljenja, obravnavo napak in pravila za nasprotujoče si posodobitve. Potrdite, katere zapise je mogoče prebrati ali spremeniti, in poslovni delovni tok preizkusite od začetka do konca.

Ali je vračilo, označeno kot dostavljeno, mogoče prikazati kot povrnjeno?

Ne samo na podlagi tega dokaza. Dostava na naslov za vračila, prejem v skladišču, pregled, odobritev povračila in uspešna izvedba povračila so različni dogodki. Sporočila strankam morajo opredeliti stopnjo, ki je bila dejansko potrjena.

Kdo naj bo odgovoren za tehnološki sklop po nakupu?

Vodja e-trgovine ali operacij je praktičen splošni lastnik, pri čemer so podpora, logistika, finance in tehnične ekipe odgovorne za svoje delovne tokove. Ena oseba mora usklajevati napake med sistemi, da težave ne ostanejo med oddelki.

Viri

Naslednji uradni viri za izdelke in dokumentacijo so izhodišča za zgoraj obravnavane poti ocenjevanja 17TRACK. Zahteve, specifične za uvedbo, preverite v ustrezni dokumentaciji in pogojih izdelka.

• 17TRACK: spletno mesto za sledenje pošiljkam
• Shopify App Store: vnos 17TRACK
• 17TRACK: informacije o Tracking API
• 17TRACK: dokumentacija API
• 17RETURNS: uradna stran izdelka