CRM 系統匯入 Excel 前怎麼整理？欄位對照、重複合併與更正流程

公司決定導入 CRM 系統時，第一個念頭常是把業務手上的 Excel、表單名單、名片資料與通訊錄一次匯入。檔案成功上傳不代表導入成功：同一人可能以不同電話格式出現，同一家公司可能有簡稱與全名，離職聯絡人仍掛在進行中的商機，而來源與蒐集目的已經無人能說明。

CRM 的起點不是匯入按鈕，而是決定什麼叫一筆客戶、哪些欄位可以覆蓋、哪些疑似重複要人工判斷，以及錯誤資料如何更正或停止使用。若沒有這些規則，自動合併會刪掉重要差異，完全不合併則讓同一客戶收到重複聯絡。

先建立資料盤點，不直接清理原始檔

每一份來源檔先記錄擁有部門、最後更新時間、欄位說明、資料取得方式、預定用途與負責人。原始檔保留唯讀版本，再複製到清理區；不要在唯一檔案上直接刪欄或改值。這能讓團隊在匯入結果異常時回頭核對，而不是靠記憶猜哪個版本才正確。

欄位對照表要把來源欄位映射到 CRM 主檔，例如「公司名稱」「聯絡人」「電話」「電子郵件」「來源」「負責業務」與「最後互動時間」。同名欄位也可能語意不同：試算表中的「狀態」可能是聯絡意願、報價結果或名單有效性，不能直接塞進同一個商機階段。

每個轉換規則應保留原值、轉換後值與失敗原因。電話格式可以標準化，空白可依規則處理，但公司名稱、聯絡人身分與同意狀態不應靠程式任意猜補。無法確定的資料進待確認清單，比靜默匯入錯誤更安全。

Microsoft 的 Dataverse 重複偵測與合併文件說明，人工輸入或大量匯入都可能產生重複資料；系統可依規則提示候選，合併時保留主要紀錄並選擇要留下的欄位。文件也列出限制，例如合併適用於特定類型，且離線模式下不會執行相同偵測。這提醒需求方：不能只寫「自動去重」，而要驗收規則、範圍與例外。

實務上可以分層比對。完全相同且已標準化的電子郵件可列為高信心候選；公司名稱加電話可能是中信心；只有姓名相同則不應直接合併。每個候選都要顯示命中理由與衝突欄位，讓審核者選擇主要紀錄、保留值或暫不處理。

合併不只影響姓名與電話，還可能牽動商機、活動紀錄、備註、任務與同意證據。驗收應確認關聯資料搬到哪裡、次要紀錄是否仍可追溯、合併能否撤回，以及匯入批次能否整批停用或回復。若平台本身不支援完整回復，就要在正式匯入前先做備份與抽樣演練。

全國法規資料庫的個人資料保護法第 11 條要求維護個人資料正確，並在一定情況下更正、補充、刪除或停止處理利用；資料正確性有爭議時，也有停止處理或利用與註明爭議的規定。實際適用仍應由組織依業務與法律意見判斷，網站或系統團隊不能替企業下法律結論。

但系統需求可以具體化：能搜尋某人的所有關聯紀錄、標記資料爭議、記錄更正前後值、指定核准者、通知曾使用資料的內部流程，並把停止利用與刪除區分開。直接刪除畫面上的客戶列，可能留下行銷名單、匯出檔或其他系統副本，因此還需要一張系統與資料流清單。

蒐集來源與用途也應成為欄位，而不是只寫在專案文件裡。業務手動新增、官網詢問、活動名單與合作夥伴提供的資料，後續可用範圍未必相同；匯入時若來源不明，應先隔離待確認，不要自動加入所有行銷流程。

北序產業地產 Northline 概念官網包含工業物件、顧問服務、專家介紹與站內諮詢示範。這是虛構品牌的概念作品，不是實際 CRM 成效案例；它適合用來測試來源辨識：同一聯絡人可能從不同物件頁送出詢問，也可能由顧問在會談後手動建立資料。

可設計一組驗收資料：聯絡人的兩次表單使用不同公司簡稱，其中一次電話含國碼，另一次沒有；業務 Excel 又有相同電子郵件但職稱較新。匯入後系統應列出重複候選與命中原因，不應直接製造三筆商機，也不能以較舊資料覆蓋較新值。審核者選定主檔後，仍要保留每次詢問的來源頁與時間。

接著模擬聯絡人要求更正職稱，確認畫面能記錄申請、處理者與變更；再標記其中一個電話有爭議，檢查名單匯出是否排除該欄位或該紀錄。這些情境比單純檢查「Excel 成功匯入幾列」更接近 CRM 上線後的責任。

正式切換前先選一個部門或一小批去識別化測試資料，跑完欄位轉換、失敗清單、重複審核、關聯搬移、權限與回復。結果應能對回原始列號，並由資料負責人抽查，不以匯入工具顯示成功作為唯一證據。

CRM 系統真正要改善的是客戶資料可被共同理解與負責，而不是把更多試算表搬進同一個畫面。把來源、欄位語意、合併決策與更正流程寫成驗收條件，才能讓業務信任資料，也讓公司在資料有爭議時知道如何處理。