跳至主要内容

文件狀態 vs 業務進度（Sales Stage）

在本 CRM 架構中，「文件狀態（Status）」與「業務進度（Sales Stage）」是兩個刻意分離的概念。

這並非資料重複，而是為了避免管理視角與作業事實混淆，導致決策失真。

一、文件狀態是「不可爭辯的事實」​

文件狀態反映的是報價單在系統中的客觀狀態，例如：

  • Draft：尚未送出
  • Sent：已正式送出
  • Accepted：客戶已接受
  • Rejected：客戶明確拒絕
  • Expired：超過有效期限

這些狀態具有以下特性：

  • 具備明確定義
  • 不依個人主觀判斷
  • 與實際文件流程高度對齊

因此，文件狀態的角色是：

描述「這份報價文件現在是什麼狀態」。

它是流程事實，不是管理判斷。

二、僅靠文件狀態，管理視角會出現盲點​

若僅依賴文件狀態，業務主管實際上無法回答以下問題：

  • 同樣是 Sent，哪些還在積極洽談？
  • 哪些 Sent 已經實質停滯？
  • 哪些案件雖未過期，但成交可能性已大幅降低？

例如：

  • 一張 Sent 的報價，可能是：
    • 剛送出，正在等待回覆
    • 正在多次協商條件
    • 已無回音，但尚未過期

在文件狀態上，它們完全相同；
在管理意義上，卻截然不同。

三、業務進度是「管理用的判斷層」​

為補足上述盲點，本系統引入 Sales Stage（業務進度） 作為管理層觀點。

Sales Stage 的設計原則為：

  • 反映實際洽談狀況
  • 允許模糊與調整
  • 由人判斷，而非系統自動推論

它的角色是：

描述「這張報價，在業務上目前走到哪裡」。

這是一個「管理輔助欄位」，而不是流程控制機制。

四、為何不將兩者合併為單一狀態​

將文件狀態與業務進度混為單一欄位，常見於早期 CRM 設計，但會帶來以下問題：

  • 為了反映洽談情況，被迫修改文件狀態
  • 文件狀態失去原本的客觀意義
  • 管理數據開始不可信

因此，本系統刻意維持以下分工：

類型角色回答的問題
文件狀態作業事實這份文件目前怎麼了
業務進度管理判斷這個案子實際走得如何

這種分離，使得兩者都能各司其職。

五、兩者如何搭配使用於管理介面​

在實際介面呈現上，兩者並非各自獨立存在，而是交叉解讀：

  • Status = Sent + Sales Stage = 洽談中
    → 正常流動
  • Status = Sent + Sales Stage = 停滯
    → 潛在風險
  • Status = Accepted + Sales Stage = 已成交
    → 可列入成果
  • Status = Sent + 長時間未變動
    → 管理警示

這樣的組合，才能支撐後續的：

  • 卡住警示
  • 風險集中判斷
  • 主管介入建議

六、對後續介面設計的影響​

明確區分文件狀態與業務進度，將直接影響：

  • Dashboard 的分類方式
  • 報表與統計口徑
  • 業務回報的設計方式
  • 管理者介入時機的判斷邏輯

也正因為有此區分，後續介面才能避免淪為單純的「報價清單」。

七、小結​

文件狀態回答的是「流程是否完成」，
業務進度回答的是「案件是否仍然活著」。

本 CRM 的介面設計，正是建立在這兩個層次清楚分工的前提之上。

下一章將進一步說明：
業務主管在介面中，如何透過這些資訊快速判斷風險與優先順序。