問題在於「發現太晚」
某間貿易公司的小型團隊每天都要手動檢查配送追蹤數據。他們直接訪問快遞網站輸入號碼，將狀態轉移到 Excel，然後判斷是否延遲。
Before（手動運營）
每天下午 2 點。團隊成員逐一確認 20 份訂單的配送狀態
出現輸入錯誤或遺漏訂單（週 2～3 次）
發現延遲平均需要 3～5 小時
向買家的通知延遲導致信任度下降
投入 Claude Code 的實驗
團隊的一位成員嘗試了一個簡單的想法。「能否自動分析配送數據，並與平均配送時間比較來預測延遲？」
他們設置 Claude Code 讀取 Google 試算表中存儲的配送記錄（出發日期、預計到達日期、當前狀態）。代碼被設置為每天上午 8 點自動執行。
每日自動執行流程
1. 從 Google 試算表讀取有效訂單數據
2. 計算每份訂單的經過時間
3. 與相同地區、相同快遞公司的數據比較
4. 給予「延遲可能性」評分
5. 超過閾值時立即發送 Slack 通知
意外的結果
第 2 週開始，事情變得奇怪了。
Claude Code 為人眼尚未確認的訂單貼上了「需要注意」的標籤。團隊半信半疑地打電話給快遞公司，結果發現那些訂單確實在釜山港口延遲。
After（自動預測）
每天上午 7 點自動分析完成（人還沒起床）
只總結延遲可能性 95% 以上的訂單（少於 5 份）
平均可提前 8 小時通知買家
上個月「配送延遲」相關投訴 0 件
有趣的發現
運行自動化 2 個月後出現了幾個模式。
• 週四下午的配送在週一延遲可能性上升 35%
• 夏季特定出口港口的平均預計到達日期比實際晚 2.3 天
• 需要重新包裝的訂單延遲信號更準確
團隊根據這些數據制定了「避免週五發貨」的內部規則。
非開發人員的領悟
「我們以為必須學習編程才能進行自動化。但有了 Google 試算表和 Claude Code，只要正確提出尋找模式的問題就可以了。」
現在團隊計畫用同樣的方式預測退貨模式和季節需求變化。一台 Windows 設備和 AI 的組合改變了小公司的預測能力。