為需要採取行動的人設計貨件時間線
面向異常處理的貨件追蹤軟體
用帶有時間戳記的事件、目前承諾、關聯佐證，以及明確指定下一步負責人的異常記錄，取代單一且會被覆寫的狀態欄位。
即時 GPS、承運商網路和預測 ETA 資料須由專業服務或整合提供；這套 App 用於讓營運記錄與異常處理保持彈性。
事件模型
將事實、預測與決策分開
將事實、預測和決策混在一起，會讓「追蹤」頁面看似最新，實際營運卻未必如此。使用者無需解讀整合資料流，就應能判斷實際發生了什麼、系統預計什麼、目前適用哪項承諾，以及下一步由誰處理。
事實
帶有時間戳記的事件說明發生了什麼、地點在哪裡，以及結果為何。
預測
ETA 說明目前的預期以及計算或收到的時間。
承諾事項
即使 ETA 變化，也應持續顯示承諾的配送時段。
決策
異常記錄會指派影響控制、溝通與恢復工作。
時間軸
使用事件歷史記錄來回答狀態背後的問題
每筆事件應保留足夠的原始資訊，才能重建貨件移動歷程。
| 活動 | 應該保留什麼 | 需要回答的問題 |
|---|---|---|
| 已分配 | 資源與調度時間 | 目前由誰負責這批貨物的移動？ |
| 已離開起運地 | 時間、來源和載荷資訊 | 執行開始了嗎？ |
| ETA 已變更 | 先前與目前的預計時間及資料來源 | 哪些承諾面臨風險？ |
| 嘗試配送 | 時間、地點、結果與佐證 | 為什麼配送點失敗？ |
| 已驗收 | 收件人、證明資料與數量備註 | 實際收到了什麼？ |
| 已退回 | 退貨原因與取件或收貨編號 | 貨物接下來去了哪裡？ |
整合設計
確保每次承運商更新都可恢復
只有串接器名稱，不代表追蹤方案完整。
啟動前定義
- 穩定的貨件與事件識別碼
- 來源事件時間與接收時間
- 重複且無序的事件行為
- 重試佇列、負責人與對帳報告
保持對使用者可見
- 最後確認的事件及其來源
- 目前的承諾和風險
- 未結案異常與營運負責人
- 貨件結案時的證明資料或退貨編號
追蹤體驗
為客戶與營運人員提供不同層次的答案
兩類使用者應依據同一組事實，但不必看到相同介面。客戶端資訊應清楚且精簡；內部記錄則須呈現來源、不確定性與恢復工作。
客戶檢視
顯示目前關鍵里程碑、預計時段與已核准的溝通內容，不揭露內部備註或無關的系統事件。
營運檢視
顯示事件來源、來源時間、接收時間、目前承諾、可信度，以及任何對帳或異常負責人。
異常警報
只在承諾或決策改變時發出提醒，不要為每次無須處理的例行掃描製造警報。
結案佐證
將已確認的證明資料、配送數量、驗收結果或退貨編號連結到最終貨件狀態。
上線決策
將資料缺失視為一種營運狀態
承運商資料逾時不代表貨件真的延誤。應顯示最後確認事件、來源事件時間、目前承諾及負責核對資料缺口的人員，並測試重複事件、順序錯亂、重試與人工更正，確保整合最不穩定時，時間軸仍可使用。
上線前必須回答的問題
貨件追蹤軟體 常見問題
貨件追蹤與配送管理有何區別？
貨件追蹤著重流轉事件、ETA 與目前狀態；配送管理還會協調請求、分派、配送點執行、證明資料、異常與退貨。
Jodoo 可以提供即時 GPS 追蹤嗎？
Jodoo 可接收並顯示串接服務的資料，但本範例不包含原生車聯網。需要持續定位資料時，應使用專業追蹤服務。
重複事件應該如何處理？
使用穩定的事件識別碼，保留來源事件時間與接收時間，隔離重複更新，並清楚顯示仍須人工協調的記錄。
哪些事件最重要？
選擇會改變客戶承諾、營運負責人或決策的事件，例如已調度、已出發、已抵達、ETA 已變更、配送失敗、已拒收、已驗收和已退回。
貨件追蹤應如何處理逾時或遺失的事件資料？
持續顯示最後確認的事件及來源，標示資料來源已逾時，明確指定負責補齊資料的人員，並避免把舊 ETA 當成目前事實。營運記錄應區分資料缺失與實際貨運延誤。
查看實際運作的產品
開啟本頁對應的範例 App
查看關聯記錄、營運檢視、真實異常審核工作流程，以及具代表性的正常、有風險、失敗與已完成配送狀態。