Before: 手動檢查庫存管理的侷限
過去三個月，我們的團隊每週遇到至少兩次這樣的情況。
打開Windows設備上的Google試算表，瀏覽訂單日誌。然後有人會說。「咦？這個沒有庫存，但訂單進來了？」
從那一刻起，後續行動就陷入混亂。聯絡買方，與其他倉庫協商，延遲交期或發送部分出貨要求電子郵件。很耗時。有時也會降低與買方的信任度。
最大的問題是「何時發現」。往往不是訂單直後，而是準備出貨時才發現。那時已經太晚了。
After: 5分鐘單位自動監視
上個月，用Claude Code製作了簡單的檢驗腳本。
作動原理：
• 主設備(Windows PC)每5分鐘讀取Google試算表的訂單表和庫存表。
• 獲取每個訂單的商品代碼和數量，與目前庫存比較。
• 發現庫存不足或為負數的訂單時，即時記錄在單獨的「警告」表中。
• 同時向Slack發送訊息通知團隊。(選項：也可發送電郵)
[庫存檢驗機器人流程]
讀取Google試算表(每5分鐘)
↓
提取訂單數據
↓
與庫存數量比較
↓
偵測超賣 → Slack通知 + 警告表記錄
↓
團隊成員立即應對
實際效果
導入第一週：
• 在出貨前3小時內偵測到2件超賣情況。
• 有時間向買方說明「部分預先出貨」，而不是「延遲出貨」。
• 其中一筆訂單通過自體庫存調整得到復原。
目前(第二週)：
• 沒有發生超賣事態。(預防效果)
• 反而「庫存不足預測」數據幫助團隊的採購判斷。
• 訂單處理時間縮短了5分鐘。(警告確認時間變得一致，有組織地進行)
細微的領悟
在這次自動化中學到的是，不必製作「完美的系統」。
我們的腳本仍然很簡單。可能無法偵測庫存調整，也不能自動將退貨商品加入庫存。但「在訂單進入那一刻」捕捉問題就足夠了。
夢想團隊的機器人不必完美。只要快速展示我們遺漏的部分就夠了。
下一步計劃是收集這些警告數據，進行「按訂單模式預測庫存不足」分析。那樣的話，「超賣」這個詞可能就不會出現在我們團隊的詞彙裡了。