Zendesk Exploreで解決までの時間を追跡する方法

解決までの時間は、カスタマーサポートにおいて最も重要な指標の1つです。これは、顧客が連絡を取ってから問題が完全に解決されるまで、顧客がどれだけ待つかを示します。正しく理解すれば、チームのパフォーマンスを明確に把握できます。間違えると、不完全なデータに基づいて意思決定を下す可能性があります。

Zendeskを使用している場合は、Zendesk Exploreに組み込まれている、解決時間を追跡するための強力なツールがあります。課題は、どの指標を使用するか、それらをどのように構成するか、そして数値が実際にビジネスにとって何を意味するかを知ることです。

このガイドでは、Zendesk Exploreで解決までの時間を追跡するために知っておくべきことすべてを説明します。さまざまな種類の解決指標、実用的な洞察を提供するレポートの作成方法、および回避すべき一般的な落とし穴について説明します。

Zendeskにおける解決までの時間とは？

解決までの時間（Time to resolution）は、チケットが作成されてから解決済みとしてマークされるまでの合計期間を測定します。Zendeskでは、これは最初は単純に見えます。顧客が月曜日の朝にメールを送信し、チームが火曜日の午後にチケットを解決した場合、解決時間は約30時間です。

しかし、ここで複雑になります。Zendeskは、測定する必要があるものに応じて、複数の方法で解決時間を計算します。

カレンダー時間（Calendar hours）は、夜間や週末を含む、経過するすべての時間をカウントします。チケットが金曜日の午後5時に作成され、月曜日の午前9時に解決された場合、これはカレンダー時間で64時間です。

営業時間（Business hours）は、チームが実際に作業している時間のみをカウントします。標準的な午前9時から午後5時までの勤務スケジュールで同じ例を使用すると、金曜日の夕方から月曜日の朝までのチケットは、営業時間の8時間にしかならない場合があります。

どちらを使用する必要がありますか？営業時間は、エージェントが積極的に作業している時間を測定するため、チームの実際のパフォーマンスをより明確に把握できます。カレンダー時間は、チームがオンラインであるかどうかに関係なく、顧客が完全な待ち時間を経験するため、顧客体験にとってより重要です。

ほとんどのサポートチームは両方を追跡します。社内パフォーマンスレビューには営業時間、顧客へのSLAコミットメントにはカレンダー時間を使用します。

最初の解決時間 vs 完全な解決時間：違いは何ですか？

ここで多くのチームがつまずきます。Zendeskは2つの異なる解決時間指標を提供しており、それらは非常に異なるストーリーを伝えます。

最初の解決時間（First resolution time）は、チケットの作成からチケットが最初に解決済みとしてマークされるまでの時間を測定します。これはあなたが望むもののように聞こえますが、大きな盲点があります：再オープンされたチケットです。

チケットが解決された後、顧客が問題を実際に修正されていないと返信したために再オープンされた場合、最初の解決時間のカウントは停止します。最初の解決時間（First resolution time）は、最初の解決のみを気にします。チケットは2週間で3回再オープンされる可能性がありますが、最初の解決時間（First resolution time）は最初の4時間の解決しか認識しません。

完全な解決時間（Full resolution time）（最新の解決時間と呼ばれることもあります）は、チケットの作成から最終的な解決までの時間を測定します。再オープンされたチケットを考慮し、顧客が完全な修正を待つために費やした実際の期間を示します。

SLAレポートにはどちらを使用する必要がありますか？完全な解決時間（Full resolution time）は、ほぼ常に最適な選択肢です。顧客は、技術的にチケットを一度解決した後に再び壊れたことを気にしません。顧客が気にするのは、永続的な解決策を得るのにどれくらいの時間がかかったかです。

最初の解決時間（First resolution time）にも価値があります。これは、早期にクローズされているチケットや、問題を完全に解決せずに急いでチケットを処理している可能性のあるエージェントを特定するのに役立ちます。最初の解決時間（First resolution time）と完全な解決時間（Full resolution time）の間に大きなギャップがある場合は、調査する価値のある危険信号です。

Zendesk Exploreで完全な解決時間レポートを作成する方法

Zendesk Exploreで解決時間レポートを作成するには、手順を知っていれば約5分かかります。その方法は次のとおりです。

必要なもの

開始する前に、次のものがあることを確認してください。

• Zendesk Explore ProfessionalまたはEnterprise（カスタムレポートは下位層では利用できません）
• Exploreでの編集者または管理者権限
• Zendeskアカウントに少なくともいくつかのチケットデータ（レポートには分析するものが必要です）

ステップ1：新しいレポートを作成する

Zendesk Exploreを開き、レポートアイコンをクリックします。新しいレポート（New report）をクリックして、最初から作成を開始します。

データセットの選択ページで、サポート（Support）を選択し、次にサポート - チケット（Support - Tickets）を選択します。このデータセットには、作成時間、解決時間、解決指標など、すべてのチケット情報が含まれています。レポートを開始（Start report）をクリックして、レポートビルダーを開きます。

ステップ2：完全な解決時間指標を追加する

左側の指標パネルで、追加（Add）をクリックします。これにより、レポートできる利用可能な指標のリストが開きます。

イベント間の期間 - カレンダー時間（時間）（Duration between events - Calendar hours (hrs)）に移動し、完全な解決時間（時間）（Full resolution time (hrs)）を選択します。代わりに営業時間が必要な場合は、イベント間の期間 - 営業時間（時間）（Duration between events - Business hours (hrs)）で同じ指標を探します。

適用（Apply）をクリックすると、Exploreはすべてのチケットの完全な解決時間の中央値を計算します。デフォルトでは、Exploreは平均値ではなく中央値を使用します。これは、中央値が外れ値の影響を受けにくいためです。解決に30日かかった1つのチケットは、レポート全体を歪めることはありません。

ステップ3：属性を追加してデータを分割する

すべてのチケットの単一の数値はあまり役に立ちません。問題を隠している可能性のある場所を確認するために、それを分解する必要があります。

列または行パネルで追加（Add）をクリックし、チケット作成 - 日付（Ticket created - Date）を選択して、日、週、または月ごとの解決時間を表示します。これは、時間の経過に伴う傾向を把握するのに役立ちます。

追加するその他の有用な属性：

• 担当者名（Assignee name）は、解決時間が長いエージェントを確認します
• チケットの優先度（Ticket priority）は、緊急チケットが実際に迅速に解決されているかどうかを確認します
• チケットグループ（Ticket group）は、チーム全体のパフォーマンスを比較します
• チケットの種類（Ticket type）は、問題が質問よりも時間がかかるかどうかを確認します

追加する各属性は、データを分析するための別の角度を提供します。

ステップ4：フィルターと視覚化でカスタマイズする

生の数値は圧倒される可能性があります。このレポートをより理解しやすくしましょう。

日付フィルターを追加するには、フィルターパネルで追加（Add）をクリックし、チケット作成 - 日付（Ticket created - Date）を選択します。これにより、先月や今四半期など、特定の期間に焦点を当てることができます。

視覚化を変更するには、視覚化タイプのメニュー（グラフアイコン）をクリックし、線（Line）を選択します。折れ線グラフは、時間の経過に伴う傾向を示すのに最適です。エージェントやグループなどのカテゴリを比較する場合は、通常、棒グラフの方が適しています。

保存アイコンをクリックし、「月ごとの完全な解決時間」（Full Resolution Time by Month）のような説明的な名前を付けてレポートを保存し、後で簡単に見つけられるようにします。

ZendeskのSLA指標カテゴリを理解する

解決時間は単独で存在するものではありません。ZendeskはSLA指標を3つのカテゴリに整理しており、それらがどのように連携するかを理解することで、サポートパフォーマンスの全体像を把握できます。

返信指標（Reply metrics）は、顧客からの返信がどれだけ迅速であるかを測定します。最初の返信時間（First reply time）は、チケットの作成から最初の応答までの待ち時間を追跡します。次の返信時間（Next reply time）は、顧客の返信とフォローアップの応答の間のギャップを測定します。

これらは、顧客満足度に直接影響するため重要です。解決に3日かかるチケットは、顧客が数時間ごとに更新を受け取った場合と、最終的な解決まで完全に沈黙していた場合とでは、非常に異なって感じられます。

更新指標（Update metrics）は、より長い調査中にチケットを前進させ続けます。定期的な更新では、エージェントが設定された間隔でコメントを追加して、作業が行われていることを顧客に知らせる必要があります。一時停止可能な更新は、チケットが保留中のステータスの場合、カウントを停止し、顧客ではなく顧客を待っていることを認識します。

これらは、解決に数日または数週間かかる複雑な技術的な問題に特に役立ちます。チケットが沈黙したり、顧客が忘れられたと感じたりするのを防ぎます。

解決指標（Resolution metrics）は、チケットのライフサイクル全体を測定します。合計解決時間（Total resolution time）は、作成から解決までの全期間です。リクエスタの待ち時間（Requester wait time）は、保留中のステータスで費やされた時間を差し引いて、顧客が積極的に待っていた時間のみを表示します。エージェントの作業時間（Agent work time）は、新しいステータスとオープンステータスの時間のみに焦点を当て、サードパーティまたは顧客の応答を待つ時間を除外します。

最適なSLAポリシーには、通常、各カテゴリから少なくとも1つの指標が含まれています。応答性のための返信指標、長いチケット中のコミュニケーションのための更新指標、および全体的な効率のための解決指標です。

高度なレポートのためのカスタムSLA指標の作成

組み込みの指標だけでは不十分な場合があります。チケットの何パーセントが4時間以内に解決されたか、またはSLAターゲットに違反したチケットの数を追跡する必要がある場合があります。

これは、カスタム計算指標が役立つ場所です。これらを使用すると、既存の指標と属性を組み合わせて、操作に関する特定の質問に答えることができます。

一般的な例は、SLAターゲット内で解決されたチケットの指標を作成することです。完全な解決時間がターゲットのしきい値未満のチケットをカウントする標準的な計算指標を作成します。

もう1つの有用な指標は、SLA違反率です。これは、違反したチケットの数を合計チケット数で割って、ターゲットを見逃している頻度の明確な割合を示します。

カスタム指標は強力ですが、学習曲線が伴います。Zendeskの数式構文と、さまざまな指標がどのように相互作用するかを理解する必要があります。苦労している場合は、Geckoboardが一般的なユースケース向けに事前構築されたカスタム指標のライブラリを維持しています。

カスタム指標について言えば、複雑さが増します。すべてのカスタム数式は、Zendeskがプラットフォームを更新するときに壊れたり、予期しない結果を生み出したりする可能性のある別のロジックです。カスタム指標を作成する前に、必要な洞察が継続的なメンテナンスに値するかどうかを尋ねてください。

場合によっては、追跡するためにますます複雑なレポートを作成するよりも、プロセスを簡素化する方が良いアプローチです。

一般的な課題とその解決方法

適切な指標が構成されていても、エッジケースやデータ品質の問題が発生します。最も一般的な問題とその処理方法を次に示します。

間違ったSLAステータスで保存されたチケット（Tickets saved in the wrong SLA status）は、スケジュール変更またはエッジケースにより、Zendeskが不正確なSLAデータを記録する場合に発生します。チケットは、実際にはターゲットを満たしている場合でも、違反として表示されたり、その逆になったりする可能性があります。Zendeskのドキュメントには、保存されたステータスではなく期間に基づいて達成度を計算する代替SLA指標を作成するためのレシピが含まれています。ネイティブ指標が信頼できない場合、これらにより、より正確なレポートを作成できます。

内部ハンドオフのグループSLA（Group SLAs for internal handoffs）は、特定の問題を解決します。チケットがサポートからエンジニアリングへ、または財務から請求へなど、チーム間で移動する場合、標準SLAは意味をなさなくなります。2番目のグループは、チケットが最初のグループで待機していた時間に対してペナルティを受けるべきではありません。グループSLAは、チケットが割り当てられたときから離れるときまで、特定のグループごとの所有時間を測定します。これにより、不当に遅延を帰属させることなく、チーム間で内部SLAを設定できます。

AIエージェントの返信とSLAへの影響（AI agent replies and SLA impact）は、ますます一般的な質問です。AIツールを使用して最初の応答を処理している場合、それらは指標にどのように影響しますか？Zendeskドキュメントによると、メッセージングのAIエージェントの返信は、最初の返信時間指標のエージェントの返信としてカウントされません。ただし、メールのAIエージェントはカウントされます。これにより、AI応答が人間の支援の真の待ち時間を隠しているため、FRTが実際よりも良く見えるという混乱を招く状況が発生します。

Zendeskと並行してAIツールを使用している場合は、最初の返信時間に加えて、次の返信時間（Next reply time）を追跡することをお勧めします。これは、顧客のメッセージと後続のエージェントの応答の間の時間を測定し、人間のパフォーマンスをより明確に把握できます。

eesel AIで解決時間追跡を簡素化する

Zendesk Exploreでカスタムレポートを作成することは、それらを維持するための時間と専門知識があれば十分に機能します。ほとんどのサポートチームは、Zendeskレポートのエキスパートになるよりも、より緊急の優先事項があります。

これは、私たちが支援できる場所です。eesel AIでは、Zendeskに直接接続し、この複雑さの多くを自動的に処理するAIチームメイトを構築しました。

レポートを手動で構成する代わりに、当社のAIは、過去のチケット、ヘルプセンター、およびマクロから学習して、特定のビジネスに適した解決策がどのようなものかを理解します。カスタムダッシュボードを作成する必要なく、解決指標をリアルタイムで追跡します。

このアプローチを異ならせるのは次のとおりです。従来のレポートは、事実の後に何が起こったかを示します。当社のAIエージェントは、実際に解決時間を改善するために瞬時に機能します。最前線のサポートチケットを自律的に処理し、エージェントがレビューする返信案を作成し、複雑な問題を適切なチームにすぐにルーティングできます。

セットアップには数時間ではなく数分かかります。eesel AIをZendeskアカウントに接続すると、トーン、プロセス、および一般的な問題が自動的に学習されます。公開する前に、過去のチケットでシミュレーションを実行して、そのパフォーマンスを正確に確認できます。推測はありません。構成が正しいことを期待することはありません。

当社の顧客は通常、会話の最大81％が自律的に解決され、AIは2か月以内に自己資金を回収します。これは解決時間の追跡だけではありません。それは実際にそれを改善しています。

レポートの作成に費やす時間が、レポートに基づいて行動する時間よりも多い場合は、代替アプローチを検討する価値があるかもしれません。

今すぐ解決時間追跡の改善を開始する

Zendesk Exploreで効果的な解決時間レポートを作成するために必要なものがすべて揃いました。最初の解決時間と完全な解決時間の違いを理解し、カスタムレポートを作成する方法を知っており、データ品質に影響を与える前に一般的な落とし穴を見つけることができます。

重要なポイントは単純です。SLAレポートには、最初の解決時間ではなく、完全な解決時間を使用してください。属性を追加してデータを分解し、隠れた問題を見つけます。レポートを履歴データと照らし合わせてテストし、正確であることを確認します。

しかし、解決時間の追跡は最初のステップにすぎません。本当の目標は、それを改善することです。それは、より良いレポートを作成したり、チームをより効果的にトレーニングしたり、AI支援を導入してルーチンチケットをより迅速に処理したりすることを意味します。

AIがチームのチケット解決をどのように支援できるかについて興味がある場合は、eesel AIができることをお見せしたいと思います。7日間無料でお試しいただくか、デモを予約して、実際のZendeskデータで動作を確認してください。