顧問公司談 CRM 客製化時，很容易先畫「潛在客戶、洽談中、已成交」三欄看板。但顧問案的風險往往發生在成交之前：同一企業可能有多個關係人，專案涉及的交易對手可能與既有客戶衝突，提案與委任範圍會反覆修訂，LINE 訊息又散在個人手機。若系統只把每次聯絡寫成一段備註，就無法回答誰做過檢查、客戶同意哪個版本，以及某則訊息是否真的處理完成。
CRM 客製化應先從「一個顧問案如何被接受」開始，而不是從欄位數量開始。本文提供的是系統規劃與驗收方向，不是特定產業的法律意見。實際的利益衝突規則、保存期間與委任方式，仍應由企業依業務、契約與適用規範確認。
客戶、關係人與案件要分開建模
一間公司可以同時詢問多個服務，一個案件也可能包含母子公司、介紹人、付款方與交易對手。如果 CRM 只有一張客戶表，業務人員常會複製公司資料，久而久之便不知道哪個名稱、地址或聯絡人是最新版本。較穩定的做法是分開建立組織、自然人、案件與角色關係，再讓每次詢問或委任引用它們。
如此一來，利益衝突檢查不必只靠公司名稱完全相同。系統可以要求承辦人列出案件關係人、曾用名稱與角色，搜尋候選關聯後交由具權限的人判斷。結果要保存「待補資料、待審、可承接、有條件承接、不可承接」等狀態、理由、檢查時間與核准者；不要用一個可任意覆寫的勾選框假裝完成審查。
這個資料模型也直接影響個資範圍。全國法規資料庫的個人資料保護法頁面列出個人資料、蒐集、處理與利用等定義，並規定蒐集時的告知事項；頁面同時清楚標示部分修正條文尚未生效。系統需求不應把「法規頁存在」簡化成自動合規，而應由企業確認當下有效規定，再把蒐集目的、欄位、使用角色、更正與刪除請求做成實際流程。
委任文件要綁版本與核准事件
顧問案常經歷需求摘要、提案、報價、議價與正式委任。若 CRM 只保留最新附件，系統就無法重建客戶在何時接受哪一個範圍。每份文件應有穩定識別碼、版本、建立者、發送時間、適用案件與取代關係；接受、退回修改或失效也應是事件，而不是直接把舊檔刪掉。
電子簽章法對電子文件、電子簽章與數位簽章分別定義，也說明符合規定的電子文件與電子簽章不得僅因電子形式被否認效力，以及文件內容可完整呈現、日後可取出查驗等條件。這不表示 CRM 裡任何「同意」按鈕都自動等同特定法律效果；需求訪談應先確認業務需要的是內部核准、客戶確認，還是具有特定效力的簽署，再決定身分驗證、文件鎖定、時間紀錄與取出方式。
驗收可準備兩個只差一項條款的版本，先發送舊版、再以新版取代，確認客戶無法誤簽失效版本，承辦人也能看到完整歷程。若核准後仍需修改，系統應建立新版本與新的核准事件，而不是讓管理員直接編輯已接受內容。
LINE 串接要處理事件，不是只把聊天室搬進 CRM
LINE Developers 的 webhook 文件說明，使用者加好友或傳訊時，LINE 平台會向已登記的 webhook URL 發送事件；接收端應驗證簽章。官方也提醒，事件可能因重送而重複，順序也可能與原始發生順序不同，可利用 webhookEventId 與時間資訊判斷。
因此「LINE CRM 串接」的規格至少要回答四件事：哪個 LINE 身分如何連到 CRM 聯絡人、哪些事件需要保存、重複事件如何去除，以及訊息如何轉成待辦。不能用訊息文字和時間當唯一識別，也不能在收到同一 webhook 兩次時建立兩筆跟進紀錄。事件進站後可先進待配對區，由授權人員連結案件；涉及附件或敏感內容時，還要定義取用、保留與刪除規則。
CRM 畫面也應區分「原始事件」與「業務解讀」。例如客戶傳來「下週再談」是原始內容；承辦人建立下週回電、指定負責人和截止日，才是可追蹤的工作。訊息遭收回、聯絡人解除綁定或 webhook 暫時失敗時，系統要留下可理解的狀態，不應默默改寫案件歷史。
用 Northline 案例演練顧問案件入口
展示作品「北序產業地產 Northline」（northline-industrial）以企業選址與工業資產為核心，讓訪客依需求了解顧問服務、物件與專家，再進入諮詢。若把這個前台入口接到 CRM，表單送出後不宜直接建立「已合格商機」；它應先產生詢問事件，辨識企業、聯絡人、需求地點與案件關係，再進入資料補齊與衝突檢查。
驗收情境可以設定為：同一企業的兩位聯絡人分別由表單與 LINE 詢問同一選址案，名稱寫法略有不同，之後又新增一個交易對手。系統要提出可能重複的組織與案件，但不能自行合併；承辦人確認後，新的關係人應觸發重新檢查。接著建立兩版提案，確認舊版失效、新版核准和後續待辦都能追溯。這是概念展示案例，不代表真實客戶成果，只用來具體化顧問入口與案件流程。
CRM 客製化的報價最後應對應資料模型、狀態流程、整合事件、權限、文件版本與例外處理。當每個重要動作都能說明輸入、核准者、失敗狀態與證據，顧問公司買到的才不只是一張好看的漏斗，而是一套能支撐承接判斷與後續交付的工作系統。
