從語音到派遣：事件驅動的訂單流程設計

電話接單不是一個動作，而是一串有先後依賴的處理。用事件描述流程，能讓每個階段的成功、失敗與等待狀態被看見。

為什麼用事件描述流程

如果系統只提供一個「建立訂單」的函式，失敗時很難判斷問題發生在哪裡：是通話沒收到、語音沒轉好、地址沒擷取，還是派遣系統沒有回應？把流程拆成事件之後，每個階段都有明確的輸入、輸出與狀態，也比較容易重試或交給人工。

這裡的事件是設計概念，不是現行系統的介面規格。命名僅用於說明流程。

流程中的事件

• call.received：電話進線，建立通話識別碼與基本脈絡。
• transcript.ready：逐字稿完成，附上時間標記與音訊參照。
• order.extracted：欄位擷取完成，包含各欄位的信心與來源片段。
• order.review_required：低信心或衝突資訊需要人工確認。
• order.confirmed：人工或規則確認完成，訂單內容定案。
• dispatch.requested：向派遣流程提出需求。
• dispatch.updated：派遣結果或狀態變更。

事件之間不應假設同步完成。語音轉文字可能比通話結束晚幾秒，人工覆核可能隔幾分鐘才發生，派遣系統也可能暫時無法回應。流程必須能處理這些等待與中斷。

失敗處理

• 冪等：同一個事件重送時，不應重複建立訂單或重複派遣。
• 重試與退避：外部服務暫時失敗時，依錯誤類型決定是否重試，而不是無限制重送。
• 待處理佇列：無法自動處理的事件需要被保存與提醒，而不是消失。
• 人工覆核：把不確定性顯性化，讓營運人員知道該確認哪一個欄位。
• 補償：已建立的錯誤結果需要有可追蹤的修正方式，而不是直接覆寫。

原則是先讓失敗可見，再談自動化。若失敗只留在日誌深處，營運人員就無法判斷訂單是否真的成立。

可觀測性

事件流程需要一個共同的關聯識別碼，把通話、逐字稿、擷取結果、覆核與派遣串在一起。每個階段應記錄狀態轉換、處理時間與失敗原因。這些紀錄同時支援除錯、營運檢視與後續的測試比較。

紀錄本身也涉及隱私。通話音訊與逐字稿可能包含個人資訊，因此需要遮蔽、權限控制與保存期限，而不是無限制保留。

設計原則

事件驅動不是為了追求架構複雜度，而是為了讓流程中的不確定性有位置可以停留。對車隊營運而言，一個「等待人工確認」的狀態，遠比一個默默失敗的訂單更容易處理。