Kaip pasirinkti siuntų sekimo API tarpvalstybinei elektroninei prekybai Brazilijoje

Pasirinkite siuntų sekimo API tarpvalstybinei elektroninei prekybai Brazilijoje išbandydami savo realius siuntimo maršrutus, tarptautinių ir vietinių vežėjų perdavimus, su muitine susijusius įvykius ir pristatymo išimtis, o ne lygindami vien viešai skelbiamą vežėjų skaičių. Tinkamas API turėtų išsaugoti naudingą siuntos informaciją, patikimai integruotis su jūsų sistemomis ir palaikyti tikslias portugališkas žinutes klientams, nepaverčiant neišsamių sekimo duomenų pristatymo pažadais.

Elektroninės prekybos operacijų vadovui ir inžinerijos komandai pirkimo sprendimas galiausiai yra operacinis: ar ši integracija gali paaiškinti, kur yra užsakymas, nustatyti, kas turėtų imtis veiksmų toliau, ir neleisti klientų aptarnavimo komandai remtis pasenusia ar klaidinančia informacija? Naudokite toliau pateiktą sistemą, kad šiuos reikalavimus paverstumėte praktišku trumpuoju sąrašu ir koncepcijos įrodymu.

Pradėkite nuo savo siuntimo maršrutų Brazilijoje, o ne nuo teikėjo vežėjų katalogo

Vežėjų sąrašas yra pradinis taškas, bet ne įrodymas, kad API seks kiekvieną iš to vežėjo perkamą paslaugą. Tarpvalstybinės siuntos gali apimti kilmės šalies vežėją, tarptautinį logistikos partnerį ir vietinį pristatymo operatorių. Sekimo tęstinumas priklauso nuo to, kokie įvykiai ir identifikatoriai prieinami konkrečioje grandinėje.

Prieš susisiekdami su teikėjais, sudarykite maršrutų sąrašą naudodami naujausias siuntas. Užrašykite kilmės šalį, siuntimo paslaugą, tarptautinį logistikos teikėją, jei žinoma, Brazilijos pristatymo operatorių ir kiekviename etape turimus sekimo numerius. Įtraukite pagrindinius maršrutus ir mažesnės apimties maršrutus, dėl kurių reguliariai gaunama klientų aptarnavimo užklausų.

• Atskirkite pašto ir skubaus pristatymo maršrutus. Nemanykite, kad sėkmė viename maršrute įrodo pasirengimą kitam.
• Užfiksuokite identifikatorių pokyčius. Nustatykite, ar perduodant siuntą ji išlaiko vieną sekimo numerį, ar gauna kitą.
• Įtraukite sudėtingas paskirties vietas ir rezultatus. Išbandykite vėluojančias siuntas, nesėkmingus pristatymo bandymus, grąžinimus ir neišsamias sekimo istorijas, ne tik sėkmingus pristatymus.
• Nustatykite verslo atsakingą asmenį. Operacijų komanda turėtų patikrinti įvykių naudingumą, inžinerijos komanda – integracijos veikimą, o klientų aptarnavimo komanda – paaiškinimus klientams.

Pirmoji pasirinkimo taisyklė turėtų būti paprasta: teikėjas turi parodyti naudingą sekimą jūsų svarbiausiuose maršrutuose. Platus aprėpties mastas kitur negali kompensuoti trūkstamo perdavimo maršrutuose, kuriais naudojasi jūsų klientai.

Apibrėžkite, ką turi apimti tinkamas naudoti sekimo įvykis

Standartizuota būsena, pvz., „gabenama“, padeda rengti ataskaitas, tačiau tarpvalstybinio aptarnavimo atveju jos retai pakanka. Paprašykite pavyzdinių atsakymų ir patikrinkite, kaip API pateikia pagrindinį įvykį. Turite atskirti tikrai naują judėjimą nuo išversto aprašymo, pasikartojančio įvykio ar pavėluotai gauto atnaujinimo.

Nereikalaukite, kad kiekviename įvykyje būtų visi laukai. Pirminiai šaltiniai gali nepateikti tam tikros informacijos. Vietoj to reikalaukite aiškaus skirtumo tarp praneštų faktų, teikėjo interpretacijų ir nepasiekiamų duomenų.

Vertinkite muitinės matomumą kaip informaciją, o ne leidimą atlikti muitinį įforminimą

Siuntoms, keliaujančioms į Braziliją, su muitine susijęs sekimas nusipelno atskiro priėmimo testo. Bendro pobūdžio išimtis gali neleisti aptarnavimo komandai nustatyti, ar siunta apdorojama, ar trūksta informacijos, arba ar pranešta apie gavėjo veiksmus.

Įvertinkite, ką API iš tikrųjų gauna iš vežėjo ar logistikos partnerio. Nemanykite, kad sekimo integracija gali apskaičiuoti importo mokesčius, pateikti muitinio įforminimo dokumentus, patvirtinti mokėjimą ar išleisti siuntą. Tai atskiros galimybės ir atsakomybės, kurias reikia tikrinti atskirai.

• Patikrinkite, ar su muitine susiję įvykiai išsaugo originalius aprašymus.
• Nustatykite, ar „reikia atlikti veiksmą“ aiškiai nurodoma, ar išvedama iš bendros būsenos.
• Nustatykite, kuris oficialus vežėjo ar logistikos kanalas turėtų patvirtinti tolesnį veiksmą.
• Neleiskite automatiniams pranešimams išgalvoti mokėjimo sumos, termino ar reikalingo dokumento.

Correios tvarkomoms siuntoms naudokite jos oficialią svetainę kaip pradinį tašką, kad patikrintumėte gavėjams taikomas procedūras. Kitų pristatymo susitarimų atveju tinkamą oficialų kanalą patvirtinkite su sutartiniu logistikos teikėju. Sekimo pranešimas turėtų paaiškinti praneštą situaciją ir saugiai nukreipti klientą, o ne pateikti nepatikrintą nurodymą kaip oficialų reikalavimą.

Išbandykite integracijos patikimumą ne tik idealiomis sąlygomis

Sėkminga API užklausa neįrodo, kad siunta visos kelionės metu išliks sinchronizuota. Paprašykite teikėjų paaiškinti registravimą, atnaujinimų gavimą, įvykių pristatymą, sekimo galiojimo pabaigą ir atkūrimą po sutrikimo. Prieš įsipareigodami patikrinkite atsakymus dokumentacijoje ir realiais bandymais.

Žiniatinklio kablių pristatymas ir atkūrimas

Jei teikėjas siūlo žiniatinklio kablius, patvirtinkite autentifikavimą, pakartotinių bandymų elgseną, skirtąjo laiko lūkesčius ir pakartojimo arba atkūrimo mechanizmą. Sukonfigūruokite gavėją taip, kad jis tvarkytų pasikartojančius pristatymus ir ne eilės tvarka gaunamus įvykius, nebent teikėjas aiškiai garantuoja kitaip. Greitai patvirtinkite gavimą, įtraukite apdorojimą į eilę ir nesiųskite klientų pranešimų tiesiogiai iš nepatikrinto gaunamo duomenų paketo.

Paklauskite, kas nutinka, kai jūsų galinis taškas nepasiekiamas. Jūsų komandai reikia dokumentuoto būdo suderinti trūkstamus atnaujinimus, naudojant gavimo galinį tašką, pakartojimo procesą ar kitą palaikomą atkūrimo metodą. Patvirtinkite, kad pasirinktas metodas atitinka numatomus sutrikimų scenarijus.

Vežėjo identifikavimas ir siuntos registravimas

Išbandykite neaiškius sekimo numerius, o ne manykite, kad automatinis aptikimas visada nustato tinkamą vežėją. Jei palaikoma, žinomo vežėjo identifikatoriaus pateikimas gali sumažinti neaiškumą. Taip pat išbandykite pasikartojančias registracijas, netinkamus numerius, pavėluotus pirmuosius nuskaitymus ir siuntą, kuri gauna antrą identifikatorių.

Duomenų naujumas ir stebimumas

Atskirkite vežėjo įvykio laiką nuo laiko, kai jį gauna jūsų sistema. Įvertinkite skirtumą pagal dokumentuotą atskaitos tašką, atsižvelgdami į tai, kad vežėjo viešasis sekimo puslapis pats gali atsinaujinti vėliau arba skirtis nuo kito duomenų kanalo. Paklauskite, kaip teikėjas tvarko užstrigusį sekimą ir laikinus šaltinio sutrikimus; neinterpretuokite kiekvieno tylaus laikotarpio kaip prarastos siuntos.

Kurkite portugališkus pranešimus pagal kitą naudingą veiksmą

Lokalizavimas į portugalų kalbą yra daugiau nei būsenų pavadinimų vertimas. Klientas turi žinoti, kas įvyko, ar reikia imtis veiksmų ir kur gauti patikimą pagalbą. Aptarnavimo agentams taip pat gali reikėti originalaus vežėjo aprašymo, kad ištirtų neįprastą įvykį.

Laikykite atskirus tris sluoksnius: šaltinio įvykį, vidinę operacinę kategoriją ir klientui skirtą pranešimą. Pavyzdžiui, neaiškus muitinės įvykis neturėtų automatiškai tapti reikalavimu sumokėti. Atvykimo nuskaitymas neturėtų tapti pranešimu „išsiųsta pristatyti“.

Nustatykite pranešimų slopinimo taisykles pasikartojantiems, senesniems įvykiams ir mažos vertės tarpiniams nuskaitymams. Jei rodote pristatymo prognozes, patikrinkite jų šaltinį ir reikšmę. Pardavėjo pažadas, vežėjo įvertis ir teikėjo sugeneruota prognozė yra skirtingi dalykai ir neturėtų būti pateikiami kaip lygiaverčiai.

Kartu patikrinkite privatumą, saugumą ir komercines sąlygas

Prieš vertindami sutarties sąlygas nustatykite, kokius duomenis perduos jūsų integracija. Sekimo įrašai gali būti susieti su klientų užsakymais, todėl sumažinkite nereikalingos asmeninės informacijos kiekį ir apribokite prieigą prie siuntų duomenų. Nesiųskite klientų mokesčių mokėtojo identifikatorių, adresų ar telefono numerių vien todėl, kad duomenų paketas leidžia papildomus laukus.

Vertinant su Brazilija susijusį asmens duomenų tvarkymą, įtraukite privatumo ar teisės komandą, kad įvertintumėte pareigas pagal LGPD. Brazilijos duomenų apsaugos institucija ANPD yra oficialus informacijos šaltinis. Peržiūrėkite tvarkymo vaidmenis, saugojimą, ištrynimą, subrangovus, tarptautinius perdavimus ir incidentų procedūras, taikomas jūsų susitarimui. Bendras tiekėjo saugumo pareiškimas nepakeičia tokio vertinimo.

Paprašykite rašytinio komercinio scenarijaus, pagrįsto jūsų siuntų kiekiu ir gyvavimo ciklu. Patvirtinkite, už ką skaičiuojamas mokestis: registraciją, sekamą siuntą, API užklausą, atnaujinimą ar kitą vienetą. Paklauskite, kaip pasiūlymą veikia dublikatai, ilgai trunkančios siuntos, pakartotinis sekimas, viršytos apimtys, palaikymas ir istorinė prieiga. Tai klausimai, kuriuos reikia patikrinti, o ne prielaidos apie kurio nors teikėjo kainodarą.

Palyginkite visas veiklos sąnaudas, įskaitant inžinerinę priežiūrą ir rankinį išimčių tvarkymą. Mažesnė nurodyta vieneto kaina nebūtinai reiškia mažesnes bendras sąnaudas, jei dėl integracijos dažniausiai naudojamuose maršrutuose reikia atlikti rankinius patikrinimus.

Kur vertinime tinka 17TRACK

Komandoms, vertinančioms sekimo integraciją, aktualus 17TRACK produktas yra Tracking API. Naudokite oficialią API dokumentaciją siūlomam įgyvendinimui įvertinti ir paprašykite patvirtinti konkrečius su Brazilija susijusius vežėjus, paslaugas bei perdavimo scenarijus.

Taikykite tuos pačius čia aprašytus priėmimo testus. Nelaikykite vartotojams skirto sekimo rezultato API pristatymo elgsenos, sutartinio prieinamumo ar konkretaus duomenų lauko įrodymu. Tiesiogiai patvirtinkite API atsakymą, integracijos reikalavimus, komercines sąlygas ir palaikymo susitarimus.

Daugelio vežėjų integraciją verta vertinti, kai jūsų maršrutai apima kelis logistikos teikėjus ir komandai reikia bendros sąsajos. Tiesioginės vežėjo integracijos gali pakakti, kai dominuoja viena sutartinė paslauga ir ji atitinka jūsų duomenų reikalavimus. Nė viena architektūra nepanaikina būtinybės išbandyti tikras siuntų istorijas.

Atlikite koncepcijos įrodymą su aiškiais pirkimo kriterijais

Naudokite istorines siuntas užbaigtoms kelionėms tikrinti, o aktyvias siuntas – atnaujinimų pristatymui išbandyti. Vien istoriniai duomenys negali parodyti, kaip greitai nauji įvykiai pasieks jūsų sistemą. Prireikus gaukite leidimą ir venkite dalytis nereikalingais klientų duomenimis.

1. Pasirinkite reprezentatyvią imtį. Apimkite svarbiausias kilmės vietas, paslaugas, vietinio pristatymo susitarimus ir išimčių tipus.
2. Apibrėžkite kiekvienos siuntos atskaitos tašką. Užrašykite atitinkamą vežėjo istoriją ir žinomus identifikatorių pokyčius. Nesutarimus dokumentuokite, o ne tyliai pasirinkite palankesnį rezultatą.
3. Matuokite maršrutų rezultatus. Įvertinkite registracijos sėkmę, svarbių įvykių prieinamumą, perdavimo tęstinumą ir stebimą atnaujinimo delsą. Aiškiai nurodykite vardiklį ir trūkstamus atvejus.
4. Išbandykite gedimų valdymą. Sustabdykite žiniatinklio kablio gavėją, pateikite dublikatus ir išbandykite atkūrimą nesukurdami pasikartojančių klientų pranešimų.
5. Peržiūrėkite pranešimus su aptarnavimo komanda. Paklauskite agentų, ar rezultatas paaiškina siuntą ir nurodo pagrįstą kitą veiksmą.
6. Patvirtinkite atsakomybę ir sąnaudas. Paskirkite atsakomybę už integracijos gedimus, kreipimąsi į vežėjus, klientų pranešimus ir sąskaitų tikrinimą.

Priėmimo ribas nustatykite prieš peržiūrėdami rezultatus, remdamiesi savo verslo poreikiais, o ne savavališku universaliu rodikliu. Reikalaujamą maršrutų aprėptį, saugią integraciją ir praleistų atnaujinimų atkūrimą laikykite pirkimo kriterijais. Antrines funkcijas naudokite teikėjams atskirti tik įvykdžius šiuos kriterijus.

Pasirinkite API, kuris praktiškai padaro jūsų svarbias į Braziliją nukreiptas keliones suprantamas ir atkuriamas. Jei svarbus perdavimas ar išimtis lieka nepatikrinti, prieš plėsdami diegimą išspręskite tai papildomais bandymais arba rašytiniu įsipareigojimu dėl įgyvendinimo.

DUK

Ar Correios palaikymo pakanka siuntoms, įvežamoms į Braziliją?

Nebūtinai. Tai priklauso nuo sutarto maršruto ir galutinio pristatymo susitarimo. Kartu išbandykite tarptautinį etapą, bet kokį identifikatoriaus pokytį ir vietinį etapą. Vieno operatoriaus įrašas nepatvirtina visos kelionės matomumo.

Ar sekimo API gali išspręsti muitinės vėlavimą?

Sekimas gali padėti parodyti praneštus įvykius ir nukreipti problemą tinkamam asmeniui. Tačiau pats savaime jis nesuteikia teisės pateikti dokumentus, surinkti importo mokėjimus ar išleisti prekes. Jei jūsų procesui to reikia, šias funkcijas patikrinkite atskirai.

Ar turėtume naudoti žiniatinklio kablius, ar apklausą?

Kai palaikomi, žiniatinklio kabliai gali sumažinti pasikartojančių užklausų poreikį. Vis tiek reikia autentifikavimo, dublikatų tvarkymo ir atkūrimo plano. Apklausa gali būti pagrindinis gavimo metodas arba suderinimo mechanizmas, atsižvelgiant į teikėjo palaikomą sprendimą ir ribas.

Kas turėtų nutikti, kai sekimas nebeatsinaujina?

Atskirkite integracijos problemą nuo siuntos, apie kurios naują judėjimą nepranešta. Patikrinkite duomenų priėmimo būklę ir oficialų šaltinį, tada taikykite konkrečiam maršrutui skirtą eskalavimo politiką. Automatiškai nevadinkite siuntos prarasta ir nežadėkite naujos pristatymo datos.

Ar sekimo API pakeičia mūsų užsakymų valdymo sistemą?

Ne. Sekimą laikykite siuntos informacijos šaltiniu. Jūsų užsakymų valdymo ir aptarnavimo procesai turi išlaikyti atsakomybę už užsakymo tapatybę, klientų komunikacijos taisykles, pinigų grąžinimą, pakeitimus ir sprendimus dėl eskalavimo.

Šaltiniai

• 17TRACK Tracking API — oficialus produkto šaltinis API integracijai vertinti.
• 17TRACK API documentation — techninis šaltinis įgyvendinimo reikalavimams ir palaikomai elgsenai tikrinti.
• Correios — oficialus pradinis šaltinis vežėjo informacijai ir gavėjams skirtoms paslaugoms.
• Autoridade Nacional de Proteção de Dados — oficialus Brazilijos duomenų apsaugos institucijos šaltinis privatumo peržiūrai.