金融與保險團隊規劃「客戶管理系統開發」時，很容易把需求寫成客戶列表、保單資料、續保提醒、LINE 訊息與主管儀表板。這些畫面都合理，但若沒有先定義「同一個人」如何被辨識、外部事件如何避免重複，以及誰能看見哪些欄位，CRM 只會把原本分散在 Excel、通訊軟體與行事曆的混亂集中到新介面。

這類系統應先從資料關係和事件規則開始，而不是先畫首頁。以下不是金融或個資法規意見，也不推定任何特定業務都能蒐集相同資料；實際欄位、保存與使用方式仍應由組織依適用規範和內部政策確認。系統規格要做的，是把已核准的資料用途轉成可執行、可限制、可追查的操作。

不要把所有識別碼都當成客戶編號

一個自然人可能同時是潛在客戶、既有保戶、某公司聯絡人或家庭關係人，也可能換電話、換電子郵件或使用不同通訊帳號。CRM 應把內部客戶主鍵、外部系統識別碼、聯絡方式與業務關係分開保存。外部識別碼只是某個來源中的索引，不應直接成為全公司的唯一客戶身分。

需求盤點可以先做「來源—識別碼—用途—可見角色」表。來源可能包含既有保戶系統、表單、人工匯入與 LINE 官方帳號；每一列要說明值由誰產生、會不會改、是否已驗證、能否解除關聯，以及衝突時由誰判斷。合併兩筆客戶也不宜覆蓋舊資料，應保留合併前的識別關係、執行人與時間，並定義能否復原。

同名同電話不必然代表同一人，姓名拼法不同也不必然是兩人。系統可以提出疑似重複清單，卻不該在沒有規則與人工確認時自動合併。驗收時可準備同名不同人、同人換電話、公司聯絡人同時是個人客戶、兩個外部來源資料衝突等情境，檢查 CRM 是否能保留不確定性。

LINE 串接先處理事件可信度與重複投遞

LINE Developers 的 webhook 接收文件說明，LINE 平台會把訊息等事件以 HTTP POST 傳到已登記的 webhook，接收端應驗證簽章，並建議非同步處理事件。文件也明確提醒，同一事件可能因不同原因送達超過一次，可用 webhookEventId 偵測重複；重新投遞後，事件抵達順序也可能與實際發生順序不同，必要時要參考事件時間。

因此，「LINE CRM 串接」不能只驗收畫面上出現一則訊息。規格至少要包含簽章驗證失敗如何處理、事件原始識別碼保存在哪裡、重複事件如何忽略、晚到事件會不會覆蓋較新的狀態，以及處理失敗如何安全重試。若訊息要轉成商機、服務紀錄或待辦，也要保留轉換規則與來源事件，而不是複製一段文字後失去脈絡。

MDN 對冪等性的說明指出，同一請求執行一次或多次，對伺服器的預期效果相同，才具有冪等性；文件同時說明 POST 並不保證冪等，實務上仍需要伺服器確保端點符合設計語意。套用到 CRM，不能因 webhook 是 POST 就假設每次都應新增一筆。接收端應以事件識別碼或明確業務鍵建立去重機制，讓重試不會重複建立客戶、商機或續保待辦。

用保戶服務 App 案例拆成事件與待辦

「保戶服務 App」（insurance-app）案例整合每日待辦、續保提醒與保戶保單總覽，並採行動優先介面。這個案例適合用來反推客戶管理系統真正需要的資料關係：保戶、保單、承辦業務、到期日與待辦是不同實體，提醒則是根據條件產生的事件，不應全部塞在一個備註欄。

例如，一張保單接近到期時，可以產生一筆帶有來源保單、負責人、預定處理日與狀態的待辦。業務完成聯繫後，應記錄結果並決定下一步，而不是單純把提醒刪除。若保單資料之後更正，到期提醒要依規則更新或註記失效；若同一事件被重送，也不能再產生第二筆相同待辦。

案例只說明介面和流程如何組織，不代表任何真實客戶成果，也不代表所有金融保險業務都適用相同欄位。需求方應用自己的角色、核准資料與實際流程重建資料模型，特別確認行動裝置遺失、離職停權、匯出及離線保存等情境由誰處理。

主管儀表板必須能回到原始紀錄

「NimbusCRM 業務儀表板」（nimbus-crm）案例把商機漏斗、業績趨勢與即將到期的合約提醒放在同一視角，並區分主管與業務畫面。這提供兩個驗收方向。第一，指標必須有明確定義，例如商機屬於哪個階段、何時進入和離開；第二，彙總數字必須能回到構成它的紀錄，而不是只有一張無法核對的圖。

權限也不能只分「管理員」和「一般使用者」。可依組織實際需要拆成本人案件、同組案件、跨組彙總、敏感欄位遮罩、匯出、重新指派與設定管理。主管看得到總數，不代表一定要看到每個欄位；業務能更新跟進紀錄，也不代表能修改外部來源的原始事件。權限變更、資料匯出、合併與刪除等高影響操作，應留下可查詢的操作者、時間與對象。

把驗收寫成重播與追查

正式上線前，可用一組去識別化測試資料走完整流程：從兩個來源建立疑似同一人的紀錄、由授權角色確認對照、接收一則 LINE 事件、重播同一事件、讓較早事件晚到、產生續保待辦、重新指派負責人，再由主管從儀表板追到原始資料。接著撤除一名測試使用者權限，確認他無法繼續查詢或匯出。

交付文件則要包含資料字典、身分對照規則、事件去重鍵、狀態轉換、角色權限矩陣、操作紀錄範圍、錯誤重試與資料匯出方式。若現成 CRM 已能支援主要模型，就不必為客製而客製；若關鍵流程必須長期靠人工複製或無法追查，才有明確的客製開發理由。

金融保險 CRM 的核心不是把聯絡人數量集中起來，而是知道每筆資料代表誰、從哪裡來、因何更新，以及誰有權使用。先把身分、事件和權限寫成可重播的驗收情境，才能讓客戶管理系統成為可靠工作台，而不是更漂亮的試算表。