概要
この記事では、既存のサービス レベル アグリーメント (SLA) 主要業績評価指標 (KPI) の顧客サービスおよび祝日スケジュールへの変更を管理する方法について説明します。
SLA KPI の時間計算を理解する
SLA KPI の顧客サービスおよび祝日スケジュールの変更を管理するには、最初に SLA KPI の時間計算がどのように機能するかを理解する必要があります。 SLA KPI の時間計算は、警告時間と失敗時間、および SLA KPI アイテムに関連付けられた顧客サービスと祝日スケジュールによって異なります。
以下は、時間計算がどのように機能するかを説明する SLA KPI の例です。 SLA KPI に設定されている構成は次のとおりです。
- 定義された作業時間: 午前 9 時から午後 5 時 (毎日 8 時間)
- 失敗期間: 12 時間
- 祝日カレンダー: 翌日は祝日としてマークされます。
- サポート案件は本日午前 10 時に作成されました。
したがって、時間の計算後、失敗期間は翌日の 14:00 (午後 2 時) になります。 これは、その日の残り時間を考慮して計算されます。つまり、午後 5 時から午前 10 時 = 7 時間であり、翌日には 5 時間残ります (失敗期間 - 本日の消費時間で計算)。 翌日は祝日のため計算されません。 したがって、失敗期間は翌々日となります: 午前 9 時+ 5 時間 = 14:00 (午後 2 時)。
顧客サービス スケジュールの作成の詳細については、「 顧客サービス スケジュールを作成し、作業時間を定義する」を参照してください。 休日のスケジュールの作成の詳細については、「 休日のスケジュールを作成および管理する」を参照してください。
警告および失敗時間の計算とは別に、SLA 時間の計算には、SLA KPI が一時停止および再開された場合に発生する経過時間の計算も含まれます。 SLA KPI が一時停止状態にある間の作業時間を無視するために、最終的なエラー発生時間の計算には経過時間を使用します。
シナリオとレコメンデーション
SLA KPI インスタンスが作成されるたびに、SLA KPI の時間計算を理解する セクションに記載されている要因に応じて、警告と失敗時間が作成されます。 カレンダーの作業時間の変更は、既存の KPI インスタンスに影響しません。
ただし、既存の KPI インスタンスに影響を与える次のシナリオがある場合があります。
- SLA KPI インスタンスの一時停止と再開。
- ターゲット エンティティでの SLA の更新。
- SLA アイテムでの変更。
- ターミナルの状態から SLA KPI インスタンスの再適用 (ターミナル状態で再計算の場合)。
上記のシナリオでは、SLA KPI の警告と失敗時間は、新しい顧客サービス スケジュールと祝日スケジュールを使用して再計算します。 ただし、既存の SLA KPI インスタンスですでに使用されている既存の顧客サービスと祝日スケジュールを変更する場合は、次のセクションで提供されるレコメンデーションを実装できます。
注意
変更を実稼働環境に適用する前に、すべてのシナリオとレコメンデーションを検証して、すべての条件が満たされていることを確認する必要があります。
シナリオ 1:
条件:
- デフォルトとして設定される SLA KPI は 1 つだけです。
- 1 つのカレンダーを関連付ける必要があります。
- 複数の SLA アイテム。
- 一時停止および再開シナリオあり/なし。
- 既存の実行中の KPI インスタンスを更新する必要はありません。
レコメンデーション:
既存の SLA とカレンダーを変更しないでください。 既存の SLA は、実稼働環境でアクティブな状態を維持し続けることができます。 新しいカレンダーと同じ種類の SLA アイテムを使用して同様の SLA を作成します。
新しい SLA をアクティブにして、デフォルトとして設定します。 これにより、すべての新しいサポート案件が新しい SLA で作成され、時間の計算が新しいカレンダー情報で実行されるようになります。 既定の SLA を使用しない場合、SLA 条件を更新して、サポート案件エンティティの SLA ID を適宜更新します。 詳細については、「 SLA の適用」を参照してください。
シナリオ 2
条件:
- 複数の SLA
- 複数のカレンダーを関連付ける必要があります。
- 複数の SLA アイテム。
- 一時停止および再開シナリオあり/なし。
- 既存の実行中の KPI インスタンスを更新する必要はありません。
レコメンデーション:
既存の SLA とカレンダーを変更しないでください。 以前の SLA は、実稼働環境でアクティブな状態を維持し続けることができます。 新しいカレンダーと同じ種類の SLA アイテムを使用して同様の SLA を作成します。
新しい SLA をアクティブ化します。 これにより、すべての新しいサポート案件が新しい SLA で作成され、時間の計算が新しいカレンダー情報で実行されるようになります。
SLA 条件を更新して、サポート案件エンティティの SLA ID を適宜更新します。 詳細については、「 SLA の適用」を参照してください。
シナリオ 3
条件:
- 複数の SLA。
- 複数のカレンダー。
- 複数の SLA アイテム。
- 一時停止と再開のシナリオは含まれていません。
- 既存の実行中の KPI インスタンスを更新する必要があります。
レコメンデーション:
既存のカレンダーを調節すると、すべての新しいサポート案件が同じ SLA で作成され、時間の計算が新しいカレンダー情報で実行されるようになります。 ただし、既存の実行中の KPI インスタンスは、新しいカレンダーに基づいて警告および失敗時間を自動的に計算しません。 KPI インスタンスのイベントを開始して、新しいカレンダーを選択する必要があります。
たとえば、一時停止状態を導入し、クイック一時停止をトリガーしてから、サポート案件の更新を再開します。 これにより、KPI インスタンスが新しいカレンダー情報を選択するようになります。 一時停止と再開を開始するには、顧客サービス担当者が各サポート案件を個別に手動で更新するか、カスタム ロジックを実装して、アクティビティが最も少ない時間帯にサポート案件を更新します。
たとえば、フローは、次のロジックを使用して、アクティビティが最も少ない時間帯に実行できます。
- 更新が必要なカレンダーから関連する SLA を見つけます。
- 上記の SLA と同じ SLA ID フィールド値を持つすべてのインシデントを検索します。 これをバッチで実行して、スケーラビリティの問題が発生しないようにすることができます。
- サポート案件を更新して、一時停止状態にします。
- サポート案件の次の更新を実行します。これにより、サポート案件が再開に戻ります。
詳細については、「 SLA の適用」を参照してください。
シナリオ 4
条件:
- 複数の SLA
- 複数のカレンダーを関連付ける必要があります。
- 複数の SLA アイテム。
- 一時停止および再開シナリオが含まれます。
- 既存の実行中の KPI インスタンスを更新する必要があります。
レコメンデーション:
これは複雑なシナリオであり、完全に実装することはできません。 新しいカレンダーが適用される前に一時停止または再開状態に設定された KPI インスタンスでは、そのようなインスタンスの経過時間が古いカレンダーの一時停止、または再開状態中にすでに計算されている可能性があるため、予期しない結果が生じる可能性があります。 したがって、最終的な計算は、一部は古いカレンダーで、一部は新しいカレンダーで行われる可能性があります。