Рівень обслуговування, календар та ескалації

Терміни налаштовують під «Settings → SLA». Сторінка сама вгорі каже, коли жодна політика не діє. Політика має три частини: назву, умови та цілі. Нові політики навмисно створюють недіючими, щоб ви могли доналаштувати їх до того, як вони почнуть щось робити.

Умови — це «Team», «Priority», «Main category» і «Subcategory». Порожнє означає «Any», тобто «стосується всього», а не «не стосується нічого». Якщо підходить кілька політик, виграє та, що має найменше число під «Order»; саме тому вузька політика стоїть угорі, а загальна під нею.

Два поля категорій згруповано за командами, бо категорії належать команді, — але пропонують вам усі, зокрема й категорії інших команд. Так зроблено навмисно: при передаванні заявка переходить, а категорія ні. Заявка, яку служба підтримки передала мережевій команді, і далі несе класифікацію служби підтримки, і політика може вказувати саме на неї. Щойно ви оберете основну категорію, поле нижче пропонуватиме лише пов'язані з нею підкатегорії — пару, якої не може бути на заявці, відхиляють при збереженні.

Кожна політика має дві цілі. «Time to first response» завершується першою відкритою відповіддю оператора — автоматичне підтвердження та внутрішня нотатка прямо не рахуються. «Time to resolution» завершується, щойно заявка досягає статусу, що вважається розв'язаним (який саме, ви задаєте під «Settings → General → Status»). Обидві цілі мають власні хвилини, власний календар і власну відповідь на порушення.

На заявці терміни стоять праворуч у картці «Details», під ними «Show deadline history»: журнал, що записує кожен крок — початок, паузу, продовження, дотримання, порушення, — кожен із причиною та витраченим робочим часом. Його бачать лише оператори та адміністратори; клієнтам він недоступний.

Якщо хтось згодом змінює пріоритет або команду, годинник переходить на політику, що підходить тоді: витрачений досі робочий час зараховують за старим календарем, а далі діють нові значення. Якщо жодна політика більше не підходить, годинник завершується без вироку — він не рахується ні дотриманим, ні порушеним.

Якщо при створенні заявки жодна політика не підійшла, годинник запускається тоді, коли після якоїсь зміни, наприклад вищого пріоритету, політика підходить уперше. Він рахує від цієї миті. Годинник першої відповіді запускається лише тоді, коли ще ніхто не відповів.

Нові годинники постають лише тоді, коли заявку відкривають повторно. Інші зміни статусу нових годинників не створюють.

Календар каже, коли годинник іде. Він має назву, власний часовий пояс і будь-яку кількість проміжків на день тижня — обідня перерва це просто день із двома проміжками. Проміжок може тривати за північ; тоді поруч з'являється «ends next day».

Який календар діє для команди, задають на команді («Settings → Teams»). На окремій цілі політики його можна перебити: «From the team» бере календар команди, або ви обираєте інший. Саме так постає звичайний випадок — збої рахують цілодобово, а все інше лише в години роботи.

Рахують той час, що справді минає всередині проміжку, а не різницю між показами годинника. При переході на літній час це дає різницю: цілодобовий день у жовтні має 25 годин, а нічна зміна з 22:00 до 06:00 навесні — сім замість восьми. Робочого проміжку з 09:00 до 17:00 це не стосується ніколи, бо в ЄС перехід відбувається вночі.

Якщо календаря з відкритими годинами знайти не вдається, терміну не створюють — краще жодного, ніж вгаданий. На заявці замість дати з'являється примітка.

Під кожним календарем стоїть список «Closed days». Натискання на «Import holidays (.ics)» приймає файл календаря й потім повідомляє чотири числа: скільки днів перейнято, скільки замінено, скільки не прочитано і скільки вже було. Окремі дні можна вводити й вручну.

Символ ↻ за днем означає «повторюється щороку». Він правильний лише для сталих дат: 3 жовтня щороку припадає на ту саму дату, а Страсна п'ятниця та Трійця залежать від дати Великодня й рухаються. Тому рухомі свята стоять у списку з конкретною датою на рік — на зображенні «Good Friday» без символа.

Неробочий день поглинає весь проміжок цього дня, зокрема ту частину, що заходить у наступний. А коли календар на найближчі дванадцять місяців не знає жодного неробочого дня, сторінка про це прямо каже — інакше система тихо рахувала б через свята й видавала хибні терміни.

Найчастіша суперечка про терміни саме така: заявка три дні чекає на відповідь клієнта, а годинник усе одно йде. Тому кожна ціль має перемикач «Pause while waiting for the requester» — окремо, а не на всю політику.

Чи ви чекаєте, вирішує статус: під «Settings → General → Status» кожен статус має позначку про те, чи вважається він «чеканням на заявника». З увімкненим перемикачем термін спочиває, поки заявка стоїть у такому статусі. Настінний годинник іде далі — тому список показує «Paused» замість залишку часу, а історія термінів містить «Paused» і «Resumed» із їхнім часом. Час очікування не рахується й тоді, коли заявку розв'язують просто з такого статусу.

Для першої відповіді перемикач зазвичай лишають вимкненим: першу відповідь ви винні незалежно від того, чого чекають. Для розв'язання його зазвичай вмикають. Зображення показує саме таке налаштування.

Щойно політика починає діяти, у списку заявок з'являється стовпець «Deadline». Він показує залишок часу наступного відкритого терміну («14h 53m»). Коли на заявці більше не йде жоден термін, там стоїть вирок: позначка «In time» для дотриманого, червона «Breached» для порушеного. Заявка без жодного годинника отримує нейтральний прочерк, і це навмисно: заявка з часів до політики не є невдачею.

Якщо жодна політика не діє, стовпця немає взагалі — він не стоїть порожнім. Те саме з фільтром: під «Filter» поле «Breached only» з'являється лише тоді, коли терміни взагалі є.

Заявка має два годинники, а стовпець — лише одне місце: він показує найтерміновіший ВІДКРИТИЙ термін. Якщо першу відповідь порушено, а розв'язання ще триває, стовпець показує залишок часу розв'язання з червоним «!» поруч. Ця позначка каже: на цій заявці термін уже порушено — і саме так її знаходить фільтр «Breached only», бо він питає про будь-який порушений термін, зокрема й давно завершений. Який саме з двох це був, написано в самій заявці.

За ним можна й сортувати: під тим самим заголовком «Deadline» стоїть поле з «Due soonest first» і «Due latest first». Заявки без чинного годинника завжди опиняються останніми — вони не найменш термінові, вони просто не зачеплені. Сортування за терміном має перевагу над сортуванням за «Updated at»: жоден список не може задовольнити два порядки водночас.

Для кожної цілі ви задаєте під «When breached», що відбувається при порушенні: «Record only» лише записує, «Notify assignee and observers» надсилає лист виконавцеві та спостерігачам (а не всій команді), «Hand over to another team» передає заявку. Для передавання треба обрати цільову команду — політику без неї відхиляють при збереженні, бо вона мала б вигляд налаштованої й нічого не робила б.

Дія виконується рівно один раз на годинник. Без цього засува перезапуск сервера надіслав би той самий лист знову. Позначку «вже зроблено» ставлять навіть тоді, коли надсилання не вдалося, — лист, який не дійшов, кращий за коло, що щохвилини надсилає новий.

Саме порушення датують тією миттю, коли настав строк, а не проходом перевірки, — інакше звітність висіла б на ритмі служби перевірки. І міряють його за витраченим робочим часом: спинений годинник порушити не може, навіть коли строк давно минув.

Передавання скидає статус на «Open». Рядки історії про це внутрішні; клієнт бачить на заявці лише новий статус і нову команду.

Під «Reports» ви обираєте період і натискаєте «Generate report» — без цього натискання сторінка лишається порожньою. Звіт тоді містить блок «Service level agreements» із рядком на кожну ціль: дотримано, порушено, ще триває, досягнута частка й середній витрачений час.

Рахують за цілями, а не за заявками — про це написано й під таблицею. Тому заявка з обома цілями з'являється двічі, по разу в кожному рядку.

Досягнута частка враховує лише вирішені годинники. Чинним не місце в знаменнику, інакше кожен щойно ввімкнений рівень обслуговування спершу мав би жахливий вигляд і покращувався б сам собою. Якщо жодного вирішеного годинника ще немає, з'являється прочерк, а не «0 %».

Якщо ви працюєте з груповими інцидентами, є ще рядок «Achieved without group incidents»: один груповий інцидент із сотнею долучених заявок інакше спотворив би частку в обидва боки. Він не враховує жодної заявки, пов'язаної з груповим інцидентом.

Оператори бачать у цьому блоці лише власні команди. Без Professional блок з'являється лише тоді, коли є дані про терміни з минулого; тоді він лишається доступним для читання.