AIコールセンターの応対品質は、月次の平均点を見るだけでは管理できません。通常の通話から一定数を選び、重大な失敗は別枠で全件確認します。会話設定や連携を変えた後の通話も分けて追ってください。

確認で見つけた問題は、起きた工程を特定します。候補は回答、業務処理、有人転送です。一度に直すのは一つです。変更前の版と対象通話を残し、回帰テストと実通話の両方で改善を確認してから完了にします。

応対品質を終了結果から定義する

最初に、対象となる用件を一つ決めます。予約変更なら「変更後の日時が業務システムへ登録され、利用者へ確定内容が伝わった状態」を合格にします。AIが自然に話し、通話を終了できたことだけでは合格になりません。

評価する範囲は、会話と業務処理を分けます。会話では用件を正しく理解し、根拠のある案内をしたかを見ます。業務処理では予約や受付が正しい顧客へ反映されたかを確認します。有人転送が必要な通話は、適切な理由で切り替え、担当者へ必要な情報を渡せたかを評価してください。

Amazon Connect Customerの評価機能は、人による応対だけでなく、ボットやAIエージェントの自動応対にも独自の評価基準を設定できます。録音と文字起こしを同じ画面で確認できます。要約と分析も参照し、個別の応対から集計へ進める構成です。

自社の評価票にも通話IDと用件を残します。合格または不合格だけでなく、どの事実を根拠に判断したかを記録してください。業務システムの処理結果も同じIDへ関連付けると、会話が正しくても処理に失敗した通話を見分けられます。

三つの枠から確認対象を選ぶ

全件を同じ深さで人が確認すると、件数が増えたときに続きません。一方、無作為抽出だけでは、頻度が低く影響の大きい失敗が選ばれない場合があります。確認対象を通常枠、重要枠、変更枠へ分けます。

通常枠は、主要な用件と時間帯から偏りなく選びます。音声認識が難しい通話や短時間で終了した通話も含めてください。応対が成功した通話だけを選ぶと、改善すべき分岐が見えません。

重要枠は、誤案内や本人取り違えなどの重大事例です。苦情と緊急判定の失敗も対象にします。誤転送や業務処理の二重実行、同じ用件での再問い合わせも、件数が少なくても優先して確認してください。

変更枠には、会話設定や参照情報を変えた後の通話を入れます。辞書と転送条件、連携項目の変更も対象です。Amazon Connect Customerの自動応対評価は、AIエージェントの版や用件、処理結果などの条件で評価対象を指定できると案内しています。自社でも、どの版で応対した通話かを抽出条件へ加えます。

一枚の評価票で失敗した工程を分ける

評価票は、印象を点数へ置き換えるものではありません。直す工程を特定するために使います。会話と処理を分けてください。有人連携と記録も別の工程にすると、同じ失敗を複数の設定で直さずに済みます。

会話では、用件の理解と回答の根拠を確認します。不明な内容を断定しなかったかも見ます。

処理では、顧客と入力値、完了状態を業務システムで照合してください。有人連携では切り替え理由と接続結果を分けます。記録では、要約から次の担当と期限を判断できるかを見ます。

Amazon Connect Customerの評価フォームでは、対象外を許す設問や条件付き設問を作成できます。重要度に応じた重みと、自動回答を上書きできる仕組みもあります。自社の評価票でも、本人確認が不要な用件に本人確認の点数を付けないようにします。

AIによる自動評価を使う場合も、最初から人の確認をなくしてはいけません。自動評価が答えられなかった通話と、人が判定を変えた通話を残します。評価処理自体の失敗も監視対象です。Amazon Connect Customerの公式文書には、分析ファイルの取得失敗や回答不能によって自動評価が失敗する例が示されています。

評価者の判断を同じ通話で校正する

評価基準を書いても、担当者によって点数が変わることがあります。「丁寧だった」「適切に転送した」のような表現は、判断する人の経験に左右されるためです。月に一度は同じ通話を複数人で評価します。

点差が出た設問は、平均を取って終わらせません。録音と処理結果へ戻り、合格となる事実を一文で書き直します。「適切に転送した」なら「本人確認ができない場合に指定キューへ転送し、確認済み項目を渡した」のようにします。

Genesys Cloudの校正機能は、同じ応対を複数の評価者が確認し、点数の一貫性をそろえる目的で使われます。設問ごとの判断差を見つけ、専門の評価者を基準にできます。評価者を責めるためではなく、設問の曖昧さを直すために使う考え方です。

校正後に評価票を変更した場合は、適用日と版を残します。旧版の点数と新版の点数を同じ推移へ混ぜると、品質が変わったのか基準が変わったのか分からなくなります。集計には評価票の版も含めてください。

一つの原因だけ直して変更版を残す

不合格の通話を見つけたら、まず発生した工程を決めます。質問を理解できなかったなら、語彙や用件分類が候補です。正しく理解して誤答したなら、参照情報や回答制約を見直します。業務システムへの登録だけが失敗した場合は、会話ではなく連携処理を確認します。

一度に会話文と辞書、転送条件を変えると、どの変更が効いたか判断できません。対象通話と原因仮説を一つ選び、変更内容と担当者、適用日時を記録します。元へ戻す条件も変更前に決めてください。

Dialogflow CXの版と環境に関する公式文書は、編集途中の草稿ではなく変更不能な版を本番へ使うことを推奨しています。開発環境と試験環境を本番から分けます。問題があれば前の版へ戻せます。本番中の会話がある状態で版を切り替える場合に、状態の不整合が起こる可能性も示しています。

製品に版管理がない場合は、自社で変更履歴を残します。会話設定と参照資料のファイルを保存し、通話記録へ版番号を付けます。CRM連携や転送先の設定も同じ変更票へまとめると、問題が再発したときに実際の状態を再現できます。

回帰テストと実通話で改善を閉じる

変更後は、問題となった一通話だけを再現して終わらせません。修正した用件が合格することに加え、以前合格していた用件が壊れていないかを確かめます。これが回帰テストです。

Dialogflow CXのテストケースは、シミュレーターで行った会話の意図と処理を期待値として保存できます。遷移も記録し、更新後に再確認できます。継続テストの公式文書では、環境に登録したテストケースを定期実行し、悪い版が公開される前に検証する仕組みが案内されています。

試験では、正常系だけでなく言い換えと聞き返しを入れます。有人転送と担当者不在、業務処理の失敗も再現してください。重大な失敗へつながった会話は、再発防止の固定ケースとして残します。

自動試験が通った後は、変更枠の実通話を確認します。音声認識や回線状態、利用者の言い回しはシミュレーターだけでは再現しきれません。合格した通話数だけでなく、同じ失敗が再発していないことを録音と業務結果で確かめます。

最初の一週間は、通常枠と重要枠、変更枠から通話を選びます。一枚の評価票で失敗工程を分け、原因を一つだけ修正してください。回帰テストと変更後の実通話がともに合格し、同じ失敗が再発しなければ改善を完了にできます。