多平台訂單漏單怎麼抓？用每日出貨對照表與查件責任界面，補上沒人確認的交接點

多平台出貨的漏單，常出在訂單交出去之後沒有人回頭確認的交接點，實際主因仍要由各品牌自己的異常紀錄判定。要抓住它，比較省力的做法是每天用一張出貨對照表，逐筆確認每張應出貨的單停在哪個狀態，停不進任何狀態的就是疑似漏單；再把顧客查件時誰先接、什麼情況才轉物流、交接時要帶哪些欄位，寫成客服、物流與承運商一起確認過的書面責任界面。

出貨慢是網購最常被回報的問題，至少在歐盟有官方統計。歐盟統計局（Eurostat）2025 年的個人電子商務調查顯示，在過去三個月有網購的歐盟民眾裡，有 20% 遇過「配送比預期慢」，是所有問題中最多人回報的一項；收到錯誤或損壞商品的約一成，覺得客訴難處理的約 6%。顧客遇到這些狀況，多半先找賣家問「我的貨呢」。這通詢問在品牌內部怎麼走，決定了漏單是當天被抓到，還是被顧客抓到。

客服群組裡那句「這單到底出了沒」

一個在多通路品牌很常見的畫面是：傍晚，客服在群組貼上一張訂單截圖，問「這單到底出了沒」，物流同仁停下手上的轉檔，翻平台後台、翻倉庫回傳的檔案、翻承運商的查詢頁，查完回一句「倉庫沒收到這張」。單補出去了，群組恢復安靜，卻很少有人接著問「還有沒有其他張也沒進倉」。

我們在意的就是那個沒被問出口的問題。每一次查件都被當成單一事件處理完，同一個交接點的破洞卻一直留著，下一次查件、下一張漏單，又從頭來一遍。

一家多平台品牌的出貨線：漏單藏在沒有回傳確認的交接點

先看一個實際案例（已移除品牌、平台組合、時間與人員等可識別資訊，文中數字另以示意呈現）。一家同時在官網與多個電商平台賣貨的零售品牌，出貨流程大致是這樣：物流同仁用機器人流程或人工，從各平台下載訂單，轉檔後交給倉庫與承運商，接著追蹤配送；顧客問「我的貨呢」，客服接起來，再轉給物流去查，物流查完回覆客服，客服再回覆顧客。

這條線上卡住的地方有三個。各平台的訂單格式都不一樣，轉檔要逐一處理；訂單交給倉庫或承運商之後，沒有固定的回傳確認，於是發生漏單，延遲出貨還被通路罰款；查件時，客服得先弄清楚「這張單歸哪一位物流同仁負責」，才知道要問誰。物流同仁的看法很直接，意思是：查件客服應該可以自己處理，如果是承運商造成沒到貨，應該由承運商自己出面，真的需要物流幫忙時再通知。

把這家公司的流程攤開來看，訂單從平台走到顧客手上，會經過三個交接點，每一個都可能讓訂單無聲消失，而且成因不同：

1. 平台到品牌：下載與轉檔。有的平台把「已付款待出貨」放在同一個狀態，有的拆成兩個；有的平台會把一張訂單拆成兩個出貨單，有的不會。用機器人流程或人工下載時，只要篩選條件少勾一個狀態，那一類訂單就整批沒被抓下來，而且不會報錯。
2. 品牌到倉庫與承運商：交出去之後沒有回音。訂單交給第三方物流倉（3PL，替品牌代管倉儲、揀貨與出貨的外包業者）後，如果對方沒有逐筆回傳「已收單、已建立託運單、已交寄」，品牌就只知道自己交了什麼，不知道對方收到什麼、寄出什麼。檔案上傳失敗、欄位錯位、倉庫系統拒收某幾筆，都會在這裡變成漏單。還有一種容易被忽略的情況：託運單和追蹤號已經印出來，包裹卻還留在倉內，系統看起來像出貨了。
3. 出貨後到顧客：查件沒有第一窗口。客服不確定該自己查、轉物流，還是請顧客去問承運商，每張查件都先繞去找「這單歸誰」。物流的時間被查件吃掉，前兩個交接點反而更沒人顧。

前兩個交接點缺的是訂單或出貨資料的接收確認，可能直接造成漏單；第三個交接點缺的是查件責任與資訊入口，影響的是異常被發現後查得多快。兩者可以靠出貨單號與包裹號串起來，但成因不同，解法也分開談。

平台規則與研究都指向同一件事：先知道，再通知

出貨狀態要讓顧客看得到，已寫進平台與主管機關的規則，學術研究則提供了一個可以參考的類比。

Amazon 針對自行出貨訂單的官方公告指出，自 2025 年 1 月 15 日起，有效追蹤率（Valid Tracking Rate）會納入所有物流服務商；公告另列特定歐洲國家的跨境訂單範圍與排除條件，賣家仍須依商品類別維持至少 95% 的有效追蹤率。台灣各平台規範不同，品牌要回頭確認追蹤號回傳時限。

美國聯邦交易委員會的郵購、網路或電話訂購商品規則（16 CFR Part 435）則從消費者端畫線：受規範的訂單，賣家要有合理依據相信能在標示的期限內出貨，未標示期限時原則上是 30 天內（訂購時申請信用付款者為 50 天）；無法如期出貨時，要在期限到期前主動提供「同意延遲」或「取消並迅速退款」的選項，部分交易類型不在適用範圍。這條規則不適用台灣，但作業前提相通：品牌得在顧客開口前，就知道哪幾張單出不去。

倫敦商學院 Delana、Savva 與 Tezcan 2021 年發表在《Manufacturing & Service Operations Management》的主動式客服研究，用排隊模型分析「服務方先掌握顧客未來需求、主動處理」的效果，結論是即使只有一部分顧客的需求能事先掌握、提前量不長、偶爾還會判斷錯誤，主動服務仍能降低整體等待時間；但顧客可能因搭便車而不願配合，等待變短也可能吸引更多需求湧入，讓效益打折。研究沒有直接檢驗零售出貨通知，放到出貨只能當類比：品牌先拿到未出貨與異常資訊，才有機會在顧客開口前處理。

每日出貨對照表：讓每張應出貨的單都停在一個狀態

回到前面的案例。這家公司為漏單設計的第一步，是每天一張出貨對照表：每個通路一列，看已下載、已出貨、未出貨，當天沒出的寫原因。用一組示意數字來看它擋得住什麼：某個週一，物流同仁從六個通路下載了 1,240 張訂單，傍晚 3PL 回報已出貨 1,228 張。差了 12 張，以前沒人比這兩個數字；這 12 張裡可能有預購、有取消，也可能真有幾張從沒進倉，不逐筆對就分不出來，真正漏掉的要等第四天顧客來問才會發現。

三欄是好起點，落地時建議再拆細。對照表的作用，是讓每張應出貨的單當天都有一個明確狀態，停不進任何狀態的就浮出來。這裡有一個前提要先講清楚：訂單、出貨單、包裹是三種不同的單位。一張訂單可能拆成兩張出貨單，兩張訂單也可能合併成一個包裹，用總張數直接相減，拆單和合單會讓數字對不上，取消、預購與跨日出貨還會製造大量假警報。所以不比總數，先以出貨單號逐筆追蹤應出貨狀態；包裹建立後，再保存出貨單號與包裹號的對照。預購、取消與交倉狀態留在出貨單層，追蹤號、交寄與物流軌跡留在包裹層。

每張應出貨的單，當天應該落在以下其中一個狀態：

1. 尚未到承諾出貨日：例如預購商品、顧客指定日期，今天本來就不必出。
2. 已交倉：3PL 已回覆收單，還在揀貨包裝。
3. 已建立追蹤號：託運單與追蹤號已產生，但還沒有承運商收件紀錄。
4. 已交寄：取得承運商首次收件掃描、交寄證明，或其他可驗證的收件事件。
5. 例外待處理：缺貨待補、地址異常待確認、3PL 拒收或格式錯誤，每張寫明原因。
6. 已取消：顧客或平台取消，要對到取消時間。

核對的規則只有一條：每一張應出貨的單都要落在其中一個狀態，落不進去的就是疑似漏單，當天要追。已建立追蹤號和已交寄一定要分成兩欄，只有已交寄才算真的出貨；追蹤號產生超過一個工作天還沒有收件掃描，也要列入追查。例外的原因要用固定選項，月底回頭統計時，才看得出問題集中在哪一段交接點。

動手之前先確認：這些狀態能不能直接從通路後台與 3PL 系統匯出逐筆明細，用公式自動比對。能匯出就先做自動版；匯不出來、只能人工抄數，就把人工版當成試行，先跑 4 週。4 週後看兩個數字：抓到幾張漏單、填表花了多少工時；抓到的少、花的多，就轉向去要匯出欄位。

要讓自動比對成立，前提是各平台的欄位講的是同一個意思。這就需要一份欄位字典，替每個平台列出幾個關鍵欄位在它的後台叫什麼、值代表什麼：

1. 訂單編號、出貨單號與包裹號：會不會拆單，用哪個號碼對到倉庫與承運商。
2. 訂單狀態：哪些算「應出貨」，取消中與退款中算不算。
3. 承諾出貨時限：出貨天數存在哪個欄位。
4. 物流方式：宅配、超商取貨、門市自取各交給哪個承運商，超商的寄件與到店時間記在哪裡。
5. 異動標記：改地址、合併出貨、部分取消在匯出檔中怎麼呈現。

欄位字典不需要一次寫完，先從出貨量最大的兩個通路開始，每次出現落不進狀態的單就補一條。

查件第一窗口：先講好誰接、誰查、什麼時候才轉物流

漏單抓得到之後，接下來要讓查件不再全部壓到物流身上。案例中的公司，最後設計出的分工是讓客服當顧客查件的第一窗口，物流退到第二線，只接需要物流動手的件。以下是這套分流，加上幾個落地時要補的細節：

1. 物流每天固定時間提供一份出貨與追蹤號清單，內容就是對照表上「已交寄」的明細，連同交寄時間。
2. 顧客來問，客服先用這份清單與承運商查詢頁自查，能直接回覆的當場結束。
3. 已交寄但物流軌跡異常的件，由客服依約定窗口向承運商發起查詢；責任歸屬要等交寄證明、掃描軌跡與倉庫紀錄核對後才確認，涉及補寄、退款或求償時，再交給有授權的單位處理。
4. 清單上查無此單、只有追蹤號卻沒有交寄紀錄、需要補出貨、改地址重寄、需要倉庫查實物，才轉給物流，並寫明轉單時限，例如每天固定時點前轉入的件當天回覆（時點由品牌依出貨截單時間自訂，此為示意）。

案件在客服、物流、承運商之間移動時，交接要帶齊同一組最少欄位：訂單號、出貨單號、包裹號、最後一筆物流事件與時間、目前在誰手上、待辦動作、下一位負責人。少了出貨單號或包裹號，下一手就得從頭再查一次；跟任務表每一列只留一位負責人是同一個道理，「下一位負責人」只能寫一個人。

這套分流要成立，有三組前提要先確認，缺一組就先別上線：

1. 客服的查詢權限。客服要看得到出貨清單與承運商查詢頁，權限要依職務設定，也要先講好顧客身分怎麼核驗、查詢有沒有留紀錄。經濟部的零售業個人資料檔案安全維護管理辦法第 9 條要求業者依業務需要設定人員不同的權限、並定期確認權限是否必要，第 10 條要求評估情境採取個資隱碼遮蔽。這份辦法有適用門檻（主要是經營實體店面或實體兼網路銷售、資本額達一千萬元以上的零售業者），自家是否適用要先確認，不適用也可以照這個方向設計。
2. 個資規範。客服把顧客資料提供給 3PL 或承運商之前，要先確認這段資料流屬於委託處理還是其他利用關係，並檢查蒐集時的告知、特定目的、需要提供的最少欄位、傳輸方式與契約約定，個人資料保護法第 5 條與第 20 條是基本框架。符合上述辦法適用範圍的業者，第 19 條另要求對受託人適當監督，並在委託契約中明確約定內容。實際做法要請法務依自家契約確認。
3. 承運商窗口與權限。每家承運商要有客服可以直接聯絡的窗口、服務帳號與回覆時限，確認客服能發起查詢、調查還是求償、案件由誰結案；也要先定義各物流方式的正常配送時限、軌跡異常門檻，以及追蹤頁失效時的備援查法。平台訂單若規定須由站內客服或平台工單受理，就依平台規則處理。

最後把這些寫成一頁書面責任界面：查件第一窗口是誰、哪幾類件由客服向承運商查詢、哪幾類轉物流、轉單時限多久、交接帶哪些欄位、誰負責每天提供清單。這一頁要由客服、物流主管與主要承運商一起對齊，建議在兩週內完成。寫下來、三方確認過的界面，在新人報到或同事請假時才照樣運作。

把漏單與查件拉回同一條線：從試行到檢討

以下是讓品牌在下一個檔期之前，就能把這條線接起來的做法，順序依「先止血、再標準化」排列：

1. 兩週內對齊查件責任界面：召集客服、物流與主要承運商，定下第一窗口、向承運商查詢的範圍、轉單條件與時限、交接欄位，寫成一頁並確認（預期效果：物流群組裡的「這單出了沒」減少；建議週期：兩週內完成，一季後檢討）。
2. 每日出貨對照表上線：先確認通路與 3PL 能否匯出逐筆明細自動比對，不行就以人工版試行 4 週（預期效果：漏單在當天被發現，不再等顧客來問；建議週期：每天一次，試行期滿檢討去留）。
3. 補齊各平台欄位字典與例外原因碼：從出貨量最大的兩個通路開始，每次有單落不進狀態就補一條（預期效果：自動比對抓到的越來越接近真正的漏單；建議週期：每週補充，兩三個月後成形）。
4. 讓原因碼指向交接點：例外原因要能指出資料停在哪個交接點，讓當日追查的人直接找到下一個確認對象（預期效果：追查不必從頭翻三個系統；建議週期：隨對照表每日使用）。

試行查件分流時，同步看三個數字，並在試行前先量一週現況當基準：

1. 客服新增工時：客服接手自查與向承運商查詢後，每天多花了多少時間。
2. 轉單率：顧客查件中，最後仍需轉給物流的比例。
3. 顧客端結案時間：從顧客第一次詢問到得到明確答覆的時間，用中位數看。

試行前也要先約定停止條件，例如顧客端結案時間連續兩週高於基準，或客服新增工時超過事先核准的容量，就暫停分流、補齊缺口後再試；門檻數值由品牌依自己的基準決定。用示意數字說明判讀方式：試行兩週後轉單率降到四成左右（示意），代表多數件客服已能自己結束；但如果客服每天多出兩小時以上工時、結案時間反而拉長，就表示前提沒到位，例如權限不足、承運商回得太慢或清單太晚提供，這時回復原做法，補齊再試。客服多出來的工時要另外記錄，因為人手夠不夠，要看工作量、品質與成果三類資料，分流把工作從物流移到客服，工作並沒有消失。

那 12 張單，應該在週一晚上就被找到

回到週一那 1,240 和 1,228。兩個數字之間的那幾張單一直都在，差別只在於誰先看到它：是物流同仁在當天傍晚的對照表上看到，還是顧客在第四天從空蕩蕩的門口發現。

漏單的解法很少從買系統開始。先讓每個交接點都有人回傳確認，讓每張應出貨的單每天都有一個狀態，再把查件該誰接寫在紙上。這三步做到了，傍晚客服群組裡那句「這單到底出了沒」，會慢慢變成一張當天就補出去的單。

品牌最常問的多平台訂單漏單問題

Q1：多平台訂單漏單通常是怎麼發生的？

A1：常發生在沒有回傳確認的交接點：下載時篩選條件漏掉某些訂單狀態、交給 3PL 後對方沒有逐筆回傳收單與交寄、託運單印了包裹卻沒交出去、出貨後查件沒有第一窗口。訂單消失時不會報錯，往往要等顧客來問才發現，實際主因要用自家的異常紀錄判定。

Q2：每日出貨對照表跟物流 KPI 有什麼不同？

A2：對照表是當天的作業工具，以出貨單號逐筆確認每張應出貨的單落在尚未到期、已交倉、已建立追蹤號、已交寄、例外或取消哪個狀態，落不進去的就是疑似漏單。物流 KPI 是事後衡量，例如準時出貨率，兩者可以共用資料。

Q3：沒有系統串接的小品牌，也能做出貨對照嗎？

A3：可以。先確認通路後台與 3PL 能不能匯出逐筆的訂單與出貨明細，能匯出就用試算表公式比對；匯不出來就以人工填寫試行 4 週。試行期滿要看抓到幾張漏單、花了多少工時，效益不划算時，優先去要匯出欄位，不要讓人工抄寫變成常態。

Q4：客服查件改成客服先處理，多久看得出效果？

A4：先量一週現況當基準，再試行二到四週，同步看客服新增工時、轉單率與顧客端結案時間，並事先約定停止條件。轉單率下降、結案時間不變或縮短，代表分流有效；客服工時暴增或結案時間拉長，就回復原做法，補齊前提再試。

Q5：讓客服直接聯絡承運商，會有個資問題嗎？

A5：要先確認。提供顧客資料給 3PL 或承運商前，要釐清屬於委託處理還是其他利用，用途落在蒐集時的特定目的內、只給必要欄位，並在委託契約中約定與監督。客服的查詢權限應依職務設定、定期檢查，並評估遮蔽不必要的個資欄位。實際做法請法務依自家契約與適用法規確認。

Q6：查件分流最容易失敗在哪裡？

A6：最常見的是前提沒到位就上線：客服看不到出貨清單或承運商查詢頁、承運商沒有固定窗口與回覆時限、客服不清楚自己能發起查詢還是求償、物流提供清單的時間太晚。查件會在客服與物流之間來回轉，所以責任界面要先寫成一頁，三方確認後再試行。

這篇是採購物流卡點系列第 4 篇，系列共 5 篇。其他四篇分別談先用問卷找出時間卡在哪：〈採購物流工作盤點問卷怎麼設計〉；採購端卡在等待與交期：〈採購交期管理：等待的天數不在工時表上〉；物流端卡在月底對帳：〈物流運費對帳為什麼拖到月底最累〉；同樣的人力怎麼分工、怎麼備援：〈物流團隊怎麼分工〉。

延伸閱讀

• 叫貨、出清、調撥總是喬不攏？先訂服務水準政策與核准規則，KPI 才訂得下去
• 呆滯庫存是採購的錯嗎？用庫存健康度拆出預測、採購、供應商各自的責任
• 補貨建議為什麼沒人照做？從活動行事曆到決策紀錄，後勤決策工具這樣選

想討論多通路出貨與查件分工怎麼規劃，歡迎預約與 91APP 團隊諮詢。