顧客名簿の重複を整理する：会社・担当者・メールアドレスの分け方

顧客名簿の重複を会社・人・窓口に分けて判定。統合候補表、項目別の残し方、案件と履歴の照合、再発防止の登録ルールを解説します。

顧客名簿の重複整理は、同じ名前を消す作業ではありません。同じ会社の別担当者、同姓同名の人、同じ代表メールを使う人を区別し、残す記録を決める作業です。

一括削除する前に、重複候補を「統合できる」「別の記録として残す」「確認が必要」に分けます。少量でも、この判定を残すことで誤った統合をやり直しやすくなります。

会社・人・窓口のどれが重複しているか確認する

会社の略称と正式名が混在しているなら、会社情報の表記ゆれかもしれません。一方、同じ会社に二人の担当者がいるなら、人物の記録をまとめるべきではありません。

会社名の一致、メールの一致、氏名の一致は、それぞれ候補を探す手掛かりです。一つだけで同一と確定しないようにします。

統合前に、元ファイルまたは対象レコードを書き出して保管します。候補表には元のIDを残し、削除後に「何と何をまとめたか」が分かるようにします。

これは架空の判定例です。確認のために不要な連絡を一斉送信するのではなく、既存のやり取りや手元の情報から判断します。確証がなければ、保留にして先へ進むこともできます。

片方のレコードが新しいからといって、すべての項目が新しいとは限りません。メールは新しいが住所は古い、といった場合があります。

統合前には、氏名、会社、メール、電話、住所、担当者、最終連絡日を項目ごとに見ます。営業メモや履歴は、新しい一行だけを残して他を消す扱いにしないようにします。

CRMの統合機能も、どの値が優先されるか、関連レコードがどう扱われるかを確認してから使います。HubSpotは同じ種類の二つのレコードを統合する機能と、その影響を公式に説明しています。HubSpotのレコード統合

連絡先が一つになっても、以前の案件が片方にだけ関連している可能性があります。統合後は、その顧客に関係する案件、活動履歴、メモ、添付を確認します。

架空例なら、P001に「ロゴ制作」、P017に「名刺追加」の案件がある場合、統合後に両方を参照できるかを見ます。統合前のIDを外部台帳で使っているなら、その参照先も更新が必要か確認してください。

メール連携や外部サービスがある場合、統合が連携先へどう反映されるかも別問題です。取り消し方法を理解できない状態で大量に処理しないようにします。

整理後は、新規登録前に既存検索を行う手順を置きます。社名の略称、全角・半角、法人格の位置などのルールを決めると、候補を探しやすくなります。

ただし、読みやすさのために正式名称を勝手に変える必要はありません。正式名と検索用の略称を分けて持つ方法もあります。個人の名寄せでは、姓の変更や旧連絡先を単純に削除せず、必要な範囲で履歴を残します。

インポート時にも、更新用の識別子を確認します。HubSpotなどでは、メールやレコードIDなどを用いて既存更新を行う方式が案内されています。インポートの識別子

まず明確に統合できる数件を処理し、連絡先と案件の対応を確認します。削除件数が多いことを成果にするのではなく、必要な顧客へ正しく連絡できることを合格条件にしてください。

重複整理が終わったら、件数、処理日、担当者、保留件数を残します。保留をゼロにするために無理に統合する必要はありません。

CRMへ移行する前なら、20件の取り込み確認と合わせて行うと、整理した情報が移行先でも維持されるかを確かめられます。