SLA, календар и ескалации

Сроковете настройвате под „Settings → SLA“. Самата страница ви казва най-горе, когато никоя политика не е активна. Политиката има три части: име, условия и цели. Новите политики нарочно се създават неактивни — за да можете да ги довършите, преди да направят каквото и да е.

Условията са „Team“, „Priority“, „Main category“ и „Subcategory“. Празно означава „всяко“, тоест „важи за всичко“ — а не „не важи за нищо“. Ако съвпаднат няколко политики, печели тази с най-малкото число под „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“ с по един ред за всяка цел: спазени, просрочени, още течащи, постигнат дял и средно използвано време.

Броенето става за всяка цел, а не за всяка заявка — това пише и под таблицата. Затова заявка с двете цели се появява два пъти, по веднъж във всеки ред.

Постигнатият дял брои само приключилите часовници. Течащите не спадат в знаменателя, иначе всяко току-що включено SLA първо би изглеждало катастрофално и после би се подобрявало само. Ако още няма нито един приключил часовник, се появява тире — а не „0 %“.

Ако работите с групови инциденти, има допълнителен ред „Achieved without group incidents“: един-единствен групов инцидент със сто прикачени заявки иначе би изкривил дела и в двете посоки. Той изключва всяка заявка, която е свързана с групов инцидент.

Операторите виждат в този блок само собствените си екипи. Без Professional блокът се появява само ако има данни за срокове отпреди; тогава той остава четим.