業務流程 · 實作指南
維修請求分流：加快日常處理，也別把緊急事件藏起來
先設計清晰的升級處理渠道，再加入 AI 請求分類。
先定義哪些事情不能等
假設物業團隊在下班後收到維修訊息。AI 分類或能整理日常工作，但把緊急事件錯列為普通請求，與分類標籤選錯，後果並不相同。先請營運人員定義警示情況、清楚可用的緊急聯絡渠道，以及系統無法判斷時的處理方式。不要讓住戶以為填好試算表就等同已有人接手。
分流不等於安全指示
收集位置、聯絡方式、問題描述和報告時間，並把原文放在建議分類旁邊。不要產生危險維修的操作指示。即使分類仍待確認，也可以透過明確規則通知指定人員。升級安排必須符合團隊真實值班能力，不能在網站上暗示存在一個實際上沒有人的二十四小時處理中心。
流程一覽
輸入整理審核執行
跟蹤誰接手，而非只看狀態
標記處理中的請求應有負責人及下一步行動。通知發送失敗時，請求要留在例外隊列，並提供後備渠道。事件驅動系統中，收到訊號與完成業務行動是不同階段；系統回應已接收，也不等於員工已確認接手。這種區分比再增加幾個分類標籤，更能防止工作消失在交接之間。
檢討漏接與誤分
先用影子模式，由現有員工維持正式分流，再檢查模型與人員的差異，特別是模型判為普通而員工要求升級的個案。記錄逾時未分派的請求，以及人員確認接手所需時間。這是營運設計建議，並非緊急應變服務，也不表示分類模型能識別所有危險；真正的安全渠道必須獨立且明確。
可以立即進行的練習
與真實值班團隊演練普通訊息、可能緊急但語意不清的訊息，以及通知失敗。逐項寫出收件人、請求人看到的狀態與後備渠道；失敗狀態沒有人負責，就先停止推出。不要用模擬支援中心取代真實人手安排。也請新同事只看指引，找出緊急聯絡方式與暫停自動化的方法；若他需要開發者在旁提示，表示操作流程尚未交付，而不是員工需要更相信模型。
來源與延伸閱讀
- The Events APIThe Events APISlack Developer Docs · 官方文件 ·
- Building effective agentsBuilding effective agentsAnthropic · 官方文件 ·
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。