Zendesk Exploreでエージェントの返信を追跡する方法：完全ガイド

エージェントがチケットに何回返信したかを追跡することは、品質保証、エスカレーションワークフロー、およびチケットの複雑さを理解するのに役立ちます。ただし、Zendesk（ゼンデスク）の用語は紛らわしい場合があります。エージェントの返信、エージェントのコメント、およびチケットのタッチは似て聞こえますが、測定するものは異なります。

このガイドでは、Zendesk Explore（ゼンデスク エクスプローラ）でエージェントの返信を正確に追跡する方法について説明します。各メトリックの意味を明確にし、必要なレポートを作成する方法を示し、どのデータセットを使用するかを説明します。

返信数に基づいてアクションを自動化する方法をお探しの場合は、eesel AIがZendesk（ゼンデスク）と統合して、返信ベースのワークフローを処理する方法についても説明します。

必要なもの

レポートの作成を開始する前に、以下を確認してください。

• Zendesk Explore Professional（ゼンデスク エクスプローラ プロフェッショナル）またはEnterprise（エンタープライズ）：レポート機能は下位のプランでは利用できません。
• Zendesk Explore（ゼンデスク エクスプローラ）の編集者または管理者権限
• Zendesk Support（ゼンデスク サポート）のチケットデータ：分析するには既存のチケットが必要です。
• Zendesk（ゼンデスク）データセットの知識：Tickets（チケット）とUpdates history（更新履歴）の違いを理解しておくと役立ちます。

エージェント返信メトリックについて

Zendesk（ゼンデスク）の用語に関する混乱を解消しましょう。3つのメトリックは似て聞こえますが、測定するものは異なります。

エージェントの返信 vs エージェントのコメント vs チケットのタッチ

ほとんどのサポートチームが求めているメトリックは**エージェントの返信 (Agent replies)**です。これは、顧客メッセージへの公開返信のみをカウントし、内部メモや最初のチケット作成はカウントしません。数式は簡単です：(Agent replies)。

**エージェントのコメント (Agent comments)**は、Updates history（更新履歴）データセットにあり、公開コメントをカウントします。返信が発生したタイミングでフィルタリングする必要がある場合は、これを使用します。

**エージェントのタッチ (Agent touches)**は、最も広範なメトリックです。コメントの追加、フィールドの変更、ステータスの更新、チケットの再割り当てなど、エージェントが実行するあらゆる操作が含まれます。これは、エージェントの全体的な作業負荷を測定するのに役立ちますが、会話パターンを分析するのには適していません。

出典：Zendesk Help - Zendesk Supportのメトリックと属性

ワンタッチ、ツータッチ、およびマルチタッチチケット

Zendesk Explore（ゼンデスク エクスプローラ）は、必要なエージェントの返信数によってチケットを分類します。

• ワンタッチチケット (One-touch tickets)：1つのエージェントの返信のみで解決
• ツータッチチケット (Two-touch tickets)：2つのエージェントの返信で解決
• マルチタッチチケット (Multi-touch tickets)：3つ以上のエージェントの返信で解決

これらのメトリックは、チケットの複雑さとエージェントの効率を示すため重要です。ワンタッチチケットの割合が高い場合は、通常、セルフサービスとエージェントのトレーニングがうまく機能していることを意味します。マルチタッチチケットが多い場合は、複雑な問題、不明確なドキュメント、またはより多くの手助けを必要とする顧客を示している可能性があります。

チケットが再オープンされ、エージェントが別のコメントを追加すると、タッチ数が増加することに注意してください。ワンタッチチケットはツータッチチケットになります。

出典：Zendesk Help - Exploreでエージェントのチケットタッチを分析する

ステップ1：適切なデータセットを選択する

Zendesk Explore（ゼンデスク エクスプローラ）には複数のデータセットがあり、間違ったデータセットを選択することはよくある間違いです。選択方法を次に示します。

次のような場合は、Tickets（チケット）データセットを使用します。

• エージェントの合計返信数などのチケットレベルのメトリック
• 返信ブラケット（ワンタッチ、ツータッチ、マルチタッチ）
• チケットのステータス、優先度、または担当者による分析

次のような場合は、Updates history（更新履歴）データセットを使用します。

• 返信が発生したタイミングでフィルタリングする
• エージェントアクティビティの時間ベースの分析
• 公開コメントと内部メモを区別する

Updates history（更新履歴）データセットには、より詳細なデータが含まれているため、レポートの実行に時間がかかる場合があります。数千件のチケットを分析する場合は、日付フィルターを追加してパフォーマンスを合理的に保ちます。

ステップ2：基本的なエージェント返信レポートを作成する

チケットごとのエージェント返信数を示す簡単なレポートを作成しましょう。

1. Zendesk Explore（ゼンデスク エクスプローラ）で、レポート (Reports) アイコンをクリックします。
2. 新しいレポート (New report) をクリックします。
3. Support（サポート） > Tickets（チケット） データセットを選択し、レポートを開始 (Start report) をクリックします。
4. メトリック (Metrics) パネルで、追加 (Add) をクリックします。
5. リストからエージェントの返信 (Agent replies) を選択し、適用 (Apply) をクリックします。
6. 行 (Rows) パネルで、追加 (Add) をクリックします。
7. 各チケットを識別するために、チケットID (Ticket ID) とチケットの件名 (Ticket subject) を追加します。
8. チケットを処理した担当者を確認するために、担当者名 (Assignee name) を追加します。
9. フィルター (Filters) パネルで、追加 (Add) をクリックします。
10. チケットのステータス (Ticket status) を追加し、アクティブな作業に焦点を当てたい場合は、クローズ (Closed) チケットを除外します。

レポートに、エージェントの返信数とともに各チケットが表示されるようになりました。[エージェントの返信 (Agent replies)] 列で並べ替えて、最も多くのやり取りが行われたチケットを見つけることができます。

ステップ3：チケットごとの平均返信数レポートを作成する

次に、1日あたりのエージェントごとの平均返信数を確認するための計算メトリックを作成しましょう。これは、チーム全体の効率を比較するのに役立ちます。

1. Support（サポート） > Updates history（更新履歴） データセットを使用して、新しいレポートを作成します。
2. 計算 (Calculations) > 標準計算メトリック (Standard calculated metric) をクリックします。
3. 「1日あたりのチケットごとの平均エージェント返信数 (Average agent replies per ticket per day)」という名前を付けます。
4. 次の数式を入力します。

D_COUNT(Agent comments)/D_COUNT(Tickets updated)

5. 保存 (Save) をクリックします。
6. メトリック (Metrics) パネルで、新しい計算メトリックを追加します。
7. 集計関数をAVGに設定します。
8. 行 (Rows) パネルで、更新者名 (Updater name) と更新 - 日付 (Update - Date) を追加します。
9. コメントの種類 (Comment type) = 公開 (Public) および更新者の役割 (Updater role) = 管理者、エージェント (Admin, Agent) のフィルターを追加します。

このレポートには、エージェントごとのチケットあたりの平均返信数が日ごとに表示されます。これを使用して、傾向を特定し、トレーニングの機会を見つけ、最も効率的なエージェントを認識します。

出典：Zendesk Help - エージェントごとの1日あたりのチケットあたりの平均返信数

ステップ4：返信ブラケットを分析する

返信の分布を理解することは、プロセス改善を特定するのに役立ちます。返信数でチケットをグループ化するレポートを作成しましょう。

Tickets（チケット） データセットを使用する場合：

1. 新しいレポートを作成します。
2. ワンタッチチケット (One-touch tickets)、ツータッチチケット (Two-touch tickets)、およびマルチタッチチケット (Multi-touch tickets) メトリックを追加します。
3. 行 (Rows) パネルにチケット解決 - 月 (Ticket solved - Month) を追加して、時間の経過に伴う傾向を確認します。
4. チケットグループ (Ticket group) または担当者 (Assignee) を追加して、チーム間で比較することを検討してください。

または、より柔軟性を高めるためにUpdates history（更新履歴） データセットを使用する場合：

1. 「公開エージェントの返信 (Public Agent Replies)」および「公開エージェントの返信があるチケット (Tickets with Public Agent Replies)」の計算メトリックを作成します。
2. 「公開エージェントの返信ブラケット (Public Agent Reply Brackets)」という名前の計算属性を作成します。
3. 次の数式を使用します。

IF (ATTRIBUTE_FIX(COUNT(Public Agent Replies), [Ticket ID])=1)
THEN "1 Agent Reply"
ELIF (ATTRIBUTE_FIX(COUNT(Public Agent Replies), [Ticket ID])=2)
THEN "2 Agent Replies"
ELIF (ATTRIBUTE_FIX(COUNT(Public Agent Replies), [Ticket ID])=3)
THEN "3 Agent Replies"
ELIF (ATTRIBUTE_FIX(COUNT(Public Agent Replies), [Ticket ID])>3)
THEN "4+ Agent Replies"
ELSE "0"
ENDIF

4. 計算元 (Computed from) をチケットID (Ticket ID) に設定します。
5. 計算属性を行 (Rows) パネルに追加します。
6. 「公開エージェントの返信があるチケット (Tickets with Public Agent Replies)」メトリックを追加します。

これにより、各返信ブラケットに該当するチケットの明確な内訳が表示されます。

出典：Zendesk Help - エージェントの返信ブラケットに関するレポート

エージェント返信追跡の一般的なユースケース

サポートチームがこれらのメトリックを使用する実際的な方法を次に示します。

品質保証 (Quality assurance)：過度のやり取りがあるチケットを特定します。チケットに5つ以上のエージェントの返信がある場合は、複雑な問題、混乱した顧客、または支援を必要とするエージェントを示している可能性があります。これらのチケットは、QAレビューに適しています。

エスカレーションワークフロー (Escalation workflows)：返信数を使用して、自動エスカレーションをトリガーします。たとえば、3つ以上のエージェントの返信があるチケットは、上級エージェントまたはマネージャーに通知するように設定できます。

エージェントのパフォーマンス (Agent performance)：チーム全体のチケットあたりの平均返信数を比較します。低い方が常に良いとは限りません（一部のチケットでは詳細な説明が必要です）が、どちらかの端にある外れ値には注意が必要です。

チケットの複雑さの分析 (Ticket complexity analysis)：どの種類の問題がより多くのやり取りを必要とするかを追跡します。請求に関する質問の平均が4つ以上の返信で、パスワードのリセットの平均が1つの場合、セルフサービスの改善に焦点を当てる場所がわかります。

ヒントとベストプラクティス

• 日付フィルターを早めに追加します (Add date filters early)。Updates history（更新履歴）データセットは非常に大きくなる可能性があります。他の属性を追加する前に、日付でフィルタリングして、レポートの応答性を維持します。

• チケットチャネルを検討してください (Consider ticket channel)。音声チケット（電話）は、メールとは異なる動作をします。「ワンタッチ」音声チケットには、通話自体で問題が解決されたため、エージェントの返信がゼロになる場合があります。

• チケットの再オープンを考慮してください (Account for ticket reopening)。解決済みのチケットが再オープンすると、返信数のカウントが継続されます。最初の解決前に3つの返信があった場合でも、チケットには合計5つの返信が表示される場合があります。

• ワンタッチ率を監視してください (Watch your one-touch rate)。業界のベンチマークは異なりますが、多くのサポートチームは60〜70％のワンタッチ解決を目指しています。低いレートが必ずしも悪いとは限りません（複雑な製品ではより多くのやり取りが必要になります）が、時間の経過に伴う傾向を追跡します。

• 返信数だけを使用しないでください (Don't use reply counts alone)。1つの返信があるチケットは、優れている（完璧な回答）場合もあれば、ひどい（失礼な拒否）場合もあります。定量的なメトリックと定性的なQAを組み合わせます。

eesel AIでエージェント分析をさらに進める

Zendesk Explore（ゼンデスク エクスプローラ）はデータを提供しますが、それに基づいて行動するには多くの場合、手作業が必要です。そこで、AIチームメイトが役立ちます。

eesel AIは、Zendesk（ゼンデスク）と直接統合して、返信ベースのワークフローを自動化します。返信数をレポートするだけでなく、次のことができます。

• 特定の返信数を超えたらチケットを自動的にエスカレーションする
• AIを使用して会話の質を分析し、感情と解決の可能性を理解する
• 手動でタグ付けせずに、会話パターンに基づいてチケットを分類する
• チケットが高タッチになるリスクがある場合にプロアクティブなアラートを取得する

違いは、Explore（エクスプローラ）は何が起こったかを示し、eesel AIは自動的にそれに基づいて行動するのに役立つことです。ルールをわかりやすい英語で定義すると（「チケットに3つ以上のエージェントの返信があり、顧客の感情が否定的な場合は、上級エージェントにエスカレーションする」）、eeselが残りを処理します。

レポートの確認とチケットの手動エスカレーションに毎週何時間も費やしている場合は、AIチームメイトを検討する価値があるかもしれません。