インポート時の連絡先照合
インポートを適用する前に更新案を確認します。
誤った一致は、見える重複より深刻なことがある
似た名前の顧客を誤って同じ人物として扱うと、一方の履歴が別の人に結び付くおそれがあります。Tsumiraの担当者取込は、似た表記をすべて同一人物とみなすのではなく、明確な識別情報を使います。重複を減らしながら、何に基づいて更新を提案しているのかを、確認する人が理解できるようにします。
より確かな連絡先から照合する
担当者取込では、まずメール、次に正規化した電話番号で既存の担当者を探します。メールの比較は大文字と小文字を区別せず、電話はCRM共通の正規化を使います。表示名だけより役立つことが多い一方、確認は必要です。共通の代表電話や再利用されたメールには、固定ルールでは分からない事情があります。予想外の更新が出た場合は、プレビューで対象を確認してください。
- 大文字小文字を区別しないメール比較
- 正規化した電話の比較
- 更新予定の確認
氏名と読みの比較を、意図的に限定する
連絡先で既存担当者が見つからない場合、氏名と読みを両方、完全一致で比較します。異体字、旧姓、同じ発音の人物を広く同一と判断する保証ではありません。読みがない場合は取込時の警告付きの代用として扱います。限定されたルールにより、実装にない人物識別能力を宣伝するのではなく、結果の理由を説明できるようにしています。
- 氏名と読みの完全一致
- 異体字を一律に解決する保証ではない
- 推測した読みではなく警告
既存データと同じファイル内の両方を確認する
取込計画は、既存担当者を照合しながら、計画された新規担当者も照合対象へ加えて進みます。同じファイルの後の行に同じ連絡先が現れた場合、新しい人物を増やすのではなく、先に計画した担当者へ対応できます。それでも結果は確認すべき計画です。誤った情報がつながる場合は元データや列の対応を直し、適用後にも重要な担当者を確認してください。
- 既存担当者との照合
- 同一ファイル内の繰り返しへの対応
- 適用前に読める変更計画
具体的な業務の流れ
確かな識別情報を用意する
元の資料に正しく含まれるメールや電話の列を準備します。存在しない情報は補いません。
列の意味を確認する
氏名、読み、連絡先が意図した項目に対応しているか確認します。
一致の予定を確認する
意外な更新があれば、同じ連絡先が本当に同じ人物を指すか確かめます。
確認した計画を適用する
不明点を解消してから適用し、代表的な担当者レコードを点検します。
実務を想定した例
利用例：同姓同名の担当者
異なる会社に同じ表示名の担当者がいて、それぞれのメールが違う場合を考えます。取込を確認する人は名前だけで同一人物とせず、識別情報と計画を見ます。一方、同じ既存顧客が同一メールで二度現れた場合は、繰り返しとして照合できます。最終的な更新内容が業務上正しいかどうかは、チームが確認します。
この機能についての質問
重複が絶対に発生しない保証ですか。
いいえ。対応する処理の中で使う明確な照合ルールです。識別情報の不足や変更、多義的なデータには、人の判断が必要な場合があります。
異体字を読みだけで一致させますか。
担当者取込の最後の氏名比較は、氏名と読みの両方の完全一致です。読みだけで異なる表記を広く統合するという説明ではありません。
複数の人が同じ代表電話を使う場合はどうしますか。
更新予定をよく確認してください。正規化は電話の書式を比較しやすくしますが、共有番号が特定の一人を指すかまでは決められません。
あらゆるレコードを一括統合する機能ですか。
いいえ。このページは取込に使う担当者照合を説明しています。すべてのCRMレコードを別の一括整理機能で自動統合できると解釈しないでください。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
