AI電話受付の要件定義で決める受付範囲

AI電話受付の要件定義は、電話に応答できるかを決める作業ではありません。用件を正しく受け付け、取次ぎまたは折り返しへ渡し、担当者が次の行動を始められる状態までを決めます。

代表電話には営業と採用、請求の連絡が入ります。既存顧客の相談と緊急連絡も混在します。すべてを同じ会話へ入れると、必要な情報と終了状態が曖昧になります。最初は一つの番号と三つ程度の用件に絞ってください。

この記事では、製品を比較する前に作る要件定義票を扱います。聞き取る項目の数ではなく、受付が正しく終わったかを判定できる受け入れ条件まで書きます。

一つの番号と対象用件を決める

最初に、どの電話番号へかかってくる電話を対象にするか決めます。代表番号と部署直通、時間外専用では発信者が異なるためです。期待される対応も同じではありません。

直近一か月の通話理由を確認します。上位の用件と件数、現在の転送先、折り返しまでの時間を残してください。間違い電話と営業電話も数えると、自動受付の対象外を定義できます。

用件は「問い合わせ」のような大分類で終えません。「請求書の再発行を受け付け、担当部署へ必要情報を通知する」のように、始まりと終了状態を一文にします。

対象外も先に置きます。契約判断と専門的な助言、緊急対応のようにAIが完了させない用件を明記してください。対象外が決まると、受付成功率の分母を候補間でそろえられます。

受付完了を担当者の次の行動で決める

名前と電話番号を聞いただけでは、受付が完了したとは限りません。担当者が通知を見て、誰に何をいつまでに返すか判断できる状態を完了とします。

請求書の再発行なら、会社名と対象月、送付先の確認が必要になる場合があります。採用問い合わせなら、応募職種と連絡方法が重要です。用件ごとに担当者が次の行動へ進むための必須項目を決めます。

終了状態は少なくとも四つに分けます。受付完了と有人取次ぎ、折り返し受付、対象外です。聞き取り不能と途中切断も別に残します。すべてを「受付済み」にまとめると、未処理を一覧から見つけられません。

完了条件には通知の成否も含めます。通話内で聞き取りが終わっても、担当者へ届かなければ業務は完了していません。

聞き取り項目と再確認の上限を決める

聞き取り項目は、多いほど良いわけではありません。用件の分類と次の行動に必要な項目へ絞ります。すでに顧客情報を参照できる場合は、同じ情報を再度話してもらう必要があるか見直してください。

Amazon Connect Customerの問い合わせ属性では、通話ごとの情報をキーと値で保持し、フローや転送で利用します。転送をまたいで共有される属性もあるため、どの情報を後続へ渡すかを要件として決められます。

聞き取れなかった場合は、同じ質問を無制限に繰り返しません。再確認の回数と別の聞き方、人へ切り替える条件を決めます。電話番号やメールアドレスのように誤りの影響が大きい項目は、復唱または別の確認方法を置きます。

不要な自由回答を増やすと、担当者が長い文字起こしから要点を探すことになります。構造化する項目と、そのまま記録する発言を分けてください。

用件分類に不明の出口を用意する

用件分類は、必ず一つへ決める設計にしません。判断できない場合に「その他」や「分類確認待ち」へ送れることが必要です。

似た用件を同じ言葉で尋ねる発信者もいます。「支払いについて」が請求書の再発行なのか、入金確認なのか、契約変更なのかを一度で決められない場合があります。追加質問で分けられる条件を用意します。

分類結果には、用件名だけでなく判断に使った回答を残します。担当者が誤分類を確認し、次回の会話を改善できるためです。製品が確信度を表示する場合も、数値だけで合否を決めず、不明時の処理を確認してください。

受け入れテストには、典型的な言い方だけでなく、曖昧な言い方と対象外用件を入れます。正しい部署へ送ることより、誤った部署へ確定しないことを優先する場面もあります。

取次ぎを不在と満員まで定義する

取次ぎは、転送先へ電話をつないだ時点で完了ではありません。担当者が応答し、用件と聞き取り済み情報を受け取れることを完了とします。

Amazon Connect Customerのキュー転送では、キューが上限へ達した場合と、それ以外のエラーを別の分岐として扱います。コールバックを提示する使い方も案内されています。これは一つの実装例ですが、要件でも満員と設定エラーを同じ結果にしないことが重要です。

転送前に相手へ待ち時間と次の選択肢を案内します。担当者が出なければ、折り返し受付へ変えるのか、別部署へ送るのかを決めてください。保留のまま切断された場合も終了状態へ残します。

取次ぎ失敗時の設計はAI電話受付で取次ぎに失敗したときの対応で詳しく扱います。要件定義票には、取次ぎ成功と失敗後の受付が別に集計できることを書きます。

折り返し受付に期限と担当を付ける

折り返し受付は「伝言を残す」ことではありません。誰が、いつまでに、どの方法で連絡するかを決めます。相手へ案内した期限と、社内の処理期限を一致させてください。

受付には用件と希望時間、優先度、担当部署を残します。担当者が確定しない場合は、部署の共有窓口へ送ります。個人名だけを宛先にすると、休暇や異動で未処理になりやすいためです。

通知後は未確認と確認済み、対応中、完了を分けます。一定時間確認されなければ代替先へ送る条件も必要です。通知の設計はAI電話受付の通知先と通知内容を決める方法へ分けます。

受け入れ条件は、通知メールが送信されたことではありません。担当者が受付を確認でき、期限超過を一覧から見つけられることです。

営業時間外と緊急用件を分ける

営業時間外は、営業時間内と同じ取次ぎ先を使いません。翌営業日の折り返し、伝言のみ、緊急窓口への接続を用件ごとに分けます。

Amazon Connect Customerの営業時間判定には、営業時間内と時間外、エラーの分岐があります。休日などの例外日を別経路へ送る設定も示されています。要件では曜日だけでなく、祝日と臨時休業も扱います。営業時間変更を誰が更新するか決めてください。

緊急用件は、発信者が「緊急」と言っただけで自動転送しない場合があります。対象となる契約や事象、受付時間を自社で定義してください。対象外なら代替窓口を明確に案内します。

時間外の詳細はAI電話受付の営業時間外対応を設計する方法で整理できます。要件定義票では、時間外受付を翌営業日に誰が確認するかまでつなげます。

受け入れ条件を通話シナリオにする

要件定義票を、機能の有無だけで終わらせません。入力と期待する会話を決めます。終了状態と担当者側の表示も一つの通話シナリオにします。

最初の作業は、直近の代表電話を二十件確認することです。用件と聞き取った情報を一行ずつ記録してください。終了状態と担当者の次の行動も残します。

上位三用件を正常と曖昧、失敗のシナリオへ変えます。AI電話受付比較表の候補へ同じ条件を渡してください。