サービスレベル合意、カレンダー、エスカレーション

期限の設定は「Settings → SLA」で行います。有効なポリシーがない場合、ページの上部がそう伝えます。ポリシーは3つの部分からできています。名前、条件、目標です。新しいポリシーは、意図的に無効の状態で作られます。何かが動き出す前に、設定を仕上げられるようにするためです。

条件は「Team」「Priority」「Main category」「Subcategory」です。空欄は「Any」、つまり「すべてに当てはまる」であって、「何にも当てはまらない」ではありません。複数のポリシーが当てはまる場合は、「Order」の数字がいちばん小さいものが優先されます。だからこそ、狭いポリシーを上に、一般的なものを下に置きます。

2つのカテゴリの欄は、チームごとにまとめられています。カテゴリはチームに属するためです。ただし、ほかのチームのものも含めて、すべてが提示されます。これは意図した設計です。引き渡しでチケットは移りますが、カテゴリは移りません。ヘルプデスクからネットワークチームに渡されたチケットは、ヘルプデスクの分類を持ったままで、ポリシーがまさにそれを指すこともあります。大分類を選ぶと、下の欄には、それにひも付いた小分類だけが並びます。チケットに存在しえない組み合わせは、保存のときに拒否されます。

どのポリシーにも、目標が2つあります。「Time to first response」は、エージェントによる最初の公開の返信で終わります。自動の受付の連絡と内部メモは、はっきり数えません。「Time to resolution」は、解決済みとして数えるステータスにチケットが達した時点で終わります。どのステータスがそれに当たるかは、「Settings → General → Status」で設定します。目標にはそれぞれ、独自の分数、独自のカレンダー、超過時の独自の動作があります。

チケットでは、期限が右の「Details」のカードにあり、その下に「Show deadline history」があります。開始、一時停止、再開、達成、超過といったすべての段階が、理由と、使われた作業時間とともに記録されます。見られるのはエージェントと管理者だけで、顧客には取得できません。

あとから優先度やチームが変わると、時計はそのとき当てはまるポリシーに切り替わります。それまでに使った作業時間は古いカレンダーで確定し、以降は新しい値が適用されます。当てはまるポリシーがなくなった場合、時計は判定なしで終わります。達成にも超過にも数えません。

チケットを作ったときに当てはまるポリシーがなかった場合、変更のあとで初めてポリシーが当てはまったとき、たとえば優先度が上がったときに、時計が動き出します。数えるのは、その時点からです。初回応答の時計が動き出すのは、まだ誰も返信していない場合だけです。

新しい時計が生まれるのは、チケットが再オープンされたときだけです。ほかのステータスの変更では、新しい時計はできません。

カレンダーは、時計がいつ進むかを定めます。名前、独自のタイムゾーン、曜日ごとの任意の数の時間帯を持ちます。昼休みは、単に時間帯が2つある日です。時間帯は日付をまたげます。その場合、横に「ends next day」と表示されます。

どのカレンダーがチームに当てはまるかは、チームの側で設定します（「Settings → Teams」）。ポリシーの個々の目標では、それを上書きできます。「From the team」でチームのものを使うか、別のものを選びます。これが、よくある形を作ります。障害は24時間通しで数え、ほかは営業時間だけで数える、という形です。

数えるのは、時間帯の中で実際に過ぎた時間であって、時計の表示の差ではありません。夏時間の切り替えでは、これが差になります。24時間通しの日は、10月には25時間あり、春の22時から6時までの夜勤は、8時間ではなく7時間になります。9時から17時の営業時間帯は影響を受けません。EU では切り替えが夜間に行われるためです。

営業時間のあるカレンダーが見つからない場合、期限は作られません。当て推量の期限より、期限がないほうがよいためです。チケットには、日付の代わりに注記が表示されます。

どのカレンダーの下にも「Closed days」の一覧があります。「Import holidays (.ics)」をクリックするとカレンダーのファイルを取り込み、そのあと4つの数値を示します。何日が反映され、何日が置き換わり、何日が読めず、何日がすでにあったかです。1日ずつ手で入力することもできます。

日付の後ろの ↻ の記号は「毎年繰り返す」という意味です。これが正しいのは、日付の固定された祝日だけです。10月3日は毎年同じ日付ですが、聖金曜日と聖霊降臨祭の月曜は復活祭の日付にひも付いており、毎年移動します。そのため、移動する祝日は年ごとの具体的な日付で一覧に並びます。図では「Good Friday」に記号が付いていません。

休業日は、その日の時間帯を丸ごと飲み込みます。翌日にまたがる部分も含みます。また、今後12か月に休業日を1日も知らないカレンダーがあれば、ページがはっきりその旨を伝えます。そうしなければ、システムは黙って祝日を通して数え、誤った期限を作ってしまいます。

期限をめぐって最もよく起きる言い争いが、これです。チケットは3日間、顧客の返事を待っているのに、時計は進み続ける、というものです。そのため、どの目標にも「Pause while waiting for the requester」のスイッチがあります。ポリシー全体ではなく、目標ごとに設定します。

待っているかどうかは、ステータスで決まります。「Settings → General → Status」で、ステータスごとに「依頼者を待っている」と数えるかどうかの印が付きます。スイッチがオンなら、チケットがそうしたステータスにある間、期限は止まります。実際の時計は進み続けます。だからこそ一覧には残り時間ではなく「Paused」と表示され、期限の履歴に「Paused」と「Resumed」が時刻とともに残ります。チケットがそうしたステータスから直接解決された場合も、待っていた時間は数えません。

初回の返信では、ふつうスイッチをオフのままにします。何を待っていようと、最初の返信はこちらの責任だからです。解決では、ふつうオンにします。図は、まさにその設定です。

ポリシーが有効になると、チケット一覧に「Deadline」の列が加わります。次に来る未確定の期限の残り時間が表示されます（「14h 53m」）。チケットのどの期限も動いていなければ、そこに判定が並びます。達成なら「In time」のバッジ、超過なら赤い「Breached」です。時計のまったくないチケットには、中立のダッシュが出ます。これは意図した設計です。ポリシーより前のチケットは、失敗ではありません。

有効なポリシーがなければ、列そのものが現れません。空のまま並ぶことはありません。絞り込みも同じです。「Filter」の中の「Breached only」の項目は、期限が存在するときにだけ現れます。

1件のチケットには時計が2つありますが、列は1つしかありません。列は、最も差し迫った「未確定の」期限を表示します。初回の返信が超過し、解決がまだ進行中なら、列には解決の残り時間が出て、その横に赤い「!」が付きます。この印は、このチケットではすでに期限を超過したものがある、という意味です。「Breached only」の絞り込みが見つけるのも、まさにこれです。とうに終わったものも含め、超過した期限があるかどうかを尋ねるためです。どちらの期限だったかは、チケットの中に書かれています。

並べ替えもできます。同じ「Deadline」の見出しの下に、「Due soonest first」と「Due latest first」の欄があります。時計の動いていないチケットは、常に最後に来ます。緊急度が最も低いのではなく、単に対象外だからです。期限での並べ替えは、「Updated at」での並べ替えより優先されます。1つの一覧が、2つの順序を同時に満たすことはできません。

目標ごとに、「When breached」で超過したときに何が起きるかを設定します。「Record only」は記録するだけ、「Notify assignee and observers」は担当者とウォッチャーにメールを送り（チーム全体には送りません）、「Hand over to another team」はチケットを引き渡します。引き渡しでは、渡し先のチームを選ぶ必要があります。指定のないポリシーは、保存のときに拒否されます。設定されているように見えて、何もしないためです。

動作は、1つの時計につき、ちょうど1回だけ実行されます。この掛け金がなければ、サーバーを再起動するたびに、同じメールがもう一度送られてしまいます。「実行済み」の印は、送信に失敗した場合でも付きます。届かなかったメールのほうが、毎分新しく送り続ける繰り返しよりましだからです。

超過そのものは、確認の実行時ではなく、期限が来た瞬間の日時で記録されます。そうでなければ、レポートが確認処理の周期に左右されてしまいます。判定は、使われた作業時間に対して行われます。止まっている時計は、期限の日時をとうに過ぎていても超過できません。

引き渡すと、ステータスは「Open」に戻ります。それについての履歴の行は内部向けで、顧客にはチケットの新しいステータスと新しいチームだけが見えます。

「Reports」で期間を選び、「Generate report」を押します。このクリックがなければ、ページは空のままです。レポートには「Service level agreements」の部分があり、目標ごとに1行ずつ、達成、超過、進行中、達成率、平均の所要時間が並びます。

数えるのはチケットごとではなく、目標ごとです。表の下にも、そう書かれています。2つの目標を持つチケットは、それぞれの行に1回ずつ、計2回現れます。

達成率が数えるのは、判定の出た時計だけです。進行中のものは分母に入りません。そうでなければ、導入したばかりのサービスレベル合意はどれも最初はひどい数字になり、あとから勝手に良くなってしまいます。判定の出た時計が1つもなければ、「0 %」ではなくダッシュが表示されます。

大規模障害を使っている場合は、「Achieved without group incidents」の行が加わります。100件の報告がひも付いた1件の大規模障害は、そうしなければ、率を両方向にゆがめてしまいます。この行は、大規模障害にひも付いたチケットをすべて除きます。

エージェントがこの欄で見られるのは、自分のチームだけです。Professional がない場合、この欄は以前の期限のデータがあるときだけ表示され、そのデータは読めるまま残ります。