エスカレーションとは、エージェントが対応しきれない場合、人間の担当者に引き継ぐまでの会話のフローのことです。 エージェントが、人間の担当者にエスカレーションすることなくユーザーの問い合わせに対応した場合、これを「偏向」といいます。 理想的な目標は、エスカレーションの回数を減らすことでエージェントの転送率を向上させることです。
Copilot Studio には、エスカレーションに対処する複数の方法があります:
担当者にエスカレーションを依頼する最も直接的な方法は、エスカレーションのシステムトピックを利用することです。 このシステムトピックは、エージェントが顧客のリクエストに対応できなくなり、人間の担当者にエスカレーションする必要がある場合にトリガーされます。 エスカレーション トピックを使用すると、エージェントが会話を、Customer Service 用オムニチャネルなどのサービスデスク ツールへ転送して担当者と直接つなぐライブ転送を行ったり、チケットの作成や折り返し電話の予約など、非同期型のサポート体験を提供したりできるようになります。
このエスカレーションをトリガーするもう 1 つの方法は、作成キャンバスにある会話の転送ノードを使用することです。
エスカレーションの種類
Copilot Studio には 2 種類のエスカレーションがあります。
直接エスカレーション: ユーザーはエージェントにアクセスし、人間の担当者と直接話したいと希望しています。 顧客の意図が直接エスカレート トピックをトリガーすることにあるため、この種のエスカレーションを避けることはできません。
顧客からの問い合わせの例:
- 「人間と話せますか?」
- 「担当者と会話する」
- 「担当者に相談する」
- 「担当者と話す」
間接エスカレーション：ユーザーは会話中に担当者へエスカレーションされます。
こうしたタイプは、予期されるエスカレーションと予期されないエスカレーションの 2 つのカテゴリーに分類されます。
- 予想されるエスカレーションは、会話の途中で話題がエスカレーションするように設計されている場合、あるいはエージェントがユーザーの問い合わせに回答しなかったためにユーザーがエスカレーションを選択した場合に発生します。
- 予期せぬエスカレーションは、エージェントが何らかの問題によるエラーに遭遇した場合に発生します。
トピック エスカレーション分析
この 4 段階のプロセスを使用し、トピックのエスカレーションを分析し、具体的な改善を行う機会を特定してください。
手順 1: トピック パフォーマンスの監視とレビューを行う
組み込みの分析機能またはカスタム分析機能を使用して、エスカレーション率の要因を特定し、最適化してください。
組み込みの分析
エスカレーションや担当者への転送につながったすべてのエージェント セッションは、トピック レベルで最初から最後まで記録されます。 このシナリオのエスカレーション ドライバーは、エージェント トピックです。
分析ダッシュボードには「エスカレーション率の要因」というセクションがあり、どのエージェント対応トピックが最も頻繁に人間の担当者にエスカレーションされるか、またその理由に関する詳細情報が表示されます。 この情報は、チャットの記録から数値的な観点で把握することができます。
たとえば、次のスクリーンショットの場合、エスカレーション率の要因 セクション配下で、返品、交換… トピックの 割合 値は 75% です。 この数値は、返品、交換…というトピックをトリガーとした全セッションのうち、75％ が、エージェントがユーザーの問題を解決できなかったため、人間の担当者にエスカレーションされたことを示しています。 エージェントは返品、交換...トピックの対応を改善し、このトピックからのエスカレーション件数を削減できます。
このチャートには赤や青のバーで 影響 も表示されます。 エスカレーション率影響スコアは、トピックを含む全体のエスカレーション率からトピックを除いた全体のエスカレーション率を引いたものです。 つまり 影響 をもとにして、このトピックが全体的なエスカレーション率に及ぼしている影響について理解できます。 あるトピックの影響が大きい場合は、そのトピックに注力してください。このトピックを改善することで、エスカレーションを減らすことができます。
赤いバーは、そのトピックのエスカレーション率が平均的なエスカレーション率より高く、全体的なエスカレーション率に悪影響を及ぼしていることを示しています。 青色のバーは、エスカレーション率が低くなり、全体的なエスカレーション率パフォーマンスにプラスの影響を与えることを示しています。 赤色で示されているトピックのエスカレーション率を改善すると、全体的なエスカレーション率の改善に非常に大きな影響を与えます。 インパクト スコアは数値ではなく、棒グラフで表示されます。
カスタム分析
会話トランスクリプト データの上に、独自のカスタム分析を構築することもできます。 マイクロソフトは、サンプル レポート テンプレートを提供しています。これの再利用や拡張によって、エスカレーションの主な要因となるトピックを特定し、自社のビジネスや状況に合わせた詳細情報を追加することができます。 例: トピックごとにエスカレーションされたセッション件数が必要な場合。
手順 2: エスカレーションに関する主要なトピックを選択します
一般的な指針としては、エスカレーション率の要因のうち上位 5 ～ 10 のトピックを最初にターゲットとし、偏向率を最適化することです。 大まかな目安として、上位 5 つのトピックそれぞれについてエスカレーション率を 10％ 改善すると、通常、エージェントの全体的な偏向率は約1 ％ 向上します。
手順 3: 選択したトピックに関する会話を確認する
上位のエスカレーション トピックの会話の記録を分析すると、エスカレーションの理由についてより詳細な情報が得られます。 会話のトランスクリプトには、ユーザーの発言や copilot の発言などの形で、やり取りがターンごとに記録されます。また、そのやり取りを引き起こしたトピック名や、セッションの結果 (解決済み、エスカレーションなど) も記録されます。
最もエスカレーションされたトピックについて、結果に基づいてこれらのセッションをフィルターで絞り込み、いくつかの会話例を確認することで、エスカレーションの原因を特定することができます。 このプロセスにより、エスカレーションを引き起こしているパターンを特定することができます。 この作業を定期的に繰り返し、偏向率を向上させ、エスカレーション率を低減し続けてください。
以下の手順ごとのガイドを参考に、チャットのトランスクリプトを分析し、トピックのパフォーマンス向上のための改善策を特定できます。
上位 5 つのトピックから 1 つを選択して、エスカレーションを減らすための改善を行います。
トランスクリプトをフィルターして、エスカレーション のセッション結果で並べ替えます。
会話トランスクリプトで最新のサンプル セットを選択します (例: 10 セッション)。 サンプル セットのサイズは、どの程度の精度を求めるかによって異なります。 手っ取り早く分析を行うには、まずは 10 回のセッションから始めてみてください。
それぞれのセッションを読み込んで、そのトピックに関連した会話で出現する、さまざまな繰り返しの対話パスを特定します。
各セッションで特定されたダイアログ パスを一覧表示し、ダイアログ パスごとにグループ分けします。
各ダイアログ パス グループについて、改善のための提案を特定します。
エージェント トピックの推奨事項を実装し、エスカレーション率と偏向率の変化を観察します。
たとえば、次のセクションで説明する注文状況の確認というトピックの例にこのアプローチを適用すると、以下のようになります。
トピックの説明
注文状況の確認は、注文と配送情報をユーザーに提供することを目的としています。
トランスクリプトの観察
このトピックに関して、エスカレーションで終了した複数の会話記録を確認したところ、エージェントが設計通りに注文情報を提供している場合でも、ユーザーが担当者にエスカレーションすることにつながる対話のフローがいくつか見つかりました。
たとえば、ダイアログパス #1 は、ユーザーが配送物の未着について問い合わせた後、エージェントが注文情報を提供するケースを扱っています。 ダイアログパス #2 は、ユーザーが複数の注文のステータスを確認しようとしている場合を想定しており、エージェントは一度に 1 件の注文のステータスしか提供しません。 ダイアログ パス #1 については、見つからない注文というシナリオに焦点を当てた新しいトピックを追加するとよいでしょう。 ダイアログパス #2 については、セルフ サービス アクションを更新し、1 件だけでなく複数の注文のステータスを表示できるようにすることを検討してください。
会話トランスクリプト レビューの概要
- サンプル セット サイズ: ダウンロードしたトランスクリプトが含むエスカレーションされたセッションのサンプル会話を分析します。 すべてが正しいトピックをトリガーします。 すべてエスカレーションで終了します。
- 想定されるダイアログ パス: OrderInfo アクションに移動し、注文状況をユーザーに提供します。
トランスクリプトのレビューで特定した新しい対話パス
- ダイアログ パス 1: OrderInfo は 注文情報の アダプティブ カード を返すが、ユーザーの問い合わせは荷物の未着に関するものであったため、ユーザーはエスカレーションを決定します (10 回のセッションのうち 7 回)。
- 対話パス 2: OrderInfo アクションは "ご注文には発送が複数含まれます" で応答しますが、すべての注文に対する配送情報を表示していないため、ユーザーはエスカレーションを決定します (10 セッション中 2 件)。
- 対話パス 3: その他 (注文番号の不一致)。ユーザーは、注文番号の入力ミスに気づかなかったため、エスカレーションを決定しました (10 セッション中 1 回)。
対話パス グループごとのレコメンデーション
- パス 1: 受け取っていない注文の処理に関する新しいトピックを追加します。
- パス 2: OrderInfo アクションを強化して、複数の注文配送情報の提供に対応します。
- パス 3: OrderInfo アクションを拡張し、注文 ID の形式を検証し、不正な注文 ID に対してエラーメッセージを表示するようにします。
手順 4: 具体的なトピックについて、的を絞った改善を行う
会話の記録を精査した上で、具体的なトピックについて的を絞った改善を行います。
トピックレベルのエスカレーション率を低減する手法としては、ユーザーが配送状況の確認などの操作を行う際に担当者に頼らなくても済むよう、セルフサービス機能を追加することや、トリガーのパフォーマンスを向上させて、担当者にエスカレーションする代わりにシステムがユーザーに適切なトピックを提示できるようにすることが挙げられます。 これらの改善点には、不足していたトリガー フレーズの追加や、既存のトリガー フレーズの更新が含まれます。
次のステップ
フォールバック クエリや認識されなかったクエリを分析し、新しいトリガー フレーズを追加したり、新しいトピックを作成したりして、エージェントのトピックを充実させる方法について説明します。 こうした取り組みは、混乱を軽減し、認知度を高め、全体的な偏向率の向上に役立ちます。