CRM 資料匯入：清理潛在客戶名單的實用指南

你正盯著一份昨天看起來還沒問題的試算表，而現在每一欄都像只要再點一下，就可能讓你的 CRM 崩潰。姓名混雜、電話格式不一致，一半的日期格式都錯了；當你開啟匯入精靈時，甚至已經能看見重複資料接踵而來。這正是 CRM 資料匯入 不再只是上傳檔案，而是轉變為受控移轉的時刻。

乾淨的 CRM 資料匯入應有的樣子

乾淨的匯入流程在任何人點下上傳按鈕之前就開始了。實際上，這表示有人會以足夠的懷疑態度檢視原始檔案，及早發現那些否則會在 HubSpot、Salesforce 或 Pipedrive 中顯現的問題，例如負責人歸屬錯誤、來源值不明，以及沒有人信任的記錄。我看過團隊先推送完整檔案，接著花上一週清理那些其實在前 5 分鐘內就能看出的問題。

成功的樣子

匯入正式上線後，良好的匯入流程應該讓人感覺平順無事。記錄會帶著標準化欄位、正確的負責人，以及足夠的背景資訊抵達，讓銷售或客戶成功團隊能立即使用，而不必先進行清理。實務上的匯入流程會先從50–100 筆記錄的小型測試批次開始，接著在完整載入前，將匯入數量與範例欄位和來源檔案進行比對，讓對應錯誤與格式問題在擴散到整個檔案前先被發現（以品質為核心的 CRM 匯入流程指南）。

**實務規則：**如果測試批次很混亂，完整匯入只會更混亂。

失敗的樣子

即使精靈顯示檔案「成功」，不良的匯入通常仍會在 3 個地方暴露問題。你會遇到遭拒的資料列、重複的聯絡人，以及已存在於 CRM 中卻缺少團隊所需欄位的記錄。常見的問題點包括不一致的日期、電話與地址格式、重複記錄，以及未對應的必要欄位；因此，最重要的工作發生在上傳之前，而不是上傳過程中。

記錄匯入後，這一點更加重要。匯入欄位在正式運作中的 CRM 內會以不同速度失效，而最快變得過時的通常是負責人指派、來源歸因、電話號碼，以及任何取決於工作流程或業務代表更新的欄位。因此，團隊需要制定合併與隔離規則。當比對結果明確且資料仍可使用時，就合併記錄。當來源不明確、識別資訊相互衝突，或某個欄位會覆寫團隊仍依賴的內容時，就將記錄隔離。

本節是為 SDR 營運主管、搬移客戶名單的代理商，以及將增補後記錄推送至 HubSpot 或 Salesforce 等系統的團隊所撰寫。如果檔案來自試算表中的潛在客戶、資料增補工具，或多個來源系統，目標始終相同：建立一個 CRM，讓資料在匯入的那一刻就能被存取、追溯來源並實際使用。

在任何 CRM 讀取資料前準備來源檔案

乾淨的匯入通常從一個幾乎看起來很樸素的檔案開始。實際工作發生在任何人開啟精靈之前，因為一旦 CRM 開始猜測欄位含義，錯誤就更難撤銷。如果來源是潛在客戶名單、資料豐富化流程或試算表清理工作，請將其維持為乾淨的 CSV、Excel 或 JSON 格式，並使用一列標題與穩定的欄位名稱。對於潛在客戶開發工作流程，像 MapLeads 電子郵件名單 這類結構化匯出檔，能讓檔案在開始欄位對映前就更接近 CRM 就緒狀態。

在對映前先統一格式

最安全的做法是 在對映前先統一數值格式。整個檔案使用同一種日期格式、同一種電話格式，以及 CRM 原生的國家、地區和是／否欄位標籤，這樣匯入工具就不必調和同一數值的六種版本。技術匯入指南也建議定義複合或舊版 ID，讓聯絡人、公司和歷史紀錄在移轉後能重新連結，尤其是在目標 CRM 結構描述與來源檔案不同時。技術匯入精靈指南 中涵蓋了這項設定的實際操作流程。

許多團隊在這裡浪費時間。Excel 可能會刪除電話號碼開頭的零，混合的日期格式可能造成排序錯誤，而合併儲存格可能以不明顯的方式拆分欄位，直到匯入拒絕資料列或將數值移入錯誤欄位時才被發現。請在來源系統或暫存工作表中清理檔案，不要在 CRM 內處理。

以即將投入正式環境的標準檢查檔案

上傳前，請檢查幾個基本問題。確認只有 一列標題、沒有任何欄位依賴合併儲存格，且電話、電子郵件與國家數值從上到下保持一致。接著排序或篩選出明顯的缺漏，因為在試算表中修正缺少的必要欄位，比 CRM 已經建立不完整紀錄後再修正容易。

• 先修正電話格式： 國碼、分隔符號和分機號碼採用同一套規則，否則下游驗證會將同一個號碼視為多個數值。
• 攤平日期格式： 混合的日期樣式是匯入錯誤的常見來源，因為試算表和 CRM 可能以不同方式讀取日期。
• 移除來源中的重複資料列： 事前去除重複資料，比事後整理重複紀錄更省成本。
• 備份原始檔案： 如果正規化版本出現問題，你會需要未經修改的來源檔案進行比對。

如果檔案來自多個工具、資料豐富化流程或手動編輯，請在繼續之前，將一部分已清理的資料列與原始匯出檔進行比對。這項快速檢查能找出通常只有在 CRM 開始拒絕欄位，或建立團隊無法使用的紀錄後才會浮現的資料偏移。匯入的欄位上線後，衰退速度也各不相同。負責人指派、來源歸因、電話號碼，以及任何依賴工作流程或業務代表更新的欄位，通常會最先過時，因此合併與隔離規則需要將這點納入考量。當比對結果明確且資料仍能支援主動作業時，請合併紀錄。當來源不明確、識別碼衝突，或某個欄位會覆寫團隊仍依賴的內容時，請將紀錄隔離。

跨 HubSpot、 Salesforce 與 Pipedrive 對應欄位

欄位對應不只是比對欄位名稱，而是決定來源檔案進入 CRM 後的運作方式。根據平台和匯入途徑，同一組電話號碼可能是電話號碼、潛在客戶識別碼，或用於去除重複資料的訊號。如果判斷錯誤，資料可能在技術上成功匯入，實際運作上卻毫無用處。

平台差異比預期更重要

當你需要 自訂屬性 時， HubSpot 通常較為友善，但這不代表每個欄位都應該成為自訂屬性。如果欄位已經符合標準物件欄位，請使用原生欄位，並將自訂屬性保留給之後需要進行報表分析的來源專屬資料。 Salesforce 通常要求事前更嚴謹，尤其是在使用 Data Loader 或匯入精靈時，這些工具往往要求在開始載入前先準備對應檔案或欄位配對計畫；而 Pipedrive 則會促使你仔細思考某個欄位應該放在人員記錄，還是組織記錄上。

三個平台都適用一項實用規則。擁有者指派、潛在客戶來源歸因 和 生命週期預設值 應在匯入前有意識地設定，而不是之後再由自動化流程推斷。如果匯入的記錄沒有正確的擁有者或階段，你的報表會立即開始偏移。

對於將潛在客戶從登陸頁面移至 HubSpot 的團隊來說，像是 將 Unbounce 潛在客戶與 HubSpot 同步 這類工作流程，說明了在資料開始流動前決定欄位對應有多重要。同樣的邏輯也適用於任何透過表單、 CSV 或整合功能推送至 CRM 的來源系統。

為了重複使用而對應，而不只是完成匯入

最完善的匯入通常會附上一份簡短的對應表，記錄來源欄位、目的地欄位，以及過程中套用的任何轉換規則。當下一批資料來自不同來源、卻使用相同結構時，這一點非常重要，因為對應檔案會成為你的參考依據，而不是靠猜測。

以下是我在實務中採用的決策順序：

1. 先對應必要欄位。 在 CRM 能夠接受該筆記錄之前，先不用擔心選用性豐富資料。
2. 分開人員與公司資料。 在 Pipedrive 中，如果同一份試算表試圖同時處理兩種工作，這個區分很容易出錯。
3. 保留來源歸因。 如果潛在客戶來自網路研討會、資料擷取或豐富資料平台，請保留該數值並使其可見。
4. 將自訂欄位視為報表資產。 如果匯入後沒有人會使用該數值，就不要建立這個欄位。

對於需要記錄潛在客戶欄位邏輯的團隊而言，MapLeads 潛在客戶文件 是一份實用的參考資料，尤其是當來源檔案包含不符合 CRM 原生結構的豐富資料欄位時。

{% youtube id="Lgl_vKT5GAg" /%}

當欄位對應處理得當時，這些記錄在 CRM 中會感覺像原生資料。處理不當時，銷售代表最後會開始詢問，為什麼公司欄位看起來像聯絡人欄位，以及為什麼一半的匯入資料都沒有生命週期階段。

符合您使用情境的去重規則

重複資料處理是匯入作業中最容易被過度簡化的環節。團隊往往喜歡「直接合併重複資料」這個想法，直到合併後的記錄抹除了已驗證的電子郵件、最近的備註，或仍在協助分流的來源歷史。Microsoft 的 Dynamics 匯入指南將重複資料識別視為匯入設定的一部分，而這正是正確的思維方式，因為去重需要一套規則，而不是下意識的反應。由 RingLead 對去重最佳實務所做的另一份檢視，也提出相同的實務重點：應根據來源品質，以及遺失仍具重要性的欄位之風險來制定比對規則。

讓規則符合記錄類型

開發潛在客戶的名單與對合規性敏感的聯絡人名單，不應使用相同的去重門檻。當 ID 比對確定無誤時，開發潛在客戶資料通常更適合使用 覆寫 邏輯，因為目標是保留最新版本的潛在客戶，並避免過時的接觸行動。客戶記錄通常值得使用 合併 邏輯，因為 CRM 中可能已經存有應予保留的備註、歷史活動或支援情境。當信心不足時，邊界比對應歸入 隔離，尤其是在電子郵件相符，但姓名或公司略有差異的情況下。

邊界重複資料不是清理問題，而是決策問題。

使用多個比對訊號

單靠電子郵件有所幫助，但不足以處理混亂的匯入資料。電話、網域和模糊姓名比對，可以找出表面上看似不同，但實際上仍指向同一個人或組織的記錄。真正困難之處在於避免忽略情境的自動合併規則，因為現代 CRM 團隊經常會將經過豐富化的記錄，與現有系統資料一併匯入，而技術上重複的記錄，仍可能帶有來源歷史或已驗證聯絡欄位等獨特價值。

因此，我寧願將少數不確定的比對結果隔離，也不願讓規則合併掉優良欄位。具有相同電子郵件、但電話號碼驗證程度更高的記錄，應該觸發審查，而不是盲目執行。具有重複公司網域、但決策者職稱更新的記錄，可能應該加入 CRM，但不應以合併覆寫的方式取代較舊的聯絡人。

建立簡單的決策架構

• 合併： 比對結果可靠，且舊備註仍具重要性時使用。
• 覆寫： 確定記錄是同一位潛在客戶，且新鮮度優先時使用。
• 隔離： 需要由人工檢查近似比對結果，以避免任何欄位遺失時使用。

如果您是從多個團隊或第三方豐富化服務匯入資料，這就是一個可運作的 CRM 與一個逐漸侵蝕信任的 CRM 之間的差異。良好的去重不只是移除重複資料，更要保存使這筆記錄值得保留的情境。

執行匯入並驗證結果

一次乾淨的匯入作業，其品質會在第一批資料中顯現。我會先進行小規模測試載入，因為如果樣本已經出現遺漏值、欄位錯位或數量錯誤，速度再快也沒有意義。先備份來源 CRM，執行測試批次，然後在擴大作業規模前，將匯入的記錄數量與範例欄位和來源進行比較，正如 以品質為重點的匯入工作流程指南 所建議。

使用受控的推出方式

從測試批次開始，而不是直接匯入完整檔案。如果 CRM 接受這些資料列，請將匯入總數與來源進行比較，並抽查負責人、來源、電話和公司等欄位是否與原始檔案一致。這能找出不易察覺的失敗情況：記錄雖然成功建立，但關鍵值卻是空白，或被移到了錯誤的位置。

如果測試批次看起來不正確，就先停在這裡。修正來源檔案或對應設定，然後重新執行測試，再處理較大的匯入作業。回復備份很重要，因為大型遷移可能會受到平台限制而失敗；匯入規劃也應在執行前納入相容性檢查、欄位配對決策，以及復原路徑。

不要擴大有問題的對應設定。這只會更快建立更多錯誤記錄。

常見的匯入失敗點與快速修正方式

記錄變更內容

維護一份簡單的操作手冊，記錄匯入檔案名稱、日期、CRM 物件、對應規則，以及測試期間發現的任何異常。當有人詢問為什麼某個欄位在遷移後看起來不同時，這份記錄就會成為你的追溯依據；下一批資料到來時，也能節省時間。

對於較大的檔案，請將匯入分割成更安全的區塊，而不是試圖強行讓一個巨大的上傳作業通過系統。目標不是盡可能快速地移動資料，而是在不為下一位人員製造清理專案的情況下完成資料移動。

上線後維持匯入資料的健康狀態

許多組織把匯入品質視為上線任務，然後在一個月後看到 CRM 開始劣化時感到驚訝。這是個錯誤。記錄上線後，匯入的欄位就會立即開始老化，尤其當 CRM 同時由多個來源、資料 enrichment 工具和自動同步機制供應資料時。實用的聯絡人資料庫管理方式，是把 CRM 視為一個持續運作的系統，而不是一次性的檔案傾倒；因此，如果你想從更廣泛的營運角度了解，這份 聯絡人資料庫管理指南 值得一讀。

留意最先衰退的欄位

有些匯入欄位比其他欄位老化得更快。電話號碼、職稱、公司規模和地址通常最先變得不可靠，因為人們會更換職位、企業會搬遷，而聯絡管道也會逐漸失效。如果來源是以地圖為基礎的清單或經擷取的商業目錄，這種衰退可能發生得更快，因為商家資訊、評分、營業時間和認領狀態都可能在匯出後發生變化。

這正是持續進行匯入資料維護的重要所在。如果你的團隊使用像是 MapLeads 銷售團隊 這類來源，匯入的記錄不應僅因為在匯出時已完成驗證，就被視為永久保持最新狀態。即使只是輕量級的重新驗證，也需要建立週期，讓你能在業務代表開始信任錯誤資料之前，更新最可能發生偏移的欄位。

建立簡單的維護循環

每次有新資料進來時，都使用相同的邏輯。重新檢查可聯絡性欄位，確認用於客群分群的公司層級屬性，並檢視那些被隔離或以低信心度合併的記錄。如果某個欄位對分派或外展至關重要，就值得定期檢查。如果它只存在於報表用途，請判斷是否仍有保留的必要。

匯入的資料會隨著時間贏得信任。它不會預設就獲得信任。

這就是一個能協助團隊推進的 CRM，和一個默默製造工作量的 CRM 之間的實際差異。乾淨的匯入在第一天很重要，但匯入資料維護才是讓它們在第三十天和第九十天持續發揮作用的關鍵。

---

如果你想在不從頭重建工作流程的情況下，取得更乾淨的 CRM 匯入資料，MapLeads 可以從 Google Maps、Apple Maps 和 Bing Maps 匯出結構化潛在客戶清單，提供標準化欄位、經驗證的聯絡欄位，以及適合 CRM 的檔案格式。造訪 MapLeads，擷取更容易對應、去重，並在匯入後持續維護健康狀態的清單。