SLA, naptár és eszkalációk

A határidőket a „Settings → SLA” alatt állítja be. Az oldal maga írja ki felül, ha egyetlen szabályzat sem aktív. A szabályzatnak három része van: a név, a feltételek és a célok. Az új szabályzatok szándékosan inaktívan jönnek létre — így be tudja fejezni a beállításukat, mielőtt bármit tennének.

A feltételek a „Team”, a „Priority”, a „Main category” és a „Subcategory”. Az üres azt jelenti: „Any”, vagyis „mindenre vonatkozik” — nem azt, hogy „semmire”. Ha több szabályzat illeszkedik, az nyer, amelyiknek az „Order” alatt a legkisebb a száma; ezért ül a szűk szabályzat felül, az általános pedig alatta.

A két kategóriamező csapatonként van csoportosítva, mert a kategóriák egy csapathoz tartoznak — de a rendszer mindegyiket felkínálja, a más csapatokéit is. Ez szándékos: átadáskor a hibajegy költözik, a kategória nem. Az a hibajegy, amelyet a helpdesk adott át a hálózati csapatnak, továbbra is a helpdesk besorolását viseli, és egy szabályzat pontosan arra mutathat. Ha kiválaszt egy főkategóriát, az alatta lévő mező már csak a hozzá kapcsolt alkategóriákat kínálja — az olyan párost, amely egy hibajegyen nem létezhet, a rendszer mentéskor visszautasítja.

Minden szabályzatnak két célja van. A „Time to first response” egy ügyintéző első nyilvános válaszával ér véget — az automatikus visszaigazolás és a belső feljegyzés kifejezetten nem számít. A „Time to resolution” akkor ér véget, amint a hibajegy megoldottnak számító állapotba kerül (hogy melyik ez, azt a „Settings → General → Status” alatt állítja be). Mindkét célnak saját perce, saját naptára és saját reakciója van a túllépésre.

A hibajegyen a határidők jobb oldalt a „Details” kártyán ülnek, alattuk a „Show deadline history”: napló, amely minden lépést rögzít — elindult, szünetel, folytatódott, teljesült, elmaradt —, mindegyiket okkal és a felhasznált munkaidővel. Csak az ügyintézők és a rendszergazdák látják; az ügyfelek nem tudják lehívni.

Ha valaki később megváltoztatja a prioritást vagy a csapatot, az óra arra a szabályzatra vált, amelyik akkor illeszkedik: az addig felhasznált munkaidőt a rendszer a régi naptárral zárja le, azután pedig az új értékek érvényesek. Ha már egyetlen szabályzat sem illeszkedik, az óra döntés nélkül ér véget — sem teljesültnek, sem túllépettnek nem számít.

Ha a hibajegy létrehozásakor egyetlen szabályzat sem illett rá, az óra akkor indul, amikor egy változás után először illik rá egy szabályzat, például magasabb prioritás esetén. Ettől a pillanattól számol. Az első válasz órája csak akkor indul, ha még senki nem válaszolt.

Új órák csak akkor jönnek létre, ha egy hibajegyet újranyitnak. Más állapotváltások nem hoznak létre új órákat.

A naptár megmondja, mikor telik az óra. Van neve, saját időzónája és hétköznaponként tetszőleges számú idősávja — az ebédszünet egyszerűen egy kétsávos nap. Egy sáv átnyúlhat éjfélen; ilyenkor mellette megjelenik az „ends next day” felirat.

Azt, hogy egy csapatra melyik naptár vonatkozik, a csapaton állítja be („Settings → Teams”). Egy szabályzat egyes célján felül lehet írni: a „From the team” a csapatét veszi, vagy választ egy másikat. Pontosan ez adja ki a szokásos esetet — a hibák körbe-körbe számítanak, minden más csak irodai időben.

A rendszer azt az időt számolja, amely valóban eltelik a sávon belül, nem az óraállások különbségét. Az óraátállításkor ez különbséget jelent: egy folyamatos nap októberben 25 órás, egy 22:00-tól 06:00-ig tartó éjszakai műszak tavasszal nyolc helyett hét. Egy 09:00-tól 17:00-ig tartó irodai sávot ez soha nem érint, mert az EU-ban éjszaka történik az átállítás.

Ha nem található nyitvatartással rendelkező naptár, nem jön létre határidő — jobb, ha nincs, mint ha kitalált lenne. A hibajegyen dátum helyett megjegyzés jelenik meg.

Minden naptár alatt ott ül a „Closed days” lista. Az „Import holidays (.ics)” gombra kattintva a rendszer átvesz egy naptárfájlt, és utána négy számot jelent: hány napot vett át, hányat cserélt le, hány volt olvashatatlan, és hány volt már meg. Egyes napokat kézzel is bevihet.

A nap mögötti ↻ jel azt jelenti: „évente ismétlődik”. Ez csak rögzített dátumoknál helyes: október 3. minden évben ugyanarra a dátumra esik, a nagypéntek és a pünkösdhétfő viszont a húsvét dátumán lóg, és mozog. A mozgó ünnepek ezért évenként a konkrét dátumukkal állnak a listában — a képen a „Good Friday” a jel nélkül.

A zárva tartó nap elnyeli az adott nap teljes sávját, azt a részt is beleértve, amely a következő napba nyúlik át. És ha egy naptár a következő tizenkét hónapra egyetlen zárva tartó napot sem ismer, az oldal ezt kifejezetten kiírja — különben a rendszer csendben átszámol az ünnepnapokon, és rossz határidőket ad.

A határidőkről szóló leggyakoribb vita ez: a hibajegy három napja vár az ügyfél válaszára, és az óra mégis tovább telik. Ezért van minden célnál a „Pause while waiting for the requester” kapcsoló — egyenként, nem az egész szabályzatra.

Azt, hogy várunk-e, az állapot dönti el: a „Settings → General → Status” alatt minden állapot visel egy jelölést arról, hogy „a bejelentőre vár”-nak számít-e. Bekapcsolt kapcsolóval a határidő nyugszik, amíg a hibajegy ilyen állapotban ül. A fali óra tovább jár — ezért mutat a lista hátralévő idő helyett „Paused” feliratot, a határidő-előzmények pedig a „Paused” és a „Resumed” bejegyzést tartalmazzák az időpontjukkal. A várakozási idő akkor sem számít, ha a hibajegyet közvetlenül ilyen állapotból oldják meg.

Az első válasznál a kapcsolót rendszerint kikapcsolva hagyja: az első válasszal attól függetlenül tartozik, hogy mire várunk. A megoldásnál rendszerint be van kapcsolva. A kép pontosan ezt a beállítást mutatja.

Amint egy szabályzat aktív, a hibajegylista megkapja a „Deadline” oszlopot. Az a következő nyitott határidő hátralévő idejét mutatja („14h 53m”). Ha a hibajegyen már egyetlen határidő sem fut, a döntés áll ott: az „In time” jelölés a teljesültnél, a piros „Breached” az elmulasztottnál. Az óra nélküli hibajegy semleges gondolatjelet kap, és ez szándékos: a szabályzat előtti hibajegy nem kudarc.

Ha egyetlen szabályzat sem aktív, az oszlop teljesen hiányzik — nem áll ott üresen. Ugyanez érvényes a szűrőre: a „Filter” alatt a „Breached only” doboz csak akkor jelenik meg, ha egyáltalán vannak határidők.

Egy hibajegynek két órája van, az oszlopnak viszont csak egy helye — a legsürgetőbb NYITOTT határidőt mutatja. Ha az első választ elmulasztották, és a megoldás még fut, az oszlop a megoldás hátralévő idejét mutatja, mellette egy piros „!” jellel. Az a jel azt mondja: ezen a hibajegyen egy határidőt már túlléptek — és pontosan így találja meg a „Breached only” szűrő, mert az bármelyik túllépett határidőre rákérdez, arra is, amelyik régen lezárult. Hogy a kettő közül melyiket érintette, az magában a hibajegyben áll.

Rendezni is lehet szerinte: ugyanaz alatt a „Deadline” cím alatt ül egy mező a „Due soonest first” és a „Due latest first” értékkel. A futó óra nélküli hibajegyek mindig a végére kerülnek — nem ők a legkevésbé sürgetők, egyszerűen nem érintettek. A határidő szerinti rendezés megelőzi az „Updated at” szerintit: egyetlen lista sem tud egyszerre két sorrendnek megfelelni.

Célonként a „When breached” alatt állítja be, mi történjen túllépéskor: a „Record only” csak rögzíti, a „Notify assignee and observers” levelet küld a felelősnek és a megfigyelőknek (nem az egész csapatnak), a „Hand over to another team” pedig átadja a hibajegyet. Az átadáshoz célcsapatot kell választania — a nélküle mentett szabályzatot a rendszer visszautasítja, mert beállítottnak látszana, és semmit nem tenne.

A művelet minden egyes órán pontosan egyszer fut le. Ilyen retesz nélkül a kiszolgáló újraindítása újra elküldené ugyanazt a levelet. A „már megtörtént” jelölést a rendszer akkor is beállítja, ha a küldés meghiúsult — a meg nem érkezett levél jobb, mint az a hurok, amely percenként újat küld.

Magát a túllépést a rendszer arra a pillanatra keltezi, amikor esedékessé vált, nem az ellenőrzési futásra — különben a kimutatás az ellenőrző szolgáltatás ritmusán lógna. És a felhasznált munkaidőhöz méri: a szünetelő óra nem tud túllépni, akkor sem, ha az esedékesség régen elmúlt.

Az átadás az állapotot visszaállítja „Open” értékre. Az erről szóló előzménysorok belsők; az ügyfél csak az új állapotot és az új csapatot látja a hibajegyen.

A „Reports” alatt kiválasztja az időszakot, és megnyomja a „Generate report” gombot — e kattintás nélkül az oldal üres marad. A kimutatás ezután tartalmazza a „Service level agreements” blokkot, célonként egy sorral: teljesült, túllépett, még fut, elért arány és az átlagos felhasznált idő.

A számolás célonként történik, nem hibajegyenként — ez a táblázat alatt is ott áll. A mindkét céllal rendelkező hibajegy tehát kétszer jelenik meg, soronként egyszer.

Az elért arány csak az eldőlt órákat számolja. A futók nem tartoznak a nevezőbe, különben minden frissen bekapcsolt SLA eleinte katasztrofálisnak látszana, majd magától javulna. Ha még egyetlen eldőlt óra sincs, gondolatjel jelenik meg — nem „0 %”.

Ha csoportos üzemzavarokkal dolgozik, van egy további „Achieved without group incidents” sor: egy csoportos üzemzavar száz csatolt hibajeggyel különben mindkét irányban torzítaná az arányt. Kihagy minden olyan hibajegyet, amely egy csoportos üzemzavarhoz kapcsolódik.

Az ügyintézők ebben a blokkban csak a saját csapataikat látják. Professional nélkül a blokk csak akkor jelenik meg, ha vannak korábbi határidőadatok; ezek ekkor olvashatók maradnak.