Integrace dopravy v BigCommerce: možnosti sazeb, štítků a sledování

Integrace přepravy v BigCommerce plní tři různé úkoly: výpočet sazeb dopravy při placení, nákup štítků pro expedici a sledování zásilek po odeslání. Pro obchodníky nemusí být správným řešením jedna aplikace, která slibuje všechno. Jde o propojený pracovní postup, ve kterém zůstávají konzistentní metody dopravy při placení, činnosti skladu, záznamy o zásilkách i informace pro zákazníky.

Začněte částí přepravy, která dnes nefunguje. Neočekávané poplatky při placení vyžadují kontrolu sazeb. Pomalé balení a expedice vyžadují kontrolu pracovního postupu pro štítky. Chybějící informace o doručení vyžadují lepší sledování. Tyto problémy mohou sdílet data objednávek, ale vyřešení jednoho z nich automaticky nevyřeší ostatní.

Co jednotlivé integrace přepravy skutečně dělají

Před výběrem integrace oddělte nabídku přepravy orientovanou na zákazníka od provozní práce potřebné k jejímu splnění. Poplatek za dopravu při placení nemusí být částka, kterou později zaplatíte za štítek, a sledovací číslo není důkazem, že přepravce zásilku převzal.

Oficiální tržiště aplikací BigCommerce je výchozím bodem pro hledání balíčkových integrací. Dokumentace pro vývojáře je výchozím bodem pro ověření vlastního propojení. Samotný záznam na tržišti by neměl být považován za potvrzení, že aplikace podporuje každou zemi, službu přepravce, konfiguraci placení nebo pracovní postup expedice, který používáte.

Vyberte způsob integrace podle svého pracovního postupu

Použijte nastavení přepravy platformy, když jsou pravidla jednoduchá

Pokud je vaše nabídka přepravy jednoduchá, nejprve zkontrolujte konfiguraci přepravy, která je již ve vašem obchodě k dispozici. Před přidáním dalšího systému definujte destinace, kam doručujete, metody, které mají zákazníci vidět, a obchodní pravidla stojící za těmito metodami.

Například obchod nabízející standardní poplatek za vnitrostátní dopravu může potřebovat jasnější přepravní zóny a výjimky namísto externího nástroje pro výpočet sazeb. Obchod, který odesílá nadrozměrné produkty z několika míst, řeší jiný problém: jednoduchý poplatek může skrývat významné rozdíly v nákladech na expedici.

Nejvhodnější pro: obchodníky s předvídatelnými zásilkami, omezenou složitostí expedice a pravidly přepravy, která lze vyjádřit v jejich stávající konfiguraci. Od této cesty upusťte, když požadovanou logiku nelze spolehlivě vyjádřit — nikoli pouze proto, že jiná aplikace nabízí více nastavení.

Použijte balíčkovou integraci pro opakované činnosti při expedici

Balíčkovou integraci přepravy stojí za to zvážit, pokud zaměstnanci opakovaně kopírují adresy, vybírají služby, nakupují štítky nebo zadávají sledovací čísla. Její hodnota spočívá v omezení předávání práce a v udržení záznamu objednávky v souladu s tím, co bylo skutečně odesláno.

Nepředpokládejte, že každá integrace štítků poskytuje také sazby při placení. Stejně tak nepředpokládejte, že aplikace importující objednávky dokáže zapsat údaje o zásilce zpět do BigCommerce. Požádejte poskytovatele, aby pomocí vašeho pracovního postupu předvedl každý požadovaný směr pohybu dat.

Nejvhodnější pro: týmy, které chtějí zavedené provozní rozhraní bez nutnosti udržovat vlastní integraci. Není vhodná, pokud zásadní skladová pravidla vyžadují ruční obcházení, které ruší ušetřený čas.

Použijte vlastní propojení, když expedici řídí jiný systém

Vlastní integrace může dávat smysl, pokud odesílání již řídí systém správy objednávek, skladová platforma nebo poskytovatel logistických služeb třetí strany. V takovém uspořádání může být BigCommerce prodejním kanálem, nikoli provozním zdrojem pravdy pro každou činnost související s přepravou.

Definujte, který systém spravuje adresy, rozhodnutí o balení, nákup štítků, vytváření zásilek a aktualizace sledování. Poté v příslušné dokumentaci ověřte potřebné operace API, požadavky na autentizaci, oprávnění a omezení platformy.

Nejvhodnější pro: obchodníky se skutečnou potřebou konkrétního pracovního postupu a technickou kapacitou jej udržovat. Vlastní vývoj není automaticky nejlevnější cestou, jakmile započítáte monitorování, podporu a budoucí změny.

Sazby: slaďte příslib při placení s provozem přepravy

Integrace sazeb by měla vytvářet nabídku doručení, kterou dokážete splnit, nikoli pouze vracet číslo. Před testováním poskytovatelů zdokumentujte vstupy pro místo odeslání, destinaci, produkt a balení, které určují způsobilost služby a náklady.

• Místa odeslání: Který sklad nebo partner pro expedici objednávku odešle?
• Údaje o produktech: Jsou hmotnosti a rozměry přesné a používají stejné jednotky?
• Balení: Využívá výpočet jednotlivé produkty, vybranou krabici nebo odhadované balení?
• Destinace: Co se stane u odlehlých oblastí, poštovních schránek a míst mimo oblast vašich služeb?
• Obchodní pravidla: Budete účtovat vypočtenou částku, dotovat dopravu nebo uplatňovat propagační limit?

Poplatky při placení a náklady na štítky se mohou lišit, protože se balení, služba, místo odeslání nebo účet použitý při expedici liší od předpokladů při placení. Než dospějete k závěru, že je výpočet sazby chybný, porovnejte obě strany testovací objednávky.

Definujte také chování při selhání. Pokud požadavek na sazbu selže, má pokladna zobrazit nakonfigurovanou alternativu, odstranit dotčenou metodu, nebo objednávku zastavit? Správná volba závisí na tom, zda váš tým dokáže alternativu splnit. Záložní poplatek, který přijme neodesílatelnou objednávku, nepředstavuje úspěšné zotavení.

U mezinárodních objednávek oddělte poplatek za přepravu od cla a daní. Neoznačujte sazbu za celkovou cenu s doručením, pokud odpovědná služba výslovně nepočítá příslušné poplatky a proces expedice nepodporuje uvedené uspořádání plateb.

Štítky: vyhodnoťte celý cyklus expedice

Nákup štítku by měl být testován od importu objednávky až po zrušení, nikoli pouze do prvního úspěšného tisku. Provozní otázkou je, zda integrace udržuje synchronizovanou práci skladu a záznamy obchodu.

Použijte tyto akceptační kontroly:

1. Import objednávek: Ověřte, že jsou správné objednávky dostupné pro expedici a že úpravy jsou zpracovávány předvídatelně.
2. Vytvoření balíku: Otestujte jednu zásilku, více zásilek a objednávku, u které se odesílá pouze část položek.
3. Výběr služby: Zkontrolujte, jak se metoda zvolená zákazníkem při placení mapuje na službu zakoupenou pracovníky skladu.
4. Tisk: Ověřte, že velikost štítku, formát souboru a nastavení tisku fungují se skutečným vybavením skladu.
5. Zpětný zápis zásilky: Ověřte, že se do objednávky BigCommerce dostanou správné údaje o sledování a odeslaných položkách.
6. Opakovaný tisk a zneplatnění: Stanovte, jak se zaměstnanci vyhnou duplicitním nákupům a jak se řeší nepoužité štítky podle platných pravidel poskytovatele.

Zvlášť užitečným testem je nákup štítku, který proběhne úspěšně, zatímco následná aktualizace objednávky selže. Zaměstnanci potřebují postup obnovy, který aktualizuje objednávku bez nákupu dalšího štítku. Právě zde se může propracovaná ukázka lišit od spolehlivého produkčního pracovního postupu.

Ověřte také, kdo vlastní zákaznická oznámení. Pokud zprávy o odeslání posílá integrace přepravy i jiný připojený systém, zákazníci mohou obdržet duplicitní nebo protichůdné aktualizace.

Sledování: rozlišujte záznamy o zásilkách od viditelnosti doručení

Zapsání sledovacího čísla do objednávky řeší problém evidence. Shromažďování pozdějších událostí přepravce řeší problém viditelnosti. Vaše firma může potřebovat obojí, ale tyto funkce by měly být hodnoceny samostatně.

Užitečný pracovní postup sledování zachovává vztah mezi objednávkou, zásilkou, balíkem, přepravcem a sledovacím číslem. Tento vztah je důležitý, když má jedna objednávka několik balíků nebo když balík prochází více než jedním doručovatelem.

Pro vrstvu sledování řízenou vývojářem je vhodné posoudit 17TRACK Tracking API. Jeho oficiální dokumentace API poskytuje základ pro vyhodnocení registrace sledování a doručování událostí ve vlastním pracovním postupu. Jde o případ použití pro sledování, nikoli o náhradu výpočtu sazeb při placení nebo nákupu štítků.

Nepředpokládejte, že dostupnost API znamená zahrnutí hotového konektoru BigCommerce. Stanovte, jak se budou údaje o zásilkách přesouvat z vašeho obchodu nebo systému expedice do služby sledování, jak se aktualizace dostanou na své místo a kdo bude propojení udržovat.

Před implementací ověřte podporu skutečných přepravců a služeb, příslušné podmínky předplatného a konfiguraci doručování aktualizací. Poté otestujte opožděné skeny, nerozpoznaná čísla, duplicitní aktualizace a výjimky při doručení. Integrace sledování nemůže vytvořit fyzický sken přepravce, ke kterému nedošlo.

Vyberte ve firmě také vlastníka sledování. Panel výjimek má omezenou provozní hodnotu, pokud nikdo neodpovídá za vyšetřování uvízlých zásilek a rozhodování, kdy kontaktovat přepravce nebo zákazníka.

Porovnávejte celkové náklady a nespoléhejte pouze na hlavní cenu

Protože tyto vrstvy integrace vykonávají odlišnou práci, porovnávejte náklady s ohledem na potřebný pracovní postup, nikoli podle jediné inzerované částky předplatného.

• Poplatky za software: Zjistěte předplatné, limity využití, nadlimitní poplatky a samostatně účtované funkce.
• Poplatky za přepravu: Oddělte poštovné a úpravy přepravce od poplatku za software.
• Implementace: Zahrňte nastavení, čištění dat, mapování služeb, testování a školení zaměstnanců.
• Průběžný provoz: Zohledněte ruční opravy, neúspěšné synchronizace a odpovědnost za podporu.
• Požadavky na ukončení: Ověřte, jak lze získat záznamy o zásilkách a odstranit propojení bez narušení otevřených objednávek.

Požádejte každého poskytovatele, aby vysvětlil, která událost se započítává do zpoplatněného využití. Objednávky, štítky, balíky, registrovaná sledovací čísla a požadavky API nejsou zaměnitelné jednotky. Při odhadu nákladů použijte reprezentativní období z vlastního provozu.

Před přechodem spusťte malý pilotní test od začátku do konce

Nejlepší metodou výběru je řízený pilot s realistickými objednávkami. Zahrňte běžnou vnitrostátní zásilku, objednávku s více položkami, rozdělenou zásilku a jakýkoli mezinárodní nebo neobvyklý typ zásilky, který je pro vaše podnikání důležitý.

U každého testu zaznamenejte nabídku při placení, vybranou službu, výsledek štítku, záznam o zásilce, místo určení sledování a zákaznická oznámení. Přidejte alespoň jeden případ selhání, například odmítnutou adresu nebo přerušenou synchronizaci.

Určete jasnou odpovědnost: tým e-commerce schvaluje chování při placení, pracovníci skladu schvalují balení a tisk, zákaznická podpora schvaluje viditelnost zásilek a technický vlastník schvaluje oprávnění a postupy obnovy. Zkontrolujte, jaká zákaznická data jednotlivá propojení přijímají, a přidělte pouze přístup potřebný pro jejich úkol.

Praktické doporučení: Udržujte nastavení tak jednoduché, jak to váš provoz dovoluje. Používejte stávající konfiguraci přepravy tam, kde splňuje požadavek, přidejte integraci expedice tam, kde odstraňuje opakovanou práci, a zaveďte samostatnou vrstvu sledování, když viditelnost zásilek potřebuje vlastní pracovní postup. Propojujte vrstvy záměrně, místo abyste automaticky nakupovali překrývající se funkce.

Časté dotazy

Potřebuji samostatné integrace pro sazby, štítky a sledování?

Ne nutně. Jedna integrace může pokrývat několik funkcí, zatímco jiná pouze jednu. Každou požadovanou funkci ověřte samostatně, včetně toho, zda čte objednávky, zapisuje údaje o zásilce zpět a doručuje pozdější aktualizace sledování.

Změní integrace štítků automaticky sazby dopravy při placení?

To nepředpokládejte. Nákup štítku probíhá během expedice, zatímco sazby při placení se zobrazují před odesláním objednávky. Ověřte, zda integrace poskytuje funkci sazeb při placení a zda funguje s konfigurací vašeho obchodu.

Mohu připojit vlastní účty přepravců?

Záleží na integraci, přepravci, způsobilosti účtu a oblasti přepravy. Zeptejte se, které účty a služby jsou podporovány, zda lze použít sazby vašeho účtu a kdo účtuje poštovné a následné úpravy.

Může 17TRACK nahradit nástroj BigCommerce pro štítky?

Tracking API by mělo být hodnoceno z hlediska viditelnosti sledování, nikoli jako náhrada nákupu štítků. Vlastní pracovní postup může propojit informace o zásilce se službou sledování a současně ponechat výpočty při placení a tvorbu štítků systémům odpovědným za tyto úkoly.

Proč zákazník po obdržení sledovacího čísla nemusí vidět žádný pohyb?

Sledovací číslo může existovat ještě předtím, než balík obdrží první sken přepravce. Dalšími možnostmi jsou nesprávné číslo, problém s identifikací přepravce nebo opožděná dostupnost událostí. Než nepřítomnost aktualizací označíte za selhání softwaru, zkontrolujte předání zásilky a údaje o přepravci.

Zdroje

• BigCommerce App Marketplace — oficiální výchozí bod pro identifikaci balíčkových integrací a kontrolu jednotlivých záznamů.
• BigCommerce Developer Documentation — oficiální reference pro ověření požadavků na integraci platformy a podrobností implementace API.
• 17TRACK Tracking API — oficiální reference produktu pro možnost API sledování popsanou v této příručce.
• 17TRACK API Documentation — technická reference pro vyhodnocení vlastního pracovního postupu sledování.