如何改善跨境訂單的貨件追蹤

要改善跨境訂單的貨件追蹤，應建立整個配送鏈的可見度，而不是只依賴單一承運商頁面。及早取得有效的追蹤識別碼，連接每一家相關承運商的事件，統一不一致的狀態，偵測停滯貨件，並在清關或交接中斷事件流程時，向客戶提供清晰更新。

對商戶而言，主要挑戰通常不是缺乏追蹤資料，而是這些資料分散於郵政營運商、商業承運商、集運商、海關流程及最後一公里合作夥伴之間。實際可行的改善計劃，必須同時處理底層物流流程，以及向客戶呈現追蹤資訊的方式。

為甚麼跨境追蹤比本地追蹤更困難

本地包裹通常會留在同一個承運商網絡內。國際訂單則可能經過賣家、倉庫、貨運集運商、出口承運商、海關機關、目的地郵政營運商及本地配送服務商。每個參與者可能使用不同的事件名稱、參考編號、掃描程序及資料傳送時間表。

這會造成幾種常見的可見度缺口：

• 出貨前缺口：雖然已存在追蹤號碼，但承運商尚未實際接收或掃描包裹。
• 承運商交接缺口：始發地承運商停止發布事件後，目的地承運商尚未開始報告事件。
• 清關缺口：包裹可能一直處於進口或出口流程中，卻沒有新的面向客戶的掃描記錄。
• 識別碼變更：集運商或最後一公里承運商可能會分配另一個參考編號。
• 狀態不一致：類似事件可能顯示為已派遣、已離開、已轉運、幹線離境或已交予航空公司。
• 資料交換延遲：實體貨件可能已經移動，但相應的電子事件尚未顯示。

因此，追蹤並不是包裹位置的連續地圖。大多數系統顯示的是由標籤、實體掃描、營運系統或電子資料交換所產生的里程碑事件。近期沒有新事件，並不自動代表包裹已遺失。

從可靠的貨件資料開始

追蹤質素取決於包裹離開倉庫前所建立的資料。如果識別碼、承運商代碼、地址或海關資料不完整，後續軟件無法完全修正問題。

驗證追蹤號碼及承運商

應將追蹤號碼儲存為結構化資料，而不是只放在備註、電郵或運輸標籤圖片中。將其與訂單、貨件、所選承運商、服務、寄件日期、始發地、目的地及任何已知的最後一公里參考編號關聯。

不應僅根據追蹤號碼的外觀推斷承運商名稱。不同格式可能重疊，而郵政貨件在不同階段可能由不同指定營運商處理。如果倉庫、市場平台或履約合作夥伴提供識別碼，應要求其在可行情況下同時提供相應的承運商或物流服務商。

分開記錄訂單、貨件及包裹

一張訂單不一定只有一件貨件。商戶可能因產品存放於不同倉庫、受不同運輸限制，或在不同時間有貨，而將訂單拆分。每個實體包裹都應有自己的追蹤記錄。

一個實用的層級如下：

• 訂單：客戶的商業購買。
• 貨件：從特定始發地發出的履約運輸。
• 包裹：擁有獨立追蹤識別碼的實體包裹。

這可避免其中一個包裹已送達時，錯誤地將整張訂單改為已送達，而另一個包裹仍在運送途中。

改善地址及海關資料輸入

地址錯誤及不完整的海關資料，可能造成看似追蹤失敗的延誤。應根據目的地驗證必要地址欄位，在系統支援的情況下保留本地字元，並在承運商或目的地流程要求聯絡時，收集可用的客戶電話號碼或電郵地址。

海關資料應準確描述貨物，並包括貨件及目的地所需的資料。相關要求會因路線、產品、承運商、運輸模式及監管制度而異。商戶應採用承運商、報關行、郵政營運商及相關海關機關的最新指引，而不是從其他市場複製一般性申報內容。

連接完整的承運商鏈

當追蹤系統同時跟進始發地網絡及目的地配送網絡時，跨境可見度便會提高。商戶應識別每個階段由誰負責，以及相關事件將如何進入其系統。

記錄交接關係

針對每項運輸服務，記錄預期鏈條：

1. 誰負責收取包裹？
2. 誰負責營運國際幹線運輸？
3. 誰將包裹提交清關？
4. 誰負責目的地分揀？
5. 誰完成最後一公里配送？
6. 追蹤識別碼會否在交接期間變更？

這份路線圖不需要預測每一個實體設施，其目的是顯示哪一方應產生下一個有意義的事件。當貨件停滯時，支援人員便可調查正確的營運商，而不是在責任已轉移至下游後仍反覆聯絡始發地承運商。

在可減少資料分散的地方使用多承運商追蹤

對偶爾寄送個人貨件的人而言，逐一開啟承運商網站可能可行，但對處理多種服務或多個目的地國家的商戶來說，這種方式難以擴展。多承運商追蹤介面可以集中事件，減少手動判斷目前由哪家承運商持有包裹的需要。

17TRACK Tracking例如提供面向消費者的介面，讓使用者輸入貨件識別碼並查看追蹤資訊。需要將追蹤資料放入訂單管理系統、支援平台或內部儀表板的企業，也可以評估已記錄的17TRACK Tracking API功能。實施前，應確認實際使用路線的承運商兼容性、事件可用性、更新行為、技術要求及商業條款。

任何聚合服務都無法建立承運商從未執行或發布的實體掃描。其價值在於更一致地收集、關聯及呈現可取得的承運商資料。

統一事件，但不要隱藏原始細節

原始承運商訊息對物流團隊很有用，但對客戶而言往往令人困惑。統一層可將不同承運商的描述轉換為較少數量的標準貨件階段。

實用的面向客戶狀態模型可以包括：

• 已收到貨件資料
• 已由承運商接收
• 運送中
• 清關處理中
• 已抵達目的地國家或地區
• 派送中
• 已送達
• 配送異常
• 可供取件
• 退回寄件人

應將原始承運商事件、時間戳記、位置、承運商及來源，與統一後的狀態一併保留。支援及營運團隊可能需要這些細節，以區分出口離境與目的地抵達，或區分清關放行與最後一公里交接。

不要將每個不熟悉的事件都翻譯成延誤。例如，電子艙單事件不一定證明包裹已被實體接收。同樣，清關處理本身也不代表出現問題。只有在承運商報告異常，或已達到明確的營運規則時，才應將事件標記為異常。

使用適合路線的異常規則偵測問題

客戶通常不需要更多通知，而是在需要採取行動時，獲得更早且更準確的通知。異常管理應將注意力集中於偏離預期模式的貨件。

有用的偵測規則包括：

• 已建立標籤，但在預期的倉庫取件時間內沒有出現承運商接收事件。
• 在正常交接點之後沒有出現新事件。
• 承運商報告地址、付款、清關、損壞、取件或配送問題。
• 包裹顯示已送達，但客戶表示未收到。
• 貨件開始退回寄件人。
• 拆單訂單中的一個包裹已送達，而另一個包裹停止更新。

時間門檻應根據服務及路線設定。對特快服務而言不尋常的停頓，對郵政經濟服務或清關流程而言可能屬正常。避免對所有國家及承運商套用單一的貨件停滯定義。

向客戶提供有用資訊，而不是大量原始事件

良好的追蹤體驗應解釋已知事項、尚未知悉的事項，以及客戶是否需要採取行動。追蹤頁面或訊息應顯示包裹識別碼、目前的統一狀態、最新承運商事件、事件時間、可用的位置、承運商，以及在有可靠估算時提供適合路線的配送預計時間。

通知應由有意義的變化觸發。常見例子包括承運商接收、重大延誤或異常、抵達目的地、派送中、配送失敗、可供取件、送達及開始退回。為每一次例行設施掃描發送訊息，可能會掩蓋客戶真正需要的更新。

談及清關時應使用謹慎措辭。商戶可以報告承運商顯示包裹正在清關處理中，但除非可靠來源明確說明結果，否則不應聲稱海關已批准、拒絕或遺失貨件。如果可能需要繳付關稅、提交文件或由收件人採取行動，應引導客戶查看與該包裹相關的官方承運商或報關行指示。

建立追蹤個案的支援作業指引

支援人員需要的不只是存取客戶已經查看過的相同公開追蹤頁面。應為他們提供簡潔、適合路線的工作流程。

1. 確認記錄：核實訂單、包裹、追蹤識別碼、承運商、服務、目的地及出貨日期。
2. 識別最新實體里程碑：區分承運商接收及設施掃描與電子貨件資料。
3. 檢查目前營運商：確定目前由始發地承運商、集運商、報關行、目的地營運商或最後一公里服務商負責下一步。
4. 檢查是否需要採取行動：查看地址更正、取件指示、文件、關稅或承運商聯絡要求。
5. 套用路線規則：將貨件與商戶預期的事件順序及升級門檻比較。
6. 傳達下一步：告知客戶已發生甚麼事、由誰處理、客戶必須做甚麼，以及商戶何時會再次檢查個案。
7. 記錄解決結果：分類原因，以便將重複出現的問題追溯至路線、承運商、倉庫、資料欄位或產品類別。

不要承諾承運商或商戶無法支持的送達日期。具體的跟進承諾，例如在下一個預期里程碑後檢查個案，比沒有根據地保證包裹很快送達更有用。

將追蹤質素視為營運流程進行衡量

單靠配送時間無法顯示追蹤是否運作良好。應衡量事件鏈的完整性及實用性。

相關內部指標包括：

• 有效追蹤率：擁有可用追蹤識別碼的包裹數量除以已出貨包裹數量。
• 接收可見度：履約後收到承運商接收事件的包裹數量。
• 交接可見度：離開始發地網絡後顯示目的地網絡事件的跨境包裹數量。
• 事件延遲：在兩個時間戳記均可取得的情況下，營運事件發生與其出現在商戶系統之間的時間。
• 異常偵測時間：可採取行動的異常發生與建立內部警報之間的時間間隔。
• 沒有先前可見度但已送達率：在缺少預期中間里程碑的情況下顯示已送達的包裹數量。
• 追蹤相關聯絡率：客戶查詢貨件位置的數量，相對於已出貨訂單的比例。

應按承運商、服務、始發地、目的地、倉庫及履約合作夥伴細分結果。整體平均值可能掩蓋某條識別碼上載延遲或目的地交接經常缺失的特定路線。

實際可行的實施順序

商戶不需要一次過更換所有物流系統。分階段方法通常能帶來更清晰的結果：

1. 審核近期跨境貨件，找出事件鏈最常中斷的位置。
2. 定義每個系統都必須保留的訂單、貨件、包裹、承運商及追蹤欄位。
3. 記錄最高貨量或最高風險路線的預期承運商鏈。
4. 直接或透過多承運商追蹤服務連接所需的承運商資料來源。
5. 建立統一狀態模型，同時保留原始承運商事件。
6. 針對缺少接收、交接停滯、承運商異常及退回設定適合路線的規則。
7. 圍繞行動及不確定性設計客戶訊息，而不是提供過多掃描細節。
8. 為支援團隊提供責任規則及升級途徑。
9. 按路線檢視指標，修正重複出現的資料、承運商或倉庫問題。

最強的追蹤營運並不是顯示最多事件的系統，而是能保留可靠識別碼、連接每一個負責的營運商、偵測有意義的異常，並向客戶提供準確下一步的系統。

常見問題

為甚麼國際追蹤號碼沒有更新？

標籤可能在承運商接收包裹前已建立，貨件可能正在掃描點之間運送，或交接事件尚未發布。首先確認承運商是否已實際接收。然後檢查是否已分配目的地承運商或第二個追蹤參考編號。

可以實時追蹤清關處理嗎？

通常不能以連續流程方式追蹤。面向客戶的追蹤可能顯示由承運商、郵政營運商或報關行提供的特定里程碑或異常。詳細程度各有不同。在清關處理期間沒有更新，並不能單獨證明貨件已遺失或被拒絕。

商戶應否向客戶顯示原始承運商狀態？

原始事件應保留以供調查，但面向客戶的頁面更適合使用統一階段及淺白解釋。應保留原始訊息、承運商、位置及時間戳記，讓支援團隊可以檢視來源細節。

商戶如何追蹤由多家承運商處理的訂單？

建立可按包裹保存原始識別碼、承運商、後續交接識別碼及目的地營運商的記錄。承運商連接或多承運商追蹤服務便可將可用事件帶入同一工作流程。應根據商戶實際使用的承運商及路線驗證兼容性。

何時應將貨件視為遺失？

沒有適用於所有情況的通用經過時間規則。應參考承運商的調查及索償程序、所選服務、最新實體事件、路線及任何適用的商戶政策。當沒有近期掃描的情況超出預期路線模式時，應觸發調查，但不應自動向客戶表示已確認遺失。

貨件追蹤與 GPS 追蹤有甚麼分別？

大多數包裹追蹤以里程碑為基礎。它會報告建立貨件資料、掃描包裹或營運系統發送更新時產生的事件。一般不會提供個別包裹持續的實時 GPS 位置。

資料來源

• 17TRACK — 全球包裹追蹤
• 17TRACK — Tracking API
• 17TRACK — API Documentation
• 萬國郵政聯盟 — 郵政標準
• 世界海關組織 — WCO Data Model
• 歐盟委員會 — Import Control System 2