建設公司、代銷或不動產顧問導入商機管理系統時，最容易先畫出「新名單、聯絡中、帶看、議價、成交」漏斗，再要求儀表板顯示各階段數量。問題是，如果每位業務對「已聯絡」與「有效商機」的理解不同，或一筆資料被反覆拖動狀態，報表看似完整，實際上無法回答名單從哪裡來、何時被處理，以及為什麼沒有繼續。
CRM 規格應先定義事件，再設計看板。事件表示某個可辨識的動作在某個時間發生，例如表單送出、完成資格判定、首次聯絡、預約賞屋、取消或結案；看板則是依這些紀錄整理出的目前狀態。兩者分開，才能保留過程，也避免只看到最後一次人工修改的結果。
先區分來源、聯絡人與商機
網站詢問、廣告表單、現場來客與合作方轉介是來源；姓名、電話或電子郵件屬於聯絡人資料；對某個建案或服務的洽談才是一筆商機。同一聯絡人可以在不同時間詢問不同案別，也可能用兩個入口重複送出。若系統把每次表單送出都當成一位新客戶，業務會看到重複資料；若只保留一列客戶，又會失去每次詢問的案別與時間。
因此發案文件應為三層資料各定義識別方式。來源紀錄要保存入口與取得時間；聯絡人合併需要人工可確認的規則；商機則要有案別、負責人、目前階段與階段歷程。不要以手機號碼相同就自動覆蓋全部欄位，也不要把追蹤參數直接當成業務認定的來源。遇到衝突時，系統應保留原值、提出候選合併並記錄處理者。
Google Analytics 的 Recommended events將商機流程拆成 generate_lead、qualify_lead、disqualify_lead、working_lead、成功結案與未成交結案等事件，並說明這組事件適合 B2B、汽車、保險或其他線下完成轉換的流程。這不代表 CRM 必須照抄英文名稱，而是顯示「產生名單」和「業務判定合格」本來就是不同事件，不能用同一個欄位混在一起。
每個階段都要有進入條件與退出原因
「聯絡中」若沒有條件，可能只是業務打開過資料，也可能代表已完成通話。較可驗收的寫法是：進入某階段時必須有哪個動作、誰能操作、必填哪些欄位，以及系統記錄哪個時間。資格不符、重複名單、客戶暫緩、聯絡不到與選擇其他案別，也應使用不同原因，不要全部丟進「失敗」。
可以建立事件規格表，至少包含事件代碼、顯示名稱、觸發方式、操作者、發生時間、關聯商機、前置條件、可否撤回及撤回後狀態。自動事件與人工判斷要分開：表單成功送達可由網站產生；「預算與需求符合」則應由有權限的人判定。若狀態被改回上一階段，系統要新增一筆更正事件並保留原因，而不是刪除先前紀錄。
Google Analytics 的 Lead acquisition report說明，報表仰賴商機產生與後續商機事件資料。對系統規格的啟示是：先約定事件何時送出及如何識別，再談來源成效。網站分析工具可以接收必要的衡量事件，個人聯絡內容與業務備註則留在 CRM；兩邊以經核准的識別策略對照，不應為了報表把整筆客戶資料送往分析服務。
用預約賞屋情境驗收完整歷程
築澄開發展示案例包含建案作品、影像內容與三步驟預約賞屋流程。這是網站展示作品，不代表真實建設公司的成交成果，也不能據此推算轉換率。它可作為前台事件的具體起點：訪客選擇建案並完成預約後，CRM 應建立或連結哪一筆聯絡人與商機？改期或取消時，是更新預約、退回商機階段，還是留下兩個彼此關聯的事件？
驗收可安排一組完整劇本：同一人先從建案頁送出詢問，隔日以相同電話預約賞屋；系統提示可能重複，由主管確認合併；業務完成聯絡並判定為有效商機；客戶改期後完成帶看，最後以明確原因結案。檢查目前狀態、事件時間軸、來源歸屬、負責人交接及報表數量是否一致，也要確認撤回錯誤操作後不會留下互相矛盾的數字。
報表必須能回到原始紀錄
漏斗上的任何數字都應能展開到對應商機，再看到使其進入該階段的事件。報表需明訂採用「目前位於該階段」還是「期間內曾進入該階段」，並固定時區、日期邊界與排除條件。兩種算法都可能合理，但不能在同一張圖中混用。
商機管理系統的核心不是讓團隊多拖幾張卡片，而是建立共同語言與可追查的過程。當來源、聯絡人、商機和事件各有邊界，業務知道何時要記錄，主管知道數字如何形成，開發團隊也能以具體劇本驗收。此時 CRM 才能支援決策，而不是把原本分散的試算表換成一個更漂亮、但同樣含糊的畫面。
