サービスレベルアグリーメント（SLA）ポリシーは、サポートチームがお客様との間で、応答および解決策を提供するまでのそれぞれの時間を取り決めたものです。
たとえば、緊急のチケットには10分で対応し、2時間以内に解決するという契約を定義することができます。メッセージングを使用しているなら、初回返信時間30秒を目標とするSLAを定義したい場合もあるかもしれません。
SLAポリシーを設定する
各SLAポリシーは、チケットが満たすべき条件と、測定対象として選択したメトリックで構成される所定の構造を持ちます。詳しくは「メトリックを組み合わせて使うためのベストプラクティス」を参照してください。
SLAポリシーを設定するには
- 管理センターで、サイドバーの「
オブジェクトとルール」をクリックし、「ビジネスルール」>「サービスレベルアグリーメント」を選択します。 - 「ポリシーを作成」をクリックします。
- 「ポリシー名」を入力します。
- 必要に応じて、「説明」を入力し、「次へ」をクリックします。
- ポリシーの条件を選択します。
条件の最初の数文字を入力するか（自動入力機能で残りは自動入力されます）、ドロップダウンメニューからオプションを選択します。
- 「次へ」をクリックします。
返信のメトリック、更新のメトリック、解決のメトリックを定義するオプションが表示されます。なお、SLAポリシーを設定する際にすべてのメトリックに目標を設定する必要はありません。
- 定義したいSLAメトリックの「目標を追加」をクリックし、メニューから目標を選択します。
- チケットの優先度ごとに目標時間を入力します。
メモ：設定できる最小の目標時間は15秒です。時間、分、または秒で入力することができます。 - それぞれの優先度について、「時間の種類」で「カレンダー時間」または「営業時間」を選択します。
- 「追加」をクリックします。
定義したメトリックがポリシーに追加されます。
- 「目標を追加」をクリックしてメニューから目標を選択して、さらにメトリックを追加します。または、「ポリシーを保存」をクリックして終了します。
既存の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のカスタマイズ」を参照してください。
SLAを定義する前に、SLAポリシーがチケットにどのように適用されるかを理解しておいてください。
返信時間のメトリック
返信時間のメトリックは、カスタマーへの応答に関して、チームがどのように成果を出しているのかを理解するのに役立ちます。
返信時間のSLAポリシーは、すべてのチケット、チャット、およびメッセージングの会話に適用されます。チャットの会話に対する返信時間SLAがオンになっていない場合、パブリック返信のみが返信時間SLAにカウントされることに注意してください。詳しくは「オンラインチャットの返信時間SLA」を参照してください。
初回返信時間
初回返信時間は、チケットが作成された時刻から、エージェントが最初のパブリックコメントを投稿するまでの時間です。このメトリックを使用して、エージェントがカスタマーに返信するのにかかる時間を指定することができます。
初回返信時間目標は、カスタマーがチケットを送信したときに始まり、エージェントがカスタマーにパブリック返信を行った時点で終了します。これが最も一般的なワークフローであり、典型的な動作です。以下の例では、初回返信時間はセグメント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に与える影響
- 初回返信時間、次の返信時間：エンドユーザーのパブリックコメントでチケットが再オープンし、すべての条件が満たされた場合、関連する返信時間メトリックで新しい目標がアクティブになります。
- 更新間隔、一時停止可能な更新：エンドユーザーのコメントでチケットが再オープンした場合、何も起こりません。パブリックコメントが追加されてチケットが再オープンした場合、関連する更新のメトリックで新しい目標がアクティブになります。
- エージェント作業時間：このメトリックは、同じターゲットを同じ経過時間/残り時間で再アクティブ化し、「解決済み」ステータスの時間を一時停止と同様に扱います。チケットが「保留中」/「待機中」ステータスになると、チケットが「オープン」ステータスになるまで一時停止したままになります。
- リクエスタの待機時間：このメトリックは、同じターゲットを同じ経過時間/残り時間で再アクティブ化し、「解決済み」ステータスの時間を一時停止と同様に扱います。チケットが「保留中」ステータスになると、チケットが「オープン」/「待機中」ステータスになるまで一時停止したままになります。
- 合計の解決時間：このメトリックは、チケットの作成時刻からカウントを再開し、継続します。「解決済み」ステータスにあった時間は一時停止として扱われ、目標時間には含まれません。