Bigcommerce 運送整合：運費、標籤及追蹤選項

BigCommerce 配送整合有三項不同工作：在結帳時計算運費、為履行訂單購買標籤，以及在發貨後追蹤包裹。對商戶而言，合適的設定未必是承諾包辦一切的單一應用程式，而是一套連接起來的工作流程，讓結帳方式、倉庫操作、貨件記錄及客戶更新保持一致。

先從目前出現問題的配送環節入手。結帳時出現意外收費，應檢視運費設定；包裝及發貨速度緩慢，應檢視標籤工作流程；缺少派送更新，則需要改善追蹤。這些問題可以共用訂單資料，但解決其中一個問題，不會自動解決其他問題。

每項配送整合實際負責甚麼

選擇整合方案前，應將面向客戶的配送選項與履行訂單所需的營運工作分開。結帳時顯示的配送費用，不一定等於你之後為標籤支付的金額；而追蹤號碼也不代表承運商已收到包裹。

BigCommerce 的官方應用程式市場是尋找套裝整合方案的起點；其開發者文件則可用於核實自訂連接。單靠市場列表，不應視為應用程式支援你所使用的每個國家、承運商服務、結帳設定或履行訂單流程。

按照工作流程選擇整合路線

規則簡單時使用平台配送設定

如果你的配送方案很簡單，應先檢視商店現有的配送設定。在加入其他系統前，先定義服務的目的地、買家應看到的方式，以及這些方式背後的商業規則。

例如，提供國內標準配送費的商店，可能只需要更清晰的配送區域及排除項目，而不必使用外部運費引擎。至於從多個地點配送超大型產品的商店，面對的問題則不同：簡單的收費可能掩蓋履行成本上的重大差異。

最適合：包裹情況可預測、履行訂單複雜程度有限，而且現有設定能表達其配送規則的商戶。只有當所需邏輯無法可靠地表達時，才應超越這條路線，而不只是因為另一個應用程式有更多設定。

重複性履行工作使用套裝整合方案

如果員工需要反覆複製地址、選擇服務、購買標籤或輸入追蹤號碼，便值得評估套裝配送整合方案。它的價值在於減少交接，並讓訂單記錄與實際發出的貨件保持一致。

不要假設每個標籤整合方案都會提供結帳運費。同樣，也不要假設能匯入訂單的應用程式可以將貨件資料回寫至 BigCommerce。要求供應商按照你的工作流程示範每個必要的資料流向。

最適合：希望使用成熟操作介面、而不必維護自有整合的團隊。如果必要的倉庫規則需要以手動方法繞過，抵消了節省的時間，這種方案便不適合。

由其他系統負責履行訂單時使用自訂連接

如果訂單管理系統、倉庫平台或第三方物流供應商已經控制發貨，自訂整合可能很合適。在這種安排下，BigCommerce 可能只是銷售渠道，而不是每項配送操作的營運真實來源。

先定義哪個系統負責地址、包裹決策、標籤購買、貨件建立及追蹤更新。然後在相關文件中確認所需的 API 操作、身份驗證要求、權限及平台限制。

最適合：有實際工作流程需求，並具備維護能力的商戶。把監控、支援及日後變更計算在內後，自訂開發並不一定是成本最低的路線。

運費：讓結帳承諾符合配送操作

運費整合應提供你能夠履行的配送方案，而不只是返回一個數字。在測試供應商前，記錄決定服務適用性及成本的出貨地點、目的地、產品及包裝輸入資料。

• 出貨地點：哪個倉庫或履行合作夥伴會發出訂單？
• 產品資料：重量及尺寸是否準確，單位是否一致？
• 包裝：計算是使用單件產品、指定紙箱，還是估算包裹？
• 目的地：偏遠地區、郵政信箱及服務範圍以外的地點會如何處理？
• 商業規則：你會收取計算出的金額、補貼運費，還是套用促銷門檻？

結帳費用與標籤成本可能不同，因為履行訂單時所使用的包裹、服務、出貨地點或帳戶，可能與結帳假設不同。在判定運費計算錯誤前，應比較測試訂單的兩個環節。

也要定義失敗時的行為。如果運費請求失敗，結帳應顯示已設定的替代方案、移除受影響的方式，還是停止訂單？合適的選擇取決於你的團隊能否履行替代方案。接受無法配送訂單的後備費用，並不算成功恢復。

對於國際訂單，應將運輸費與關稅及稅項分開。除非負責的服務明確計算相關費用，而且履行流程支援所述付款安排，否則不要將運費描述為全包的到岸成本。

標籤：評估完整發貨週期

標籤購買應從訂單匯入一直測試至取消，而不只是測試首次成功打印。營運上的問題在於，整合方案能否讓倉庫工作與商店記錄保持同步。

使用以下驗收檢查：

1. 訂單匯入：確認正確訂單可供履行，並且編輯能按預期處理。
2. 包裹建立：測試單件包裹、多件包裹，以及只發出部分商品的訂單。
3. 服務選擇：檢查買家在結帳時選擇的方式，如何對應倉庫員工購買的服務。
4. 打印：確認標籤尺寸、檔案格式及打印設定能配合實際倉庫設備。
5. 貨件資料回寫：核實正確的追蹤資料及已發出商品已傳回 BigCommerce 訂單。
6. 重新打印及作廢：確定員工如何避免重複購買，以及未使用標籤如何按照適用的供應商規則處理。

一項特別有用的測試，是標籤購買成功但其後訂單更新失敗。員工需要有一條恢復路徑，在不再次購買標籤的情況下更新訂單。這正是精美示範與可靠生產工作流程可能存在差異的地方。

也要檢查由誰負責客戶通知。如果配送整合方案及另一個已連接系統都發送發貨訊息，客戶可能收到重複或互相矛盾的更新。

追蹤：區分貨件記錄與配送可見度

將追蹤號碼寫入訂單，可以解決記錄保存問題；收集其後的承運商事件，則可以解決可見度問題。你的業務可能兩者都需要，但應分開評估。

實用的追蹤工作流程會保留訂單、貨件、包裹、承運商及追蹤號碼之間的關係。當一個訂單包含多個包裹，或一個包裹由多於一個配送營運商處理時，這種關係非常重要。

對於由開發者主導的追蹤層，17TRACK Tracking API 是值得評估的選項。其官方 API 文件為在自訂工作流程中評估追蹤登記及事件傳送提供基礎。這是追蹤用途，不能取代結帳運費計算或標籤購買。

不要假設有 API 就代表包含現成的 BigCommerce 連接器。應確定貨件資料如何從你的商店或履行系統傳送至追蹤服務、更新如何送達目的地，以及由誰維護連接。

實施前，確認支援你實際使用的承運商及服務、相關訂閱條款，以及更新傳送設定。然後測試延遲掃描、無法識別的號碼、重複更新及配送例外情況。追蹤整合無法製造尚未發生的實體承運商掃描。

也要在業務內部指定追蹤負責人。除非有人負責調查停滯貨件，並決定何時聯絡承運商或客戶，否則例外情況儀表板的營運價值有限。

比較總成本，不要只依賴宣傳價格

由於這些整合層負責不同工作，應根據所需工作流程比較成本，而不是只看單一宣傳訂閱價格。

• 軟件費用：了解訂閱、用量限額、超額費用及另行收費的功能。
• 配送費用：將郵資及承運商調整費與軟件費分開。
• 實施：計入設定、資料清理、服務對應、測試及員工培訓。
• 持續營運：考慮手動修正、同步失敗及支援責任。
• 退出要求：檢查如何取回貨件記錄，以及如何在不干擾未完成訂單的情況下移除連接。

要求每個供應商說明哪些事件會計入可收費用量。訂單、標籤、包裹、已登記追蹤號碼及 API 請求並不是可互換的單位。估算成本時，應使用你自己業務中具代表性的期間。

切換前進行小規模端到端試行

最有效的選擇方法，是使用真實情況訂單進行受控試行。包括普通國內包裹、多件商品訂單、分拆貨件，以及任何對你的業務重要的國際或特殊貨件類型。

每項測試都記錄結帳方案、所選服務、標籤結果、貨件記錄、追蹤目的地及客戶通知。至少加入一個失敗案例，例如地址遭拒或同步中斷。

明確分配責任：電子商務團隊批准結帳行為，倉庫員工批准包裝及打印，客戶支援批准貨件可見度，而技術負責人批准權限及恢復程序。檢查每個連接會接收哪些客戶資料，並只授予其工作所需的存取權。

實際建議：在業務允許的範圍內，讓設定保持簡單。符合要求時使用現有配送設定；能消除重複工作時加入履行整合；當貨件可見度需要獨立工作流程時，引入專用追蹤層。應有意識地連接各層，而不是預設購買重疊功能。

常見問題

我是否需要為運費、標籤及追蹤使用獨立整合方案？

不一定。一個整合方案可能涵蓋多項功能，另一個則可能只處理其中一項。應獨立核實每項所需功能，包括它是否讀取訂單、將貨件資料回寫，以及提供後續追蹤更新。

標籤整合方案會自動更改結帳配送費嗎？

不要作此假設。標籤購買發生在履行訂單期間，而結帳運費則在下單前顯示。確認整合方案是否提供結帳運費功能，以及是否適用於你的商店設定。

我可以連接自己的承運商帳戶嗎？

這取決於整合方案、承運商、帳戶資格及配送地區。詢問支援哪些帳戶及服務、是否可以使用你的帳戶費率，以及由誰收取郵資及其後的調整費。

17TRACK 可以取代 BigCommerce 標籤工具嗎？

Tracking API 應用於評估追蹤可見度，而不是作為標籤購買的替代方案。自訂工作流程可以將貨件資料連接至追蹤服務，同時由負責相關工作的系統處理結帳計算及標籤建立。

客戶收到追蹤號碼後，為甚麼可能看不到進度？

追蹤號碼可能在包裹首次接受承運商掃描前已經存在。其他可能性包括號碼錯誤、承運商識別問題或事件延遲提供。在將沒有更新視為軟件故障前，先檢查履行交接及承運商資料。

來源

• BigCommerce 應用程式市場 — 用於識別套裝整合方案及查看個別列表的官方起點。
• BigCommerce 開發者文件 — 用於核實平台整合要求及 API 實施細節的官方參考資料。
• 17TRACK Tracking API — 本指南所討論追蹤 API 選項的官方產品參考資料。
• 17TRACK API Documentation — 評估自訂追蹤工作流程的技術參考資料。