顧問公司的業務管理系統若只是一張「公司、聯絡人、預估金額、下次聯絡日」清單，很快會遇到兩種問題：所有詢問都被算成商機，漏斗看起來很大卻無法預測；提案在郵件與雲端資料夾反覆修改，系統只留下最後一份檔案，沒有人能說明客戶同意的是哪個範圍。
顧問服務的成交往往不是單一商品下單，而是經過需求訪談、適配判斷、保密安排、提案修訂與決策人確認。規劃業務管理系統時，應把「線索、商機、提案、合約與續約」視為不同紀錄，並定義它們何時建立、誰能修改、轉換後保留哪些證據。
先定義合格商機，避免把名單當業績
潛在客戶留下名片或表單，不等於已經形成可投入售前工時的案件。資格審查可依公司自行定義，但至少要回答：對方要解決什麼問題、是否符合服務範圍、誰參與決策、預計何時開始，以及下一步是否已獲雙方確認。沒有答案時可以保留在線索池，不必硬填預估金額。
Microsoft 的潛在客戶轉換文件將資格確認後的線索連結至客戶與聯絡人，並建立商機追蹤；不符合條件的線索可以標記為不合格，同時保留稽核軌跡。這提供一個實用的資料邊界：拒絕或暫緩不是刪除資料，也不該假裝仍在洽談。系統要保留原因、日期與負責人，報表才能區分真實進行中的案件與已結束線索。
「NimbusCRM 業務儀表板」（nimbus-crm）案例把商機漏斗、業績趨勢與合約到期提醒放在同一個主管視角，並區分主管與業務使用介面。將它用在顧問公司時，漏斗數字應來自明確狀態，而不是由業務自由輸入百分比；合約提醒則應連回有效期間與續約負責人。如此主管看到的不是漂亮圖表，而是能追查到原始商機與合約的待辦。
一個客戶可以有多個商機，但不要複製客戶資料
同一家公司可能同時詢問策略顧問、教育訓練與年度陪跑。這些案件的預算、決策人與時程不同，應拆成不同商機，卻共用同一個組織與聯絡人主檔。若每來一案就複製一份公司資料，地址或窗口異動時會出現多個版本，後續也無法彙整客戶關係。
因此資料模型可以分成組織、人物、人物與組織的角色、商機、商機參與者與活動紀錄。商機參與者要標明決策者、使用者、財務或法務等角色，而不是在備註欄寫一段文字。當窗口離職時，更新人物與角色關係即可，不必改寫歷史提案；新商機也能沿用經確認的組織資料。
提案要有版本與狀態，不能覆蓋同一份檔案
顧問案常因範圍、交付項目、時程或付款條件調整而改版。Microsoft 的報價文件區分草稿、啟用與關閉狀態，並說明報價在洽談中可能多次修改；啟用後的金額會被鎖定，接受後再進入訂單。顧問公司不必照搬產品名稱，但可採用相同原則：送出的版本不可被悄悄覆寫，改條件時建立新版，舊版標記為已修訂或失效。
每一版提案至少保存版本號、建立者、核准者、送出時間、服務項目、數量或計價單位、金額、有效條件與附件雜湊或檔案版本。商機畫面應清楚顯示目前有效版，而不是讓使用者從檔名猜測。驗收時可模擬客戶要求刪除一項服務、改變時程，再確認舊版仍可讀取、新版重新經內部核准，而且成交只連到客戶正式接受的版本。
客戶資料要按目的與角色開放
CRM 集中姓名、電話、電子郵件、職稱、洽談紀錄甚至合約資訊，不代表所有員工都應看到全部內容。全國法規資料庫的個人資料保護法第 5 條要求蒐集、處理或利用不得逾越特定目的必要範圍；第 8 條列出直接蒐集時應告知的事項，包括目的、資料類別、利用期間、地區、對象與方式，以及當事人權利。系統設計應先讓公司依實際業務與法律顧問意見確認適用內容，不能把安裝 CRM 當成合規結論。
可落地的規格包括：表單保存告知版本與同意時間；業務只能看自己或所屬團隊的商機；財務能讀取開票資料但不必看到完整訪談筆記；匯出名單需要額外權限並留下操作者、時間與條件；客戶要求更正或停止利用時，有明確受理與完成狀態。對外行銷名單與履約中的聯絡人也應分開管理，避免把曾經詢價直接解讀成永遠可行銷。
用狀態轉換與稽核紀錄驗收
驗收不要只看能不能新增客戶，而要用一條完整情境測試：表單建立線索、業務判斷不適配、主管重新開啟；另一條線索完成資格審查後建立商機，新增兩版提案，舊版失效，新版通過核准並成交；最後由合約日期產生續約提醒。每次狀態改變都應記錄前後值、操作者與時間，必要欄位缺少時則阻止轉換並說明原因。
這樣的業務管理系統不會替顧問做專業判斷，但能把判斷依據、提案承諾與資料責任留在同一條可追查的紀錄中。當團隊擴大或案件交接時，新負責人看到的是有版本、有權限、有下一步的案件脈絡，而不是散落在個人信箱裡的記憶。
