金融保險團隊詢問 CRM 系統費用時，常先列帳號數、客戶欄位、商機漏斗與報表張數。這些項目可以估畫面，卻不足以估權限。兩個人都叫「業務」，可能一位只能查看自己承辦的案件，另一位還要支援同組同仁；主管能看彙總，不一定能下載明細；系統管理者能設定流程，也不一定需要看所有客戶內容。

權限若等到開發後期才補，往往會牽動資料查詢、匯出、通知、報表與測試。比較可靠的估價方式，是先把角色、資料範圍與操作拆成矩陣，再判斷現成 CRM 的標準角色能否涵蓋、需要設定多少例外，以及哪些才值得客製。

帳號數不等於角色複雜度

Microsoft Learn 的 Predefined security roles for Sales說明，Dynamics 365 Sales 以角色中的權限與存取層級控制使用者能接觸的資料及操作；文件把角色分成管理與客製、主要銷售、功能、應用程式存取及內部角色，也區分 Sales Manager、Salesperson、Forecast Manager 與 Forecast User 等不同責任。

這份官方文件提供估價時很實用的拆法：不要只問「有幾個使用者」，而要問每種人要進哪個應用、看哪個範圍、執行哪些操作。十位完全同權限的使用者，與十位分屬跨區主管、業務、客服、稽核及外部合作人員，開發與驗收工作量完全不同；但不能因此猜一個固定倍數，仍需逐項盤點。

Microsoft 也提醒，以預設角色為基礎建立的自訂角色，不會自動繼承日後新增到預設角色的權限。這表示「客製角色」不只是一筆初期設定，也會產生版本升級、權限檢查與回歸測試的維護成本。若標準角色已足夠，就不必為了名稱好看另做一套；若確有差異，應記錄偏離標準的理由。

用三個維度建立權限矩陣

第一個維度是物件，例如潛在客戶、聯絡人、商機、案件、文件、活動與報表。第二個維度是操作，包括新增、讀取、修改、刪除、指派、核准、匯入及匯出。第三個維度是資料範圍，例如本人、同組、同分公司、全公司，或只看去識別化彙總。

需求書可以讓每個角色在這三個維度交叉填答。業務可能能更新本人商機、讀取同組公開活動，但不能匯出完整聯絡資料；主管可能看全組漏斗並重新指派，卻不能修改系統欄位；營運人員可能批次匯入，但每次匯入要留結果與核准紀錄。這比「一般使用者／管理員」兩級更接近日常工作。

還要把欄位層級差異寫清楚。看得到客戶名稱，不代表也要看到所有財務或健康相關資料；能看報表總數，不代表能下鑽到每筆明細。若遮罩、條件式欄位或跨單位分享是核心需求，應在估價前提出，因為它們會影響 API、搜尋、通知與匯出，不只是前端把字蓋住。

個資權利會形成可驗收的工作流程

全國法規資料庫的個人資料保護法第 3 條列出當事人對其個人資料的查詢或閱覽、製給複製本、補充或更正、停止蒐集處理利用及刪除等權利；第 5 條要求蒐集、處理或利用不得逾越特定目的必要範圍；第 11 條則涉及正確性、更正及特定目的消失或期限屆滿時的處理。

系統不能從條文直接猜出每家公司的保存期間或處理結果，實際義務仍要由組織依業務與適用規範確認。但一旦內部規則確認，CRM 就需要能接住請求：建立案件、辨識資料散落位置、限制處理、由授權角色審核、執行更正或其他核准動作，再保留完成證據。若只讓管理員直接改資料，日後很難說明誰判斷、改了什麼、哪些下游系統同步成功。

因此估價範圍要包含資料盤點與例外流程。客戶紀錄若同時出現在 CRM、郵件行銷、文件庫和舊系統，單做一顆「刪除」按鈕不代表工作完成。應先定義系統邊界、外部責任人、失敗重試與結果回報，再決定本期要自動化到哪裡。

用 Novaflow 案例演練角色，而不是複製畫面

Novaflow 金流營運平台展示案例有多層導覽、方案比較與開發者文件等資訊入口。它是產品官網展示作品，不是 CRM 導入成果；可借用的地方，是把不同受眾需要的資訊路徑分開，而不把所有內容塞進同一層。

套用到金融保險 CRM，可先挑一筆模擬商機，讓第一線業務建立聯絡、主管查看彙總、營運人員補齊資料、管理者調整角色。每位測試者只應看見完成任務所需的範圍。接著將業務調到另一團隊，確認舊案件、未完成待辦與新範圍如何交接；最後撤除帳號，確認應用程式入口、API 權杖、匯出與既有分享是否一併失效。

案例中的金融科技視覺與功能不能證明任何特定合規結果，真正的驗收仍以企業核准的角色矩陣為準。它只是協助團隊把「不同使用者有不同入口」轉成一組可走查的情境。

報價表應拆出設定、客製、資料與持續維護

比較現成 CRM 與客製方案時，可要求供應商把費用驅動因素分成四組：標準角色與流程設定、自訂物件或權限邏輯、舊資料清理遷移與外部串接，以及上線後的權限盤點、版本回歸與人員異動。不要只看初期帳號費或開發總價，也不要在來源不足時自行推算市場價格。

驗收案例至少包含同名不同角色、跨組協作、代理期間、主管只看彙總、未授權匯出、角色變更、離職停權與歷史紀錄追查。每個案例要指定預期可見資料、允許操作、拒絕方式與應留下的紀錄。供應商若能用同一組資料跑完，報價範圍才容易比較。

CRM 系統費用不是角色名稱乘以帳號數。真正需要估的是資料邊界有多少種、例外如何核准、個資請求如何流轉，以及版本更新後怎麼確認權限仍正確。先完成矩陣再選現成、設定或客製，能把預算放在真正影響營運與風險的地方。