FIELD NOTE / 受付・振り分け
同じ用件の再入電を見分ける｜新規案件との判定基準
再入電を別案件として散らさないために、顧客・対象・用件・期間を照合し、元案件へ追加する条件と新規に分ける条件を整理します。
最初に押さえること
電話番号だけで同じ案件と決めず、顧客、対象、用件、前回の未完了状態を照合してから、元案件への追記か新規作成かを選びます。
1. 「同じ顧客」と「同じ案件」を分けて考える
同じ人から再び電話があっても、前回と同じ案件とは限りません。顧客IDや確認済みの連絡先は記録を探す手掛かりですが、注文と修理、予約と請求のように対象や目的が違えば、別案件として管理した方が経緯を追いやすくなります。反対に、連絡先が違っても受付番号と対象が一致するなら、同じ案件の続きである可能性があります。
受付では、顧客、対象の商品・契約・予約、用件、前回の連絡時期、未完了の次の行動を順に照合します。本人確認が必要な情報は、自社の正式な手順を完了するまで表示・案内しません。曖昧な段階で既存案件へ統合せず、候補として保留できる状態も用意します。
2. 再入電判定ルールを、担当者の記憶から表へ移す
以下は架空の窓口で使う判定例です。一項目の一致だけで自動的に統合せず、対象と用件が一致し、前回案件に未完了の行動があるかを重く見ます。迷う場合は新規案件を作って関連IDを残し、責任者が後から統合要否を確認できるようにします。
| 照合結果 | 受付時の扱い | 記録すること |
|---|---|---|
| 顧客・対象・用件が一致し、前回が回答待ち | 元案件へ再入電として追加 | 再入電日時、今回の質問、顧客への次回案内 |
| 顧客は一致するが対象または用件が異なる | 新規案件を作成 | 元案件IDは参考リンクにとどめる |
| 受付番号は一致するが本人確認が未完了 | 詳細を開示せず確認保留 | 確認した項目と未確認理由 |
| 一致候補が複数ある | 統合せず責任者へ確認 | 候補ID、対象、発生日、判断期限 |
3. 元案件には、今回増えた事実だけを時系列で足す
再入電を元案件へ結び付ける場合も、前回の記録を上書きしません。今回の発言、受付者が確認した事実、未確認事項、顧客へ伝えた予定を日時付きで追加します。前回の案内と食い違うときは、どちらかを消さず、差異と確認先を残すことで訂正の経緯を追えます。
担当者へ渡す通知には、顧客が再び電話した事実と、約束していた期限への影響を含めます。ただし、再入電の回数だけで緊急度を決めると、単なる追加情報と重大な遅延を混同します。期限、影響、顧客の希望を分けて記録し、優先度は運用ルールに従って判断します。
4. 分散と誤統合の両方を定期的に点検する
改善時は、新規として作られた後に同一案件と分かった件数だけでなく、誤って統合したため別の依頼を見落とした例も確認します。検索に使えなかった項目、顧客が覚えていなかった番号、担当者によって判断が分かれたケースを集め、判定表の質問順と保留条件を更新します。
CRMや案件管理ツールに自動候補表示を入れる場合も、候補の理由を受付者が確認できるようにします。電話番号の一致だけで自動統合せず、権限、本人確認、監査履歴を含む実際の設定は利用中のシステムと社内ルールで確認してください。
よくある質問
電話番号が同じなら、同じ案件としてよいですか？
電話番号は検索の手掛かりですが、共有番号や代理連絡もあります。対象、用件、時期、前回の未完了状態を照合し、本人確認が必要な場合は正式な手順を完了してから紐付けます。
同じ案件か判断できないときはどうしますか？
無理に統合せず、新規または確認保留として記録し、候補の案件IDと判断期限を残します。後から責任者が統合しても、元の受付履歴が消えない運用にします。
参考資料・この記事の位置づけ
本文の帳票や進め方は、ContactXによる運用設計の提案です。効果を保証する数値や、特定企業の導入実績ではありません。
- Amazon Connect：Casesによる顧客案件の管理
複数回のやり取り、対応手順、結果を一つの案件として追跡する考え方を確認するための一次資料。記事中の項目名・状態・記入例はContactXによる架空の運用設計です。
- Amazon Connect：機能概要
電話・チャット等の窓口、履歴共有、ケース管理の機能例を確認するための一次資料。以下の運用表はContactXによる設計例です。