Technologijų paketas po pirkimo: siuntų sekimas, grąžinimai, pagalba ir jų sąveika
Po pirkimo naudojamų technologijų rinkinyje sujungiami siuntų sekimas, grąžinimų valdymas, klientų aptarnavimas ir sistemos, kuriose saugomi užsakymų bei mokėjimų įrašai. Elektroninės prekybos komandoms tikslas nėra kiekvienai užduočiai įsigyti atskirą programėlę. Tikslas – užtikrinti, kad pristatymo įvykiai, klientų užklausos ir sprendimai dėl pinigų grąžinimo judėtų tarp sistemų neprarandant konteksto ir nesukeliant prieštaringų veiksmų.
Šiame vadove paaiškinama, už ką turėtų būti atsakingas kiekvienas sluoksnis, kaip tarp jų turėtų judėti informacija ir kaip išbandyti ryšius prieš plečiant technologijų rinkinį. Naudingiausia pradėti nuo vienos klientų kelionės: užsakymas išsiunčiamas, kažkas pasikeičia, klientui prireikia pagalbos ir kažkas turi nuspręsti, kas vyks toliau.
Kurkite pagal atsakomybes, o ne pagal programėlių sąrašą
Siuntų sekimo įrankis gali pranešti apie siuntos eigą, tačiau siuntos atnaujinimas nėra visas užsakymo įrašas. Grąžinimų portalas gali surinkti užklausą, tačiau ši užklausa nėra įrodymas, kad pinigai jau grąžinti. Klientų aptarnavimo agentas gali patvirtinti išimtį, tačiau sprendimas vis tiek turi pasiekti sistemą, kuri jį įvykdys.
Šie skirtumai svarbūs, nes sujungtos sistemos gali rodyti tą pačią informaciją, tačiau neturėti vienodų teisių ją keisti. Kiekvienam įrašui paskirkite pagrindinę sistemą ir nustatykite, kad kitos sistemos į ją remtųsi.
| Sluoksnis | Rekomenduojama atsakomybė | Keistina informacija |
|---|---|---|
| Prekybos platforma arba užsakymų valdymo sistema | Užsakymo tapatybė, įsigytos prekės, įvykdymo paskirstymas ir komercinė užsakymo būsena | Užsakymų ID, eilučių ID, kiekiai, klientų nuorodos ir sąsajos su siuntomis |
| Siuntų sekimas | Siuntos matomumas ir pristatymo įvykių interpretavimas | Vežėjų nuorodos, sekimo numeriai, įvykių laikai, būsenos ir išimtys |
| Grąžinimų valdymas | Grąžinimo užklausos, taisyklių patikros, patvirtintos prekės ir grąžinimo proceso būsena | Grąžinimų ID, prekių kiekiai, priežastys, patvirtinimai ir patikros rezultatai |
| Klientų aptarnavimas | Pokalbiai su klientais, tyrimas ir patvirtintos išimtys | Užklausų ID, svarbus užsakymo kontekstas, sprendimai ir eskalavimo atsakomybė |
| Sandėlio ir mokėjimų sistemos | Fizinis priėmimas ir patikra; finansinis vykdymas ir suderinimas | Priėmimo rezultatai, prekių paskirtis, pinigų grąžinimo nuorodos ir operacijų rezultatai |
Tai rekomenduojamas atsakomybių modelis, o ne reikalavimas naudoti penkis atskirus produktus. Viena platforma gali apimti kelias atsakomybes. Svarbu, kad kiekviena reikšminga būsena turėtų aiškų savininką ir kad kitos sistemos galėtų atskirti prašomą veiksmą nuo užbaigto veiksmo.
Sekimas turėtų paaiškinti siuntos eigą, o ne priimti komercinius sprendimus
Sekimo sluoksnis susieja vežėjo veiklą su kliento užsakymu. Jis turėtų padėti klientams suprasti, kur yra jų siunta, ir darbuotojams atpažinti, kada siuntai reikia dėmesio. Pašto pristatymo atveju pašto siuntų sekimas yra viena šio matomumo sluoksnio dalių; platesnėje architektūroje taip pat reikia atsižvelgti į užsakymus su keliomis siuntomis ar skirtingais vežėjais.
Modeliuokite užsakymus ir siuntas atskirai. Užsakyme su dviem pakuotėmis viena gali būti pristatyta, o kita vis dar gabenama. Pažymėjus visą užsakymą kaip pristatytą po pirmojo pristatymo įvykio, gali būti siunčiami klaidinantys pranešimai, pateikiami neteisingi atsakymai klientų aptarnavimo skyriuje ir kyla neaiškumų, kurioms prekėms taikomas grąžinimas.
Išsaugokite pradinį įvykį kartu su supaprastinta būsena
Klientui skaitomą būseną, pvz., „gabenama“, suprasti lengviau nei vežėjo įvykių srautą. Tačiau klientų aptarnavimo komandoms tiriant problemą vis tiek gali reikėti pradinio įvykio teksto, vietos ir laiko žymos. Jei įmanoma, išsaugokite abu vaizdus ir atskirkite laiką, kada vežėjas pranešė apie įvykį, nuo laiko, kada jūsų sistema jį gavo.
Sekimo išimtis paprastai turėtų pradėti peržiūrą arba nustatytą procesą, o ne automatiškai suteikti teisę grąžinti pinigus. Vėlavimas, nesėkmingas pristatymas ir pažymėta, bet negauta siunta reikalauja skirtingų veiksmų. Sprendimą turėtų lemti prekybininko politika ir tyrimo procesas.
Paskirkite atsakomybę už pranešimus
Nuspręskite, kuri sistema siunčia kiekvieną pranešimą. Jei prekybos platforma, sekimo programa ir klientų aptarnavimo automatizavimas siunčia pristatymo atnaujinimus, klientas gali gauti pasikartojančius arba nesuderintus pranešimus. Tvarkykite pranešimų žemėlapį, kuriame nurodomas paleidiklis, siuntėjas, auditorija, slopinimo sąlygos ir paskirties nuoroda.
Pavyzdžiui, pranešime apie siuntos vėlavimą nereikėtų žadėti pakeitimo, nebent pakeitimas iš tikrųjų patvirtintas. Jo paskirtis gali būti tiesiog paaiškinti naujausią būseną ir pateikti kelią į pagalbą.
Grąžinimams reikalingas prekės lygio kontekstas ir atskira finansinė būsena
Grąžinimas prasideda nuo prekės ir sprendimo pagal politiką, o ne vien nuo sekimo numerio. Grąžinimų sluoksnis turi žinoti, kas buvo įsigyta, kokius kiekius dar galima grąžinti ir ar ankstesnis grąžinimas arba pinigų grąžinimas jau turi įtakos užklausai.
Prieš diegdami automatizavimą apibrėžkite įvykius, kurie perkelia grąžinimą į kitą etapą. Praktiniame procese galima atskirti užklausos pateikimą, užklausos patvirtinimą, siuntos perdavimą, siuntos gavimą, patikros užbaigimą ir pinigų grąžinimo užklausą. Faktiniai etapai turėtų atitikti jūsų verslo veiklą.
Nesujunkite šių etapų į vieną etiketę „grąžinta“. Vežėjo įvykis, rodantis grąžinamos siuntos pristatymą, pats savaime nepatvirtina, kad sandėlio darbuotojai patikrino jos turinį. Taip pat pinigų grąžinimo užklausa nepatvirtina, kad mokėjimų sistema sėkmingai įvykdė grąžinimą.
- Daliniams grąžinimams: keiskitės eilučių ID ir kiekiais, o ne tik bendra užsakymo suma.
- Mainams: apibrėžkite, kas rezervuoja atsargas, sukuria pakeitimo užsakymą ir tvarko kainos skirtumą.
- Ankstyvam pinigų grąžinimui: nurodykite kvalifikuojantį įvykį, rizikos patikras, tvirtinimo teisę ir išimčių procesą.
- Politikos išimtims: įrašykite, kas patvirtino išimtį ir kokį tolesnį veiksmą ji leidžia.
Tinkamumui apibrėžti naudokite paskelbtą politiką ir taikomus įsipareigojimus. Programinės įrangos konfigūracija turėtų įgyvendinti šiuos sprendimus, o ne tyliai tapti pačia politika.
Klientų aptarnavimas yra išimčių sprendimų sluoksnis
Klientų aptarnavimo darbo vietoje turėtų būti pakankamai konteksto bylai išspręsti, kad agentams nereikėtų rekonstruoti užsakymo keliose informacijos suvestinėse. Tai nereiškia, kad kiekviename biliete reikia kopijuoti visus įrašus.
Naudingame užsakymo skydelyje pateikiamos sąsajos su siuntomis, naujausi svarbūs sekimo įvykiai, atviri grąžinimai, pinigų grąžinimo rezultatai ir ankstesni sprendimai. Taip pat turėtų būti rodoma, kada informacija paskutinį kartą atnaujinta. Sena būsena be laiko žymos gali atrodyti esama ir paskatinti agentą pateikti neteisingą informaciją.
Atskirkite skaitymo prieigą nuo veiksmų leidimų. Daugeliui agentų gali reikėti peržiūrėti pinigų grąžinimo istoriją, tačiau mažesniam skaičiui gali būti suteikta teisė grąžinti pinigus arba pakeisti grąžinimo tinkamumą. Veiksmai, turintys įtakos pinigams ar atsargoms, turėtų būti registruojami audito žurnale ir apsaugoti nuo pasikartojimo.
Nukreipkite bylas pagal reikalingą darbą. Siuntai, kurioje ilgą laiką nėra naujų įvykių, gali reikėti logistikos tyrimo. Atmesta pinigų grąžinimo operacija gali būti mokėjimų operacijų klausimas. Grąžinta siunta su netikėtu turiniu gali reikalauti sandėlio patikros. Bilieto kategorija naudinga tik tada, kai ji nukreipia pas įvardytą atsakingą asmenį ir kitą veiksmą.
Kaip sistemos susiejamos: sekite vieną išimtį nuo pradžios iki pabaigos
Įsivaizduokite užsakymą, kurį sudaro dvi prekės, išsiųstos atskiromis siuntomis. Viena siunta atvyksta, o kitoje atsiranda pristatymo išimtis. Klientas kreipiasi į aptarnavimo skyrių ir vėliau grąžina pristatytą prekę.
- Užsakymų sistema sukuria ryšius. Kiekviena užsakymo eilutė susiejama su tinkama siunta. Aptarnavimo skyrius gali matyti, kad nepristatyta prekė nėra pristatytoje siuntoje.
- Sekimo sluoksnis gauna išimtį. Jis išsaugo siuntos nuorodą ir įvykio informaciją. Procesas sukuria arba atnaujina tyrimą, o ne traktuoja visą užsakymą kaip prarastą.
- Aptarnavimo skyrius peržiūri bylą. Agentas patikrina atitinkamą siuntą ir įrašo sutartą kitą veiksmą. Jei pakeitimas patvirtinamas, užsakymų sistema gauna atskirą nurodymą jį sukurti.
- Klientas paprašo grąžinti pristatytą prekę. Grąžinimų sistema patikrina prekę ir kiekį pagal užsakymą bei esamą grąžinimų veiklą.
- Sandėlis priima ir patikrina grąžinimą. Patikros rezultatas pridedamas prie grąžinimo įrašo, o ne nustatomas vien pagal siuntos sekimą.
- Finansinis procesas įvykdo patvirtintą sprendimą. Pinigų grąžinimo rezultatas įrašomas atgal, kad aptarnavimo skyrius ir klientui rodoma grąžinimo informacija nesupainiotų patvirtinimo su įvykdymu.
Ryšiai veikia sėkmingai, kai kiekvienas dalyvis mato tą patį rezultatą, tačiau negali perrašyti įrašų už savo atsakomybės ribų.
Integracijos detalės, kurias reikia išbandyti, o ne laikyti savaime suprantamomis pagal pardavimo demonstraciją
Bendri identifikatoriai ir įrašų sutapdinimas
Užsakymams, eilučių elementams, siuntoms, grąžinimams ir bilietams susieti naudokite stabilius vidinius identifikatorius. Nepasitikėkite vien el. pašto adresu ar rodomu užsakymo numeriu. Sutapdinimo taisyklėse turi būti atsižvelgiama į tai, kad sekimo numeriai interpretuojami pagal vežėją ir kad klientas gali turėti kelis aktyvius užsakymus.
Įvykių perdavimas ir suderinimas
Kai palaikoma, žiniatinklio kabliai gali pranešti priimančiajai sistemai, kai įvyksta įvykis. Tačiau vis tiek reikia tvarkyti trūkstamus, vėluojančius, pasikartojančius ar ne eilės tvarka gautus pranešimus. Išsiaiškinkite, kaip kartojamas nepavykęs perdavimas ir kaip komanda gali atkurti įvykius po sutrikimo.
Užtikrinkite, kad pakartotinis apdorojimas būtų saugus. Pavyzdžiui, du kartus gavus tą patį grąžinimo patvirtinimą neturėtų būti du kartus grąžinami pinigai. Suderinimo procesas taip pat turėtų palyginti svarbius įrašus tarp sistemų, kad praleistas pranešimas nepaliktų grąžinimo ar pinigų grąžinimo visam laikui įstrigusio.
Autentifikavimas ir klientų duomenų ribos
Sekimo peržiūrai, grąžinimo užklausai ir agento inicijuotam pinigų grąžinimui reikalingi skirtingi prieigos lygiai. Nuspręskite, kaip klientai įrodo, kad gali peržiūrėti ar keisti užsakymą, kaip priskiriami darbuotojų leidimai ir kokios asmeninės informacijos iš tikrųjų reikia kiekvienai prijungtai programai.
Diegdami patikrinkite žiniatinklio kablių autentifikavimą, kredencialų saugojimą, prieigos atšaukimą, saugojimo nustatymus ir audito žurnalus. Venkite kopijuoti visus klientų įrašus į žurnalus, kai pakanka vidinės nuorodos.
Kur architektūroje tinka 17TRACK
Vertindami pagal 17TRACK, pradėkite nuo produkto įėjimo taško, atitinkančio atliekamą darbą. vartotojų siuntų sekimo svetainė skirta atskirų siuntų paieškai. Prekybininkai, vertinantys užsakymų sekimo programą, gali peržiūrėti 17TRACK įrašą Shopify parduotuvėje. Komandos, kuriančios pasirinktinį ryšį, gali susipažinti su sekimo API informacija ir API dokumentacija. Grąžinimų reikalavimus reikėtų atskirai įvertinti peržiūrint 17RETURNS.
Tai yra aktualūs vertinimo keliai, o ne įrodymas, kad kiekvienas šiame vadove aprašytas ryšys veikia iš karto. Patvirtinkite konkrečius naudojamus duomenų laukus, palaikomus procesus, leidimus ir komercines sąlygas produktui, kurį ketinate naudoti. Nemanykite, kad pasirinkus susijusius produktus automatiškai sinchronizuojami aptarnavimo bilietai, sandėlio patikros ar mokėjimų rezultatai.
Įdiekite mažiausią procesą, kuris pašalina realią spragą
Pradėkite nuo brangiausio perdavimo etapo esamoje veikloje. Jei agentai nuolat rankiniu būdu tikrina siuntų būseną, pirmenybę teikite sekimo kontekstui klientų aptarnavimo sistemoje. Jei klientai negali suprasti, ar grąžinimas gautas arba už jį grąžinti pinigai, pirmenybę teikite ryšiui tarp grąžinimo, sandėlio ir mokėjimo.
Prieš pirkdami kitą programą, susisteminkite galimybes, kurios jau prieinamos jūsų prekybos platformoje ir klientų aptarnavimo sistemoje. Pridėkite specializuotą įrankį, kai jis pašalina apibrėžtą spragą, ir patikrinkite visą procesą, o ne vertinkite jį vien pagal klientui rodomą puslapį.
Naudingas priėmimo testas turėtų apimti:
- Užsakymą, padalytą į kelias siuntas.
- Sekimo atnaujinimą, kuris gaunamas po naujesnio įvykio.
- Pasikartojantį įvykį, kuris neturi pakartoti finansinio veiksmo.
- Dalį grąžinamų prekių, kai tam pačiam užsakymui jau buvo grąžinti pinigai.
- Nesėkmingą pinigų grąžinimą, kuris lieka matomas aptarnavimo skyriui.
- Laikiną integracijos sutrikimą ir vėlesnį atkūrimą.
- Rankinę išimtį, kuri pakeičia įprastą procesą ir turi užregistruotą priežastį.
Kiekvienam nepavykusiam testui paskirkite atsakingą asmenį ir apibrėžkite, kaip darbuotojai dirbs, kol integracija nepasiekiama. Rankinis atsarginis procesas yra dizaino dalis, o ne pripažinimas, kad automatizavimas nepavyko.
Matuokite rezultatus visuose perdavimo etapuose
Sekite su pristatymu susijusių kontaktų skaičių vienam išsiųstam užsakymui, grąžinimo apdorojimo laiką, neišspręstas integracijos klaidas ir laiką nuo pinigų grąžinimo patvirtinimo iki patvirtinto įvykdymo. Tiksliai apibrėžkite kiekvieną rodiklį. Pavyzdžiui, atskirkite grąžinimo gabenimo laiką nuo sandėlio apdorojimo laiko, kad už rezultatą atsakinga komanda galėtų imtis veiksmų.
Jei įmanoma, lyginkite panašius laikotarpius ir klientų grupes. Klientų aptarnavimo užklausų sumažėjimas ne visada reiškia pagerėjimą, jei klientai taip pat prarado prieigą prie pagalbos. Efektyvumo rodiklius derinkite su neišspręstomis bylomis, pakartotiniais kontaktais ir įrodymais, kad klientai gavo tinkamą sprendimą.
DUK
Ar mažoms parduotuvėms reikia atskirų sekimo, grąžinimų ir aptarnavimo įrankių?
Ne. Pradėkite nuo jau turimų galimybių ir nustatomų veiklos problemų. Atskiri įrankiai tampa naudingi, kai esama sąranka negali užtikrinti pakankamo matomumo, politikos kontrolės ar patikimų perdavimų. Daugiau programų be aiškios atsakomybės gali padidinti rankinio darbo kiekį.
Ar sekimo įvykiai turėtų automatiškai pradėti pinigų grąžinimą?
Tik pagal aiškiai patvirtintą procesą su tinkamomis patikromis. Siuntų įvykiai aprašo judėjimą ar pristatymo veiklą; jie nebūtinai nustato teisę į pinigų grąžinimą. Paleidimo įvykį, leidimo sprendimą ir finansinį vykdymą laikykite atskirais etapais.
Ar API ryšio pakanka, kad du įrankiai veiktų kartu?
Ne. Ryšiui taip pat reikalingi suderinami identifikatoriai, laukų susiejimas, leidimai, klaidų tvarkymas ir prieštaringų atnaujinimų taisyklės. Patvirtinkite, kuriuos įrašus galima skaityti ar keisti, ir išbandykite verslo procesą nuo pradžios iki pabaigos.
Ar galima grąžinimą, pažymėtą kaip pristatytą, rodyti kaip grąžintą?
Ne, remiantis vien šiuo įrodymu. Pristatymas grąžinimo adresu, gavimas sandėlyje, patikra, pinigų grąžinimo patvirtinimas ir sėkmingas pinigų grąžinimo įvykdymas yra skirtingi įvykiai. Klientų pranešimuose reikėtų nurodyti faktiškai patvirtintą etapą.
Kas turėtų būti atsakingas už po pirkimo naudojamų technologijų rinkinį?
Elektroninės prekybos arba veiklos vadovas yra praktiškas bendras savininkas, o klientų aptarnavimo, logistikos, finansų ir techninės komandos atsako už savo procesus. Vienas asmuo turėtų koordinuoti tarp sistemų kylančius gedimus, kad problemos neliktų tarp skyrių.
Šaltiniai
Toliau pateikiami oficialūs produktų ir dokumentacijos ištekliai yra pirmieji 17TRACK vertinimo kelių, aptartų aukščiau, taškai. Diegimui būdingus reikalavimus patikrinkite atitinkamoje dokumentacijoje ir produkto sąlygose.
