SLAポリシーの定義

現在のプランを確認

Suite Growth、Professional、Enterprise、Enterprise Plus Professional、Enterpriseプラン

ファストパス：管理センター >「オブジェクトとルール」>「ビジネスルール」>「サービスレベルアグリーメント」

注意：四半期ごとの最新情報で発表されたように、「初回返信時間」と「次の返信時間」の両方のSLAのサポートがまもなくメッセージングチケットで開始されます。

サービスレベルアグリーメント（SLA）ポリシーは、サポートチームがお客様との間で、応答および解決策を提供するまでのそれぞれの時間を取り決めたものです。

たとえば、緊急のチケットには10分で対応し、2時間以内に解決するという契約を定義することができます。

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

SLAポリシーを設定する
どのようなSLAメトリックを測定できるかについて
チケットの再オープンがSLAに与える影響

社内チームのためのグループSLAの定義

SLAポリシーを設定する

各SLAポリシーは、チケットが満たすべき条件と、測定対象として選択したメトリックで構成される所定の構造を持ちます。なお、SLAポリシーを設定する際にすべてのメトリックに目標を設定する必要はありません。詳しくは「メトリックを合わせて使うためのベストプラクティス」を参照してください。

注意：チケットは、システムのデフォルトの「優先度」フィールドに優先度が設定されている必要があります（カスタムチケットフィールドはカウントされません）。優先度が設定されていない場合、どのルールも満たされません。トリガを使って、チケット作成時に優先順位を設定することができます。詳しくは「トリガの作成」を参照してください。

SLAポリシーを設定するには

管理センターで、サイドバーの「 オブジェクトとルール」をクリックし、「ビジネスルール」>「サービスレベルアグリーメント」を選択します。
「ポリシーを追加」をクリックします。
「ポリシー名」を入力します。
必要に応じて、「説明」を入力します。
ポリシーの条件を選択します。

条件の最初の数文字を入力するか（自動入力機能で残りは自動入力されます）、ドロップダウンメニューからオプションを選択します。
「返信目標」セクションで、各メトリックとチケットの優先度について目標時間を入力します。

詳細については、「返信時間のメトリック」を参照してください。

メモ：設定できる最小の目標時間は1分です。時間、分、または両方を入力することができます。
「更新目標」セクションで、各メトリックとチケットの優先度について目標時間を入力します。更新時間のメトリックは2つありますが、どちらか一方のみを使用することが推奨されています。

詳細については、「更新時間のメトリック」を参照してください。
「解決目標」セクションで、各メトリックとチケットの優先度について目標時間を入力します。解決時間のメトリックは1つだけ使用することが推奨されています。

詳細については、「解決時間のメトリック」を参照してください。
スケジュールを設定した場合、各優先度の「稼働時間」に「カレンダー時間」または「営業時間」を選択します。
「保存」をクリックします。
SLAポリシーが作成されました。

既存のSLAがある場合は、最新のSLAがリストの一番下に追加されます。SLAポリシーの順序は、チケットに適用される順番となります。

ポリシーの効果を最大限に引き出すには、最も制限の強いポリシーから、制限の緩いポリシーの順に、ポリシーを大まかに並べ替えます（「SLAポリシーの順序付け」を参照）。

コミュニティのヒント：常に正しいポリシーが適用されるようSLAを設定する方法については、Mat Cropperの記事「Running triggers, automations, and reporting based on ticket SLAs（チケットのSLAに基づくトリガ、自動化、レポーティングの実行）」を参考にしてください。また、タイムゾーン別にSLAを設定する方法については、Mark Powellの記事「Using SLAs with different time zones, contracts, and business hours（異なるタイムゾーン、連絡先、営業時間に応じたSLAを使用する）」をお読みください。

どのようなSLAメトリックを測定できるかについて

返信時間、更新時間、および解決時間のメトリックを含む7つの異なるメトリックについて、SLAサービス目標を定義することができます。

注意：SLAの返信時間をZendeskネイティブの返信時間メトリックと混同しないようにしてください。詳しくは「ZendeskのSLAと初回返信時間」を参照してください。

返信時間のメトリック

返信時間のメトリックは、カスタマーへの応答に関して、チームがどのように成果を出しているのかを理解するのに役立ちます。

返信時間SLAポリシーは現在、チャットチケットまたはメッセージングチケットではサポートされていません。

メモ：パブリックコメントにオートリプライを送るトリガを設定すると、返信時間のメトリックが満たされます。オートリプライを利用できるのは、「高度なAI」アドオンでのみです。

初回返信時間

初回返信時間は、チケットが作成された時刻から、エージェントが最初のパブリックコメントを投稿するまでの時間です。このメトリックを使用して、エージェントがカスタマーに返信するのにかかる時間を指定することができます。

初回返信時間目標は、カスタマーがチケットを送信したときに始まり、エージェントがカスタマーにパブリック返信を行った時点で終了します。これが最も一般的なワークフローであり、典型的な動作です。以下の例では、初回返信時間はセグメントAとBの組み合わせとなります。

エージェントがカスタマーに代わって社内メモ付きチケットを作成する場合、初回返信時間目標は、カスタマーがパブリックコメントを行ったときに始まり、エージェントがパブリック返信を行ったときに終了します。以下の例では、初回返信時間はセグメントC、D、Eの組み合わせとなります。

初回返信時間メトリックに関する以下の考慮事項に注意してください。

エージェントがパブリックコメント付きチケットを作成した場合、チケットの初回返信時間は計算されません。この場合、SLAの初回返信時間の目標が、チケット作成と同時に達成されるからです。達成度をアクティブにしたり、記録したりすることはありません。
ライトエージェントがチケットに社内メモで初回のコメントを行った場合、SLAの初回返信時間目標はそのコメントから始まり、エージェントによる次回のパブリックコメントまで続きます。
サイドカンバセーションチケットのSLA初回返信時間目標には、その他の考慮事項があります。詳しくは、「社内のSLAや子チケットのサイドカンバセーションを利用したOLAポリシーの定義」を参照してください。

次の返信時間

「次の返信時間」は、回答されていないカスタマーのコメントのうち最も古いものが作成されてから、エージェントが次にパブリックコメントを作成するまでの時間です。このメトリックを使用して、チームがカスタマーに返信するまでにかかる時間を設定します。

「次の返信時間目標」は、返信をしていない最も古いカスタマーコメントから始まり、エージェントがパブリックコメントを行った時点で終了します。下の例では、セグメントEが次の返信時間を表します。

以下の例では、次の返信時間はセグメントC、D、Eの組み合わせとなります。

更新時間のメトリック

更新時間のメトリックを使用して、問題を解決している間、どれくらいの頻度でカスタマーに情報を提供するかを設定することができます。

更新間隔

更新間隔は、エージェントによる各パブリックコメント間の時間を計測します。これは、チームからカスタマーに最新情報を提供する頻度と考えてください。

このメトリックは、エージェントのパブリックコメントを開始点として使用し、以降、エージェントがパブリックコメントを追加するたびにリセットされます。以下の例では、更新間隔はセグメントC、D、Eの組み合わせとなります。

一次停止可能な更新

チケットが新規、オープン、および保留中のステータスの場合、エージェントからの各パブリックコメント間の時間を測定します。

メモ：カスタムチケットステータスをアクティブにしている場合、以下の説明が、「オープン」、「待機中」、「保留中」のステータスカテゴリにあるカスタムチケットステータスに適用されます。

エージェントがチケットに費やす時間の予想として、「一次停止可能な更新」メトリックを使用します。以下の例では、一次停止可能な更新はセグメントB、D、Eの組み合わせとなります。

一時停止可能な更新は、エージェントが「新規」、「オープン」、または「待機中」のチケットステータスのチケットに最初のパブリックコメントを行ったときに適用されます。このメトリックは、チケットが「保留中」ステータスに変更されると一時停止します。パブリックコメントを付けずに、または社内メモを付けてステータスが「オープン」または「待機中」に変更されると、メトリックは再開します。

解決時間のメトリック

解決時間のメトリックは、チケットのステータス（カスタムチケットステータスがアクティブな場合はステータスカテゴリ）を使用して、チケットに費やされた時間を測定します。

なお、複数の解決時間メトリックを選択することもできますが、混乱を避けるために1つに絞るのが最善の方法です。

解決時間のメトリックはコメントではなく、常に、チケットの開始、一時停止中、停止のステータスを使用します。以下の図で、解決時間のメトリックがチケットライフサイクルのどの時期に相当するか見てみましょう。

リクエスタの待機時間

リクエスタの待機時間は、チケットが「新規」、「オープン」および「待機中」のステータスにあった合計時間です。

「リクエスタの待機時間」は、チケットが作成された時点で始まり、チケットが解決された時点で終了します。このメトリックは、チケットが「保留中」ステータスになると一時停止します。

以下の例では、リクエスタの待機時間はセグメントA、B、D、Eの組み合わせとなります。

このメトリックを設定する際には、チームが問題を完全に解決するまでにかかる時間を考慮してください。

エージェント作業時間

「エージェント作業時間」は、チケットが「新規」および「オープン」のステータスにあった合計時間です。

チケットのステータスが「待機中」または「保留中」の場合、このメトリックは一時停止します。

以下の例では、エージェント作業時間はセグメントA、B、Eの組み合わせとなります。

このメトリックを設定する場合、エージェントがチケットに費やす時間を考慮してください。

合計の解決時間

「合計の解決時間」は、「保留中」ステータスの時間を含む、チケットの解決にかかる時間の合計です。チケットが作成されてから解決されるまで、チケットのライフサイクル全体を測定します。チケットステータスの変更時に一時停止することはありません。

メトリックを合わせて使うためのベストプラクティス

SLAポリシーのすべてのメトリックに目標を設定する必要はありません。以下の例では、すべてのメトリックとその重なり具合を示しています。

SLAポリシーを設定する場合、測定したい最も関連性の高いメトリックを選択します。以下は、ベストプラクティスの例です。

初回返信時間は簡単で、チームに責任を負わせたいメトリックがわからない場合の出発点としてよいでしょう。
「リクエスタの待機時間」、「エージェント作業時間、または「合計の解決時間」の中から、解決時間のメトリックを1つだけ選択します。
次の返信時間と更新間隔時間の両方のメトリックをアクティブにすることは可能です。目標ステータスには、違反に最も近いメトリックが示されます。

チケットの再オープンがSLAに与える影響

チケットを再オープンした場合、次のメトリックに影響があります。返信時間と更新時間の目標によって新しい目標がアクティブになり、作業時間と待機時間の目標が再度アクティブになります。

初回返信時間、次の返信時間：エンドユーザーのパブリックコメントでチケットが再オープンし、すべての条件が満たされた場合、関連する返信時間メトリックで新しい目標がアクティブになります。
更新間隔、一時停止可能な更新：エンドユーザーのコメントでチケットが再オープンした場合、何も起こりません。パブリックコメントが追加されてチケットが再オープンした場合、関連する更新メトリックで新しい目標がアクティブになります。
エージェント作業時間：このメトリックは、同じターゲットを同じ経過時間/残り時間で再アクティブ化し、「解決済み」ステータスの時間を一時停止と同様に扱います。チケットが「保留中」/「待機中」ステータスになると、チケットが「オープン」ステータスになるまで一時停止したままになります。
リクエスタの待機時間：このメトリックは、同じターゲットを同じ経過時間/残り時間で再アクティブ化し、「解決済み」ステータスの時間を一時停止と同様に扱います。チケットが「保留中」ステータスになると、チケットが「オープン」/「待機中」ステータスになるまで一時停止したままになります。
合計の解決時間：このメトリックは、チケットの作成時刻からカウントを再開し、継続します。