Tehnološki stek nakon kupovine: praćenje, povrati, podrška i kako su povezani

Tehnološki paket nakon kupovine povezuje praćenje pošiljki, upravljanje povratima, korisničku podršku i sisteme koji čuvaju podatke o porudžbinama i plaćanjima. Za ecommerce timove, cilj nije kupovina posebne aplikacije za svaki zadatak. Cilj je da se događaji isporuke, zahtevi korisnika i odluke o povraćaju novca prenose između sistema bez gubitka konteksta ili pokretanja suprotstavljenih radnji.

Ovaj vodič objašnjava šta svaki sloj treba da obuhvata, kako informacije treba da teku između njih i kako testirati veze pre proširenja paketa. Najkorisnija početna tačka je jedno korisničko putovanje: porudžbina se šalje, nešto se menja, korisniku je potrebna pomoć i neko mora da odluči šta će se dalje dogoditi.

Gradite oko odgovornosti, a ne oko spiska aplikacija

Alat za praćenje može da izveštava o napretku pošiljke, ali ažuriranje pošiljke nije potpun zapis o porudžbini. Portal za povrate može da prikupi zahtev, ali taj zahtev nije dokaz da je povraćaj novca izvršen. Agent korisničke podrške može da odobri izuzetak, ali odluka i dalje mora da stigne do sistema koji je izvršava.

Ove razlike su važne zato što povezani sistemi mogu prikazivati iste informacije, a da nemaju isto ovlašćenje da ih menjaju. Odredite autoritativni sistem za svaki zapis i neka se drugi sistemi na njega pozivaju.

Ovo je preporučeni model vlasništva, a ne zahtev za korišćenje pet zasebnih proizvoda. Jedna platforma može pokrivati više odgovornosti. Test je da li svako važno stanje ima jasnog vlasnika i da li drugi sistemi mogu da razlikuju zatraženu radnju od završene radnje.

Praćenje treba da objašnjava napredak pošiljke bez donošenja komercijalnih odluka

Sloj za praćenje povezuje aktivnost prevoznika sa porudžbinom korisnika. Trebalo bi da pomogne korisnicima da razumeju gde se njihov paket nalazi i zaposlenima da prepoznaju kada je pošiljci potrebna pažnja. Za poštanske isporuke, praćenje pošte predstavlja deo tog sloja vidljivosti; šira arhitektura mora da uzme u obzir i porudžbine sa više paketa ili različitim prevoznicima.

Modelujte porudžbine i pošiljke odvojeno. Porudžbina sa dva paketa može imati jedan paket isporučen, dok je drugi još u transportu. Označavanje cele porudžbine kao isporučene nakon prvog događaja isporuke može stvoriti obaveštenja koja dovode u zabludu, netačne odgovore podrške i nedoumice o tome koje stavke mogu da se vrate.

Zadržite originalni događaj uz pojednostavljeni status

Status namenjen korisniku, kao što je „u transportu“, lakši je za čitanje od niza događaja prevoznika. Timovima podrške i dalje mogu biti potrebni originalni tekst događaja, lokacija i vremenska oznaka za istragu problema. Kada je moguće, sačuvajte oba prikaza i razlikujte trenutak kada prevoznik navodi da se događaj dogodio od trenutka kada ga je vaš sistem primio.

Izuzetak u praćenju obično treba da pokrene pregled ili definisani proces, a ne da automatski odobri povraćaj novca. Kašnjenje, pokušaj isporuke i paket označen kao isporučen, ali koji nije primljen, zahtevaju različite radnje. Politika trgovca i proces istrage treba da odrede rešenje.

Dodelite odgovornost za obaveštenja

Odlučite koji sistem šalje svaku poruku. Ako platforma za trgovinu, aplikacija za praćenje i automatizacija podrške svi šalju ažuriranja o isporuci, korisnik može dobiti duplirane ili protivrečne poruke. Održavajte mapu obaveštenja koja navodi okidač, pošiljaoca, publiku, uslove potiskivanja i odredišnu vezu.

Na primer, poruka o kašnjenju pošiljke ne treba da obećava zamenu ako zamena zapravo nije odobrena. Njena svrha može biti samo da objasni najnoviji status i pruži put do pomoći.

Za povrate su potrebni kontekst na nivou stavke i odvojeno finansijsko stanje

Povrat počinje stavkom i odlukom na osnovu pravila, a ne samo brojem za praćenje. Sloj za povrate mora da zna šta je kupljeno, koje količine se još mogu vratiti i da li prethodni povrat ili refundacija već utiču na zahtev.

Pre uvođenja automatizacije definišite događaje koji pomeraju povrat napred. Praktičan proces može razlikovati podnet zahtev, odobren zahtev, predat paket, primljen paket, završen pregled i zatražen povraćaj novca. Stvarne faze treba da odgovaraju načinu na koji poslovanje funkcioniše.

Ne spajajte ove faze u jednu oznaku „vraćeno“. Događaj isporuke prevoznika za paket koji se vraća sam po sebi ne potvrđuje da je osoblje skladišta pregledalo njegov sadržaj. Isto tako, zahtev za povraćaj novca ne potvrđuje da je sistem za plaćanje uspešno obradio povraćaj.

• Za delimične povrate: razmenjujte identifikatore stavki i količine, a ne samo ukupan iznos porudžbine.
• Za zamene: definišite ko rezerviše zalihe, kreira zamensku porudžbinu i rešava eventualnu razliku u ceni.
• Za rane povraćaje novca: navedite kvalifikujući događaj, provere rizika, ovlašćenje za odobrenje i proces za izuzetke.
• Za izuzetke od pravila: zabeležite ko je odobrio izuzetak i koju narednu radnju on dozvoljava.

Koristite objavljena pravila i primenljive obaveze za definisanje podobnosti. Konfiguracija softvera treba da sprovodi te odluke, a ne da tiho postane sama politika.

Podrška je sloj za donošenje odluka o izuzecima

Radni prostor podrške treba da objedini dovoljno konteksta za rešavanje slučaja, bez potrebe da agenti rekonstruišu porudžbinu kroz nekoliko kontrolnih tabli. To ne znači kopiranje svakog zapisa u svaki tiket.

Korisni panel porudžbine obuhvata veze sa pošiljkama, najnovije relevantne događaje praćenja, otvorene povrate, ishode povraćaja novca i prethodne odluke. Takođe treba da prikaže kada su informacije poslednji put ažurirane. Stari status bez vremenske oznake može izgledati kao aktuelan i navesti agenta da pruži pogrešan savet.

Odvojite pristup za čitanje od dozvola za radnje. Mnogi agenti možda moraju da vide istoriju povraćaja novca; manji broj njih treba da ima ovlašćenje da izda povraćaj ili zaobiđe podobnost za povrat. Radnje koje utiču na novac ili zalihe treba da imaju revizijski trag i zaštitu od ponavljanja.

Usmeravajte slučajeve prema potrebnom radu. Pošiljka bez nedavnog kretanja može zahtevati logističku istragu. Odbijena transakcija povraćaja novca može zahtevati finansijske operacije. Povrat primljen sa neočekivanim sadržajem može zahtevati pregled skladišta. Kategorija tiketa je korisna samo ako vodi do imenovanog vlasnika i sledećeg koraka.

Kako se sistemi povezuju: pratite jedan izuzetak od početka do kraja

Razmotrimo ilustrativnu porudžbinu koja sadrži dve stavke poslate u odvojenim paketima. Jedan paket stiže, dok se kod drugog pojavljuje izuzetak u isporuci. Korisnik kontaktira podršku i kasnije vraća isporučenu stavku.

1. Sistem porudžbina kreira veze. Svaka stavka je povezana sa odgovarajućom pošiljkom. Podrška može da vidi da stavka koja nije isporučena nije u dostavljenom paketu.
2. Sloj za praćenje prima izuzetak. On čuva referencu pošiljke i detalje događaja. Proces kreira ili ažurira istragu, umesto da celu porudžbinu tretira kao izgubljenu.
3. Podrška pregledava slučaj. Agent proverava relevantnu pošiljku i beleži dogovoreni sledeći korak. Ako je zamena odobrena, sistem porudžbina prima posebnu instrukciju za njeno kreiranje.
4. Korisnik zahteva povrat isporučene stavke. Sistem za povrate proverava stavku i količinu u odnosu na porudžbinu i postojeću aktivnost povrata.
5. Skladište prima i pregleda povrat. Rezultat pregleda se dodaje zapisu o povratu, a ne zaključuje se samo na osnovu praćenja paketa.
6. Finansijski proces izvršava odobreno rešenje. Rezultat povraćaja novca se upisuje tako da podrška i prikaz povrata namenjen korisniku ne pomešaju odobrenje sa izvršenjem.

Veze su uspešne kada svaki učesnik vidi isti ishod, a da pritom ne može da prepiše zapise izvan svoje odgovornosti.

Detalji integracije koji zaslužuju test, a ne pretpostavku zasnovanu na prodajnoj demonstraciji

Zajednički identifikatori i uparivanje zapisa

Koristite stabilne interne identifikatore za povezivanje porudžbina, stavki, pošiljki, povrata i tiketa. Nemojte se oslanjati samo na adresu e-pošte ili prikazani broj porudžbine. Pravila uparivanja treba da uzmu u obzir tumačenje brojeva za praćenje u kontekstu prevoznika i činjenicu da korisnik može imati više aktivnih porudžbina.

Isporuka događaja i usklađivanje

Tamo gde su podržani, vebhukovi mogu obavestiti sistem koji prima podatke kada se događaj dogodi. Oni ne uklanjaju potrebu za obradom nedostajućih, odloženih, ponovljenih ili poruka pristiglih van redosleda. Pitajte kako se neuspela isporuka ponavlja i kako vaš tim može da oporavi događaje nakon prekida rada.

Učinite ponovljenu obradu bezbednom. Na primer, primanje istog odobrenja povrata dva puta ne bi smelo da izda dva povraćaja novca. Posao usklađivanja takođe treba da upoređuje važne zapise između sistema kako propušteno obaveštenje ne bi trajno blokiralo povrat ili povraćaj novca.

Autentifikacija i granice podataka o korisnicima

Provera praćenja, zahtev za povrat i povraćaj novca koji izdaje agent zahtevaju različite nivoe pristupa. Odlučite kako korisnici dokazuju da mogu da vide ili menjaju porudžbinu, kako se dodeljuju dozvole zaposlenima i koje lične podatke svaka povezana aplikacija zaista zahteva.

Tokom implementacije proverite autentifikaciju vebhukova, čuvanje akreditiva, opoziv pristupa, podešavanja zadržavanja podataka i revizijske dnevnike. Izbegavajte kopiranje potpunih zapisa o korisnicima u dnevnike kada je dovoljna interna referenca.

Gde se 17TRACK uklapa u arhitekturu

Za procenu usmerenu na 17TRACK, počnite od ulazne tačke proizvoda koja odgovara poslu. veb-sajt za praćenje za korisnike relevantan je za pojedinačnu proveru pošiljke. Trgovci koji procenjuju aplikaciju za praćenje porudžbina mogu pogledati 17TRACK stranicu na Shopify-ju. Timovi koji osmišljavaju prilagođenu vezu mogu pogledati informacije o Tracking API-ju i API dokumentaciju. Zahtevi za povrate pripadaju zasebnom pregledu proizvoda 17RETURNS.

Ovo su relevantni putevi za procenu, a ne dokaz da je svaka veza iz ovog vodiča dostupna odmah. Potvrdite konkretna polja podataka, podržane procese, dozvole i komercijalne uslove za proizvod koji nameravate da koristite. Nemojte pretpostaviti da izbor povezanih proizvoda automatski sinhronizuje tikete podrške, preglede skladišta ili ishode plaćanja.

Uvedite najmanji proces koji rešava stvarni nedostatak

Počnite od najskupljeg primopredajnog koraka u postojećem poslovanju. Ako agenti stalno ručno proveravaju status pošiljke, dajte prednost kontekstu praćenja u podršci. Ako korisnici ne mogu da utvrde da li je povrat primljen ili refundiran, dajte prednost vezi povrat–skladište–plaćanje.

Pre kupovine druge aplikacije mapirajte mogućnosti koje su već dostupne na vašoj platformi za trgovinu i u sistemu podrške. Dodajte specijalizovani alat kada rešava definisan nedostatak i proverite čitav proces, umesto da ga procenjujete samo na osnovu stranice namenjene korisnicima.

Koristan test prihvatanja treba da obuhvati:

• Porudžbinu podeljenu na više pošiljki.
• Ažuriranje praćenja koje stiže nakon novijeg događaja.
• Ponavljani događaj koji ne sme ponoviti finansijsku radnju.
• Delimičan povrat uz prethodni povraćaj novca na istoj porudžbini.
• Neuspešan povraćaj novca koji ostaje vidljiv podršci.
• Privremeni prekid integracije nakon kojeg sledi oporavak.
• Ručno uveden izuzetak koji zaobilazi uobičajeni proces uz zabeležen razlog.

Dodelite vlasnika svakom neuspešnom testu i definišite kako će zaposleni raditi dok integracija nije dostupna. Ručna rezervna opcija deo je dizajna, a ne priznanje da je automatizacija neuspešna.

Merite ishode kroz primopredaje

Pratite kontakte povezane sa isporukom po poslatoj porudžbini, vreme obrade povrata, nerešene greške integracije i vreme između odobrenja povraćaja novca i potvrđenog izvršenja. Precizno definišite svaku metriku. Na primer, odvojite vreme transporta povrata od vremena obrade u skladištu kako bi tim odgovoran za rezultat mogao da reaguje.

Upoređujte slične periode i grupe korisnika kada je moguće. Smanjenje broja kontakata sa podrškom nije automatski poboljšanje ako su korisnici istovremeno izgubili pristup pomoći. Mere efikasnosti uparite sa nerešenim slučajevima, ponovljenim kontaktima i dokazima da su korisnici dobili odgovarajuće rešenje.

Česta pitanja

Da li malim prodavnicama trebaju odvojeni alati za praćenje, povrate i podršku?

Ne. Počnite od već dostupnih mogućnosti i operativnih problema koje možete da prepoznate. Odvojeni alati postaju korisni kada postojeće podešavanje ne može da pruži dovoljnu vidljivost, kontrolu pravila ili pouzdane primopredaje. Veći broj aplikacija bez jasnog vlasništva može povećati ručni rad.

Da li događaji praćenja treba automatski da pokreću povraćaj novca?

Samo u okviru izričito odobrenog procesa sa odgovarajućim proverama. Događaji pošiljke opisuju kretanje ili aktivnost isporuke; oni ne potvrđuju nužno podobnost za povraćaj novca. Odvojite događaj koji pokreće proces, odluku o ovlašćenju i finansijsko izvršenje.

Da li je API veza dovoljna da bi dva alata radila zajedno?

Ne. Vezi su takođe potrebni kompatibilni identifikatori, mapiranje polja, dozvole, obrada grešaka i pravila za protivrečna ažuriranja. Potvrdite koji zapisi mogu da se čitaju ili menjaju i testirajte poslovni proces od početka do kraja.

Može li povrat označen kao isporučen biti prikazan kao refundiran?

Ne samo na osnovu tog dokaza. Isporuka na adresu za povrate, prijem u skladištu, pregled, odobrenje povraćaja novca i uspešno izvršenje povraćaja različiti su događaji. Poruke korisnicima treba da navedu fazu koja je zaista potvrđena.

Ko treba da bude vlasnik tehnološkog paketa nakon kupovine?

Vođa ecommerce-a ili operacija praktičan je ukupni vlasnik, dok su timovi podrške, logistike, finansija i tehnike odgovorni za svoje procese. Jedna osoba treba da koordinira kvarove između sistema kako problemi ne bi ostajali između odeljenja.

Izvori

Sledeći zvanični resursi o proizvodima i dokumentaciji predstavljaju početne tačke za puteve procene 17TRACK-a o kojima je bilo reči. Zahteve specifične za implementaciju proverite u relevantnoj dokumentaciji i uslovima proizvoda.

• 17TRACK: veb-sajt za praćenje pošiljki
• Shopify App Store: 17TRACK stranica
• 17TRACK: informacije o Tracking API-ju
• 17TRACK: API dokumentacija
• 17RETURNS: zvanična stranica proizvoda