訂單出貨對接自動流

🎯 這條流程解決什麼

出貨是電商最重複、最沒有產值、卻最容易出包的環節。一張訂單成立後，出貨人員要做的事一連串：登入物流商系統、把顧客的收件姓名、電話、地址一個欄位一個欄位複製貼上、產生託運單、列印、貼到包裹上，然後回到電商後台把追蹤碼填回去、把訂單狀態改成「已出貨」，最後還要記得通知顧客。這一套流程聽起來簡單，但每一筆都要五到八分鐘，而且每一個複製貼上的動作都是一次出錯的機會——地址少貼一個樓層、電話多打一碼、追蹤碼貼錯訂單，旺季手忙腳亂時尤其常見。

實際算一下成本。一間日出五十單的小型電商，光是建單、回填、通知這三件事，每天就要耗掉四到六個小時的人力，等於一個專職人員大半天的工時都黏在重複勞動上。一旦遇到雙11、母親節這種檔期，單量翻三倍，人力卻補不上，就會出現「出貨延遲」「追蹤碼漏填」「顧客追問包裹在哪」的連鎖客訴。更別說貼錯地址造成的錯寄，補寄一次的運費加商品成本，往往比省下的那點人力貴上好幾倍。

這條流程把訂單到物流單的整段串接全自動化。付款完成的訂單透過 Webhook 即時進入流程，系統自動呼叫物流商 API 產生託運單與追蹤碼，把追蹤碼與出貨狀態同步回電商後台和出貨表，再主動傳出貨通知與查詢連結給顧客；地址不全或缺貨的異常訂單則自動攔截、標記給人工處理，不會盲目出錯。出貨人員從「逐筆手工操作」變成「只處理被攔截的少數例外」，把時間留給真正需要判斷的事情。想看更多電商營運自動化的搭配玩法，可以先逛 自動化專區。

導入後的改變

導入前，出貨是一條全靠人工肉身串接的生產線：訂單在電商後台、物流單在物流系統、通知在通訊軟體，三套系統之間靠人來搬資料，搬一次錯一次的風險就累積一次。旺季時，出貨人員加班到深夜還貼不完單，顧客在後台看到的狀態永遠慢半天，「我的包裹寄出了嗎」的客服訊息塞爆信箱。

導入後，付款完成到顧客收到出貨通知，整段可以在幾秒內自動完成。效益估算上，原本每筆五到八分鐘的人工作業壓縮到趨近於零，以日出五十單計算，每天省下四到六小時人力，等於一個月省下一名兼職人員的時間成本。錯寄率因為不再人工複製地址而大幅下降，常見可從百分之二到三降到接近零。客服詢問量也跟著掉——因為顧客在出貨當下就主動收到追蹤連結，「包裹到哪了」這類問題自己就能查，客服訊息量普遍能減少三到四成。最關鍵的是旺季不再崩潰：單量翻倍，流程照跑，出貨速度不打折，顧客體驗反而比平日更穩。

流程怎麼運作

第一步・觸發新訂單。 電商平台在訂單付款完成時，透過 Webhook 即時把訂單資料推送進流程，帶著商品明細、收件人姓名、電話、地址與配送方式。用付款完成（而非下單）當觸發點，是為了避免未付款的保留單也跑去建物流單。

第二步・建立物流單。 系統把訂單資料整理成物流商要的格式，呼叫物流商 API 產生託運單與追蹤碼。超商取貨、宅配、貨到付款等不同配送方式，對應不同的 API 參數，流程裡用條件分支自動判斷該走哪一條。

第三步・回寫後台。 拿到追蹤碼後，系統把它同步回電商平台的對應訂單，並把訂單狀態更新為「已出貨」，同時在 Google Sheet 出貨表逐筆留痕，誰、什麼時候、哪張單、哪個追蹤碼，全部可稽核。

第四步・通知顧客。 透過 Line 或 Email 主動傳出貨通知，附上物流查詢連結，讓顧客自己就能追蹤包裹進度，不必再問客服。

第五步・異常攔截。 任何一步出問題——地址資訊不全、商品缺貨、API 回傳失敗——流程不會硬著頭皮出貨，而是把該筆訂單標記為異常並通知人工處理。這道關卡是整條流程能安心自動跑的前提。

需要的工具與串接重點

平台用 n8n 或 Make 都能搭。電商平台 Webhook 是觸發核心，需要在後台設定「訂單付款完成」事件推送；若平台不支援即時 Webhook，可改用排程定時拉取新訂單清單。物流商 API 負責建單與取號，事前要申請好串接金鑰並確認支援的配送方式。Google Sheet 扮演出貨總表與稽核底稿的角色，每筆出貨的處理狀態都留痕。Line 官方帳號或 Email 則是顧客通知通道。

串接重點有三：一是 Webhook 要做去重與冪等處理，避免同一筆訂單因重送而建了兩張物流單；二是物流 API 呼叫失敗要有重試與失敗告警，不能默默吞掉；三是各種配送方式的欄位規格不同，務必先用測試單跑過每一種情境再正式上線。

常見錯誤與注意事項

這條流程涉及顧客的收件地址、電話等個資，串接物流 API 一律使用最小權限金鑰並妥善保管，資料只用於出貨用途，不可外流或挪作行銷名單。最常見也最傷的錯誤是「異常訂單照樣自動出貨」：地址缺漏、收件人資訊不全、或顯示缺貨的訂單，必須一律攔下交由人工確認再出，避免錯寄造成的運費與商品損失。涉及金流的環節——例如貨到付款金額、退款訂單——更要謹慎，務必先確認付款與訂單狀態正確再建單，這類涉及金流與庫存的判斷需人工把關，不可全交給自動化裸跑。另外，物流 API 偶有壅塞或維護，流程要能容錯與重試，不能因為一次呼叫失敗就讓整批訂單卡住。

台灣中小企業情境案例

桃園一間賣寵物零食的網路商店，平日日出三十多單，雙11檔期一口氣衝到一百多單。導入前，老闆和一名兼職員工兩個人從早到晚輪流貼單、回填追蹤碼，常常忙到忘記改訂單狀態，顧客一直問「我的訂單怎麼還在處理中」，客服訊息一天破百則。有一次更慘，地址複製時漏貼了門牌號碼，整箱零食被退回來，補寄又多花一筆運費。導入這條出貨對接流程後，付款完成的訂單自動建物流單、回填追蹤碼、發出貨通知，他們只需要盯著「異常攔截」那一格，處理少數地址有問題的單。檔期跑下來，兩個人輕鬆消化一百多單，客服詢問量掉了快四成，錯寄歸零，老闆說那是他做電商以來第一個沒加班到半夜的雙11。

延伸應用

這條流程的骨架可以往前後兩端延伸。往後接，出貨完成後自動排程「到貨後第三天」的滿意度詢問或使用教學，把單純的交易延伸成顧客關係經營；也能把已出貨顧客自動標記，導入後續的回購喚醒節奏。往前接，可以串上庫存系統，出貨同時自動扣減庫存、低於安全量就告警補貨。多物流商的店家還能加上「智慧分流」，依配送地區、重量、成本自動選擇最划算的物流商。想把出貨、庫存、回購串成一整套營運自動化，可以逛逛 任務食譜 與 工作流總覽，挑出適合自己規模的模組拼起來。

流程圖

用到的工具

更多「零售商店」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →