重複問い合わせ・二重申込を統合する設計｜同一人物判定と運用フローの作り方

問い合わせ管理が混乱する原因のひとつが「同じ人が何度も送ってくる」問題です。
送信ボタンの連打、通信エラー、家族が別端末で申し込む、フォームが複数ある、メールでも来る…。
重複が増えると、担当が二重に動き、返信が食い違い、顧客体験が悪化します。
この記事では、重複を“削除”ではなく“統合”として扱う設計を、判定・運用・ログまで含めて整理します。

1. 同一人物判定は「強いキー」と「弱いキー」を分ける

同一人物判定を完璧にするのは無理です。だからこそ、キーを強弱で分けます。

• 強いキー：メールアドレス、会員ID、予約番号（あれば）
• 中くらい：電話番号（表記ゆれ注意）、郵便番号＋住所
• 弱いキー：氏名のみ、会社名のみ（誤判定が多い）

フォーム側の入力ゆれを減らすには、入力最適化（UIパターン）や、即時バリデーション（設計）が効きます。
「電話番号のハイフンは自動整形」「全角→半角」など、判定が安定する前処理が重要です。

2. 二重送信は“入口で止める”と“統合で吸収する”を併用する

入口で止められるものは止めるべきです。
ただし、入口対策だけではゼロになりません。運用として統合を用意します。

• 入口対策：二重送信防止（ボタン無効化、トークン）＋エラー時の案内
• 統合対策：同一人物判定で「関連あり」を出し、担当がまとめて扱う

入口の文言は、サンキューページ（メッセージ例）とセットで設計します。
「送信できたか不安で連打する」を減らすだけで、重複率は下がります。

3. 統合モデル：削除しない。親チケット＋子チケットで履歴を残す

重複を削除すると、後から「送ったのに無視された」と言われたときに追えません。
実務では、次のどちらかが回りやすいです。

• 親子方式：親（代表）に統合し、子（重複）を紐づけて残す
• マージ方式：メッセージを統合ログとして親に吸収（原文も参照できる）

どちらにしても、統合した操作ログ（誰が、いつ、なぜ）を残す必要があります。
ログ設計の基本は 権限・ログ設計 の考え方で、恣意的に消せない形に寄せます。

4. 担当割当：統合後に“窓口”を1人に固定する

重複の怖さは、担当が分かれて返信が食い違うことです。
統合したら、担当は原則1人（窓口）に固定します。割当ロジックは 自動・手動・混在 と整合させるのが安全です。

• 親チケットの担当＝窓口担当
• 子チケットは担当を持たず、親に従属
• 統合されたことをチーム内に通知（“二重返信”を防ぐ）

SLA運用がある場合は、親の期限で管理する（SLA設計）と、重複のせいで期限が増殖しません。

5. 重複の原因を“タグ”で残すと改善に回せる

重複は、原因を潰すと減ります。原因分類をタグ化（タグ設計）し、集計（レポート）に回します。

• 送信後画面が分かりにくい
• 通信エラー／タイムアウト
• フォームが複数あって迷う
• 返信が遅くて再送する

返信が遅いが原因なら、フォローアップ設計（メール文面）や、一次回答期限（SLA）の整備が効きます。

業種別での典型

不動産（反響・内見）

ポータル経由、電話、フォーム、メールが混ざり、重複が多い領域です。業務像は 不動産向け を前提に、
同一人物判定のキー（電話・メール）を強化し、内見予約（導線）と反響管理を統合して扱うと混乱が減ります。

自動車販売・整備・タイヤショップ

電話予約とWeb予約が並走しやすく、重複が起きやすいです。業務像は 自動車販売・整備・タイヤショップ向け を前提に、
車両情報（ナンバー下4桁等）を“弱い補助キー”として使うと、同姓同名の誤判定を減らせます（ただし個人情報の扱いは 同意設計 と整合させます）。

まとめ

重複はゼロにできません。だからこそ、入口で減らしつつ、統合で吸収する設計が必要です。
同一人物判定は強いキー中心にし、統合は削除せず親子で履歴を残す。担当窓口を固定し、原因タグをレポートに回せば、重複は“事故”ではなく改善材料になります。