AI tendencijos, formuojančios patirtį po pirkimo: siuntų sekimas, pagalba ir grąžinimai

DI keičia po pirkimo patirtį, pateikdama naudingesnius siuntų atnaujinimus, pagalbos asistentus, veikiančius su užsakymų informacija, ir grąžinimo procesus, padedančius komandoms interpretuoti užklausas. Elektroninės prekybos operacijų vadovams praktinė galimybė nėra tiesiog pridėti pokalbių robotą. Svarbu sujungti patikimus sekimo duomenis, patvirtintas taisykles ir kontroliuojamus veiksmus, kad klientai gautų aiškesnius atsakymus, nesukuriant nepagrįstų pristatymo pažadų ar neteisingų sprendimų dėl pinigų grąžinimo.

Šiame vadove daugiausia dėmesio skiriama vertiems įvertinti veiklos modeliams, o ne diegimo rodiklių prognozėms ar universaliai investicijų grąžai žadėti. Geriausia pradžia – siaura klientų problema, į kurią galima patikimai atsakyti: paaiškinti siuntos įvykį, patikrinti teisę grąžinti prekę arba parengti pagalbos atvejį žmogui.

Atskirkite naudingą DI nuo įprasto automatizavimo

Daugeliui po pirkimo patirties patobulinimų DI nereikalingas. Pranešimo siuntimas, kai siunta pasiekia tam tikrą būseną, patikrinimas, ar užsakymas patenka į grąžinimo laikotarpį, ir bilieto nukreipimas pagal aiškią taisyklę yra įprastos automatizavimo užduotys.

DI tampa naudingesnis, kai įvestis yra dviprasmiška arba nestruktūrizuota. Pavyzdžiui, galima interpretuoti kliento aprašytą pristatymo problemą, apibendrinti ilgą pokalbį su pagalbos tarnyba arba techninį sekimo įvykį išversti į paprastą kalbą. Prognozavimo modeliai atlieka kitą funkciją: pagal aktualius istorinius ir dabartinius signalus įvertina rezultatą, pavyzdžiui, pristatymo laikotarpį.

Šios funkcijos neturėtų turėti vienodų įgaliojimų. Kalbos modelis gali parengti paaiškinimą, taisyklių variklis turėtų nustatyti teisę, o autentifikuota operacinė sistema turėtų atlikti pinigų grąžinimą. Atskirai išlaikant šias atsakomybes, klaidas lengviau aptikti ir apriboti.

Sekimas pereina nuo būsenos rodymo prie kontekstinio paaiškinimo

Sekimo puslapyje gali būti rodomas tikslus vežėjo įvykis, tačiau klientas vis tiek gali likti nesupratęs situacijos. „Etiketė sukurta“ nebūtinai reiškia, kad vežėjas jau perėmė siuntą. Vien tarpas tarp nuskaitymų neįrodo, kad siunta prarasta. DI padedami paaiškinimai gali padėti klientams suprasti šiuos skirtumus, jei paaiškinimas neperžengia turimų įrodymų ribų.

Paaiškinkite įvykį, nesugalvodami kito

Naudingas sekimo atsakymas turėtų atskirti tris dalykus: ką pranešė vežėjas, ką šis įvykis paprastai reiškia ir ką klientas gali daryti toliau. Taip pat reikėtų išsaugoti įvykio laiko žymą ir nurodyti, ar atvykimo prognozė gauta iš vežėjo, ar iš atskiros prognozės.

Pavyzdžiui, pagrįstas atsakymas galėtų būti toks: „Naujausias vežėjo įvykis rodo, kad siuntimo informacija buvo pateikta. Šiame sekimo sraute kol kas nerodomas paėmimo arba priėmimo nuskaitymas.“ Nereikėtų to paversti teiginiu „Jūsų siunta išvyko iš sandėlio“, nebent kitą sistemą patikimai patvirtintų šį faktą.

• Padarykite pradinį įvykį pasiekiamą. Paprastos kalbos santrauka turėtų papildyti pagrindinį vežėjo sekimo įrašą, o ne jį paslėpti.
• Rodykite duomenų aktualumą. Nurodykite, kada įvyko siuntos įvykis ir, jei naudinga, kada duomenys buvo paskutinį kartą gauti.
• Atskirkite stebėjimą nuo prognozės. Prognozuojamas pristatymo laikotarpis nėra patvirtintas susitikimo laikas.
• Naudokite aiškią atsarginę formuluotę. Jei srautas nepasiekiamas, nurodykite, kad būsenos nepavyko atnaujinti, o ne pateikite seną įvykį kaip naują.

Pristatymo prognozes vertinkite kaip įverčius su išmatuojama paklaida

Prognozuojamus pristatymo įverčius verta vertinti, kai įmonė turi pakankamai aktualią siuntų istoriją ir būdą patikrinti rezultatus. Jų naudingumas priklauso nuo maršruto, paslaugos, turimų įvykių ir nuo to, kiek vertinimo duomenys panašūs į tikras siuntas.

Palyginkite siūlomą modelį su paprastu atskaitos tašku, pavyzdžiui, įmonei jau prieinama vežėjo prognoze. Atskirai matuokite skirtingų siuntimo paslaugų ir paskirties vietų paklaidą. Vienas vidurkis gali paslėpti nepatikimus tarpvalstybinių maršrutų ar sutrikimų laikotarpio rezultatus. Jei konkrečios siuntos prognozė nepatikima, klientui gali būti geriau rodyti patvirtintą būseną be naujo įverčio.

Pagalbos asistentams reikia veiklos konteksto, o ne tik sklandžių atsakymų

Asistentui, tvarkančiam užklausą „Kur yra mano užsakymas?“, reikia daugiau nei sekimo numerio. Priklausomai nuo užklausos, jam gali reikėti autentifikuotos prieigos prie užsakymo, įvykdymo būsenos, siuntos istorijos, taikomo pristatymo pažado ir prekybininko patvirtintos eskalavimo taisyklės.

Paieška pagrįsta pagalba sujungia asistentą su aktualiais įrašais ir taisyklių dokumentais prieš jam sugeneruojant atsakymą. Tai gali padaryti atsakymus aktualesnius, tačiau vien paieška negarantuoja teisingumo. Sistema gali pasirinkti pasenusią taisyklę, supainioti dvi siuntas arba padaryti išvadą, kurios rasta informacija nepagrindžia.

Kurkite procesą, pagrįstą patikra ir eskalavimu

1. Patikrinkite prieigą. Prieš atskleisdami adresus, pirkimo informaciją ar siuntos duomenis įsitikinkite, kad klientas turi teisę peržiūrėti užsakymą.
2. Gaukite aktualius įrašus. Susiekite užsakymą, siuntą ir kliento užklausą. Atsižvelkite į dalinius siuntimus, o ne manykite, kad vienas užsakymas reiškia vieną siuntą.
3. Nustatykite leistiną atsakymą. Naudokite taikomą taisyklių versiją ir atskirkite patvirtintus faktus nuo neaiškių interpretacijų.
4. Pasiūlykite leidžiamą kitą veiksmą. Tai gali būti sekimo nuoroda, pagalbos atvejis arba grąžinimo užklausa, bet nebūtinai iškart grąžinami pinigai.
5. Eskalavimo metu perduokite kontekstą. Žmogui perduokite kliento problemą, patikrintus įrašus, atliktus veiksmus ir neišspręstą klausimą.

Pradėkite nuo pagalbos agentams, jei taisyklių išimtys dažnos arba užsakymų duomenys nenuoseklūs. Agentui peržiūrėti skirtas juodraštis gali būti naudingas prieš įmonei pasirengiant savarankiškiems sprendimams klientų akivaizdoje. Net ir įjungus tiesioginius atsakymus, klientai turėtų turėti aiškų kelią gauti žmogaus pagalbą.

Grąžinimų valdymui naudinga interpretacija, tačiau teisę turi nustatyti taisyklės

Grąžinimo užklausose pateikiama informacija, kurią sunku užfiksuoti trumpame išskleidžiamajame sąraše. „Netinka“ gali reikšti dydį, gaminio matmenis arba netikslų aprašymą. DI gali padėti suskirstyti šiuos paaiškinimus, apibendrinti pateiktą informaciją ir nustatyti užklausas, kurias reikia patikslinti.

Ši interpretacija turėtų likti atskirta nuo sprendimo dėl grąžinimo. Teisė gali priklausyti nuo pirkimo datos, prekės kategorijos, būklės, paskirties vietos, prekybininko taisyklių ir taikomų vartotojų teisių. Asistentas neturėtų sugalvoti išimties ar laikyti savo santraukos įrodymu, kad klientas atitinka sąlygas.

Naudokite DI atvejui parengti, o ne tyliai perrašyti taisykles

Kontroliuojamas procesas pirmiausia gauna užsakymą ir taikomą taisyklę. Tada prašoma tik trūkstamos informacijos, atliekami teisės patikrinimai ir pateikiamos leistinos parinktys. DI gali padaryti pokalbį lengviau suprantamą, o pagrindinės taisyklės nustato, kas gali būti pasiūlyta.

Pavyzdžiui, jei klientas praneša apie sugadintą prekę, asistentas gali surinkti aprašymą ir sutvarkyti pateiktus įrodymus. Atskirame procese turėtų būti nuspręsta, ar reikalinga patikra, pakeitimas, pinigų grąžinimas ar žmogaus peržiūra. Jei naudojama vaizdų analizė, ji neturėtų būti laikoma galutiniu žalos ar netinkamo elgesio įrodymu.

Rizikos vertinimui taip pat reikia santūrumo. Neįprastas grąžinimų modelis gali pagrįsti peržiūrą, tačiau neįrodo sukčiavimo. Išlaikykite apskundimo galimybę, dokumentuokite sprendimų priežastis ir patikrinkite, ar taisyklės nesukuria nepateisinamų kliūčių teisėtiems klientams.

Veiksmus atliekantys asistentai padidina riziką

Paaiškinti grąžinimo taisyklę ir išduoti pinigų grąžinimą yra labai skirtingi dalykai. Kai DI asistentas gali iškviesti operacinius įrankius, jo klaidos gali pakeisti įrašus, išleisti pinigus arba atskleisti klientų informaciją.

Naudokite leidimų modelį, atspindintį kiekvieno veiksmo pasekmes. Įgalioto užsakymo įrašo skaitymas, atsakymo juodraščio rengimas, grąžinimo prašymas, adreso keitimas ir pinigų grąžinimas neturėtų būti laikomi lygiavertėmis galimybėmis.

• Įgyvendinkite apribojimus ne modelyje. Įrankių leidimai, taisyklių patikros ir patvirtinimo reikalavimai turi būti įgyvendinti programos logikoje.
• Neleiskite atlikti pasikartojančių veiksmų. Pakartotiniai bandymai neturi sukurti kelių pinigų grąžinimų, etikečių ar pakeitimo užsakymų.
• Patvirtinkite reikšmingus pakeitimus. Kai tinkama, prieš vykdymą parodykite numatomą veiksmą ir svarbią informaciją.
• Saugokite audito pėdsaką. Įrašykite naudotą informaciją, prašytą veiksmą, jo leidimą ir rezultatą.
• Klientų žinutes laikykite nepatikima įvestimi. Žinutėje ar priede pateiktos instrukcijos neturi pakeisti sistemos leidimų ar verslo taisyklių.

NIST AI rizikos valdymo sistema yra naudingas valdymo orientyras, apimantis funkcijas Govern, Map, Measure ir Manage. Tai nėra sertifikatas, kad konkretus asistentas yra saugus; įmonei vis tiek reikia testų ir jos pačios procesams pritaikytų kontrolės priemonių.

Prieš pasirinkdami DI sluoksnį sukurkite duomenų pagrindą

Sekimas, pagalba ir grąžinimai turėtų būti sujungti nuosekliu ryšiu tarp klientų, užsakymų, prekių ir siuntų. Be šio pagrindo asistentas gali pateikti nepriekaištingą atsakymą apie ne tą siuntą arba pritaikyti taisyklę ne tai prekei.

Diegdami sprendimą, paremtą 17TRACK, peržiūrėkite 17TRACK Shopify listing, skirtą prekybininko sekimo atvejui, taip pat Tracking API ir API documentation, skirtus pasirinktinės integracijos vertinimui. Grąžinimo procesams peržiūrėkite 17RETURNS. Tai tinkami atspirties taškai vertinant operacinius sluoksnius; jų įtraukimas nereiškia, kad jie suteikia visas šiame vadove aprašytas DI galimybes.

Klientams skirta tracking page gali padėti rasti siuntą, tačiau jos paskirtis skiriasi nuo autentifikuotos prieigos prie duomenų ir veiksmų kontrolės, reikalingos prekybininko pagalbos asistentui. Prieš kurdami sprendimą pagal bet kurį produktą patvirtinkite tikslias integracijos funkcijas, leidimus, duomenų tvarkymą ir plano reikalavimus.

Išbandykite vieną procesą ir matuokite klientų rezultatus

Tinkamas pirmasis bandymas – tik skaitymui skirtas asistentas, paaiškinantis patvirtintus sekimo įvykius ir perduodantis neaiškius atvejus pagalbos tarnybai. Jį lengviau įvertinti nei asistentą, kuris vienu metu keičia adresus, tvirtina grąžinimus ir grąžina pinigus.

Sukurkite testų rinkinį, apimantį įprastus užsakymus ir sudėtingus atvejus: dalinius siuntimus, trūkstamus nuskaitymus, pasenusius įrašus, skundus, kai rodoma „pristatyta“, bet prekė negauta, pasibaigusius grąžinimo laikotarpius ir prieštaraujančius taisyklių dokumentus. Įtraukite bandymus pasiekti kito kliento užsakymą ir žinutes, kuriomis bandoma apeiti asistento instrukcijas.

• Atsakymo kokybė: Ar atsakymas tiksliai atspindi gautus siuntos ir taisyklių įrašus?
• Nepagrįsti teiginiai: Ar jis išgalvoja pristatymo datas, teisę arba atliktus veiksmus?
• Problemos išsprendimo kokybė: Ar kliento problema išspręsta, ar jis vėl kreipėsi į pagalbos tarnybą dėl tos pačios problemos?
• Eskalavimo kokybė: Ar neaiškūs ir jautrūs atvejai buvo perduoti su naudingu kontekstu?
• Veiklos sąnaudos: Kiek kainuoja vienas išspręstas atvejis, įskaitant peržiūrą, integracijas ir taisymus?
• Kliento pastangos: Ar procesas sumažino pakartotinius paaiškinimus ir nereikalingus veiksmus?

Nesiekite optimizuoti vien pagalbos bilietų skaičiaus mažinimo. Mažiau pokalbių gali reikšti geresnį savitarną, tačiau taip pat gali reikšti, kad klientai negalėjo pasiekti pagalbos. Plėskite bandymą tik tada, kai kokybė išlieka priimtina visais atvejais, kuriuos sistema iš tikrųjų tvarkys.

DUK

Ar DI gali sekti siuntą be vežėjo duomenų?

DI negali nustatyti dabartinės siuntos vietos vien sugeneruodamas atsakymą. Patikimam atsakymui reikia siuntos informacijos iš vežėjo ar kito įgalioto šaltinio. Modelis gali interpretuoti įvykius arba įvertinti rezultatą, tačiau neturėtų pateikti nė vieno iš jų kaip naujo fizinio nuskaitymo.

Ar DI asistentas turėtų automatiškai tvirtinti grąžinimus?

Tik pagal aiškiai apibrėžtus ir išbandytus leidimus. Aiškios teisės taisyklės gali tvarkyti paprastas užklausas, o DI padeda interpretuoti klientų kalbą. Išimtys, dviprasmiški įrodymai ir reikšmingi sprendimai turėtų būti perduodami patvirtintam peržiūros procesui. Taip pat būtina gerbti taikomas teisines teises.

Ką pirmiausia turėtų įdiegti maža elektroninės prekybos komanda?

Pradėkite nuo nuoseklios užsakymų ir sekimo informacijos, lengvai pasiekiamų taisyklių ir patikimų pranešimų pagal būseną. Jei šie pagrindai jau veikia, išbandykite DI sugeneruotus pagalbos atsakymų juodraščius arba tik skaitymui skirtus sekimo paaiškinimus prieš įvesdami savarankiškus veiksmus.

Kiek klientų duomenų turėtų gauti DI procesas?

Tik tiek informacijos, kiek būtina užduočiai atlikti. Peržiūrėkite prieigos kontrolę, saugojimą, registravimą, paslaugų teikėjo sąlygas ir taikomus privatumo įsipareigojimus. Venkite siųsti visus klientų profilius ar mokėjimo informaciją, kai pakanka ribotos užsakymo nuorodos ir siuntos būsenos.

Koks yra stipriausias ženklas, kad diegimas veikia?

Klientai gauna tikslius atsakymus ir tinkamus tolesnius veiksmus su mažesnėmis pastangomis, o pakartotinių kontaktų ir taisymo darbų nepadaugėja. Greitesni atsakymai naudingi, tačiau jie nepakeičia teisingo problemos išsprendimo.

Šaltiniai

• NIST: AI Risk Management Framework — orientyras DI valdymui, vertinimui ir rizikos valdymui organizuoti.
• 17TRACK tracking — vartotojų siuntų paieškos orientyras.
• 17TRACK Shopify app listing — prekybininko sekimo produkto vertinimo orientyras.
• 17TRACK Tracking API ir official API documentation — sekimo integracijos vertinimo šaltiniai.
• 17RETURNS product page — grąžinimų valdymo produkto vertinimo orientyras.