減少客戶支援工作量的訂單追蹤頁面
當訂單追蹤頁面在客戶聯絡客服人員之前，先回答他們最常提出的問題時，便能減少客服支援工作：我的訂單在哪裏？最新狀態代表甚麼？我應該何時收到貨件？如果貨件停止更新，我應該怎麼辦？實用的追蹤頁面不只是一個承運商連結，而是結合清晰的貨件事件、相關訂單詳情、配送指引，以及在自助服務不足時直接尋求協助的途徑。
本指南適合負責購後體驗的電子商貿團隊、營運經理及開發人員。指南將說明如何設計準確、易於瀏覽且具備營運實用性的追蹤頁面，同時避免承諾承運商尚未確認的資訊。
為甚麼追蹤頁面會造成或避免客服工作
客戶通常會在無法理解眼前資訊時聯絡客服。承運商的「運送中」、「異常」或「已建立標籤」等狀態，在技術上可能完全正確，但仍會令客戶不清楚下一步應該怎麼做。只重複顯示事件而不解釋其實際意義的頁面，會把工作由網站轉移至客服團隊。
相反的做法，是將追蹤視為自助決策工具。頁面應協助客戶判斷應該等待、核對地址、聯絡承運商、留意派送嘗試，還是聯絡商店。這個區別很重要，因為並非所有貨件問題都可以由商戶解決。頁面應清楚說明責任歸屬，而不是令人以為商店能控制配送的每個階段。
- 客戶需要解讀：以簡單易明的語言解釋最新事件代表甚麼。
- 營運團隊需要準確性：在可行情況下，顯示貨件事件的來源及時間戳記。
- 客服團隊需要背景資訊：讓客戶開立支援工單前，便能取得訂單及貨件詳情。
- 商戶需要安全的升級途徑：將未解決的問題連同相關資訊轉交給正確的團隊。
先從客服團隊已經收到的問題開始
在修改頁面之前，先檢視部分與追蹤相關的工單、聯絡表格、聊天記錄及社交媒體訊息。按客戶意圖而非每則訊息的措辭將問題分類。常見類別包括配送延誤、追蹤沒有更新、顯示已送達但未收到的訂單、地址不正確、派送失敗、海關問題、貨件損壞及退貨。
這項檢視能為你提供實際的內容待辦清單。如果客戶反覆詢問標籤是否已建立，或訂單是否已離開倉庫，這些狀態便應在頁面上清楚顯示。如果客戶詢問更改地址，頁面應說明商戶還是承運商可以處理該要求，以及客戶下一步應前往何處。如果客戶詢問退貨，退貨連結不應埋藏在一般配送文字之中。
不要假設增加更多文字便能消除所有客服聯絡。有些問題需要調查、向承運商提出索償、進行付款審核或作出政策決定。目標是透過自助服務解決簡單問題，並讓客服人員更容易處理複雜個案。
實用追蹤頁面的資訊架構
1. 首先顯示目前狀態及下一步預期
第一個畫面應顯示訂單識別碼或安全的客戶可見參考編號、最新貨件狀態、最近更新時間，以及在有提供時顯示預計送達時間範圍。如果沒有可用的送達預計，應直接說明，而不是顯示虛假的精確時間。
在狀態下方加入簡短解釋。例如，「承運商已收到貨件，貨件正經其網絡運送中」比只顯示「運送中」更有用。措辭應描述現有證據，而不是保證結果。「預計送達」及「安排送達」不應視為可互換的標籤。
2. 顯示時間軸，但不要令讀者資訊過載
貨件時間軸應區分有意義的里程碑與價值較低的技術事件。客戶可能需要看到標籤已建立、貨件已被接收、已抵達目的地設施、曾進行派送嘗試，或海關處理仍在進行中。他們通常不需要所有內部掃描都以同等的視覺比重呈現。
為需要完整資料的客戶及客服人員保留完整事件記錄，但應突出顯示最新事件及下一個可能的行動。在可行情況下加入日期、當地時間，以及承運商提供的相關地點。如果時間戳記來自不同系統或時區，應保持一致的標示方式。
3. 將貨件與訂單連結起來
當追蹤資訊包含客戶預期的訂單背景時，便更容易理解：訂單參考編號、所選配送方式、目的地區域，以及有限的貨品摘要。避免披露不必要的個人資料。對於多包裹訂單，應顯示每件貨品屬於哪個包裹，以及各包裹是否具有不同狀態。
當客戶認為訂單不完整時，這一點尤其重要。顯示一個包裹已送達、另一個包裹仍在運送中的頁面，可以避免不必要的「訂單遺失」查詢，也能協助客服人員判斷問題涉及履行訂單還是運輸。
4. 為異常狀態提供獨立指示
異常狀態不應只有警告顏色。每個狀態都應附有簡短解釋及適當的下一步。例子包括：
- 已建立標籤：配送資料已準備妥當，但承運商可能尚未記錄實體接收。
- 曾嘗試派送：查看承運商的指示，了解再次派送、取件或與地址相關的行動。
- 地址問題：確認承運商或商戶能否更正地址，以及更改是否可能影響配送。
- 海關或進口處理：說明額外審查、文件或費用可能由承運商或當地主管部門處理，具體取決於貨件及目的地。
- 已送達：在升級處理前，建議查看送貨位置、家庭成員、大廈職員或安全放置通知。
這些指示應與客服及營運團隊一同審閱。如果將客戶指向無法採取所要求行動的一方，一般化指示反而可能造成更多工作。
圍繞安全的自助服務設計頁面
追蹤頁面應讓常見操作清晰可見，但不要將每種狀態都變成銷售訊息。實用操作可能包括查看配送詳情、聯絡客服、查閱退貨政策、在承運商允許的情況下更新配送偏好，或開啟配送問題表格。
升級表格應收集客服人員否則需要另行索取的資料。可考慮包括訂單參考編號、追蹤號碼、最新狀態、配送地址所在區域、問題類型及客戶描述。避免要求客戶重新輸入頁面已知的資料。同時，除非你的政策及系統支援這些結果，否則不要自動承諾退款、補發、更改地址或送達日期。
當頁面會披露個人訂單資料時，應使用驗證或安全存取連結。追蹤號碼可能很容易被分享，因此團隊應評估在沒有帳戶驗證的情況下，哪些資料可以安全顯示。適當的存取程度取決於商店的資料、風險模型及實作方式。
讓承運商資料易於理解，但不要誇大確定性
承運商資料是輸入資訊，而不是完整的客戶服務答案。不同承運商使用不同的事件名稱、掃描方式及送達預計。國際貨件亦可能在多個郵政、快遞、海關或最後一公里營運商之間轉交。追蹤頁面應在可行情況下統一使用體驗，同時保留原始承運商事件以便追溯。
不要將缺少掃描轉化為貨件遺失的確定說法。「自[日期]起尚未收到新的掃描記錄」比「你的包裹已遺失」更安全且更具資訊性。頁面接着可以解釋商戶的升級處理門檻，或在貨件超過預計送達時間範圍時引導客戶聯絡客服。
對於跨境訂單，應清楚顯示承運商及追蹤號碼，在可用時指出相關目的地，並解釋配送時間可能取決於海關及當地配送合作夥伴。避免發布通用的海關處理時間表，或承諾收件人永遠不會需要支付費用。這些結果會因貨件及目的地而異。
選擇實作方式
合適的實作方式取決於承運商數量、訂單量、網店平台及所需的控制程度。
商店前台原生追蹤
平台內置的訂單狀態體驗適合產品目錄較小，或只使用有限配送流程的商戶。其優勢是實作路徑較短；限制則可能包括對承運商標準化、品牌設計、異常訊息及多包裹呈現的控制較少。
品牌化追蹤軟件
專用追蹤方案可以協助商戶在一致的面向客戶體驗中，呈現多個承運商的貨件事件。17TRACK 的官方 Shopify App Store 列表將其應用程式定位於電子商貿訂單追蹤及品牌化購後體驗。有意使用的商戶應根據自身要求，核實目前的功能、支援的承運商流程、資料存取及升級選項，而不要假設每個承運商或狀態的運作方式都完全相同。
對於 Shopify 商店，實際的評估問題包括：頁面能否清楚顯示部分貨件？團隊能否編輯狀態解釋？客戶能否連同訂單背景聯絡客服？實作是否保留原始承運商事件？支援的承運商是否適合商店的配送路線？
透過 API 自訂追蹤
當追蹤是更廣泛的客戶入口網站、流動應用程式、訂單管理系統或服務流程的一部分時，自訂頁面可能更合適。基於 API 的方式能讓工程團隊更有效控制版面及業務規則，但同時也令團隊需要負責驗證、資料新鮮度、錯誤處理、承運商對應、監控及支援工具。
17TRACK 為其追蹤 API 及開發人員文件分別發布相關資料。評估 API 的團隊應直接在官方文件及採購流程中確認目前的驗證要求、支援的承運商、請求限制、webhook 或輪詢行為、錯誤回應、資料保留及商業條款。這些詳情可能會改變，不應從市場推廣頁面推斷。
實用的品質檢查清單
使用真實訂單情境測試頁面，不要只檢查版面是否正確。至少應檢視已送達的包裹、近期沒有更新的包裹、派送失敗、多包裹訂單、國際貨件，以及承運商資料不完整或延遲的訂單。
- 無需捲動頁面便能看到最新狀態嗎？
- 頁面能否區分預計送達與已確認的送達事件？
- 客戶即使不了解承運商術語，也能理解最新事件嗎？
- 日期、時間、地點及時區的呈現方式一致嗎？
- 客戶能否辨識涉及一個還是多個包裹？
- 每個重要異常是否都包含實際可行的下一步？
- 客戶能否在不重新輸入已知訂單資料的情況下聯絡正確團隊？
- 頁面是否避免披露不必要的個人資料？
- 客服人員能否看到與客戶相同的貨件歷史？
- 當承運商資料流延遲、無法使用或不完整時，會發生甚麼情況？
衡量頁面成效不應只看訪問量。實用的營運指標可能包括與追蹤相關的聯絡量、同一訂單的重複聯絡、解決配送問題所需時間、升級原因，以及使用所提供自助服務途徑的客戶比例。解讀這些指標時應保持謹慎：聯絡量下降可能代表自助服務改善，但也可能代表客戶放棄使用頁面。應將營運數據與可用性意見及未解決個案檢討結合分析。
優秀的追蹤頁面不會承諾甚麼
追蹤頁面無法控制承運商掃描、海關決定、天氣干擾、地址限制或客戶的配送環境。其價值在於令現有資訊更易理解，並清楚說明下一步行動。當資料不完整時，誠實地表達不確定性，勝過作出自信但沒有依據的送達承諾。
因此，最優秀的頁面並不是擁有最多事件或最多推廣內容的頁面，而是能協助客戶快速回答三個問題的頁面：發生了甚麼事、接下來可能發生甚麼，以及如果貨件沒有如預期般更新，誰可以提供協助。
常見問題
追蹤頁面可以消除配送客服工單嗎？
不可以。追蹤頁面可以透過解釋狀態及提供相關訂單背景，減少可避免的問題，但有些個案需要調查、向承運商提出索償、作出政策決定或安排補發。頁面應減少重複聯絡，並改善仍需要人工協助的個案質素。
追蹤頁面應顯示承運商的原始狀態嗎？
通常應該，前提是能夠清晰顯示。簡單易明的解釋有助客戶理解，而原始事件則可以協助客服團隊並提高可追溯性。兩者不應互相矛盾。
如果一直沒有追蹤更新，頁面應該怎樣說？
說明最近一次可用掃描的日期，並解釋尚未收到更新的事件。然後根據商戶政策提供行動指引，例如等候至指定時間、查看預計送達時間範圍或聯絡客服。沒有充分證據時，不要將貨件標記為遺失。
多承運商貨件應如何顯示？
清楚顯示包裹層級的關係。每個包裹都應有自己的追蹤號碼、目前狀態及事件歷史，而訂單檢視應指出所有貨品是一起還是分開配送。
對小型商店而言，品牌化追蹤頁面有用嗎？
可以，尤其是商店使用多個承運商，或經常收到「我的訂單在哪裏？」的問題時。不過，小型商店仍應將實作工作量、資料質素、承運商支援、客戶服務流程及成本，與預期獲得的價值作比較。
