現在のプランを確認
Suite Professional、Enterprise、またはEnterprise Plus
Support + Explore Professional または Enterprise

数値を集計したい場合、Exploreからダッシュボードのレポートをスケジュールして、PDFをチームに配布する方法があります。または、毎月手作業で数字を計算し、スプレッドシートに入力するやり方もあります。また、同じ数値についてExploreでレポートを作成することもあります。れこらの方法で得られた結果が異なる場合、なぜ数字が一致しないのか困惑するかもしれません。

このような不一致を調べる際の重要なポイントは、PDFやスプレッドシートは静的であるのに対し、Exploreは動的であるということです。

この記事では、次のトピックについて説明します。

  • 結果が変動する理由
  • 数値を大局的に把握する
  • 適切な集計方法を使用する
  • まとめ

結果が変動する理由

例えば、8月1日に7月分のデータをエクスポートし、スプレッドシートに書き出したとします。しかし、9月に同じデータを使ってExploreで別のレポートを実行すると、7月のデータが異なる数値で表示されます。

8月に実行したエクスポートに基づく7月の列 9月にExploreで実行したレポートの7月の列

さらに詳しい説明:

  • 作成されたチケットの数が異なるのはなぜですか?
  • 解決したチケットの数が異なるのはなぜですか?
  • カテゴリによってチケットの数が異なるのはなぜですか?

作成されたチケットの数が異なるのはなぜですか?

チケットを削除した場合、作成されたチケットの総数が減少することがあります。

削除されたチケットはTicketsデータセットから除外されます。つまり、チケットをスパムとしてマークしたり、あるいは削除したりすると、これらのチケットはチケットの全体の数からは引かれます。このため、最終的に、作成されたチケットの数にも影響します。

上記の例では、作成されたチケットの数は、705件から693件に減少しました。これは、8月にデータがエクスポートされた以後、9月にExploreでレポートが実行されるまでの間に、12件のチケットが削除されたことが考えられます。

逆に、削除済みのチケットを復元した場合に、作成されたチケットの総数が増加することがあります。

削除されたチケットと復元されたチケットの数を調べるには、Updates historyデータセットのチケット削除数と復元チケットのメトリックを使用できます。

チケット削除数については、チケットIDやその他の属性などの情報は確認できませんが(チケットが削除されているため)、以下の情報は確認することができます。

  • チケットの削除された日時:更新 - タイムスタンプ属性を使って確認できます。
  • チケットを削除したユーザー:更新者 - 名前属性を使って確認できます。

復元チケットについては、復元された日時および復元したユーザーについて同様の情報を確認でき、また、チケットIDなどの他のチケット属性も見ることができます(チケットが復元されたため)。

解決したチケットの数が異なるのはなぜですか?

通常、作成されたチケットは作成されたチケット - 日付属性で、解決されたチケットは解決されたチケット - 日付属性で確認できます。しかし、これらの数値は、イベントによって変動するシナリオがあります。

解決済みチケットを解決済みの日付で確認する場合、これらの数値は再オープンメトリック(TicketsデータセットおよびUpdates historyデータセットで利用可能)の影響を受けます。データのエクスポート時とExploreレポートの実行時の間にチケットが再オープンされた場合、この数値は変化します。再オープンによって、チケットがこのメトリックから完全に削除されるか(もはや解決されていないため)、またはチケットがある期間から別の期間へ移動されます(最終的な解決が初回の解決と異なる期間であった場合)。

解決済みチケットを作成日で確認する場合、これらの数値は、時間経過ともに解決されたチケットによって影響を受けます。たとえば、月曜日にチケットが10件作成され、同日に2件解決された場合、エクスポートには月曜日の2件の解決済みチケットが含まれます。火曜日にさらに3件のチケットが解決されると、レポートと次のエクスポートでは、5件の解決済みチケットは月曜日に作成されたものとされます。

Updates historyデータセットの解決済みチケットメトリックは、現在解決されているチケットのうち、最後に解決されたチケットだけを拾います。このことは、以下のメトリックの式、特に太字の2つの条件を見ればわかります。

IF ([Changes - Field name]="status" 
    AND [Changes - Previous value]!="solved" 
    AND ([Changes - New value]="solved" OR [Changes - New value]="closed") 
    AND ([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed") 
    AND [Update - Timestamp]=[Ticket solved - Timestamp]) 
THEN [Update ID] 
ENDIF

解決済みチケットをすべて追跡したい場合は、現在のステータスと日付に関するこれら2つの条件を除いた標準ユーザー定義メトリックを作成すれば、以下のような式になります。

IF ([Changes - Field name]="status" 
    AND [Changes - Previous value]!="solved" 
    AND ([Changes - New value]="solved" OR [Changes - New value]="closed")) 
THEN [Update ID]
ENDIF

カテゴリによってチケットの数が異なるのはなぜですか?

Ticketsデータセットは、ステータス、グループ、担当者、優先度、カスタムなどのフィールドで、チケットの現在の状態を確認します。したがって、データのエクスポートからExploreレポートの実行までの間にフィールドの値が変更された場合に、結果に違いが生じる可能性があるということになります。

上述のスクリーンショットの例では、8月のエクスポートでは10件のblipと61件のbugがあったデータが示されています。しかし、9月のExploreレポートでは、2件のblipと69件のbugを表示しています。これは、データのエクスポートとレポートの実行の間に、8件のチケットがblipからbugに再分類されたことを示唆しています。

この種の変更は、レポートのフィルターにも影響します。たとえば、グループAのチケットのみを表示するようフィルタリングされたレポートがあるとします。データのエクスポートとレポートの実行の間にグループAから他のグループに移動されたチケットは、レポートには表示されなくなります。

逆に、グループBに割り当てられたチケットが、グループAに再割り当てされた場合、フィルタリングにより、レポートに表示されるチケットの数は再割り当て前より多くなります。

数値を大局的に把握する

Exploreのレポートとエクスポートの間で数値に不一致が出た場合、実際の数値そのものを大まかに把握しておくと理解の助けになります。たとえば、以下のシナリオを検討してみましょう。

  • ある結果でチケットの数が20件から21件に変わった場合、その増加分は1件です。この差を大きく感じるかもしれませんが、変化は5%の増加です。
  • 別の結果で1,998件から2,100件に変わった場合、その差は102件です。この差は大きく感じるかもしれませんが、これもわずか5%の変化でです。

数値の差異については、生の数字だけでなく、パーセンテージも見てください。そうすることで、重要な数値であるかどうかを判断できます。

次は、エージェントの数を考えてみましょう。200人のエージェントがいるとして、ある結果で102人分差異があったとすると、データのエクスポートからExploreレポートの実行までの間に、平均して約半数のエージェントが1件のチケットでそのフィールドを変更したことになります。

繰り返しますが、これらの結果は、Updates historyデータセットで調べることができます。更新者名属性を使用して、関連する[変更 - フィールド名]属性と、前の結果または不可解な新しい結果を表示するレポートをフィルタリングします。

ヒント:[変更 - フィールド名]を使用して数式を作成する方法の例については、「Exploreレシピ:Tracking ticket assigns across groups(グループ間のチケット割り当ての追跡)」を参照してください。

多くの場合、たとえば期間中に100人のエージェントが約1つのフィールドを変更した場合などに、幅広い分布で変更が見られます。

しかし、1人、2人のエージェントが頻繁にフィールドの結果を変更していることがわかる場合もあります。それを行っているのは、おそらく、チームメンバーの後始末をしているチームのマネージャーでしょう。あるいは、フィールドの適用方法を理解していない新人のエージェントかもしれません。その場合は、もっとトレーニングしたほうがよいかもしれません。

適切な集計方法を使用する

最後に、作業時間を調べるときは、「量と質」を頭にいれておくとよいでしょう。

デフォルトでは、Exploreは初回返信時間や解決時間などのメトリックに中央値(MED)の集計方法を使用します。しかし、扱うチケット量がごく少数で、通常のエージェントとはまったく異なる方法で対応する担当者やグループがいるかもしれません。おそらく、財務やセキュリティ関連のチームメンバーで、チケットに関わることはそれほど多くなく、応答時間に対して同じ期待を抱いていない人たちが該当します。

期間メトリックにMED集計方法を使用すると、これらの外れ値を除外することができます。平均(AVG)集計方法を使用した場合には、この機能が低下します。たとえば、財務チームが、あるカスタマーからの1件のチケットを6か月も放置しているのに対し、他のチームは常に1週間以内にチケットを解決しているとします。この財務チームの外れ値は、特にAVG集計方法を使用している場合、未解決チケットの期間に深刻な影響を与えます。

財務チームが最終的にそのチケットを解決したとき、解決した期間の解決時間にも大きな影響があります(特にAVG集計方法を使用した場合)。

まとめ

時間の経過とともに変動する数値に戸惑うことがあります。無理もありません。特に、上司から質問された場合はなおさらです。しかし、数値の変化にはさまざまな論理的な理由があります。

心配な場合は、上記で挙げた問題と、それがどのような影響を及ぼしているのかをよく考えてみてください。それでもわからないことがあれば、Exploreのドキュメントやコミュニティの情報を参照するか、Zendeskカスタマーサポートにお問い合わせください。

Powered by Zendesk