顧問公司常從活動名單、轉介紹、網站表單與 LINE 同時收到詢問。初期用 Excel 還能記姓名與電話，但當多位顧問共同跟進、案件需要訪談與提案，真正缺少的不是更多欄位，而是大家對「這筆商機走到哪裡、下一步由誰完成」沒有共同定義。

商機管理系統因此不該先從畫儀表板開始。先把資格判定、階段門檻、活動紀錄與結案原因寫清楚，才知道 CRM 要保存什麼資料。現成或客製只是後面的選擇；若流程未定，任何工具都可能變成另一份沒人更新的名單。

名單、商機與客戶是不同狀態

下載資料、參加講座或傳 LINE 訊息的人，不一定已經是值得投入提案的商機。顧問公司可以先定義最低資格，例如需求範圍是否屬於服務領域、是否有可辨識的決策角色，以及雙方是否同意下一次會談。未達條件者仍可保留聯絡與同意紀錄，但不必全部塞進業務漏斗。

Microsoft Learn 的 商機階段文件 以 Qualify、Develop、Propose、Close 示範階段推進，並在不同階段收集聯絡人、採購時程、需求、利害關係人、提案與決策日期。這不是所有公司都要照抄的固定流程，而是很好的規格觀念：階段名稱之外，還要定義進入下一階段前必須掌握的資料與完成的工作。

顧問案可改成「初步詢問、資格確認、需求診斷、提案評估、簽約或結案」。每一階段最多保留少數必要條件，避免為了填表拖慢工作；但「負責人、下一步、預定日期」應成為進行中商機的基本欄位。沒有下一步的案件，再高的預估金額也很難管理。

漏斗要能解釋，不只顯示總數

主管看到某階段案件變多，需要判斷是新案增加、案件停滯，還是階段定義被不同業務各自解讀。因此系統應保留階段變更時間與操作者，並能查看停留時間、逾期下一步及未填結案原因的案件。

「贏單」和「未成交」也不夠。可用少量、可行動的原因，例如需求不符、時程不合、預算未核准、選擇其他方案或暫緩，並保留文字補充。分類應定期檢視，不要把顧問的主觀猜測當成客戶事實。報表的用途是找出流程問題，不是用一個看似精準的機率代替專業判斷。

LINE CRM 串接先處理事件，再談自動化

LINE Developers 的 接收訊息文件 說明，使用者傳訊息或加入官方帳號時，LINE 平台會向登記的 webhook URL 傳送事件；文件也要求在處理前驗證簽章，並建議非同步處理。若啟用失敗事件重送，同一事件可能出現不只一次，可使用 webhookEventId 辨識重複，事件抵達順序也可能不同。

這些細節會直接影響 CRM：若每次收到 webhook 都新增一筆跟進，重送便可能產生重複紀錄；若只按到達順序排列，延遲事件可能顛倒對話脈絡。驗收規格至少要包含簽章驗證、重複事件處理、失敗重試、事件時間與處理時間，以及無法對應客戶時的待整理佇列。

也不要把 LINE 顯示名稱直接當成 CRM 客戶身分。系統需要一個經授權的帳號連結或人工確認流程，並記錄連結依據。顧問公司還應決定哪些訊息可進 CRM、誰能查看、保存多久，以及使用者收回訊息時怎麼處理；這些規則應由企業依實際服務與適用要求確認。

案例：主管視角與第一線待辦必須同時成立

「NimbusCRM 業務儀表板」把商機漏斗、業績趨勢與即將到期的合約提醒放在同一頁，並分開主管與業務視角。這個案例的可借鏡之處，是儀表板上的數字能回到具體案件，而第一線也能從案件得到下一個行動；如果只有主管報表，資料輸入很快會變成額外負擔。

「保戶服務 App」則把每日待辦、續保提醒與保戶保單總覽整合在行動介面。顧問服務雖不是保險業，仍可看到相同原則：人在外面跟進時，最需要的是今天要做什麼與對方的必要脈絡，而不是把桌機後台完整縮到手機。

用情境驗收，而不是只核對欄位

驗收可用一筆網站詢問、一筆 LINE 新訊息與一筆舊客轉介紹走完整流程：確認是否正確去重、指派負責人、建立下一步、推進階段、留下提案版本，再以成交或未成交結案。接著測試權限，確保顧問只能看授權案件，主管可檢視團隊，而匯出與大量修改另有限制。

一套有效的商機管理系統，價值不在收集最多資料，而在讓每一筆進行中商機都有清楚階段、責任人與下一步。先把這三件事定義好，再決定 CRM 買現成還是客製，導入才不會只是把 Excel 換成更昂貴的表格。