Zendesk Exploreの「解決済みチケット数」メトリクスの使い方：完全ガイド
Stevia Putri
最終更新 February 26, 2026
Zendesk Explore (ゼンデスクエクスプローラー) を見て、「解決済みチケット」をカウントしているように聞こえる2つの異なるメトリクスがあるのはなぜだろうと思ったことがあるなら、それはあなただけではありません。「解決済みチケット」と「解決チケット数」の区別は、経験豊富な管理者でさえ混乱させます。それを間違えると、レポートは、サポートキューで実際に起こっていることとはまったく異なるストーリーを語ることになります。
詳しく見ていきましょう。このガイドでは、これら2つのメトリクスの重要な違い、それぞれの使用時期、およびチームのパフォーマンスを実際に反映する正確なレポートを作成する方法について説明します。
| ユースケース | 使用するメトリクス | データセット |
|---|---|---|
| 担当者別の現在のワークロード | 解決済みチケット | チケット |
| 今日/今週解決されたチケット数 | 解決チケット数 | チケット |
| 経時的な傾向（作成数と解決数） | 解決チケット数 | 更新履歴 |
| SLAコンプライアンスの追跡 | 解決チケット数 | 更新履歴 |
| 担当者のパフォーマンスレビュー | 目標による | どちらか |
結論は？傾向を追跡したり、経時的なパフォーマンスを測定したりする場合は、ほとんどの場合、更新履歴データセットの解決チケット数を使用します。解決済みのワークロードの現在のスナップショットが必要な場合は、チケットデータセットの解決済みチケットを使用します。
手動でのレポート作成を超えて進みたいチームのために、データセットや数式を使用せずにこれらの洞察を提供する自律的な解決追跡を提供しています。
レポートに適したデータセットの選択
Zendesk Explore (ゼンデスクエクスプローラー) はデータをデータセットに整理します。間違ったデータセットを選択することは、混乱を招く結果を得るための最も早い方法です。次に、決定方法を示します。
チケットデータセット：現在の状態とスナップショットの場合
チケットの現在のステータスを知りたい場合は、これを使用します。履歴の変更なしに、一般的なチケット情報が含まれています。
- 最適：現在のワークロード、オープンチケット数、バックログ分析
- 時間属性：チケット作成日、チケット解決日（最新）、チケット更新日
- 主要なメトリクス：解決済みチケット、未解決チケット、解決済みチケット - 過去7日間
更新履歴データセット：経時的な変更を追跡する場合
このデータセットは、チケットに加えられたすべての変更を記録します。これはイベントベースであり、何がいつ発生したかを追跡することを意味します。
- 最適：傾向分析、作成数と解決数のレポート、担当者のアクティビティ追跡
- 時間属性：更新タイムスタンプ（変更が発生した日時）
- 主要なメトリクス：チケット作成数、チケット解決数、担当者の更新、コメント
バックログ履歴データセット：履歴スナップショットの場合
これは、特定の日付に存在した未解決チケットの数を示しています。Explore (エクスプローラー) は、データの同期時に毎回このデータを収集します。
- 最適：経時的なバックログの増加または減少の理解
- 制限：リアルタイムではなく、同期ポイントからのデータのみをキャプチャします
簡単な意思決定フレームワーク
自問してください：私はどのような質問に答えようとしていますか？
- 「現在、解決済みのチケットは何件ですか？」→チケットデータセット
- 「今週解決したチケットは何件ですか？」→更新履歴データセット
- 「バックログの傾向はどうですか？」→バックログ履歴データセット
- 「チケットの量に対応できていますか？」→更新履歴データセット（作成数と解決数）
作成数と解決数のチケットレポートを作成する方法
これは、サポートチームが最も必要とするレポートの1つです。水面下で苦労しているのか、遅れをとっているのか、それとも先に進んでいるのかを示します。次に、その作成方法を示します。
ステップ1：更新履歴データセットで新しいレポートを作成する
Explore (エクスプローラー) に移動し、レポートアイコンをクリックして、新しいレポートをクリックします。「データセットの選択」ページで、サポート > サポート - 更新履歴を選択し、レポートを開始をクリックします。
ステップ2：メトリクスを追加する
[メトリクス]パネルで、[追加]をクリックします。リストから、次を選択します。
- チケット > チケット作成数
- チケット > チケット解決数
次に、[適用]をクリックします。
なぜこれらのメトリクスを一緒に使用するのですか？チケット作成数は、流入量を示します。チケット解決数は、流出量を示します。解決数が一貫して作成数を超える場合、バックログは減少しています。作成数が解決数を超える場合、キューは増加しています。
ステップ3：日付フィルタリングを構成する
[フィルター]パネルで、[追加]をクリックします。時間 - チケット更新 > 更新 - 年を選択し、[適用]をクリックします。
追加した更新 - 年フィルターをクリックし、[日付範囲の編集]をクリックします。「今年」のような単純な範囲を選択するか、[詳細設定]タブをクリックして、「過去12週間から過去1週間」のようなオプションを表示できます。
プロのヒント：正確な曜日分析を行うには、常に完全な週のデータを使用してください。部分的な週は結果を歪める可能性があります。
ステップ4：列と視覚化を追加する
[列]パネルで、[追加]をクリックします。時間 - チケット更新 > 更新 - 日付を選択して、毎日の結果を表示します。[適用]をクリックします。
[視覚化]メニューから、列チャートタイプを選択します。チャート構成メニューから：
- [チャート]をクリックし、[積み上げ]をオンにします
- [集計値]をオフにします
- [表示値]をクリックし、列内に値を表示するように選択します
[保存]をクリックして、レポートを保存します。これで、ダッシュボードに追加したり、後でライブラリから再度開いたりできます。
高度な追跡のためのカスタムメトリクスの構築
組み込みのメトリクスでは、必要なものが正確に得られない場合があります。次に、計算メトリクスが役立つ2つの一般的なシナリオを示します。
最初の解決日メトリクス
チケットが後で再度オープンされた場合でも、チケットが最初に解決された日時を追跡する場合は、これを使用します。これは、初回タッチ解決率の測定に役立ちます。
作成するには：
- レポートで、計算メニュー（電卓アイコン）をクリックします
- 標準計算メトリクスを選択します
- 「最初の解決更新日」という名前を付けます
- 次の数式を貼り付けます。
IF ([変更 - フィールド名] = "status" AND [変更 - 新しい値] = "solved"
AND [変更 - 以前の値] != "solved" AND [更新 - タイムスタンプ] =
DATE_FIRST_FIX([更新 - タイムスタンプ], [チケットID], [変更 - フィールド名]))
THEN [更新チケットID]
ENDIF
- [保存]をクリックします
ソース：Zendeskヘルプセンター - チケットの最初の解決日メトリクスの作成
SLA内で解決されたパーセンテージ
SLAターゲットを満たすチケットのパーセンテージを追跡したいですか？2つの計算メトリクスが必要です。
まず、しきい値内で解決されたチケットのメトリクスを作成します（例：20分）：
IF (VALUE(完全解決時間（分）) < 20 AND [チケットステータス - 未分類] = "解決済み")
THEN [チケットID]
ENDIF
次に、パーセンテージメトリクスを作成します。
COUNT(20分未満で解決されたチケット) / COUNT(解決済みチケット)
これをパーセンテージとしてフォーマットし、レポートに適用します。SLAに合わせてしきい値（20分）を調整できます。
ソース：Geckoboard - 20分未満で解決されたチケットの割合
一般的な間違いとその回避方法
経験豊富な管理者でもこれらのエラーを犯します。注意すべき点は次のとおりです。
間違い1：傾向分析にチケットデータセットを使用する
チケットデータセットは、現在のステータスを表示し、履歴イベントは表示しません。チケットデータセットを使用して「日付別の作成数と解決数」レポートを作成しようとすると、数値が現実と一致しません。傾向レポートには常に更新履歴データセットを使用してください。
間違い2：営業時間と暦時間を無視する
Zendesk (ゼンデスク) は両方を追跡します。SLAが営業時間に基づいているのに、レポートで暦時間を見ている場合、誤解を招く結果になります。使用している時間メトリクスを確認してください。
- 暦時間：「完全解決時間（分）」
- 営業時間：「完全解決時間 - 営業時間（分）」
間違い3：誤差を考慮しない
Zendesk (ゼンデスク) は、更新履歴データセットの一部の計算に、メトリクスの計算方法により、小さな誤差があることを認めています。ほとんどの運用レポートでは、これは問題ではありません。ただし、正確な財務計算またはエグゼクティブダッシュボードを作成する場合は、チケットレベルのデータに対して数値を検証してください。
ソース：Zendesk - 作成されたチケットと解決されたチケットのレポート
間違い4：解決済みからクローズ済みへの移行を二重にカウントする
更新履歴データセットの「解決チケット数」メトリクスには、解決済みからクローズ済みへの移行はすでに除外されています。ただし、カスタム数式を作成する場合は、これらの移行を個別の解決としてカウントしないようにしてください。
検証のヒント
- レポートの数値に対してサンプルチケットをスポットチェックします
- 更新履歴の「解決チケット数」を、同じ期間のチケットデータセットの「解決済みチケット」と比較します。再オープンされたチケットがあるため、完全に同じではありませんが、近い値になるはずです。
- 最初に小さな日付範囲で計算メトリクスをテストします
弊社のAIエージェントを使用した基本的なレポート作成を超える
Zendesk Explore (ゼンデスクエクスプローラー) は強力ですが、手動でのレポート作成、データセットの知識、および数式の作成が必要です。複雑さを伴わずに解決に関する洞察を得たいチームのために、別のオプションがあります。
弊社のAIエージェントはZendesk (ゼンデスク) と直接統合されており、自律的な解決追跡を提供します。レポートを作成する代わりに、次のものが得られます。
- カスタム数式なしのリアルタイムの解決に関する洞察
- 自然言語クエリ - データセットをナビゲートする代わりに、「今週解決したチケットは何件ですか？」と質問します
- 解決率、SLAコンプライアンス、および担当者のパフォーマンスの自動追跡
- 手動でのレポートメンテナンスなし - チケットがシステムを流れるにつれて、洞察が自動的に更新されます
すでにZendesk (ゼンデスク) を使用しているチームの場合、既存のセットアップと連携します。弊社のAIは、過去のチケット、ヘルプセンター、およびマクロから学習し、特定のビジネスコンテキストに一致する洞察を提供します。
洞察に基づいて行動するよりもレポートの作成に多くの時間を費やしている場合は、分析を自動的に処理するアプローチを検討する時期かもしれません。
よくある質問
Share this article
Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.
