如何在一个平台上管理多个承运商的货运？

要在一個平台上管理多家承運商的貨件，應集中追蹤資料、透過受支援的整合連接每家承運商、統一狀態名稱，並將例外情況分配給明確的負責人。平台應讓營運團隊從單一畫面查看貨件進度，同時保留承運商的原始事件詳情，以便調查。

這種方式適用於電子商務商戶、物流團隊及軟件開發者。合適的設定取決於你是否需要內部追蹤儀表板、面向客戶的訂單追蹤體驗，或是將資料輸送至 OMS、ERP、服務台或網店的 API。

多承運商貨件平台應具備的功能

多承運商平台不只是接受追蹤號碼的頁面。它應協助你的團隊收集、解讀、監控及處理來自不同運輸服務供應商的貨件資訊。

• 接受多種承運商格式：追蹤號碼及事件資料應與正確的承運商和貨件建立關聯。
• 呈現統一時間線：使用者應能追蹤貨件進度，而無需了解每家承運商的術語。
• 保留原始事件：當狀態含糊不清或客戶對更新內容提出異議時，承運商的原始描述非常有用。
• 顯示例外情況：延誤、派送失敗、地址問題、清關事件及退回貨件，應比一般掃描記錄更容易識別。
• 支援不同受眾：營運使用者可能需要詳細事件，而購物者通常只需要簡潔易明的派送資訊。

支援某家承運商並不代表在每個國家或服務級別都能自動獲得可靠覆蓋。在選擇平台前，請確認與你的業務相關的具體承運商、服務、目的地及追蹤事件。

管理多家承運商的實用工作流程

1. 為每件包裹建立一筆貨件記錄

從一致的內部記錄開始。最低限度應儲存訂單參考編號、追蹤號碼、承運商、服務級別（如有）、目的地國家、建立貨件日期及目前狀態。如果一張訂單可以拆分為多件包裹，應將訂單記錄與包裹記錄分開儲存，但互相建立關聯。

這可避免常見的營運問題：當訂單中只有一件包裹送達時，卻將整張訂單視為已送達。面向客戶的頁面應清楚顯示訂單與每件包裹之間的關係。

2. 可靠地識別承運商

不要只依賴追蹤號碼格式。不同承運商的號碼格式可能重疊，而貨件也可能在物流服務供應商之間轉交。只要你的訂單或履行系統提供明確的承運商欄位，就應使用該欄位，然後根據承運商的回應驗證結果。

當無法確定承運商時，應將貨件置於待審核狀態，而不是默默將其分配給錯誤的供應商。錯誤的承運商可能導致缺少掃描記錄、狀態誤導，或造成貨件沒有活動的錯誤印象。

3. 統一狀態，但不要隱藏承運商詳情

不同承運商會為相似的步驟使用不同事件名稱。共用的狀態模型可以讓報告及客戶溝通更容易。例如，內部模型可以包括：

在統一狀態旁保留承運商的原始狀態、時間戳記、位置及描述。統一化是報告層，而不是取代來源資料。

4. 將一般追蹤與例外管理分開

當每件貨件都需要同等程度的關注時，統一儀表板會變得難以使用。為近期沒有事件、派送失敗、地址問題、清關相關事件、損壞跡象及退回中的貨件建立檢視或篩選條件。

為每種例外定義下一步應如何處理。例如，客戶支援人員可以因地址問題聯絡收件人，而物流專員則可以調查停滯不前的國際貨件。平台應清楚顯示負責人及下一步行動，而不只是再顯示一個狀態標籤。

5. 決定追蹤資料的更新頻率

追蹤資料不一定會持續更新。更新行為可能取決於承運商、服務、整合方式及平台規則。應根據營運重要性選擇更新方式：高優先級例外可能需要比已完成或不活躍貨件更頻繁的檢查。

同時，應定義如何處理重複事件、延遲到達的掃描記錄及時間戳記順序錯亂。較晚接收到的事件不一定是較晚發生的實際事件，因此系統應使用事件時間戳記及承運商背景，而不應只依賴資料接收時間。

6. 為客戶提供比內部營運人員更簡單的檢視

客戶通常想知道包裹在哪裏、接下來會發生甚麼，以及他們是否需要採取行動。他們很少需要了解每個內部處理代碼。使用清晰準確的面向客戶時間線，同時讓支援及營運團隊可以查看詳細的承運商事件。

除非底層資料及服務能夠支持相應的確定性，否則不要承諾派送日期。承運商的預計日期可能因天氣、清關、地址問題、網絡中斷或其他商戶無法控制的因素而改變。

如何選擇合適的平台

最佳平台取決於它必須支援的工作流程，而不只是產品頁面上列出的承運商數量。在實施前，請評估以下範疇：

• 承運商及服務覆蓋：確認你的實際承運商、本地及國際服務、目的地市場，以及所需的事件類型。
• 整合方式：決定你是否需要網頁介面、電子商務應用程式、API、檔案交換，或與 OMS、ERP 或服務台整合。
• 資料擁有權：了解追蹤號碼、承運商識別碼、事件歷史及貨件更新的儲存及匯出方式。
• 例外處理：尋找篩選器、提示、分配選項、備註及升級工作流程，而不只是狀態顯示。
• 客戶體驗：確認平台是否支援可分享的追蹤頁面、訂單級別追蹤、通知，或其他符合你流程的面向客戶渠道。
• 營運控制：在大規模部署前測試權限、審計歷史、重複處理、更新行為及報告功能。
• 商業條款：直接向供應商查看目前的定價、使用限制、超額規則、支援條款及任何特定承運商條件。

17TRACK 的適用場景

17TRACK 提供多種方案，可能適合不同的多承運商追蹤需求。當使用者需要在受支援的承運商中查找包裹時，其追蹤體驗便適用於此情況。對於 Shopify 商戶，官方 Shopify 應用程式頁面是查看產品目前面向商戶功能及條款的合適位置。

對於要將追蹤功能建置到自己應用程式或營運系統中的公司，請查看17TRACK API 概覽及API 文件。在決定實施方案前，請確認你的使用場景所需的承運商、請求限制、欄位、驗證要求及事件行為。對於需要程式化控制的團隊而言，API 方案通常比只需偶爾手動查詢的小型營運更合適。

因此，實際選擇應以場景為基礎：查詢時使用追蹤介面；當工作流程集中於受支援的電子商務商店時使用商戶應用程式；當貨件資料必須進入自己的系統時使用 API。這些選項應根據相同的承運商、資料、例外及客戶體驗要求進行評估。

低風險實施計劃

1. 列出實際貨件場景。包括本地包裹、國際包裹、拆分訂單、退貨、補發，以及在你的營運中會出現的供應商之間轉交的貨件。
2. 選擇有限的試點範圍。先從具代表性的承運商及服務開始，而不是一次連接所有可能的供應商。
3. 定義狀態模型。就每個主要事件，確認營運、支援及客戶應看到的內容。
4. 測試複雜情況。包括無效追蹤號碼、沒有收件掃描的標籤、延誤貨件、派送失敗、清關事件、重複事件及已送達包裹。
5. 分配例外負責權。每個高影響例外都應有負責團隊、回應目標及升級途徑。
6. 比較平台資料與承運商資料。在試點期間，檢查時間戳記、位置、狀態轉換及送達結果是否正確呈現。
7. 獲得營運確認後才擴展。記錄已知限制，並在向客戶提供新承運商或服務前進行驗證。

應避免的常見錯誤

• 所有情況都使用一個通用狀態：這會掩蓋標籤建立、運送、延誤及派送之間的差異。
• 忽略包裹級別追蹤：多包裹訂單可能導致客戶及支援決策不準確。
• 根據標誌清單假設承運商覆蓋：某家承運商可能只支援某個國家、服務或事件類型，而不支援其他範圍。
• 完全取代承運商詳情：簡化狀態很有用，但調查問題時仍需要來源事件。
• 為每次掃描都發送提示：過多通知可能掩蓋需要採取行動的事件。
• 承諾確切的派送結果：追蹤可見性並不能消除承運商或清關方面的不確定性。

常見問題

一個平台可以追蹤不同承運商的貨件嗎？

可以。當相關承運商及服務獲得支援時，多承運商追蹤平台可以整合不同供應商的貨件。請確認你的業務所使用的具體路線、服務及事件類型是否獲得覆蓋。

我應該使用儀表板還是 API？

當人員主要需要共用介面來進行查詢、監控及例外審查時，應使用儀表板。當追蹤資料必須整合至 OMS、ERP、網店、支援系統或自訂應用程式時，應使用 API。有些企業會同時使用兩者。

應如何比較不同承運商的狀態？

將承運商事件映射至受控的內部狀態模型，但保留原始事件名稱、時間戳記、位置及描述。這樣既能讓團隊進行一致的報告，又不會失去故障排查所需的資訊。

當貨件沒有新的掃描記錄時，我應該怎樣做？

首先根據你的營運規則，檢查承運商、服務、最後事件、目的地及經過時間。然後判斷貨件是否需要再次更新、與客戶溝通、聯絡承運商或進行升級。單是沒有新的掃描記錄，並不能證明包裹已遺失。

多承運商平台可以提供確切的派送日期嗎？

當承運商提供預計日期時，平台可能會顯示該預計日期，但不應將預計日期呈現為保證。隨着新事件、例外、清關活動或網絡狀況出現，派送時間可能會改變。

來源

• 17TRACK 追蹤
• 17TRACK API 概覽
• 17TRACK API 文件
• 17TRACK Shopify 應用程式頁面