AI電話受付の通知先と通知内容を決める方法

AI電話受付の通知は、メールアドレスやチャットのチャンネルを登録するだけでは完成しません。用件ごとに「誰が次に動くか」「いつまでに確認するか」「未確認ならどこへ回すか」を決めます。通知を送れたことと、担当者が対応したことは別の状態です。

最初に、直近の入電を通常・優先・緊急の三つへ分けると設計しやすくなります。すべてを即時通知にすると、本当に急ぐ用件が日常的な連絡に埋もれます。

用件ごとに通知の目的を決める

通知の目的は、電話の内容を共有することではありません。次の担当者が一つの行動を選べる状態にすることです。その場で案内が完了した電話まで、担当者へ通知する必要はありません。

通常・優先・緊急の定義は、電話受付システムに任せません。取消期限が迫る依頼や設備停止など、自社で影響と対応時間を決めます。AIが判断できない場合は緊急ではないと決め付けず、確認が必要な用件として人へ渡してください。

個人名より役割を通知先にする

通知先を特定の社員一人へ固定すると、休暇や異動で止まります。最初の受信先は「採用受付」「請求担当」「夜間当番」のような役割またはキューにします。その中で、実際に対応する人を一人割り当てます。

一件の受付には、主担当と代替先を一つずつ決めます。部署全員へ同じ通知を送り、誰かが対応する形にはしない方が良いです。複数人が同時に折り返す問題と、全員が誰かに任せる問題の両方が起きるためです。

Amazon Connectのタスク機能は、顧客対応の後続作業を優先付けし、担当者またはキューへ割り当てて追跡できる仕組みです。これは一つの実装例ですが、候補製品でも「通知先へ送る」だけでなく、受信後に担当者を確定できるか確認します。

異動や休暇の変更は、通知設定と当番表へ同時に反映します。個人のメールアドレスが残っていないか、月に一度は一覧で確認した方が良いです。

通知の先頭に次の行動を書く

通知内容は通話要約から始めず、担当者が行うことから始めます。「本日15時までに折り返す」「契約状況を確認して回答する」のように、行動と期限を一行目へ置きます。

その後に、発信者の氏名または会社名と折り返し先を続けます。受付時刻と用件も必要です。

AIが確認できた項目と未確認の項目は分けます。緊急扱いにした場合は、判定理由を書いてください。最後に受付IDと、詳しい受付履歴を開くリンクを付けます。

docomo business ANCAR Voiceの公式発表では、営業時間外などに聞き取った用件や連絡先をテキスト化・要約し、メールなどで担当者へ通知すると案内しています。IVRyの受電通知機能も、用件別の通知先と複数の通知チャネルを案内しています。機能の有無だけでなく、自社の担当者が通知を見て次の行動を選べる内容かを試してください。

全文の文字起こしを、誰でも見られるチャットへ貼る必要はありません。Amazon Connectの通知ガイドは、通知へ個人を特定できる情報を含めず、対象者を絞るよう案内しています。AI電話受付でも、通知本文は必要最小限にし、詳しい記録は権限のある画面で確認する構成が扱いやすくなります。

緊急度に合わせて通知手段を変える

同じ内容を複数の通知手段へ一斉に送ると、三件の仕事が発生したように見える場合があります。受付IDを共通にし、どの通知が正本かを決めます。

日常的な折り返し依頼は、担当者を割り当てられるタスクやCRMを正本にします。チャットやメールは新しいタスクがあることを知らせる入口です。担当者は通知上で対応を終えず、正本の状態を更新します。

優先用件は、担当部署のチャットやプッシュ通知へ即時に送ります。緊急用件は当番者へ直接知らせ、確認がない場合に代替先へ送る仕組みが必要です。案内だけで完了した電話は即時通知せず、集計へ回せます。

Amazon Connectの同ガイドは緊急表示を用意しています。一方で、対象者を狭くして関連する更新をまとめ、通知過多を避けるよう案内しています。緊急通知を目立たせるには、通常通知を減らす運用も必要です。

通知済みと対応完了を分けて残す

通知後の状態は、担当者の行動が分かる粒度にします。「既読」だけでは、内容を読んだ後に何をしたか確認できません。

Amazon Connectは、通話やタスクの状態をイベントとして扱います。キューへ入った時点と担当者へつながった時点、完了した時点を区別できます。公式のコンタクトイベント説明では、イベントがベストエフォートで送られ、順序も保証されないとされています。製品側の通知履歴だけを正本にせず、自社の受付IDと現在状態を保存してください。

担当者が通知を開いた時刻と、対応を始めた時刻も分けます。急ぐ用件では受領までの時間、通常の折り返しでは完了までの時間を見ると、通知と実作業のどちらに滞留があるか分かります。

未確認時の代替先を先に決める

確認期限を過ぎた通知は、同じ宛先へ同じ文章を再送するだけでは改善しません。通常用件は部署の管理者へ、優先用件は代替担当へ、緊急用件は次の当番者へ移します。誰へ回ったかを元の受付へ残します。

通知やタスクの作成そのものに失敗する場合もあります。Amazon Connectのルール実行失敗に関する公式説明では、タスク作成などのアクション失敗をイベントで通知し、原因を確認する方法が示されています。候補製品では、通知先へ届かなかった場合や連携処理が失敗した場合を、どこで確認できるか聞いてください。

代替先へ回すときも、新しい受付を作らず同じ受付IDを使います。元の担当者が後から通知を開いても、すでに別の人が対応中だと分かるようにします。

本番前に七つの通知経路を試す

テストでは、通知が表示された画面だけでなく、担当者の操作後に受付状態が変わるところまで確認します。

1. 通常の折り返し依頼が担当部署へ一件だけ届く
2. 優先用件が通常通知と区別され、担当者を割り当てられる
3. 緊急用件を当番者が確認しない場合に代替先へ移る
4. 担当者の休暇中は通知が別の人またはキューへ届く
5. 通知作成に失敗した場合に管理者が検知できる
6. 同じ受付IDを再処理しても通知とタスクが増えない
7. 完了後に元の受付履歴と対応結果を照合できる

通知本文に含めた情報も確認します。担当者が次の行動を選ぶために不足がないか、公開範囲の広いチャネルへ不要な情報が出ていないかを見ます。

最初に、直近の入電二十件を案内完了・伝言・折り返し・優先・緊急へ分けてください。それぞれに主な通知先、確認期限、未確認時の代替先を一つずつ割り当てます。その上でAI電話受付・電話代行比較表から、用件別通知と対応状態を管理できる候補を確認すると進めやすくなります。