Integrimet e transportit të BigCommerce: Opsione për tarifat, etiketat dhe gjurmimin

Integrimet e transportit të BigCommerce kryejnë tre detyra të ndryshme: llogaritjen e tarifave të transportit gjatë pagesës, blerjen e etiketave për përmbushjen e porosive dhe gjurmimin e pakove pas dërgimit. Për tregtarët, konfigurimi i duhur nuk është domosdoshmërisht një aplikacion që premton gjithçka. Është një rrjedhë pune e lidhur, në të cilën metodat e pagesës, veprimet e magazinës, të dhënat e dërgesave dhe përditësimet për klientët mbeten të njëjta.

Filloni me pjesën e transportit që po dështon sot. Tarifat e papritura gjatë pagesës kërkojnë rishikimin e tarifave. Paketimi dhe dërgimi i ngadaltë kërkojnë rishikimin e rrjedhës së punës për etiketat. Mungesa e përditësimeve të dorëzimit kërkon gjurmim më të mirë. Këto probleme mund të përdorin të njëjtat të dhëna porosie, por zgjidhja e njërës nuk i zgjidh automatikisht të tjerat.

Çfarë bën në të vërtetë çdo integrim transporti

Para se të zgjidhni një integrim, ndani ofertën e transportit që sheh klienti nga puna operacionale e nevojshme për ta përmbushur atë. Tarifa e transportit gjatë pagesës nuk është domosdoshmërisht shuma që do të paguani më vonë për një etiketë, dhe një numër gjurmimi nuk është provë se transportuesi e ka marrë pakon.

Tregu zyrtar i aplikacioneve i BigCommerce është një pikënisje për gjetjen e integrimeve të gatshme. Dokumentacioni për zhvilluesit është pika e nisjes për verifikimin e një lidhjeje të personalizuar. Vetëm prania e një aplikacioni në treg nuk duhet të konsiderohet konfirmim se ai mbështet çdo shtet, shërbim transportuesi, konfigurim të pagesës ose rrjedhë përmbushjeje që përdorni.

Zgjidhni rrugën e integrimit sipas rrjedhës suaj të punës

Përdorni cilësimet e transportit të platformës kur rregullat janë të thjeshta

Nëse oferta juaj e transportit është e thjeshtë, fillimisht rishikoni konfigurimin e transportit që është tashmë i disponueshëm në dyqanin tuaj. Përcaktoni destinacionet ku shërbeni, metodat që duhet të shohin blerësit dhe rregullat tregtare pas këtyre metodave para se të shtoni një sistem tjetër.

Për shembull, një dyqan që ofron një tarifë standarde transporti brenda vendit mund të ketë nevojë për zona dhe përjashtime më të qarta transporti, jo për një motor të jashtëm tarifash. Një dyqan që dërgon produkte të mëdha nga disa vendndodhje ka një problem tjetër: një tarifë e thjeshtë mund të fshehë ndryshime të rëndësishme në koston e përmbushjes.

Më i përshtatshmi: tregtarët me pako të parashikueshme, kompleksitet të kufizuar përmbushjeje dhe rregulla transporti që mund të shprehë konfigurimi ekzistues. Kaloni përtej kësaj rruge kur logjika e nevojshme nuk mund të përfaqësohet me besueshmëri, jo thjesht sepse një aplikacion tjetër ka më shumë cilësime.

Përdorni një integrim të gatshëm për punë të përsëritshme përmbushjeje

Një integrim i gatshëm transporti ia vlen të vlerësohet kur stafi kopjon vazhdimisht adresat, zgjedh shërbimet, blen etiketa ose fut numrat e gjurmimit. Vlera e tij vjen nga zvogëlimi i kalimeve ndërmjet proceseve dhe mbajtja e të dhënave të porosisë në përputhje me atë që është dërguar realisht.

Mos supozoni se çdo integrim etiketash ofron edhe tarifa gjatë pagesës. Po kështu, mos supozoni se një aplikacion që importon porosi mund t'i rikthejë të dhënat e dërgesës në BigCommerce. Kërkojini ofruesit të demonstrojë çdo drejtim të nevojshëm të lëvizjes së të dhënave duke përdorur rrjedhën tuaj të punës.

Më i përshtatshmi: ekipet që duan një ndërfaqe të konsoliduar operimi pa mirëmbajtur integrimin e tyre. Është zgjedhje e dobët nëse rregullat thelbësore të magazinës kërkojnë zgjidhje manuale që e neutralizojnë kohën e kursyer.

Përdorni një lidhje të personalizuar kur një sistem tjetër kontrollon përmbushjen

Një integrim i personalizuar mund të ketë kuptim kur një sistem menaxhimi porosish, platformë magazine ose ofrues logjistike i palës së tretë kontrollon tashmë dërgimin. Në këtë organizim, BigCommerce mund të jetë kanali i shitjeve dhe jo burimi operacional i së vërtetës për çdo veprim transporti.

Përcaktoni se cili sistem zotëron adresat, vendimet për pakot, blerjet e etiketave, krijimin e dërgesave dhe përditësimet e gjurmimit. Më pas konfirmoni operacionet e nevojshme të API-së, kërkesat e autentifikimit, lejet dhe kufizimet e platformës në dokumentacionin përkatës.

Më i përshtatshmi: tregtarët me një kërkesë reale për rrjedhën e punës dhe kapacitet teknik për ta mirëmbajtur atë. Zhvillimi i personalizuar nuk është automatikisht rruga më e lirë kur përfshihen monitorimi, mbështetja dhe ndryshimet e ardhshme.

Tarifat: bëjeni premtimin në pagesë të përputhet me operacionin e transportit

Një integrim tarifash duhet të prodhojë një ofertë dorëzimi që mund ta përmbushni, jo thjesht të kthejë një numër. Para se të testoni ofruesit, dokumentoni hyrjet e origjinës, destinacionit, produktit dhe paketimit që përcaktojnë përshtatshmërinë dhe koston e shërbimit.

• Origjinat: Cila magazinë ose partner përmbushjeje do ta dërgojë porosinë?
• Të dhënat e produktit: A janë të sakta peshat dhe përmasat dhe a janë njësitë e tyre të njëjta?
• Paketimi: A përdor llogaritja produkte individuale, një kuti të zgjedhur apo një pako të vlerësuar?
• Destinacionet: Çfarë ndodh me zonat e largëta, kutitë postare dhe vendndodhjet jashtë zonës suaj të shërbimit?
• Rregullat tregtare: A do të tarifoni shumën e llogaritur, do ta subvenciononi transportin apo do të aplikoni një prag promocional?

Tarifat gjatë pagesës dhe kostot e etiketave mund të ndryshojnë sepse pakoja, shërbimi, origjina ose llogaria e përdorur gjatë përmbushjes ndryshon nga supozimet e pagesës. Krahasoni të dyja anët e një porosie testuese para se të arrini në përfundimin se llogaritja e tarifës është e gabuar.

Përcaktoni edhe sjelljen në rast dështimi. Nëse një kërkesë tarife dështon, a duhet pagesa të shfaqë një alternativë të konfiguruar, të heqë metodën e prekur apo ta ndalojë porosinë? Zgjedhja e duhur varet nga fakti nëse ekipi juaj mund ta përmbushë alternativën. Një tarifë rezervë që pranon një porosi të pamundur për t'u dërguar nuk është rikuperim i suksesshëm.

Për porositë ndërkombëtare, ndani tarifën e transportit nga detyrimet dhe taksat. Mos e përshkruani një tarifë si kosto përfundimtare gjithëpërfshirëse nëse shërbimi përgjegjës nuk i llogarit qartë tarifat përkatëse dhe procesi i përmbushjes nuk e mbështet mënyrën e deklaruar të pagesës.

Etiketat: vlerësoni të gjithë ciklin e dërgimit

Blerja e etiketës duhet të testohet që nga importimi i porosisë deri te anulimi, jo vetëm deri te printimi i parë i suksesshëm. Pyetja operacionale është nëse integrimi e mban të sinkronizuar punën e magazinës me të dhënat e dyqanit.

Përdorni këto kontrolle pranimi:

1. Importimi i porosive: Konfirmoni që porositë e sakta bëhen të disponueshme për përmbushje dhe që ndryshimet trajtohen në mënyrë të parashikueshme.
2. Krijimi i pakos: Testoni një pako të vetme, disa pako dhe një porosi që dërgon vetëm disa artikuj.
3. Zgjedhja e shërbimit: Kontrolloni si lidhet metoda e pagesës së blerësit me shërbimin e blerë nga stafi i magazinës.
4. Printimi: Konfirmoni që madhësia e etiketës, formati i skedarit dhe cilësimet e printimit funksionojnë me pajisjet reale të magazinës.
5. Rikthimi i të dhënave të dërgesës: Verifikoni që informacioni i saktë i gjurmimit dhe artikujt e dërguar arrijnë te porosia në BigCommerce.
6. Riprintimet dhe anulimet: Përcaktoni si shmang stafi blerjet e dyfishta dhe si trajtohen etiketat e papërdorura sipas rregullave të zbatueshme të ofruesit.

Një test veçanërisht i dobishëm është një blerje etikete që përfundon me sukses ndërsa përditësimi pasues i porosisë dështon. Stafi ka nevojë për një mënyrë rikuperimi që përditëson porosinë pa blerë një etiketë tjetër. Këtu një demonstrim i përpunuar mund të ndryshojë nga një rrjedhë pune e besueshme në prodhim.

Kontrolloni gjithashtu se kush zotëron njoftimet për klientët. Nëse si integrimi i transportit ashtu edhe një sistem tjetër i lidhur dërgojnë mesazhe për dërgimin, klientët mund të marrin përditësime të dyfishta ose kontradiktore.

Gjurmimi: dalloni të dhënat e dërgesës nga dukshmëria e dorëzimit

Shkrimi i një numri gjurmimi në një porosi zgjidh një problem të mbajtjes së të dhënave. Mbledhja e ngjarjeve të mëvonshme të transportuesit zgjidh një problem dukshmërie. Biznesi juaj mund të ketë nevojë për të dyja, por ato duhet të vlerësohen veçmas.

Një rrjedhë e dobishme gjurmimi ruan lidhjen ndërmjet porosisë, dërgesës, pakos, transportuesit dhe numrit të gjurmimit. Kjo lidhje është e rëndësishme kur një porosi ka disa pako ose kur një pako kalon përmes më shumë se një operatori dërgese.

Për një shtresë gjurmimi të drejtuar nga zhvilluesit, API-ja e gjurmimit 17TRACK është një mundësi për t'u vlerësuar. Dokumentacioni zyrtar i API-së ofron bazën për vlerësimin e regjistrimit të gjurmimit dhe dërgimit të ngjarjeve në një rrjedhë pune të personalizuar. Ky është një rast përdorimi për gjurmim, jo zëvendësim për llogaritjen e tarifave gjatë pagesës ose blerjen e etiketave.

Mos supozoni se disponueshmëria e API-së do të thotë se përfshihet një lidhës i gatshëm për BigCommerce. Përcaktoni si do të kalojnë të dhënat e dërgesës nga dyqani ose sistemi juaj i përmbushjes te shërbimi i gjurmimit, si do të arrijnë përditësimet në destinacionin e tyre dhe kush do ta mirëmbajë lidhjen.

Para zbatimit, konfirmoni mbështetjen për transportuesit dhe shërbimet tuaja reale, kushtet përkatëse të abonimit dhe konfigurimin e dërgimit të përditësimeve. Më pas testoni skanimet e vonuara, numrat e panjohur, përditësimet e dyfishta dhe përjashtimet e dorëzimit. Një integrim gjurmimi nuk mund të krijojë një skanim fizik të transportuesit që nuk ka ndodhur.

Zgjidhni gjithashtu një përgjegjës për gjurmimin brenda biznesit. Një panel përjashtimesh ka vlerë të kufizuar operacionale nëse askush nuk është përgjegjës për hetimin e dërgesave të bllokuara dhe vendosjen se kur duhet kontaktuar transportuesi ose klienti.

Krahasoni koston totale pa u mbështetur te çmimi kryesor i reklamuar

Meqë këto shtresa integrimi kryejnë punë të ndryshme, krahasoni kostot me rrjedhën e punës që ju nevojitet dhe jo me një shifër të vetme abonimi të reklamuar.

• Tarifat e softuerit: Identifikoni abonimet, kufijtë e përdorimit, tejkalimet dhe veçoritë e faturuara veçmas.
• Tarifat e transportit: Ndani tarifat postare dhe rregullimet e transportuesit nga tarifa e softuerit.
• Zbatimi: Përfshini konfigurimin, pastrimin e të dhënave, hartëzimin e shërbimeve, testimin dhe trajnimin e stafit.
• Operacionet e vazhdueshme: Llogaritni korrigjimet manuale, sinkronizimet e dështuara dhe përgjegjësinë për mbështetjen.
• Kërkesat e daljes: Kontrolloni si mund të merrni të dhënat e dërgesave dhe të hiqni lidhjen pa ndërprerë porositë e hapura.

Kërkojini çdo ofruesi të shpjegojë se cila ngjarje llogaritet në përdorimin me pagesë. Porositë, etiketat, pakot, numrat e regjistruar të gjurmimit dhe kërkesat API nuk janë njësi të këmbyeshme. Përdorni një periudhë përfaqësuese nga operacioni juaj kur vlerësoni koston.

Kryeni një pilot të vogël nga fillimi në fund para ndryshimit

Metoda më e mirë e përzgjedhjes është një pilot i kontrolluar duke përdorur porosi realiste. Përfshini një pako të zakonshme vendase, një porosi me disa artikuj, një dërgesë të ndarë dhe çdo lloj dërgese ndërkombëtare ose të pazakontë që ka rëndësi për biznesin tuaj.

Për çdo test, regjistroni ofertën gjatë pagesës, shërbimin e zgjedhur, rezultatin e etiketës, të dhënat e dërgesës, destinacionin e gjurmimit dhe njoftimet për klientin. Shtoni të paktën një rast dështimi, si adresë e refuzuar ose sinkronizim i ndërprerë.

Caktoni përgjegjësi të qarta: ekipi i tregtisë elektronike miraton sjelljen gjatë pagesës, stafi i magazinës miraton paketimin dhe printimin, mbështetja e klientit miraton dukshmërinë e dërgesës dhe përgjegjësi teknik miraton lejet dhe procedurat e rikuperimit. Rishikoni çfarë të dhënash klienti merr çdo lidhje dhe jepni vetëm aksesin e nevojshëm për detyrën e saj.

Rekomandimi praktik: mbajeni konfigurimin aq të thjeshtë sa lejon operacioni juaj. Përdorni konfigurimin ekzistues të transportit kur plotëson kërkesën, shtoni një integrim për përmbushjen kur heq punën e përsëritur dhe vendosni një shtresë të dedikuar gjurmimi kur dukshmëria e dërgesave ka nevojë për rrjedhën e vet të punës. Lidhini shtresat me qëllim në vend që të blini automatikisht aftësi të mbivendosura.

Pyetje të shpeshta

A më duhen integrime të veçanta për tarifat, etiketat dhe gjurmimin?

Jo domosdoshmërisht. Një integrim mund të mbulojë disa funksione, ndërsa një tjetër mund të trajtojë vetëm një. Verifikoni çdo funksion të nevojshëm veçmas, duke përfshirë nëse lexon porositë, rikthen informacionin e dërgesës dhe dërgon përditësime të mëvonshme gjurmimi.

A do t'i ndryshojë automatikisht integrimi i etiketave tarifat e transportit gjatë pagesës?

Mos e supozoni këtë. Blerja e etiketave ndodh gjatë përmbushjes, ndërsa tarifat e pagesës paraqiten para vendosjes së porosisë. Konfirmoni nëse integrimi ofron funksionalitet tarifash gjatë pagesës dhe nëse funksionon me konfigurimin e dyqanit tuaj.

A mund të lidh llogaritë e mia të transportuesve?

Kjo varet nga integrimi, transportuesi, përshtatshmëria e llogarisë dhe rajoni i transportit. Pyetni cilat llogari dhe shërbime mbështeten, nëse mund të përdoren tarifat e llogarisë suaj dhe kush faturon tarifat postare dhe rregullimet pasuese.

A mund ta zëvendësojë 17TRACK një mjet etiketash BigCommerce?

API-ja e gjurmimit duhet të vlerësohet për dukshmërinë e gjurmimit, jo si zëvendësim për blerjen e etiketave. Një rrjedhë e personalizuar mund t'i lidhë të dhënat e dërgesës me një shërbim gjurmimi, ndërsa llogaritjet gjatë pagesës dhe krijimi i etiketave mbeten te sistemet përgjegjëse për këto detyra.

Pse mund të mos shohë klienti asnjë lëvizje pasi merr një numër gjurmimi?

Një numër gjurmimi mund të ekzistojë para se pakoja të marrë skanimin e parë nga transportuesi. Mundësi të tjera janë një numër i pasaktë, problem me identifikimin e transportuesit ose vonesë në disponueshmërinë e ngjarjeve. Kontrolloni dorëzimin te përmbushja dhe informacionin e transportuesit para se ta konsideroni mungesën e përditësimeve si dështim të softuerit.

Burimet

• Tregu i aplikacioneve BigCommerce — pikënisje zyrtare për identifikimin e integrimeve të gatshme dhe kontrollimin e listimeve individuale.
• Dokumentacioni për zhvilluesit e BigCommerce — referencë zyrtare për verifikimin e kërkesave të integrimit të platformës dhe detajeve të zbatimit të API-së.
• API-ja e gjurmimit 17TRACK — referencë zyrtare e produktit për opsionin e API-së së gjurmimit të diskutuar në këtë udhëzues.
• Dokumentacioni i API-së 17TRACK — referencë teknike për vlerësimin e një rrjedhe të personalizuar gjurmimi.