設計目標與前提
本文件說明本 CRM 介面設計的核心目標與設計前提，目的在於讓相關決策者在討論功能之前，先對「這套系統是為了解決什麼問題」建立共識。
若未先釐清此層次，後續的介面與功能討論容易流於個人偏好，而無法有效支援實際業務管理。
一、此介面並非為了取代現有作業流程
本 CRM 介面的設計前提，是建立在既有作業流程之上，而非推翻或重構整個業務制度。
目前公司內部對於報價單（Quotations）已有相對穩定且可執行的流程，包括：
- 報價單的產出方式
- 報價內容的組成結構
- 文件狀態的使用習慣（Draft / Sent / Accepted / Rejected / Expired）
因此，本階段的設計重點不在於「重新定義流程」，而是：
如何讓現有流程的狀態，能被更有效地閱讀、判斷與管理。
二、設計核心並非「資料齊全」，而是「決策可用」
傳統 CRM 系統往往強調資料完整性，例如：
- 所有欄位是否填齊
- 是否能追蹤每一次互動紀錄
- 是否具備完整 Pipeline 階段
但在實際管理情境中，業務主管更常面臨的問題是：
- 資料很多，但不知道哪些需要注意
- 案件看得到，卻看不出是否有風險
- 問題往往在事後才被發現
因此，本介面設計的優先順序為：
- 讓異常與停滯狀態能被快速辨識
- 讓風險集中點能自然浮現
- 協助主管判斷是否需要介入
而非追求功能數量或資料維度的完整。
三、本階段優先服務的對象是「管理者視角」
本 CRM 並非只服務單一角色，但在設計順序上，優先以業務主管的管理需求為出發點。
原因在於：
- 業務人員的作業需求通常較為明確（填寫、回報、跟進）
- 管理者的需求若未被清楚定義，系統容易淪為「資料倉庫」
因此，本文件與介面設計會先回答以下問題：
- 業務主管在什麼情況下會打開系統？
- 他希望在 1 ～ 2 分鐘內看出什麼？
- 哪些狀況應該被視為「需要介入」？
在此基礎穩定後，才逐步延伸至其他角色的操作介面。
四、為何不直接導入完整 Pipeline 模型
在標準 CRM 架構中，Pipeline 是常見且成熟的做法。
但在目前情境下，存在以下現實前提：
- 業務活動並非從「線索」開始被系統化管理
- 報價單本身已是多次溝通後的結果
- 公司內部對「文件狀態」已有高度共識
因此，本階段選擇：
- 以 Quotations 作為核心資料單位
- 將 Pipeline 的概念，轉化為「業務進度（Sales Stage）」欄位
- 避免在流程尚未成熟前，引入過度複雜的階段定義
這並非否定 Pipeline，而是基於目前組織成熟度所做的取捨。
五、本文件不處理的事項（刻意保留）
為避免討論發散，本階段設計刻意不處理以下議題：
- 自動化跟進流程（Automation）
- 預測模型或加權金額計算
- 跨部門 KPI 與績效評估
- 業務獎酬或抽成制度
上述內容並非不重要，而是需要在管理視角與基礎資料穩定後，再進行討論。
六、小結
本 CRM 介面設計的目標，不是打造一套「功能齊全的系統」，而是：
讓管理者能在最短時間內，看懂現在發生了什麼，以及該不該介入。
後續章節將依此原則，逐步說明業務主管在介面中實際看到的資訊，以及各區塊所對應的管理意義。