[Intum Dev](https://intum.dev.md) / [Oprogramowanie dla firm](https://intum.dev/oprogramowanie-dla-firm.md)

# [SLA i eskalacja w Intum - jak pilnować czasy reakcji](https://intum.dev/oprogramowanie-dla-firm/jak-skonfigurowac-sla-z-eskalacja-w-intum.md)

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 | Email |
| 3 | 120 min | Manager supportu | Email |

### 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

1. Ticket jest otwarty i nikt nie reaguje
2. System sprawdza czas od ostatniej aktywności
3. Gdy upłynie czas z kroku - tworzy incydent eskalacji (widoczny w historii ticketu)
4. Wysyła powiadomienie do wskazanych osób
5. Osoby na urlopie są pomijane (jeśli włączone w polityce)
6. 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.

---

## Powiązane

- [Jak wygląda dzień firmy, która opiera się na systemie Intum](https://intum.dev/oprogramowanie-dla-firm/dzien-firmy-na-dzialajacej-na-intum.md)
- [Eskalacja w systemach obsługi klienta — jak to działa i jak to zrobić dobrze](https://intum.dev/oprogramowanie-dla-firm/eskalacja-w-systemach-obslugi-klienta.md)