サポートチケットレポートの作成方法：ステップバイステップ

サポートチケットのレポート作成は、そのほとんどが定義の問題です。作成されたチケット数、解決されたチケット数、初回返信時間、解決時間などは、どれも一見して自明のように思えます。しかし、同じヘルプデスク内であっても、これらの一つひとつに複数の公式な定義が存在します。

集計ルールを明確に定義しておけば、レポートは自然と出来上がります。このステップを怠ると、2人の誠実な担当者が同じデータをエクスポートしたとしても、時間単位で結果が食い違うことになります。

本ガイドでは、レポートに含めるべき要素、定義が分岐する4つのポイント、そしてチケットのエクスポートデータからレポートを作成する方法について解説します。

サポートチケットレポートに含めるべき要素

件数（ボリューム）だけでは、ほとんど何もわかりません。数値を正しく読み解くためには、その整理の仕方が重要になります。

項目	記載する理由
期間内に作成されたチケット数	需要側（流入量）の把握
期間内に解決されたチケット数	供給側（処理量）の把握（規定のステータスルールに基づく）
期末時点のバックログ	未解決または未クローズのすべてのチケット
初回返信時間	規定の計測時間と定義に基づく
解決時間	初回解決か最終解決かを明示
再オープンされたチケット数	他の数値に隠れがちな品質のシグナル
未返信のチケット数	プロセスが完全に機能しなかった箇所
明示された基準日と対象範囲	どのチャネル、ブランド、キューが含まれているか

表の中の2つの行は、その見た目以上に重要な意味を持っています。再オープンされたチケットと未返信のチケットこそが、レポートを単なるスコアボードから、実用的なツールへと変える要素です。

Zendeskは算出ロジックを公開しているため、定義は主観的な意見ではなく、客観的に検証可能です。同社のメトリックと属性のリファレンスに、それぞれの定義が記載されています。

最もシンプルなものから始めましょう。解決済みチケットとは「解決済み（Solved）またはクローズ済み（Closed）のチケット数」を指すため、このメトリックは1つではなく2つのステータスにまたがっています。

「初回返信時間」には2つの公式な定義がある

これは最も意見の食い違いが生じやすい分岐点であり、ベンダー自身も直接注意を促しています。

ZendeskのSLAドキュメントには、次の一文が明記されています。「SLA返信時間と、Zendeskネイティブの返信時間メトリックを混同しないでください。」

ネイティブのメトリックは、誰が返信したかについて厳格です。Zendeskは「初回返信時間は、エージェントによる返信のみに基づいて計算される」としています。自動送信やボットによるアクションは「初回返信時間の計算時には考慮されません」。

一方、SLAメトリックはそうではありません。SLAにおける初回返信時間は「チケット作成から、エージェントによる最初のパブリックコメント（または自動返信）までの時間」と定義されています。Zendeskはさらに、「パブリックコメントで自動返信を行うトリガを設定している場合、返信時間メトリックは達成されたとみなされます」と付け加えています。

この2つの定義を合わせると、その影響は明らかです。自動応答によってSLA目標は達成されても、ネイティブの初回返信時間の計測は走り続けることになります。

したがって、SLA達成率が98%である一方で、初回返信時間の中央値が4時間となっているレポートは、矛盾しているわけではありません。2つの異なる指標を、どちらも正しく報告しているのです。

知っておく価値のある、より細かい例外が2つあります。1つは、エージェントがチケットを作成し、最初のコメントがパブリックである場合です。時間メトリックのリファレンスによると、この場合の2つ目のタイムスタンプは「エージェントによる2回目のパブリックコメントにシフト」します。

もう1つは、共有チケットはカウントされないという点です。Zendeskは、チケット共有を使用して別のアカウントからエージェントがパブリックコメントを投稿した場合、「自アカウントの初回返信時間にはカウントされません」と説明しています。

「解決時間」にも2つの定義がある

解決メトリックについても同様の分岐が存在し、こちらでは両方のバージョンがデフォルトで提供されています。

初回解決時間（First resolution time）は「チケット作成から最初の解決までの期間」であり、「チケットステータスが最初に解決済み（Solved）に設定された時点」で終了します。

最終解決時間（Full resolution time）は「チケット作成から最新の解決までの期間」です。これは「チケットステータスが最後に解決済み（Solved）に設定された時点」で終了します。

1回で解決したチケットの場合、この2つの数値は同じになります。しかし、解決された後に再オープンされ、再度解決されたチケットの場合、2回目の対応にかかった時間の分だけ数値が乖離します。

これこそが、再オープンされたチケットをレポートに含めるべき理由です。Zendeskはこれらを「解決された後に再オープンされた」チケットと定義しており、このメトリックには「同じアップデート内で解決され、再オープンされたチケットは含まれない」と説明しています。

また、見落とされがちな二次的影響もあります。解決済みチケットの日次平均は「現在解決済みまたはクローズ済みである場合のみ」カウントされます。そのため、今日再オープンされたチケットは、先月の解決済み件数から静かに差し引かれることになります。

したがって、6月に実行したレポートを8月に再実行しても、同じ結果は再現されません。システムが壊れたわけではなく、元データのステータスが変化したためです。

さらに、「待ち時間」と「作業時間」を区別する2つのメトリックがあります。リクエスタの待ち時間（Requester wait time）は、新規（New）、オープン（Open）、保留中（On-hold）ステータスの合計時間であり、エージェントの待ち時間（Agent wait time）は、待機中（Pending）ステータスの合計時間です。

この2つの指標は、解決時間の平均値だけでは見えてこない疑問に答えてくれます。顧客の返答待ちによって解決時間が長引いているケースと、キューの滞留によって長引いているケースは、まったく異なる問題だからです。

カレンダー時間か、営業時間か

すべての返信時間と解決時間の数値には2つの時間軸（クロック）が存在し、どちらか一方を選択することは必須です。

Zendeskは両方を保存しています。最初のパブリック返信の後、「システムはカレンダー時間と営業時間で初回返信時間を計算」します。どちらのメトリックも「チケットデータとともに保存」されます。

画面に表示されるデフォルトの設定は、中立なものではありません。Zendeskは、あらかじめ用意されたExploreレポートが「カレンダー時間で情報を表示する」と説明しています。営業時間メトリックは「利用可能であり、独自のレポートで使用できます」。

そのため、午前9時から午後5時まで働くチームは、デフォルトのレポートでは対応が遅いように見えてしまいます。金曜日の午後6時に届いたチケットは、月曜日の朝までに約63時間のカレンダー時間を消費しますが、営業時間で計算すればほぼゼロ時間になります。

リアルタイムの会話チャネルでは、さらに複雑な要素が加わります。メッセージングやチャットにおける「初回返信時間（秒）」メトリックは、「メッセージングの営業時間やライブチャットの稼働時間の設定を無視」します。

また、チャットの返信時間SLAはオプトイン方式です。Zendeskは、ライブチャットの返信時間SLAは「デフォルトでオフになっている」と説明しているため、SLA違反が発生していないのは、完璧なパフォーマンスのおかげではなく、単に設定がオフになっているからかもしれません。

手動で行う方法

オプション1：メトリックの系統ごとにタブを分ける

メトリックフィールドを含めてチケットリストをエクスポートし、集計を行う前に、件数、返信時間、解決時間をそれぞれ別のタブに分割します。

エクスポート時にどちらか一方を選ぶのではなく、カレンダー時間と営業時間の列を並べて保持しておきましょう。後からもう一方の数値を求められることになるからです。

時間に関するメトリックでは、平均値ではなく中央値を算出してください。連休中に放置されたわずかなチケットが、実態とはかけ離れた平均値へと数値を引き上げてしまうためです。

この方法の限界は、スプレッドシートではステータスの履歴を追えない点にあります。取得できるのは各チケットの現在の状態のみであるため、再オープンの挙動は、履歴の再構築からではなく、再オープン回数のカウントから把握するしかありません。

オプション2：最初に定義タブを作成する

返信時間の定義、使用する時間軸（クロック）、解決時間のメトリック、解決済みのステータスルール、対象となるチャネル、および基準日を記録しておきます。

その上で、そのレポートが「保証しないこと」も記録します。SLA達成率とネイティブの初回返信時間は異なるものを測定していると明記しておくことで、善意の同僚がそれらを同じ数値として引用するのを防ぐことができます。

この方法の限界は、よくある話ですが、ルールを文書化してもそれが自動的に適用されるわけではないという点です。次の四半期には、誰かが記憶を頼りにピボットテーブルを再作成しているかもしれません。

オプション3：平均を出す前にセグメント化する

時間メトリックを計算する前に、チャネルごとに分割します。メール、チャット、電話のチケットはそれぞれ性質が異なるため、これらを混ぜ合わせた中央値は、どのチャネルの実態も表さなくなってしまいます。

次に、数値を歪めるチケットを除外するか、フラグを立てます。顧客からの返答を何週間も待っているチケットは、解決時間の平均に含めるのではなく、別の行に分けるべきです。

何を除外し、それが何件あったのかを明示しましょう。フィルターが適用されていることが見えないと、読者はフィルターなど存在しないと思い込んでしまいます。

この方法の限界は、セグメント化によって作業量が倍増することです。3つのチャネル × 2つの時間軸 × 2つの解決メトリックとなると、管理すべき数値は12個にのぼります。

共通の限界： これら3つのオプションはすべて、エクスポートデータがすべてのキューに対して同一の基準日、同一 of 期間をカバーしていることを前提としています。タブ間で期間が混在してしまうことは、このレポートで最も発生しやすい、気づきにくいエラーです。

手動ルートで行き詰まるポイント

最初のサポートチケットレポートの作成には半日かかります。しかし、4回目の作成にはそれ以上の時間がかかるようになります。なぜなら、その間にヘルプデスクの設定が変更されているからです。

新しいチャネルが有効化されると、パフォーマンスとは無関係な理由で全体の混合中央値が変動します。新しい地域のために営業時間が編集されると、過去のすべての営業時間データもそれに引きずられて変化します。

さらに、再オープンの影響が及びます。前四半期の数値が再現できなくなり、その理由を説明するだけで、レポートを再作成する以上の時間がかかってしまいます。

そして、プレッシャーがかかる場面で初めて露呈する4つ目のコストがあります。「今四半期、サポートは迅速化されたか？」と尋ねられたとき、誠実に回答するためには、まず時間軸、定義、そしてチャネルの構成比を明確にする必要があります。

顧客満足度というもう一つの側面については、NPSレポートの作成方法に関するガイドをご覧ください。問い合わせ件数そのものが課題である場合は、プレセールス顧客サポート向けAIエージェントの構築方法の解説で、問い合わせ削減（デフレクション）の側面をカバーしています。

Powerdrill Bloomでレポートを作成する方法

ステップ1：チケットのエクスポートデータをアップロードする

チケットのエクスポートデータ、またはチケットとSLAのエクスポートデータを一緒にアップロードします。Powerdrill Bloomは取り込み時に対象列のプロファイルを分析するため、中央値が計算される前に、空のタイムスタンプ、混在する日付フォーマット、初回返信のないチケットなどが検出されます。

ステップ2：自然言語でレポートの内容を説明する

定義を再構築するのではなく、言葉で指定します。返信時間の定義、時間軸、使用したい解決メトリック、解決済みのステータスルール、対象チャネルを指定します。

その上で、エラーをあぶり出すための質問を投げかけます。「エージェントの返信がまったくないチケットは何件あるか」「どのチケットが再オープンされたか」「混合値ではなく、チャネルごとの中央値を出してほしい」といった具合です。

ステップ3：チャート、レポート、またはスライド資料をエクスポートする

チャネルごとのメトリック表や、バックログを背景にした作成数対解決数のチャートを出力します。数値の横に定義が併記されたスライド資料も、同じプロセスから作成できます。

よくある間違い

SLA達成率を初回返信時間として引用する： 一方は自動返信を許容しますが、もう一方は自動化されたアクションを完全に除外します。

カレンダー時間と営業時間を比較する： デフォルトのレポートは前者を表示しますが、目標値はおそらく後者に基づいて設定されています。

返信時間や解決時間に平均値を使用する： 放置された少数のチケットによって、平均値が実態とかけ離れた数値になってしまいます。

チャネルを混在させる： チャットとメールの中央値は設計上異なるものであり、混ぜ合わせてしまうと両方の実態が見えなくなります。

どちらの解決時間かを明示せずに報告する： 初回解決時間と最終解決時間は別々に保存されるメトリックであり、端数処理の違いなどではありません。

解決数を確定値として扱う： 解決数には現在解決済みまたはクローズ済みであるチケットのみが含まれるため、再オープンによって過去の数値が変動します。

未返信のチケットを除外する： これらはエージェントの返信が1回未満のチケットと定義され、レポートが浮き彫りにできる最も明確なプロセスの失敗を示しています。

結論

返信時間の定義を明示し、時間軸を指定し、初回解決か最終解決かを選択し、ステータスルールを規定し、チャネルごとにセグメント化し、再オープンや未返信のチケットを表示する。これらを行うことで、次のアクションにつながるサポートチケットレポートが完成します。

ただし、このレポートを使って他社の数値と単純に比較することは避けるべきです。定義はカスタマイズ可能であるため、どこかで目にしたベンチマークは、ほぼ間違いなく異なるルールで測定されています。

代わりに、固定されたルールに基づいて、自社の過去のデータと比較して追跡しましょう。それこそが、実際に改善が進んでいるかどうかを教えてくれる唯一のレポートです。

毎月のレポート再作成に丸一日を費やしているなら、チケットのエクスポートデータを使ってPowerdrill Bloomをお試しください。また、AIレポートジェネレーターのページや、顧客の声サマライザーもあわせてご覧ください。

よくある質問

SLA達成率と初回返信時間が一致しないのはなぜですか？

これらは異なる事象を測定しているためです。ZendeskのSLA初回返信時間は自動返信によって達成されますが、ネイティブの初回返信時間メトリックは自動化されたアクションやボットのアクションを完全に除外します。

初回解決時間と最終解決時間のどちらを報告すべきですか？

どちらを使用しているかを明示した上で、報告してください。初回解決時間はチケットが最初に解決済みに設定された時点で終了します。最終解決時間は最後に解決済みに設定された時点で終了するため、再オープンされたチケットによって2つの数値に差が生じます。

サポートメトリックはカレンダー時間と営業時間のどちらで測定されますか？

両方のデータが保存されています。ZendeskのデフォルトのExploreレポートはカレンダー時間を表示しますが、ご自身で作成するレポートでは営業時間メトリックも利用可能です。

前四半期の解決数が変化したのはなぜですか？

解決数には、現在解決済みまたはクローズ済みであるチケットのみが含まれるためです。対象期間が終了した後に再オープンされたチケットは、その期間のカウントから除外されます。

自社の解決時間を業界のベンチマークと比較することはできますか？

大まかな参考程度にとどめるべきです。定義、時間軸、チャネル構成はすべてカスタマイズ可能であるため、公開されている数値は、おそらく貴社とは異なるルールで測定されています。