Moduł eskalacji w Intum automatycznie reaguje gdy coś wymaga uwagi i nikt się tym nie zajął. Działa z helpdeskiem, monitoringiem i dowolnym źródłem alertów.
Trzy scenariusze
Klient pisze na support i nikt nie odpowiada
Ticket wpada do biurka helpdesku. Po 30 minutach osoba odpowiedzialna dostaje przypomnienie. Po godzinie powiadomienie idzie do grupy “Support L2”. Po dwóch godzinach email trafia do managera.
Serwer przestaje odpowiadać
Monitoring wykrywa problem i tworzy alert przez API. Alert automatycznie staje się ticketem w biurku wskazanym w polityce eskalacji. Polityka daje 5 minut - potem powiadamia devopsa, po 15 minutach CTO. Gdy monitoring wysyła “OK”, ticket zamyka się sam.
Zadanie w projekcie stoi od tygodnia
Skrypt lub flow sprawdza zadania i tworzy alert gdy coś stoi zbyt długo. Alert trafia do biurka z eskalacją - team lead dostaje powiadomienie.
Jak skonfigurować
1. Polityka eskalacji
Automatyzacja > Eskalacja > Nowa polityka. Nadaj nazwę, ustaw jako aktywną i dodaj kroki.
Każdy krok to:
- Opóźnienie - ile minut od otwarcia ticketu (np. 5, 30, 60, 120)
- Kogo powiadomić - osobę odpowiedzialną za ticket, konkretnego usera lub całą grupę
- Kanał - notyfikacja w systemie lub email
Przykład polityki “SLA Standard”:
| Krok | Po | Kogo | Kanał |
|---|---|---|---|
| 1 | 30 min | Osoba odpowiedzialna | Notyfikacja |
| 2 | 60 min | Grupa Support L2 | |
| 3 | 120 min | Manager supportu |
2. Biurko alertów
W ustawieniach polityki wybierz Biurko alertów - to biurko na którym będą tworzone tickety z zewnętrznych źródeł (monitoring, API, skrypty). Alerty trafiają na to biurko automatycznie.
3. Przypisanie polityki
Politykę można przypisać na trzech poziomach:
Biurko helpdesku - wszystkie tickety w tym biurku podlegają eskalacji.
Klient CRM - klient ma własne SLA, niezależne od biurka. Ticket od klienta z polityką “SLA Premium” eskaluje szybciej.
Priorytet: polityka klienta > polityka biurka.
4. Integracja z monitoringiem (API)
Zewnętrzne systemy mogą tworzyć alerty przez API:
POST /automation/escalation/alerts.json
Parametry:
-
policy_id- ID polityki eskalacji (ticket trafi na biurko alertów z tej polityki) -
title- tytuł alertu (np. “Serwer web-1 nie odpowiada”) -
content- opis (opcjonalne) -
alert_key- klucz do deduplikacji (np. “web-1-down”). Ten sam alert nie tworzy wielu ticketów -
priority- priorytet (opcjonalne) -
source- nazwa źródła (np. “uptimerobot”)
Auto-resolve - zamknięcie alertu gdy problem zniknie:
POST /automation/escalation/alerts/resolve.json
Parametry: policy_id, alert_key
Co się dzieje podczas eskalacji
- Ticket jest otwarty i nikt nie reaguje
- System sprawdza czas od ostatniej aktywności
- Gdy upłynie czas z kroku - tworzy incydent eskalacji (widoczny w historii ticketu)
- Wysyła powiadomienie do wskazanych osób
- Osoby na urlopie są pomijane (jeśli włączone w polityce)
- Eskalacja zatrzymuje się gdy ktoś odpowie lub zmieni status
Typowe polityki
SLA Basic - jeden krok, 60 minut, email do odpowiedzialnego.
SLA Standard - trzy kroki (30/60/120 min), rosnący łańcuch eskalacji.
SLA Premium - dwa kroki z krótkimi czasami (15/30 min). Dla kluczowych klientów.
Infra Critical - 5 minut do devopsa, 15 minut do CTO. Dla alertów z monitoringu.