次の方法で共有


トピックのエスカレーションの分析

エスカレーションとは、エージェントが会話を処理できず、人間の担当者にエスカレーションされた会話フローのことです。 エージェントが人間の担当者にエスカレーションすることなくユーザーの質問に答えることができる場合、それが転送です。 理想的な目標は、エスカレーションの回数を減らすことでエージェントの転送率を向上させることです。

Copilot Studio にはエスカレーションを処理する方法が複数あります。

  • 人間の担当者へのエスカレーションを開始する直接の方法は、エスカレート システムのトピックを介して行われます。 このシステムトピックは、エージェントが顧客の要求に対応できなくなり、担当者にエスカレーションする必要がある場合にトリガーされます。 「エスカレーション」トピックを通じて、エージェントが、ライブ担当者の転送のための Dynamics 365 Customer Service 用オムニチャネルなどの担当者サービスデスクツールや、チケットの作成、コールバックのスケジュール設定などの非同期サポートエクスペリエンスに会話を転送できるようにすることができます。
  • このエスカレーションをトリガーするもう 1 つの方法は、作成キャンバスで会話の転送ノードを使用することです。

会話の転送の選択が表示されたスクリーンショット。

エスカレーションの種類

Copilot Studio には 2 種類のエスカレーションがあります。

  1. 直接エスカレーション:この場合、ユーザーはエージェントにアクセスし、人間の担当者と直接話したいとします。 この種のエスカレーションは、顧客の意図がエスカレーション トピックを直接トリガーすることであるため、避けることはできません。

    お客様からの問い合わせの例:

    • "人間と話せますか"
    • 「担当者と会話する」
    • 「担当者に相談する」
    • "担当者に代わってください"
  2. 間接エスカレーション: この場合、ユーザーは会話中に担当者にエスカレーションされます。

これらは 予期する または 予期しない エスカレーションにグループ化できます。

予期 エスカレーションは、会話のある時点でトピックがエスカレートするように設計されている場合、またはエージェントがクエリに応答しなかったためにユーザーがエスカレーションを選択した場合に発生しますが、予期しない エスカレーションは 、他の問題が原因でエージェントがエラーが発生した場合に発生する可能性があります。

予想されるエスカレーションと予期しないエスカレーションを診断するために使用される 4 つの手順を示す図。

トピックのエスカレーションの分析

ステップ1: トピック パフォーマンスの監視とレビュー

エスカレーション率の要因の特定と最適化は、組み込み分析 または カスタム分析 で実行できます。

組み込み分析

担当者へのエスカレーションまたは転送につながったすべての エージェント セッションは、トピック レベルで最初から最後までキャプチャされます。 このシナリオのエスカレーション ドライバーは、エージェント トピックです。

分析ダッシュボードには「エスカレーション率ドライバー」のセクションがあり、どのエージェントトピックがほとんどの時間、人間の代表者にエスカレーションされたか、またその理由の詳細が表示されます。 この情報は、チャット トランスクリプトをもとにしており、数値的な観点で利用できます。

たとえば、次のスクリーンショットの場合、エスカレーション率の要因 セクション配下で、返品、交換… トピックの 割合 値は 75% です。 つまり、返品、交換...トピックのトリガーとなった全セッションの 75% が人間の担当者にエスカレーションされたことになります。 エージェントはユーザーの問題を解決できなかったため、ユーザーが返品について問い合わせた75%の確率で、エージェントは人間の担当者にエスカレーションする必要がありました。 これで、エージェント作成者は、返品、交換... トピック を改善して、このトピック を通じて発生するエスカレーションの件数を減らすことができます。

このチャートには赤や青のバーで 影響 も表示されます。 エスカレーション率影響スコアは、トピックを含む全体のエスカレーション率からトピックを除いた全体のエスカレーション率を引いたものです。 つまり 影響 をもとにして、このトピックが全体的なエスカレーション率に及ぼしている影響について理解できます。 影響が大きい場合は、トピックに重点を置く必要があります。トピックを改善すると、エスカレーションに与える潜在的な影響も改善されるからです。

赤いバーは、そのトピックのエスカレーション率が平均的なエスカレーション率より高く、全体的なエスカレーション率に悪影響を及ぼしていることを示しています。 青色のバーは、エスカレーション率が低くなり、全体的なエスカレーション率パフォーマンスにプラスの影響を与えることを示しています。 赤色で表示されたトピックのエスカレーション率を下げると、全体的なエスカレーション率の改善に最も大きな影響を与えます (影響スコアは数値ではなく棒グラフで表されます)。

エスカレーション率の要因を強調表示したコパイロット分析のスクリーンショット。

カスタム分析

会話トランスクリプト データに基づいて、独自のカスタム分析を構築することもできます。 Microsoft が提供する サンプル テンプレート レポート の再利用や拡張によって、エスカレーションを引き起こす上位のトピックを特定し、ビジネスやコンテキストに固有のカスタム詳細を追加できます。 例: トピックごとにエスカレーションされたセッション件数が必要な場合。

ステップ 2: 上位のエスカレーション トピックを選択します

一般的なガイダンスでは、転送率を最適化するために、まず エスカレーション率の要因 のうち上位 5 ~ 10 のトピックを対象にします。 大まかに見積もると、上位 5 つのトピックのそれぞれについてエスカレーション率を 10% 改善すると、エージェントの全体的な転送を 1% 改善できます。

エスカレーション率の要因として寄与しているトピックに焦点を当てたスクリーンショット。

ステップ 3: 選択したトピックの会話を確認する

上位のエスカレーション トピックの会話の記録を分析すると、エスカレーションの理由についてより詳細な情報が得られます。 会話のトランスクリプトには、ユーザーが言うコパイロットが言うのように、順番に記録されます。 また、トリガーされたトピック名とセッションの結果もキャプチャします (例: 解決済み、エスカレーション済みなど)。

これにより、エスカレーションの上位トピック の結果に基づき、これらのセッションをフィルターして、いくつかのサンプル会話を確認し、エスカレーションの原因を確認できます。 これは、エスカレーションを引き起こしているパターンを特定するのに役立ちます。 この取り組みを定期的に繰り返すことで、継続的に転送率を改善してエスカレーション率を低下させることができます。

チャット記録を分析して、トピックのパフォーマンスを改善する適切なレコメンデーションを見つけるために使用できる、順を追ったガイダンスを以下に示します。

  1. 上位 5 つのトピックの 1 つを取り上げ、エスカレーションを減らすための改善を行います。

  2. トランスクリプトをフィルターして、エスカレーション のセッション結果で並べ替えます。

  3. 会話トランスクリプトで最新のサンプル セットを選択します (例: 10 セッション)。 サンプル セットのサイズは、どの程度の精度を求めるかによって異なります。 すばやく分析する場合は、10 セッションから開始できます。

  4. それぞれのセッションを読み込んで、そのトピックに関連した会話で出現する、さまざまな繰り返しの対話パスを特定します。

  5. 各セッションで識別された対話パスをリストし、その対話パスごとにグループ化します。

  6. この対話パス グループごとに、改善に役立つレコメンデーションを考え出します。

  7. エージェントトピックの推奨事項を実装し、エスカレーション率と偏向率の変化を観察します。

次のセクションで説明する 注文状態の確認 トピックの例に、上記のアプローチを適用すると、次のようになります。

注文状態確認トピックのスクリーンショット。

トピックの説明

注文状態の確認 は、ユーザーに注文や配送の情報を提供します。

トランスクリプトの観察

エスカレーションで終了したこのトピックの複数の会話トランスクリプトを確認した後、エージェントが設計どおりに注文情報を提供した場合でも、ユーザーが担当者にエスカレーションするように誘導する複数のダイアログパスが出現しています。

ユーザーが不足している出荷について尋ねたときに エージェント が注文情報を提供するダイアログ パス #1 が存在する可能性があります。 また、ユーザーが複数の注文のステータスを探しているのに対し、エージェントは現在一度に1つの注文のステータスのみを提供している別のダイアログパス#2が存在する可能性もあります。 1 番目のダイアログ パスに対するレコメンデーションは、受け取っていない注文 シナリオのみを扱う新しいトピックを追加することであり、一方で 2 番目のダイアログ パスに対するレコメンデーションは、セルフサービス アクションを更新して、1 つだけではなく複数の注文状態を提供することでしょう。

会話トランスクリプト レビューの概要

  • サンプル セット サイズ: ダウンロードしたトランスクリプトが含むエスカレーションされたセッションのサンプル会話を分析します。 すべてが正しいトピックをトリガーしました。 すべてが最終的にエスカレーションしました。
  • 想定されるダイアログ パス: OrderInfo action に移動し、注文状況をユーザーに提供します。

トランスクリプトのレビューで特定した新しい対話パス

  • 対話パス 1: OrderInfo注文情報アダプティブカード で応答しますが、ユーザーは受け取っていないパッケージについて問い合わせているため、ユーザーはエスカレーションを決定します (10 セッション中 7 セッション)。
  • 対話パス 2: OrderInfo アクションは "ご注文には発送が複数含まれます" で応答しますが、すべての注文に対する配送情報を表示していないため、ユーザーはエスカレーションを決定します (10 セッション中 2 件)。
  • 対話パス 3: その他 (注文番号の不一致)。ユーザーは、注文番号の入力ミスに気づかなかったため、エスカレーションを決定しました (10 セッション中 1 回)。

対話パス グループごとのレコメンデーション

  • パス 1: 受け取っていない注文の処理に関する新しいトピックを追加します。
  • パス 2: OrderInfo アクションを強化して、複数の注文配送情報の提供に対応します。
  • パス 3: 注文 ID の形式を検証するように OrderInfo アクションを拡張して、間違った注文 ID に対してエラー メッセージを提供します。

ステップ 4: 選択したトピックに対して的確な改善を行う

会話トランスクリプトのレビュー結果に基づいて、これらの選択したトピックに的確な改善を加えることができます。

トピック レベルのエスカレーション率を下げるために適用できる手法には、セルフサービス機能を追加してユーザーがアクションを人間の担当者に頼らなくても済むようにする (たとえば、出荷状況を確認する)、人間の担当者にエスカレーションする代わりに適切なトピックがユーザーに提示されるようにトリガー パフォーマンスを向上させる (不足しているトリガー フレーズの追加や既存のトリガー フレーズの更新など) などがあります。