Zendeskの優先度別SLAポリシーメトリクス：2026年完全ガイド

Zendesk でサービスレベル契約 (SLA) を設定するのは簡単そうに見えますが、すべてのチケットが同じ応答時間であるべきではないことに気づくまでです。緊急のシステム停止は、機能リクエストとはまったく異なるタイムラインを必要とします。優先度ベースの SLA ポリシーは、このニーズに対応します。

このガイドでは、優先度レベルごとに異なるメトリクスを使用して Zendesk SLA ポリシーを設定するために知っておくべきことをすべて説明します。SLA を初めて設定する場合でも、既存のポリシーを最適化する場合でも、すぐに適用できる実践的な例とベストプラクティスが見つかります。

Zendesk SLA ポリシーとは何か、そして優先度が重要な理由

Zendesk のサービスレベル契約 は、基本的にタイマー付きの約束です。チームが顧客の問題に対応し、解決するためにコミットする速度を定義します。SLA がないと、手探りで進むことになります。チームが素晴らしい仕事をしているように感じるかもしれませんが、それを裏付ける具体的な測定値はありません。

優先度ベースの SLA は、単純な真実を認識しています。すべてのチケットが平等に作成されるわけではありません。すべてのユーザーに影響を与えるバグは、払い戻しポリシーに関する質問よりも迅速な対応が必要です。優先度レベルごとに異なる目標を設定することで、緊急の問題に必要な注意を払い、ルーチンリクエストに対する現実的な期待を維持できます。

ただし、課題はここにあります。積極的な SLA 目標を一貫して達成するには、単なる善意以上のものが必要です。チームは、ピーク時のボリューム中、または複雑なチケットで調査が必要な場合に、最初の応答時間の目標を達成するのに苦労することがよくあります。ここで、eesel AI のような AI ソリューションが役立ちます。ルーチンチケットを即座に処理し、エージェントが本当に人間の専門知識を必要とする問題に集中できるようにします。

Zendesk の 4 つの優先度レベルを理解する

Zendesk は 4 つの標準優先度レベルを使用します。それぞれが何を表しているかを理解すると、適切な目標を設定するのに役立ちます。

緊急度 (Urgent priority)

緊急度の高いチケットは、「すべてを中断する」カテゴリです。システム停止、セキュリティ侵害、または顧客が重要なビジネスを行うことを妨げる問題を考えてください。これらのチケットは通常、即時のエスカレーションと上級エージェントの注意が必要です。

緊急度の高いチケットに対する一般的な顧客の期待は積極的です。15 分以内の最初の応答、2 ～ 4 時間以内の解決。これらの目標を設定する場合は、実際に目標を達成するための人員配置とエスカレーション手順があることを確認してください。

高優先度 (High priority)

高優先度は、生産性に影響を与えるが、運用を完全に停止させない重要な問題をカバーします。例としては、複数のユーザーに影響を与える壊れた機能や、有料機能へのアクセスをブロックする請求の問題などがあります。

高優先度のターゲットベンチマークは、通常、1 時間以内の最初の応答と 8 ～ 24 時間以内の解決です。正確な数値は、業界と顧客の期待によって異なります。SaaS (Software as a Service) 企業は通常、この範囲のより速い方を目標としています。

通常優先度 (Normal priority)

通常優先度は、サポートボリュームの大部分を処理します。一般的な質問、ハウツーリクエスト、および重要でない問題。これらのチケットはタイムリーな応答が必要ですが、進行中の作業を中断する必要はありません。

ここでの標準的な目標範囲は、最初の応答で 4 ～ 8 時間、解決で 24 ～ 72 時間です。これは、営業時間と暦時間が本当に重要な場所です。金曜日の夕方に送信されたチケットは、営業時間を使用している場合、SLA メトリクスに影響を与えることなく、月曜日の朝まで待つことができます。

低優先度 (Low priority)

低優先度は、あると便利な改善、ドキュメントの提案、および軽微な外観上の問題に対応します。これらは、多くの場合、遅い期間中に処理されるか、定期的なメンテナンスサイクルにバンドルされます。

低優先度の目標は、通常、最初の応答で 8 ～ 24 時間、解決で 72 時間以上です。一部のチームは、低優先度のチケットに対して解決目標をまったく設定せず、合理的な時間枠内でそれらを認識するだけです。

Zendesk SLA の 7 つのメトリクスの説明

Zendesk は、SLA に対するパフォーマンスを測定するための 7 つのメトリクスを提供しています。すべてを使用する必要はありません。実際、ほとんどのチームは、2 つまたは 3 つのメトリクスでニーズを効果的にカバーできると考えています。

最初の応答時間 (First reply time)

最初の応答時間は、チケットの作成からチームの最初の公開応答までの期間を測定します。顧客の不安に直接対処するため、最も一般的に使用される SLA メトリクスです。誰かがサポートリクエストを送信すると、受信され、処理されていることを知りたいと考えます。

このメトリクスは、すべての優先度レベルでうまく機能します。一般的な目標範囲は、15 分 (緊急) から 24 時間 (低) です。最初の応答時間は、チケットが解決されているかどうかに関係なく、エージェントが応答すると一時停止します。

次の応答時間 (Next reply time)

次の応答時間は、顧客が最初の回答に返信した後、フォローアップの応答を待つ時間を追跡します。最初だけでなく、会話全体を通してチームの応答性を測定します。

このメトリクスは、最初の応答後にアクティブになり、次のエージェント応答まで実行されます。目標は通常、最初の応答時間と同様か、わずかに長くなります。次の応答時間を使用するには、最初の応答時間をアクティブにする必要があることに注意してください。

リクエスターの待機時間 (Requester wait time)

リクエスターの待機時間は、顧客の視点から見て最も公平なメトリクスです。チケットが「新規 (New)」、「オープン (Open)」、または「保留 (On-hold)」ステータスで費やした合計時間を測定し、チケットが「保留中 (Pending)」ステータスの場合に一時停止します。これは、ボールが顧客のコートにあるときにクロックが停止することを意味します。

チームを実際に待つ時間を測定する場合は、このメトリクスを使用します。特に、解決 SLA に役立ちます。

エージェントの作業時間 (Agent work time)

エージェントの作業時間は、エージェントがチケットに費やすアクティブな時間を追跡します。「新規 (New)」および「オープン (Open)」ステータスの時間のみをカウントし、「保留中 (Pending)」および「保留 (On-hold)」で一時停止します。このメトリクスは、チームの実際のワークロードとキャパシティを理解するのに役立ちます。

これは、顧客への約束ではなく、内部向けのメトリクスです。人員計画や、過剰なリソースを消費するチケットの特定に役立ちます。

合計解決時間 (Total resolution time)

合計解決時間は、チケットの作成から最終解決までのライフサイクル全体を測定します。リクエスターの待機時間とは異なり、チケットのステータスに関係なく、暦時間をカウントします。チケットが「保留中 (Pending)」で 3 日間経過した場合、その 3 日間は解決時間にカウントされます。

このメトリクスは、遅延の原因に関係なく、顧客に確固たる締め切りがある場合に意味があります。顧客の遅延に対してペナルティが科せられるため、リクエスターの待機時間ほど一般的ではありません。

定期的な更新時間 (Periodic update time)

定期的な更新時間は、問題の処理中に顧客を更新する頻度を測定します。エージェントからの各公開コメントの後にリセットされます。このメトリクスは、顧客が忘れられていると感じないようにする必要がある、実行時間の長いチケットに役立ちます。

解決に数日または数週間かかるチケットがあり、定期的な進捗状況の更新をコミットする場合は、このメトリクスを設定します。包括的なカバレッジのために、リクエスターの待機時間と組み合わせると効果的です。

一時停止可能な更新時間 (Pausable update time)

一時停止可能な更新時間は、チケットが「新規 (New)」、「オープン (Open)」、または「保留 (On-hold)」ステータスの場合にのみカウントする、定期的な更新のバリエーションです。「保留中 (Pending)」ステータスで一時停止します。このメトリクスは、アクティブなエンゲージメント時間を測定する必要がある複雑なワークフロー向けに設計されています。

定期的な更新との主な違いは、一時停止の動作です。アクティブな作業期間中にのみ更新を測定する場合は、これを使用します。

優先度別に SLA ポリシーを設定する方法

効果的な SLA ポリシーを作成するには、時間目標を入力するだけでは不十分です。ステップバイステップのプロセスを次に示します。

ステップ 1: 管理センターで SLA ポリシーに移動する

管理センター > オブジェクトとルール > ビジネスルール > サービスレベル契約に移動します。このセクションにアクセスするには、Suite Professional 以上 が必要です。Suite Team または Support Team を使用している場合は、SLA ポリシーを使用するためにアップグレードする必要があります。

ステップ 2: 新しいポリシーを作成する

「ポリシーを作成 (Create policy)」をクリックし、明確でわかりやすい名前を付けます。適切な名前は、対象者と目的の両方を示します。「標準カスタマーサポート - メール (Standard Customer Support - Email)」または「VIP エンタープライズ - すべてのチャネル (VIP Enterprise - All Channels)」。このポリシーがどのチケットに適用されるかを説明する説明を追加します。

ステップ 3: 条件を構成する

条件は、この SLA がどのチケットに適用されるかを決定します。次の条件でフィルタリングできます。

• チケットの優先度
• チャネル (メール、チャット、ウェブフォームなど)
• 組織またはリクエスター
• チケットフォーム
• カスタムフィールド

具体的にしてください。「すべてのチケット (all tickets)」に適用されるポリシーは、優先度ベースのターゲティングにはあまり役に立ちません。代わりに、チケットの種類や顧客セグメントごとに個別のポリシーを作成します。

ステップ 4: 各優先度のメトリクスを設定する

追跡するメトリクスごとに、「ターゲットを追加 (Add target)」をクリックして、メトリクスの種類を選択します。次に、各優先度レベルの時間目標を入力します。

各メトリクスについて、営業時間と暦時間 を選択します。営業時間は、営業時間外にクロックを一時停止します。暦時間は継続的に実行されます。

ステップ 5: ポリシーを正しく順序付けする

Zendesk は SLA ポリシーを上から下に適用 し、最初に一致するポリシーを使用します。順序は非常に重要です。最も制限の厳しいポリシーを一番上に、包括的なポリシーを一番下に配置します。

たとえば、「VIP 顧客 (VIP Customers)」ポリシーと「標準サポート (Standard Support)」ポリシーがある場合は、VIP を最初に配置します。そうしないと、すべてのチケットが VIP ルールに到達する前に、標準ポリシーに一致する可能性があります。

ステップ 6: テストと監視

ポリシーを保存した後、テストチケットを作成して、正しく適用されることを確認します。次のことを確認してください。

• 条件に基づいて適切なポリシーが一致する
• 各優先度の時間目標が正しく表示される
• 営業時間が予想どおりに計算される

エージェントがカウントダウンタイマーを確認できるように、SLA 列をチケットビューに追加します。「次の SLA 違反 (Next SLA breach)」列は、エージェントがすぐに注意を払う必要のあるチケットを優先順位付けするのに役立ちます。

優先度ベースの SLA のベストプラクティスとベンチマーク

目標を設定することは、戦いの半分にすぎません。これらのベストプラクティスは、SLA が適切な動作を促進するのに役立ちます。

優先度別の業界ベンチマーク

すべてのビジネスは異なりますが、これらのベンチマークは開始点を提供します。

SaaS 企業:

• 緊急 (Urgent): 最初の応答 15 分、解決 4 時間
• 高 (High): 最初の応答 1 時間、解決 8 時間
• 通常 (Normal): 最初の応答 4 時間、解決 24 時間
• 低 (Low): 最初の応答 24 時間、解決 72 時間

E コマース:

• 緊急 (Urgent): 最初の応答 30 分、解決 4 時間 (注文の問題)
• 高 (High): 最初の応答 2 時間、解決 24 時間
• 通常 (Normal): 最初の応答 8 時間、解決 48 時間
• 低 (Low): 最初の応答 24 時間、解決 5 日

エンタープライズ B2B:

• 緊急 (Urgent): 最初の応答 1 時間、解決 4 時間
• 高 (High): 最初の応答 4 時間、解決 24 時間
• 通常 (Normal): 最初の応答 8 時間、解決 3 日
• 低 (Low): 最初の応答 24 時間、解決 1 週間

これらは要件ではなく、開始点です。一貫して達成できる目標から始め、チームが改善するにつれて目標を厳しくします。

避けるべき一般的な間違い

非現実的な目標の設定: 一貫して SLA 目標を達成できないほど士気を低下させるものはありません。チームが 40% の時間で違反している場合、目標は積極的すぎます。85 ～ 95% の達成率を目指してください。

営業時間の忘れ: チームが 9 時から 5 時まで勤務しているときに、24 時間年中無休の暦時間目標を実行すると、週末の違反が保証されます。真の 24 時間年中無休の対応がない限り、営業時間を使用してください。

SLA の可視性に関するエージェントのトレーニング不足: エージェントは、効果的に優先順位を付けるために SLA タイマーを確認する必要があります。SLA 列をデフォルトビューに追加し、それらの読み方を説明します。

ポリシーの作成が多すぎる: 各ポリシーは複雑さを増します。10 個の重複するポリシーではなく、1 つまたは 2 つの適切に設計されたポリシーから始めます。

目標を調整するタイミング

SLA パフォーマンスを毎月確認します。目標の 100% を達成している場合は、寛大すぎる可能性があります。15% 以上違反している場合は、積極的すぎます。

パターンにも注意してください。特定のチケットの種類が一貫して違反していますか? ワークフローごとに個別のポリシーが必要になる場合があります。違反が特定の時間に集中していますか? 人員配置のギャップがある可能性があります。

追跡を超えて: SLA 目標を一貫して達成する方法

SLA の追跡は重要ですが、一貫して達成することが本当の課題です。チケットのボリュームが急増したり、複雑な問題で調査が必要になったりすると、十分な人員を配置したチームでも応答時間を維持するのに苦労します。

ここで、AI 自動化が価値を発揮します。目標を達成したかどうかを監視するだけでなく、AI を使用して目標をより一貫して達成できるようにすることができます。

たとえば、eesel AI は、AI エージェント を通じて Zendesk と直接統合し、ルーチンチケットを即座に処理します。顧客がパスワードのリセット、注文状況、または一般的なハウツーの質問について問い合わせると、AI はすぐに応答できます。これにより、これらのチケットの最初の応答時間がほぼ瞬時に向上します。

人間の専門知識を必要とするより複雑な問題については、eesel AI の Copilot 機能がエージェントと連携して、ナレッジベースと過去のチケットに基づいて応答を下書きします。エージェントは、最初から作成するのではなく、確認して送信できるため、エージェントの作業時間と合計解決時間の両方が短縮されます。

主な利点は、eesel AI が既存の Zendesk データから学習することです。過去のチケットからブランドボイスを理解し、ヘルプセンター、マクロ、および接続されたドキュメントソースから情報にアクセスできます。これは、AI の応答が一般的なチャットボットではなく、チームからのものであるように感じられることを意味します。

今すぐ Zendesk SLA パフォーマンスの最適化を開始する

効果的な SLA ポリシーは、顧客の期待と運用の現実のバランスを取ります。基本から始めます。優先度別の最初の応答時間の目標、合理的な解決目標、およびチームの可用性に一致する営業時間。次に、データから得られる情報に基づいて絞り込みます。

SLA は、報告するメトリクスだけでなく、より優れた顧客体験を提供するためのツールであることを忘れないでください。目標は完璧なコンプライアンスではありません。サポートが必要なときに、顧客がタイムリーで役立つ応答を得られるようにすることです。

プロセスの改善だけでは達成できないレベルまで SLA パフォーマンスを向上させたい場合は、AI 自動化がどのように役立つかを検討してください。eesel AI のようなソリューションは、既存の Zendesk 設定 内で動作し、ルーチンチケットを即座に処理し、複雑なチケットでエージェントを支援します。動作を確認 したり、ライブワークフローに変更を加える前に、過去のチケットでテストしたりすることもできます。