重複した問い合わせを整理する｜同じ人と同じ用件を分けて照合する

人の一致と用件の一致を区別する

同じ人が請求について質問した翌日に、新しい商品の相談をすることがあります。メールアドレスの一致だけで一件へまとめると、別の仕事が消えます。連絡先、受付日時、対象商品、注文番号、質問の要点を見て、同一の用件か判断します。「同じ人」「同じ用件」「判定できない」を分け、候補抽出と統合を同じ処理にしません。

候補と正本のIDを残す

受付IDQ-401とQ-408が同じ注文についての追加連絡なら、正本IDと関連受付IDを記録します。古い行を削除するのではなく、関連済みとして通常の未対応一覧から外します。受付日時、元の本文、添付資料、送信経路はそれぞれ残します。顧客が追加した新しい情報を、古い本文で上書きしないことが大切です。

照合に使う値を安全に整える

比較用のメールアドレスや注文番号は前後の空白を除いて照合します。ただし元の値も残し、顧客の自由記述を一律に短縮しません。会社名が似ているだけ、氏名が同じだけ、問い合わせの文が似ているだけなら統合しない基準を決めます。共通の代表アドレスを使う会社では、担当者や案件が異なる場合もあります。

統合後の担当と返信を一つにする

同じ用件と確認できたら、担当者、次の返信期限、参照する本文を決めます。重複候補の両方へ自動返信を続けると別々の担当が対応を始めることがあります。正本側に追加情報を案内し、関連側には正本IDと確認者を残します。顧客へは社内の重複判定を詳しく説明するより、質問を受け取り同じ担当が進める旨を伝えます。

誤ってまとめた場合に分離できるようにする

統合前の担当、状態、期限を残しておけば、別の用件だったと分かったときに戻せます。復旧では関連を外し、元のIDで案件を再開し、止めていた通知や返信待ちを確認します。履歴を丸ごとコピーすると重複が増えるため、元の受付データを再利用します。統合操作の日時と理由も残し、後から削除で辻褄を合わせないようにします。

重複率より見落としを確認する

確認用には同じ人の別用件、同じ用件の別経路、同姓同名、共通アドレス、添付だけの追加連絡を用意します。統合した件数だけを成果にすると、まとめ過ぎが見えなくなります。別用件を消していないか、追加資料を失っていないか、正本の返信期限が変わっていないかを確認します。候補一覧は顧客情報を扱える担当者に限定します。

Q-401とQ-408：追加資料を残して関連付ける

確認用のQ-401は商品の寸法についての質問、Q-408は同じ注文番号と追加写真を含む連絡とします。担当者が同じ用件と確認したら、Q-408の写真と受付日時を残したままQ-401へ関連付けます。正本の返信期限は、追加資料が届いたからといって無条件に延ばしません。一方、Q-410が同じ顧客の請求書の質問なら別案件として残します。後から写真が別商品のものだと分かった場合は関連を外し、Q-408を元のIDで再開します。この動きを確認できれば、重複の整理と履歴の消去を混同せずに済みます。元データを残すことが、誤った判断から戻るための条件になります。

候補を確認する一覧では、一致した理由を表示します。メールアドレスが同じ、注文番号が同じ、本文が似ているといった根拠を分けると、担当者が判断しやすくなります。文字の一致が少なくても同じ用件の場合があり、一致率をそのまま統合の決定にしません。確認者と確認日を残し、未確認の候補が通常の受付から消えないようにします。候補が多過ぎる場合は条件を緩めて自動処理を増やすのでなく、対象経路や期間を絞って確認します。統合前後に受付の総数を照合すると、整理の途中で行を消してしまった問題にも気づきやすくなります。

道具と費用を増やす前に確認する

件数が少ない間は、候補を並べて担当者が確認するだけでも十分です。自動照合を増やすなら、候補抽出、確認、復旧にかかる時間を別々に見積もります。Makeなどの処理回数だけで安さを判断せず、誤統合の修正時間も含めます。少数の例で誤判定が多い場合は、条件を増やすより自動統合を止める方が扱いやすくなります。

• Airtableで問い合わせ管理表を作る｜受付・担当・対応状況の設計
• MakeとAirtableを連携する方法｜受付データの検索・追加・更新
• Webhookの重複・順序・再実行｜自動化の受け取り仕様を作る