Eskalácia v ITSM nie je „nech tým vie, že incident je dlho otvorený". Je to predefinovaná, naprogramovaná postupnosť akcií, ktoré GLPI vykoná automaticky, keď incident nepostupuje podľa SLA. Bez eskalačných pravidiel je SLA len dátum v databáze. S nimi je SLA proces, ktorý funguje aj keď je technik na obede, na schôdzke alebo na dovolenke.
Čo presne v GLPI eskaluje
GLPI má dva mechanizmy:
- SLA actions (Setup → Service levels → SLA → Action). Pri vytvorení SLA sa definujú akcie, ktoré sa spustia v určitý moment relatívne k deadline-u: X minút pred, v moment porušenia, X minút po. Akcie môžu byť: zmena priority, zmena urgency/impactu, pridanie observera, zmena assigned group, e-mailová notifikácia.
- OLA actions (Operational Level Agreement) — to isté, ale pre interné cieľové časy medzi tímami (napr. L1 ↔ L2 handover do 30 min), nie pre zákaznícky SLA.
SLA aj OLA majú dva typy: Time to own (TTO — ako rýchlo sa niekto musí prihlásiť k tiketu) a Time to resolve (TTR — ako rýchlo musí byť vyriešený).
Praktická eskalačná matica
Príklad pre stredne veľkú firmu s 24/7 support pre kritické systémy:
Priorita 1 (P1) — kritický (ERP, e-mail, finančný systém down)
TTO: 15 min | TTR: 4 hod
-10 min: notifikácia L1 technikovi (e-mail + SMS)
-5 min: notifikácia L1 team lead-ovi
T0: priradiť assigned group L2 (escalation team)
+15 min: notifikácia IT manažérovi
+30 min: notifikácia CIO
+1 hod: notifikácia CEO (ak ERP down)
Priorita 2 (P2) — vysoká (čiastočný výpadok, jeden tím nefunguje)
TTO: 1 hod | TTR: 8 hod
-30 min: notifikácia L1 technikovi
T0: notifikácia team lead-ovi
+1 hod: priradiť L2 + notifikácia IT manažérovi
Priorita 3 (P3) — normálna (jeden používateľ, workaround existuje)
TTO: 4 hod | TTR: 2 dni
T0: notifikácia L1 technikovi
+4 hod: notifikácia team lead-ovi (ak žiadny progress)
Priorita 4 (P4) — nízka (kozmetické chyby, nice-to-have)
TTO: 8 hod | TTR: 5 dní
T0: notifikácia technikovi (žiadna eskalácia)Matrix sa nakonfiguruje raz v Setup → Service levels, naviaže na SLA na úrovni biznis pravidla (kategória + entita = ktoré SLA platí) a od tej chvíle GLPI eskaluje automaticky.
Konfigurácia v UI
- V Setup → Service levels → SLA vytvorte SLA „P1 — kritický (4 hod TTR)".
- V detaile SLA, záložka SLA actions, kliknite + Add.
- Vyberte typ akcie (napríklad „Add a recipient" pre notifikáciu, alebo „Modify ticket properties" pre zmenu group).
- Definujte časový offset (relatívny k deadline-u: before, during, after).
- Zopakujte pre každý krok matice.
Aby sa SLA priradilo automaticky, použite biznis pravidlo v Administration → Rules → Rules for ticket assignment: IF urgency = Very high AND impact = Major → SET SLA_TTR = "P1 — kritický".
Eskalácia notifikácií
Notifikácie sa konfigurujú v Setup → Notifications → Notifications → Add. Pre každú úroveň matice vytvorte samostatnú notifikáciu s presnou skupinou príjemcov a špecifickou šablónou — generický „escalation notice" e-mail je horší než žiadny, lebo manažér ho ignoruje.
Praktické tipy:
- P1 notifikácie posielajte aj cez SMS alebo Slack/Teams — e-mail v noci nikto nečíta. Integrácia notifikácií cez webhook na #incidents kanál v Teams je najefektívnejší kanál.
- Eskalujte počet príjemcov, nie iba úroveň — pri každej eskalácii pridajte ďalšiu osobu, neodstraňujte predchádzajúcu. Tým sa technik dozvie, že ide manažér, a manažér uvidí celú reťazec.
- Definujte working hours v calendari (Setup → Dropdowns → Calendars). SLA „4 hod" v noci s nestop modelom znamená iné než vo working hours.
Reporting na eskalácie
V GLPI dashboarde alebo cez vstavaný report builder sa dá zobraziť: % tiketov, ktoré boli eskalované, priemerný čas do prvej eskalácie, najčastejšie eskalované kategórie, technici s najvyšším eskalačným pomerom. Tento report by mal IT manažér čítať raz týždenne — ak istá kategória má 80 % eskaláciu, neplatí jej SLA, alebo nestačí kapacita.
Eskalačný systém v GLPI nie je „nice to have" feature — je to jadro fungujúceho service desku. Bez neho sú SLA len marketingový text. S ním je SLA niečo, čo sa dá merať a vymáhať.