顧客・問い合わせ・予約の重複は、完全にはなくなりません。
メールと電話で別々に登録される、フォーム送信が二重になる、担当者が異なる入口から同じ顧客を登録する、同姓同名の別人が混ざる。こうしたことは、日常の業務で普通に起こります。
重複を放置すると、二重対応、対応漏れ、集計のズレにつながります。
一方で、マージを強くしすぎると、別人や別案件を誤って統合してしまい、元に戻す作業が必要になります。
この記事では、重複が起きる前提で、同一判定、候補提示、マージ手順、権限、履歴、ロールバックをどう設計するかを整理します。
重複には種類があります。
顧客、問い合わせ、予約を同じ考え方で統合しようとすると、判断が粗くなります。
同一人物・同一法人と判断できる場合、履歴や案件を主レコードへ紐付けます。
電話、メール、フォームなど、別入口の連絡を同じ案件として確認できるようにします。
二重予約や同姓同名を検知し、必要に応じて確認・キャンセル・変更につなげます。
受付チャネル横断の考え方は 電話・メール・フォームの統合 とセットで見ると、重複が「入口の違い」なのか「本当に別件」なのかを判断しやすくなります。
誤った統合を避けるには、自動マージを強いキーに限定します。
氏名や社名の部分一致だけで統合すると、別人や別会社をまとめてしまう可能性があります。
基本は、自動統合、候補提示、統合しない、の3段階に分けます。
| 判定区分 | 条件例 | 扱い |
|---|---|---|
| 自動統合可 | 会員ID、顧客番号、完全一致のメールアドレス、外部システムの一意ID | 事前ルールに合う場合だけ自動で統合。ただしログは必ず残す。 |
| 候補提示 | 電話番号＋氏名、住所の一部一致、法人名＋部署名、車両番号＋電話番号など | 画面上で候補として出し、人が確認して確定する。 |
| 自動NG | 氏名のみ一致、社名の部分一致、同姓同名、家族名義、共用メールアドレス | 自動統合しない。必要なら関連候補として弱く表示する。 |
この判定は、検索・絞り込みの導線とも関係します。 マージ対象を確認しやすい画面にするには、一覧の検索・フィルタ（絞り込み導線）を合わせて検討しておく必要があります。
マージで重要なのは、データを消すことではありません。
どのレコードを主データにするかを決め、問い合わせ、予約、履歴、添付ファイルなどの参照先を付け替え、統合前の情報も確認できるようにします。
登録日：2026/04/20
メール：yamada@example.jp
電話：090-0000-1111
登録日：2026/05/02
メール：yamada@example.jp
電話：090-0000-1111
問い合わせを親チケットにまとめる場合は、ステータス設計 と合わせて、どの問い合わせを主にするか、どの履歴を関連扱いにするかを決めます。 予約の場合は、枠の競合が関係するため、空き表示 の考え方と合わせて確認します。
現場担当者がスマホで確認する画面では、いきなりマージ操作まで出すよりも、「同じ顧客・同じ予約の可能性があります」と知らせる方が安全です。
統合は管理画面側で行い、現場画面では確認・保留・担当者への連絡に留める構成が扱いやすくなります。
5月12日 10:30 / タイヤ交換 / 山田 太郎
5月12日 10:00 / タイヤ交換 / 山田太郎
予約では、同一人物であっても「同じ予約」とは限りません。 家族分の予約、別車両の予約、同じ法人内の別担当者などもあるため、現場画面では即時統合より確認を優先します。
マージ操作では、誤って統合する可能性があります。
そのため、統合後に元の状態を確認できない、参照を戻せない、統合前の値が残っていない、という設計は避けるべきです。
最低限、次の情報を残します。
メール、電話、顧客番号などをもとに重複候補を検出します。
主レコード、採用する値、統合理由を画面上で確認します。
問い合わせ、予約、履歴などを主レコードへ紐付けます。
統合前の値、操作ログ、ロールバック用の情報を残します。
権限とログは 権限・ログ設計 を前提に、マージ実行は管理者のみ、候補確認はスタッフでも可能、といった分け方が現実的です。 誰でも統合できる状態にすると、誤操作時の影響が大きくなります。
マージ機能だけでは、重複の発生そのものは減りません。
入力・送信・検索・運用の段階で、重複を減らす打ち手も合わせて入れておくと、確認作業を減らしやすくなります。
メールや電話番号を入力した時点で、既存候補を出します。
二重送信防止、受付番号表示、確認メールで重複送信を減らします。
候補一覧、保留、担当者確認、マージ履歴を管理画面で扱います。
不動産では、同じ人がポータル、電話、自社フォームから複数回問い合わせることがあります。
この場合、顧客マスタは安全側に統合しつつ、反響や内見希望は履歴として残す構成が向いています。
業務像は 不動産向け を前提に、反響〜内見の導線（関連：取りこぼし防止）をチケットで束ねると確認しやすくなります。
自動車販売・整備・タイヤショップでは、電話予約の後にWeb予約が入る、家族名義で申し込まれる、同じ顧客が複数台の車両を持っている、といった重複が発生します。
顧客だけでなく、車両単位での紐付けも考える必要があります。
業務像は 自動車販売・整備・タイヤショップ向け を前提に、入庫管理の考え方（入庫予約）と合わせると、顧客と車両の関係を設計しやすくなります。
重複データは、発生する前提で設計する必要があります。
自動統合は会員ID、顧客番号、完全一致のメールアドレスなど強いキーに限定し、それ以外は候補提示に留める方が安全です。
強いキーだけを自動対象にし、氏名一致などは候補提示にします。
統合前の値、採用した値、参照付け替え先、操作理由を保存します。
誤統合に備え、参照付け替え一覧とロールバック用の情報を残します。
マージの中心は、データ削除ではなく、主レコードの決定、履歴の保持、参照付け替えです。 権限、ログ、ロールバックまで決めておけば、現場も安心して重複候補を確認できます。
重複を完全になくすよりも、見つけやすく、確認しやすく、戻せるようにする。 この前提で設計すると、二重対応や集計のズレを減らしながら、誤統合のリスクも抑えやすくなります。