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

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

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

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

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

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

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

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

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

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

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

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

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

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

請求書の再発行依頼を受ける記入例

以下は、AIが請求情報を回答せず、担当部署へ依頼を渡す架空の設計例です。番号や本人確認方法は実際の契約・業務に合わせて決めます。

この例では「電話に出た」「依頼を受け付けた」「担当者が受領した」「再発行した」は別の結果です。どの段階までをAIサービスへ依頼するかを契約前にそろえます。

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

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

Amazon Connect Customerの問い合わせチェーンの属性には、転送後も共有する属性と通話区間ごとの属性があります。製品の実装は異なりますが、訂正後の値を後続へ渡せるかは共通して確認したい条件です。

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

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

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

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

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

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

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

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

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

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

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

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

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

折り返し受付は「伝言を残す」ことではありません。誰が、いつまでに、どの方法で連絡するかを決めます。社内の受領期限と顧客へ約束した連絡期限は別の項目です。顧客に時刻を約束した場合は、その期限に間に合う社内期限を設定してください。

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

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

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

通知の失敗も実演対象にします。試験用の通知先を無効にし、受付がどこへ残るかを見ます。Amazon SNSのデッドレターキューは配信できなかったメッセージを保存する仕組みですが、別途設定が必要です。「自動再送がある」という回答だけでは、保存や復旧を保証できません。受付の保存先、再処理する人、重複を防ぐ方法まで確認します。

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

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

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

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

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

同時着信と録音の条件を見積もりへ渡す

同時通話数は、AI受付と回線、取次ぎ先を分けて聞きます。AIが10件を受けても、転送先が2件までなら残る電話の出口が必要です。この数字は設計上の例で、製品の仕様や推奨値ではありません。

候補には通常時だけでなく、最も集中する時間帯の件数と通話時間を渡します。たとえば15分に30件、平均受付2分なら、その区間の受付量は60通話分です。平均では4件分の同時処理に相当しますが、4回線で足りるという意味ではありません。到着の集中と長い通話、転送中に占有する回線を含めて試験します。

同時着信を実演できない場合は、負荷試験の件数・時間・転送率を提示してもらいます。自社条件との差と、上限を超えたときの話中・待ち呼・折り返しへの切り替えを記録してください。

録音と文字起こし、要約も一つの成功状態にまとめません。TwilioのVoice Webhooksでは、通話の状態と録音の処理状態を別に通知します。録音が利用可能になる前でも、担当者が受付内容を確認できるかを試します。生成失敗時の表示と再処理、閲覧・出力・削除の権限は候補の仕様書で確認してください。

見積もりは同じ条件で、通常月と混雑月、時間外受付を含む月を分けます。番号と受電の基本費用に加え、AI応対や転送の従量料金を確認します。通知・記録・設定支援が別料金になるかもそろえてください。費目と計算方法はAI電話受付の料金を受付業務から比較する方法で確認できます。

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

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

最初の商談では、次の3本を同じ順番で実演してもらいます。固有名詞は架空のものを使い、個人の連絡先を試験へ持ち込みません。

会話中の認識表示だけで合格にせず、受付票と担当者側の通知を照合してください。2本目でAIが「9月」と言っていても、通知に8月が残れば不合格です。

基本の3本が通った後に、時間外・祝日・臨時休業を試します。転送先の満員と設定エラーも分けて再現してください。通知先の無効化や録音生成失敗を加え、会話が終わった後の処理まで確認します。

試験結果には受付IDと設定版、期待値、実際の値を残します。実演できなかった条件は「対応可能」の口頭回答と分け、試験未確認としてください。

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

上位三用件を正常と曖昧、失敗のシナリオへ変えます。AI電話受付比較表の候補へ同じ条件を渡してください。返答には記録画面と仕様書の該当箇所を添えてもらいます。追加費用も書面で確認すれば、機能の丸印だけで比べるより契約後の認識違いを減らせます。