同一間公司在 CRM 出現三次：一次用英文全名、一次用縮寫，另一次只有聯絡人的電郵。市場部把它當成新客戶，銷售部卻已經完成報價。這時加入 AI，只會讓系統更快地處理互相矛盾的資料。
第一方數據，是企業直接從自身與客戶的互動中取得的資料，例如查詢、購買、帳戶偏好及服務記錄。它是否有用，取決於定義、品質與允許用途，並非單看數量。
對正在起步的企業，先整理 CRM 的基本欄位，往往比立即增加大型平台更容易驗收。
從七個業務欄位建立共同語言
以下是針對 B2B 查詢流程的起步設計，實際欄位應按業務調整：
| 欄位 | 要解決的問題 |
|---|---|
| 內部客戶／公司識別碼 | 哪些記錄屬於同一對象？ |
| 公司與聯絡角色 | 對方是誰，與採購有何關係？ |
| 來源 | 這次查詢由哪個接觸點產生？ |
| 需求與感興趣服務 | 對方實際表達過甚麼需要？ |
| 所處階段 | 正在查詢、評估、報價，還是已結案？ |
| 負責人與下一步日期 | 誰要在甚麼時候做甚麼？ |
| 聯絡偏好與允許用途記錄 | 哪些溝通或用途已獲適當確認？ |
欄位不應只追求填滿。客戶沒有提供採購時間，就保留「未知」，不要要求同事或 AI 隨便選一個月份。虛假的完整，會令後續分組及預測更難使用。
把來源和推測分開保存
AI 可以把「想了解三語網站及區域推廣」整理成「多語內容需求」，但這是分類結果，應與客戶原文分開保存。若再推測對方正在拓展亞洲市場，也要標明推測依據，不能當成已確認事實。
資料更新時，最好知道是客戶自行提交、同事修改，還是模型產生。這樣遇到錯誤，團隊才知道應修正來源、規則，還是提示內容。
對跨國公司，還要分清楚母公司、地區辦公室及個別聯絡人。電郵網域相同，不一定代表可以把所有採購機會合併。
事件名稱一致，報告才可以比較
「有興趣」「有效查詢」「已聯絡」看似容易理解，每位同事卻可能有不同定義。建議用可觀察的事件描述，例如「提交服務查詢」「完成首次會議」「發出建議書」。
同一事件也應區分嘗試與完成。客戶按了預約按鈕，不等於會議已確認；發出會議邀請，不等於客戶有出席。若把這些混在一起，AI 分析及營銷報告都會高估進度。
選幾宗真實個案，由市場與銷售一起分類，很快就能找到定義不一致的地方。
客戶資料不需要全部流進每個工具
不同系統有不同用途。CRM 需要知道聯絡人是誰，分析工具則可能只需要記錄某類事件是否發生。Google Analytics 的官方說明要求避免傳送其政策不允許的可識別個人資料，提醒企業在連接系統時逐項檢查欄位，而不是把整份客戶紀錄直接送出。參考：Google Analytics 資料處理指引
在實務上，可以建立欄位清單，列明每項資料的業務目的、接收系統、負責人及保留安排。使用 AI 摘要時，只提供該任務需要且獲准使用的內容；測試則優先採用合成或適當去識別的資料。這些是資料治理的起步工作，具體法規要求仍需按實際市場與用途確認。
甚麼時候才值得擴大數據平台？
當團隊已經有一致定義，卻仍需要跨多個來源建立客戶輪廓、處理身份關聯或支援多渠道應用，就有較清楚的理由評估進一步整合。
採購前先寫出三個無法完成的工作，以及新平台要改善的指標。例如減少重複記錄、縮短更新延遲，或讓某個客群能準確進入指定流程。單純「想為 AI 做準備」，不足以形成可靠的驗收標準。
想找出 CRM 最值得先整理的資料？ 向 Martech HK 提交查詢，一起檢視欄位、客戶旅程及後續 AI 應用。