Zendesk Exploreのチケットタイプ属性の使い方

Zendesk Explore（ゼンデスク エクスプローラ）のチケットタイプ属性は、どれほどの洞察を引き出せるかに気づくまで見過ごされがちな機能の1つです。ほとんどのサポートチームはチケットのボリュームと解決時間を追跡していますが、処理しているチケットのタイプを掘り下げているチームは少数です。それは機会損失です。

チケットタイプの分布を理解すると、パターンを見つけることができます。チケットの60％が実際には、より良いドキュメントで対応できる簡単なQuestion（質問）ですか？特定の期間中にIncident（インシデント）が急増していますか？Problem（問題）チケットは、リンクされたIncident（インシデント）が積み重なっている間、未解決のままですか？

このガイドでは、Zendesk Explore（ゼンデスク エクスプローラ）の属性チケットタイプをレポートで使用する3つの実践的な方法について説明します。基本的な概要を作成する方法、経時的な傾向を追跡する方法、特定のチケットタイプのフィルタリングされたレポートを作成する方法を学びます。自動化でこれをさらに進める方法についても見ていきます。

必要なもの

レポートの作成を開始する前に、基本事項が整っていることを確認してください。

• Zendesk Explore Professional（ゼンデスク エクスプローラ プロフェッショナル）またはEnterprise（エンタープライズ） - Lite（ライト）プランでは、属性を使用したカスタムレポートはサポートされていません
• Explore（エクスプローラ）の編集者または管理者権限 - 閲覧者はレポートを作成または変更できません
• 異なるタイプのチケットがすでに作成されている - レポートを有意義にするには、Question（質問）、Incident（インシデント）、Problem（問題）、Task（タスク）チケットを混在させる必要があります

1つ簡単な説明：「チケットタイプ」属性は、ここで説明しているのは、4つの固定値を持つ標準のZendeskフィールドです。これは、作成した可能性のあるカスタムチケットフィールド（「製品カテゴリ」や「問題タイプ」など）とは異なります。カスタムフィールドには独自のアプローチがあり、カスタムチケットフィールドに関するZendesk Explore（ゼンデスク エクスプローラ）のレシピガイドで説明しました。Zendeskの標準フィールドの詳細については、チケット属性に関するZendeskの公式ドキュメントを参照してください。

4つのチケットタイプを理解する

Zendeskでは、4つのチケットタイプを使用できます。それぞれがサポートワークフローで異なる目的を果たします。

**Question（質問）**は、ほとんどのチケットのデフォルトのタイプです。一般的な問い合わせ、ハウツーリクエスト、および他のカテゴリに当てはまらないものに使用します。これらは通常、1つの回答または簡単なやり取りで解決されます。

**Incident（インシデント）**は、緊急の注意が必要な問題に使用します。システムの停止、重大なバグ、または複数のユーザーに影響を与えるものと考えてください。Incident（インシデント）はProblem（問題）チケットにリンクできるため、個々のユーザーへの影響と根本原因の両方を追跡できます。

**Problem（問題）**は、複数のIncident（インシデント）の背後にある根本原因を表します。Problem（問題）チケットを特定したら、Incident（インシデント）をそれにリンクできます。これにより、影響を受けるすべてのユーザーに一度に更新を伝え、問題全体の解決の進捗状況を追跡できます。

**Task（タスク）**は、期日付きのアクション可能なアイテムに使用します。フォローアップ、スケジュールされた作業、または特定の時間までに実行する必要があるものに使用します。Task（タスク）は、ビューに期日が強調表示されて表示されます。

チームにこれらのタイプを一貫して使用させるのが難しい点です。ほとんどのチケットはデフォルトでQuestion（質問）になり、エージェントは時間をかけて再分類しません。しかし、習慣を身につけることができれば、レポートは大幅に役立ちます。Incident（インシデント）を緊急キューに自動的にルーティングしたり、Problem（問題）の解決にかかる時間を追跡したり、セルフサービスへの取り組みが実際にQuestion（質問）を減らしているかどうかを測定したりできます。

レシピ1：基本的なZendesk Explore（ゼンデスク エクスプローラ）属性チケットタイプレポートを作成する

基礎から始めましょう。このレシピでは、各タイプのチケット数を示すシンプルなテーブルを作成します。

ステップ1：Zendesk Explore（ゼンデスク エクスプローラ）で、Reports（レポート）アイコンをクリックし、**New report（新しいレポート）**をクリックします。

ステップ2：**Support（サポート）** > **Support - Tickets（サポート - チケット）**を選択し、**Start report（レポートを開始）**をクリックします。Tickets（チケット）データセットには一般的なチケット情報が含まれており、このタイプの概要に適しています。

ステップ3：**Metrics（メトリック）**パネルで、**Add（追加）**をクリックし、Tickets（チケット） > **Tickets（チケット）**を選択し、**Apply（適用）**をクリックします。これにより、すべてのチケット数が表示されます。

ステップ4：**Filters（フィルター）**パネルで、**Add（追加）**をクリックし、**Time created - Date（作成時間 - 日付）**を選択し、期間を設定します。構築中にタイムアウトを防ぐために、過去30日間などの短い期間から始めます。範囲はいつでも拡大できます。

ステップ5：**Rows（行）**パネルで、**Add（追加）をクリックし、属性リストでTicket type（チケットタイプ）**を見つけて、**Apply（適用）**をクリックします。属性は、カスタムフィールドセクションではなく、Tickets（チケット）フォルダの下にあります。

ステップ6：**Visualization type（視覚化タイプ）がまだTable（テーブル）**に設定されていない場合は、設定します。Question（質問）、Incident（インシデント）、Problem（問題）、Task（タスク）と、それぞれのチケット数が表示されます。

**ステップ7：**レポートに「チケットタイプの内訳」などのわかりやすい名前を付けて、**Save（保存）**をクリックします。

この基本的なレポートは、「チケットの何パーセントがIncident（インシデント）ですか？」または「Problem（問題）チケットをまったく使用していますか？」などの質問に答えます。95％がQuestion（質問）で、他のタイプがほとんどない場合は、チームがチケットを一貫して分類していないことを示しています。

レシピ2：チケットタイプの傾向を経時的に分析する

次に、チケットタイプが月ごとにどのように変化するかを見てみましょう。これは、パターンを見つけ、プロセス変更の影響を測定するのに役立ちます。

ステップ1：**Support - Tickets（サポート - チケット）**データセットを使用して、新しいレポートを作成します。

ステップ2：**Tickets（チケット）**メトリックをレポートに追加します。

ステップ3：**Columns（列）**パネルで、**Add（追加）**をクリックし、**Ticket created - Month（チケット作成 - 月）**を選択します。これにより、日付範囲内の各月の列が作成されます。

ステップ4：**Rows（行）**パネルで、**Ticket type（チケットタイプ）**を追加します。これで、マトリックスができました。チケットタイプが行、月が列です。

**ステップ5：**好みに応じて、**Visualization type（視覚化タイプ）をColumn（列）またはLine（線）**に設定します。列はボリュームの比較に適しており、線は傾向を把握しやすくします。

**ステップ6：**日付フィルターを調整して、少なくとも3〜6か月をカバーします。これより短い期間では、ランダムな変動ではなく、実際の傾向を特定するのが難しくなります。

**ステップ7：**レポートに「月ごとのチケットタイプの傾向」などの名前を付けて保存します。

このレポートを使用して、次のような質問に答えます。前回の製品リリース後にIncident（インシデント）が増加していますか？ナレッジベースの更新により、実際にQuestion（質問）が減少しましたか？Problem（問題）チケットの解決にかかる時間は、時間の経過とともに長くなっていますか？視覚的な形式により、これらのパターンは生の数字ではわからない方法で浮かび上がります。Zendesk Explore（ゼンデスク エクスプローラ）での傾向分析の詳細をご覧ください。

レシピ3：特定のチケットタイプでレポートをフィルタリングする

特定のチケットタイプを分離して、より深く分析したい場合があります。計算されたメトリックを使用すると、これを行うことができます。

ステップ1：**Support - Tickets（サポート - チケット）**データセットを使用して、新しいレポートを作成します。

ステップ2：**Calculations（計算）**メニュー（電卓アイコン）をクリックし、**Standard calculated metric（標準計算メトリック）**を選択します。

**ステップ3：**メトリックに「Incident tickets only（インシデントチケットのみ）」などの名前を付けます。

**ステップ4：**数式フィールドに次のように入力します。

この数式は、Explore（エクスプローラ）に、タイプがIncident（インシデント）のチケットのみをカウントするように指示します。IFステートメントを使用した計算メトリックのその他の例については、Zendeskの計算メトリックガイドを参照してください。

ステップ5：**Save（保存）をクリックします。新しいメトリックがCalculated metrics（計算メトリック）**フォルダに表示されます。

**ステップ6：**計算されたメトリックをレポートに追加します。同じ数式パターンを使用して、Problem（問題）およびTask（タスク）チケットの同様のメトリックを作成できます。

**ステップ7：**これらのメトリックを他のフィルターと組み合わせます。たとえば、**Ticket group（チケットグループ）**をRows（行）パネルに追加して、どのチームが最も多くのIncident（インシデント）を処理しているかを確認します。または、**Ticket channel（チケットチャネル）**を追加して、Incident（インシデント）が主にメール経由で発生しているか、チャット経由で発生しているかを確認します。

このアプローチは、特定のワークフローに焦点を当てたダッシュボードを作成する場合に役立ちます。Incident（インシデント）ダッシュボードには、解決時間、エージェントのワークロード、エスカレーション率が表示され、すべてIncident（インシデント）チケットのみにフィルタリングされます。Problem（問題）チケットダッシュボードでは、リンクされたIncident（インシデント）と根本原因の修正までの時間を追跡できます。

一般的な問題とトラブルシューティング

明確な手順を踏んでも、うまくいかない場合があります。最も一般的な問題の解決方法を次に示します。

チケットタイプが属性リストに表示されない チケット属性を含むデータセットを使用していることを再確認してください。**Support - Tickets（サポート - チケット）**データセットには間違いなく含まれています。カスタムデータセットまたは別のデータソースを使用している場合、属性が利用できない可能性があります。また、適切な権限を持っていることを確認してください。閲覧者は常にすべての属性を表示できるとは限りません。

データが存在することがわかっているのに、結果が空である 最初に日付フィルターを確認してください。先月「作成された」チケットは、先月「解決された」チケットまたは先月「更新された」チケットとは異なります。質問に適した日付フィールドでフィルタリングしていることを確認してください。また、チケットにQuestion（質問）以外のタイプが実際に割り当てられていることを確認してください。すべてのチケットがQuestion（質問）の場合、Incident（インシデント）でフィルタリングしても何も返されません。

過去のデータに予想と異なるタイプが表示される チケットタイプは遡って変更できます。エージェントがチケットをQuestion（質問）からIncident（インシデント）に更新すると、Explore（エクスプローラ）は過去のレポートでもその変更を反映します。これは通常、必要なこと（正確な現在の分類）ですが、チケットが作成時にどのタイプであったかを追跡しようとしている場合は混乱する可能性があります。

Incident（インシデント）チケットにリンクされたProblem（問題）チケットが表示されない Incident（インシデント）とProblem（問題）の間のリンクは、チケットタイプ自体とは異なる方法で保存されます。リンクされたチケットをレポートするには、チケットタイプだけでなく、**Ticket problem ID（チケット問題ID）**属性を使用する必要があります。この属性は、Incident（インシデント）がリンクされているProblem（問題）チケットを示します（存在する場合）。

レポートのタイムアウトまたは「ネットワークエラー」 データセットが大きすぎます。より短い時間フィルター（過去30日間ではなく、過去7日間を試してください）を追加するか、より多くのフィルターを追加して結果を絞り込みます。チケットのボリュームが多く、日付範囲が長い場合、Tickets（チケット）データセットは非常に大きくなる可能性があります。

さらに進む：eesel AI（イーゼルAI）でチケット分類を自動化する

手動によるチケットタイプの分類はボトルネックを生み出します。エージェントは忙しく、すべてのチケットを分類するのに時間がかかると、応答時間が遅くなります。しかし、一貫した分類がなければ、レポートは不十分になります。

ここで自動化が役立ちます。eesel AI（イーゼルAI）では、チケットの内容を読み取り、自動的に分類するAIエージェントを構築しています。エージェントにチケットタイプを選択するように依頼する代わりに、AIは件名と説明を分析して、何かがQuestion（質問）、Incident（インシデント）、Problem（問題）、またはTask（タスク）であるかどうかを予測します。AI Triage（AIトリアージ）製品は、この分類を大規模に処理します。

実際の動作は次のとおりです。

• チケットが「システムダウン - ダッシュボードにアクセスできません」という件名で届きます
• AIはコンテンツを読み取り、緊急度インジケーターと影響範囲を特定します
• チケットをIncident（インシデント）として分類し、緊急キューにルーティングします
• また、優先度レベルを提案し、すぐに注意が必要なものとしてフラグを立てます

AIは既存のチケットから学習します。過去のデータでトレーニングすると、誤分類を修正するにつれて、時間の経過とともに改善されます。ほとんどのチームは、数週間のトレーニング後、80％以上の精度を実現しています。

Zendesk統合を通じて、これを既存のZendeskワークフローに接続できます。AIは、チケットフィールドの更新、タグの追加、特定のグループへのルーティング、さらにはチケットのタイプと内容に基づいて初期応答の草案を作成できます。

チケットタイプレポートの作成と維持に多大な時間を費やしている場合は、AIエージェントが役立つかどうかを検討してください。当社のプラットフォームはチケットの内容を自動的に読み取り、手動による分類なしに、そのデータに基づいて洞察を生成したり、アクションを実行したりできます。さらに進みたいチームは、カスタマーサービス向けのAIソリューションをご覧ください。

Zendesk Explore（ゼンデスク エクスプローラ）でチケットタイプの分析を開始する

チケットタイプ属性は、重要な洞察を引き出すことができるシンプルなツールです。現在の分布を理解するには、レシピ1から始めます。そのベースラインができたら、レシピ2に進んで時間の経過に伴う傾向を追跡します。集中的な分析が必要な場合は、レシピ3の計算されたメトリックを使用すると、特定のチケットタイプを掘り下げることができます。

一貫したチケットタイプの使用が基礎となります。チームが今日チケットを分類していない場合は、そこから始めます。大まかな分類でも、何もしないよりはましです。どのレポートが実際に意思決定を促進するかを確認しながら、時間の経過とともにプロセスを改善できます。

クリーンなデータが得られたら、レポートは強力になります。以前は見えなかったパターンを見つけ、プロセス変更の影響を測定し、人員配置と優先順位についてより多くの情報に基づいた意思決定を行うことができます。

次のステップに進み、チケット分類を自動化する準備ができたら、eesel AI（イーゼルAI）をお試しください既存のZendeskセットアップでどのように機能するかを確認してください。