先回答客人此刻的問題
結帳後，客人想知道訂單是否成立、店舖做到哪一步、承運商掌握甚麼消息，以及自己是否需要行動。這些並不是同一個問題。單寫「已寄出」，可能把倉庫列印運單與承運商真正收件混在一起。頁面應先以白話交代目前已確認的狀態，再說下一步是甚麼，同時顯示訂單參考編號、最後一項已知更新的時間、所選送貨方式，以及資料似乎有錯時的求助途徑。預計到達時間不可包裝成必然承諾。Shopify 的訂單狀態文件展示一種實際分工：頁面可先展示店舖處理進度；有受支援承運商及追蹤資料時，才顯示其後的運送更新。這只是狀態分工的例子，不代表每個商戶或承運商都有相同資料。店舖須先確定自己真正能核實哪些事件。
先定義狀態，再畫頁面
應按系統實際收到的事件，先畫出訂單生命週期。「已收到訂單」表示結帳建立了紀錄，單憑這項事件不能證明款項已結算或庫存已分配。「準備中」要按店舖實際工作解釋，例如正在核對與包裝。「已交承運商」如要使用這種措辭，就應有真正交接證據。「運送中」和「派送中」要依承運商回報，不能因印好運單過了若干時間便自動推定。「已送達」需要相應送達事件或有紀錄的人手確認；派送未果等例外亦應另作說明。Shopify 指出，已標記履行的訂單可維持 Confirmed，直至承運商回報運送中；沒有追蹤資料時，也可能不會收到運送更新。因此不宜為了令進度條熱鬧而虛構中間階段。簡單而真實的一句話，往往比裝飾性時間線更有用。
標示追蹤資料從何而來
有追蹤號碼，不等於客人已有可用的追蹤體驗。應核對承運商名稱及連結是否對應該包裹、按下後是否到達預期頁面，以及店舖顯示的狀態是否有承運商事件作依據。Shopify 說明，受支援承運商可在訂單狀態頁展示位置與運送更新；不受支援時，號碼可能只會連到承運商網站，店舖頁面不能提供即時狀態。文件亦提醒，部分承運商連結只到一般查詢頁，客人仍須自行輸入號碼。頁面應說明實際會遇到哪一種情況。若承運商尚未掃描包裹，只有在流程確實如此時，才可寫「承運商收件後或會顯示追蹤資料」，不可說貨件已在路上。分拆寄出的訂單，須逐件列出承運商、號碼及所含商品；其中一箱送達，不能令人以為整單已齊。
保護資料，也要讓客人查得到
狀態連結可能被轉寄、貼到客服對話，或在共用裝置開啟。店舖須決定只持有連結的人能看哪些資料，以及何時需要進一步核實。單靠容易猜到的訂單號碼，不應向任何人展示完整姓名、地址、電話、付款方式或詳細追蹤資料。訪客買家也要有實用的重新查閱方法，可依原訂單聯絡渠道及適當核實步驟處理。Shopify 自身做法是在若干存取期限後限制詳細資料，並可能要求提供訂單號碼及結帳時的電郵或電話；具體時限是該平台行為，不是所有店舖的共同規定。值得借鑑的是把低敏感度的進度資訊與私人訂單詳情分開。應測試轉寄連結、另一個瀏覽器及會話過期後的情況：真正客人仍知道大致進度及如何恢復授權存取，其他人卻看不到敏感資料。
資料空白與異常要解釋
正常流程中斷時，狀態頁尤其有用。若送貨方式根本沒有追蹤服務，不要留一個空白追蹤框；應說明沒有即時承運商追蹤，並指出下一個有用的核對時點。若已建立運單但承運商未掃描，應顯示店舖最後一項已核實事件及其時間。若出現派送未果，應說明客人該聯絡承運商、查看取件通知，還是找店舖；不能只丟下一個籠統狀態名稱。預期更新未出現時，提供帶有訂單參考編號的求助途徑，不要叫客人從頭再輸入所有資料。時間區與事件來源也要清楚，尤其承運商系統使用不同時間時。Shopify 的疑難排解資料顯示，承運商誤判或追蹤資料不完整，可造成錯誤連結；因此在頁面自信地宣稱可追蹤前，營運上應先核對。
以分拆寄送作實例
假設客人買了一盞檯燈及兩個備用燈泡。店舖確認訂單後，從一處倉位包好檯燈，燈泡則在另一處等待處理。有用的狀態頁應先顯示同一訂單編號，再分兩組履行資料：檯燈已有經核實的承運商交接及追蹤連結；燈泡仍在準備中，暫無追蹤號碼。即使承運商回報檯燈已送達，整張訂單也不能標成全部送達。若燈泡延遲，應展示最後一項已確認更新及具體求助途徑，而不是虛構新的到達日期。訂單確認訊息應連回同一狀態頁，方便客人日後再查。這是假設的測試個案，不代表店舖真的有這種庫存安排；其作用是暴露資料模型有否分清訂單、商品組、貨件及承運商事件。
讓員工有一致的資料來源
客服看到的基礎事件，應與客戶頁一致；只有獲授權員工才可見額外的私人營運資料。店舖應訂明誰可更正承運商、替換失效連結、記錄人手交接或處理例外，並保留更改原因與時間，避免頁面悄悄改寫歷史。承運商事件可能遲到或順序顛倒；顯示時不應無解釋地把包裹進度倒退。若由第三方履行程式提供資料，應檢查它除號碼外，也有傳送承運商及追蹤網址；Shopify 提醒，只有號碼時可能誤認承運商。員工須知道追蹤暫不可用時怎樣解釋，以及資料不符何時需要升級處理。較有用的服務檢查，是結合經審核的客服個案，看看客人能否從頁面解答真正問題；沒有量度前，不能聲稱較漂亮的進度條已減少查詢。
按真實事件邊界驗收
發佈前，應建立測試訂單，涵蓋沒有追蹤的送貨、單件可追蹤貨件、分拆寄送、不受支援承運商，以及派送未果。每一階段都把客戶畫面的文字與店舖、承運商實際紀錄比較。在全新瀏覽器開啟每條追蹤連結，核對訂單編號、所選聯絡渠道與時間區。當追蹤資料缺少、錯誤或過期，頁面應提供下一步；複製連結也不應洩露私人資料。承運商更新後及存取期限屆滿後，都要重新查看同一測試訂單；建立時正確的頁面，稍後仍可能失效。若營運上無法可靠取得某項事件，就不要用經過時間去估算那個里程碑。只顯示店舖有能力支持的狀態與條件，待有新證據才改進頁面。
按已核實證據撰寫狀態文字
可為店舖真正能證明的每項事件，建立一份簡短的狀態用語表。逐項記下資料來源、客人看到的句子、顯示的更新時間，以及下一步。「已建立運單」可說店舖正在準備交寄，不能說承運商已收件；「承運商已接收」可說包裹已交接，除非有可核實的服務承諾，否則不應保證某天送達。「曾嘗試派送」則要按實際安排，引導買家查看承運商通知或聯絡店舖。員工亦須有方法回報畫面標籤與實物貨件不符。履行夥伴、承運商接駁或送貨服務一改，就要重新檢查用語表。這樣新的追蹤資料不會悄悄帶入客人可能誤當保證的陌生詞彙；當店舖與承運商系統時間不同，客服也有一致的解釋。
進行前先確認
- 客人能否分清店舖確認與承運商實際運送？
- 每件貨是否顯示各自經核實的狀態與下一步？
- 轉寄或過期的狀態連結，能否保護私人訂單資料？
