# Pemantauan SLA


## Ringkasan

**Service Level Agreement (SLA)** adalah target waktu respons dan penyelesaian yang wajib dipatuhi oleh tim agent untuk setiap percakapan. OmniStream mendukung kebijakan SLA berlapis: satu organisasi dapat memiliki banyak policy aktif sekaligus — misalnya kebijakan ketat untuk kanal WhatsApp divisi VIP dan kebijakan standar untuk email umum. Scheduler backend akan memilih policy yang paling cocok untuk setiap percakapan baru berdasarkan kombinasi **kanal** dan **divisi** yang terkait.

Halaman **SLA Policies** berada di rute `/sla-policies` dan dapat diakses oleh supervisor dan admin. Dari sini Anda dapat membuat, mengubah, menandai sebagai default, atau menonaktifkan kebijakan SLA.

:::info
**Hak akses:** Halaman `/sla-policies` memeriksa `authStore.isSupervisor`. Peran **agent** akan melihat layar *"Access Restricted"*.
:::

## Konsep SLA di OmniStream

Setiap kebijakan memiliki empat parameter utama:

| Parameter | Arti | Satuan di DB |
|---|---|---|
| **First Response Time (FRT)** | Waktu maksimum sejak percakapan masuk hingga agent mengirim balasan pertama | detik (`first_response_time_secs`) |
| **Resolution Time** | Waktu maksimum sejak percakapan masuk hingga status berubah menjadi `resolved` | detik (`resolution_time_secs`) |
| **Warning Threshold %** | Persen dari durasi SLA yang memicu peringatan dini (mis. 80% → warning saat 80% waktu telah terlewat) | integer (`warning_threshold_pct`) |
| **Priority** | Angka manual yang dapat dipakai untuk tie-breaker antar policy dengan score sama | integer (`priority`) |

Setiap policy juga dapat di-scoping ke:

- **Channel** (`whatsapp`, `instagram`, `email`, atau kosong untuk semua kanal)
- **Division** (ID divisi atau kosong untuk semua divisi)
- **Is Default** (flag yang membuat policy dipakai sebagai fallback saat tidak ada yang cocok)

## Prioritas pencocokan policy

Sistem menghitung **score** untuk setiap policy aktif berdasarkan aturan berikut, lalu memilih yang score-nya tertinggi:

| Kombinasi cocok | Score | Keterangan |
|---|---|---|
| **Channel + Division** (keduanya cocok eksak) | **4** | Prioritas tertinggi |
| **Division-only** (policy tanpa channel, division cocok) | **2** | |
| **Channel-only** (policy tanpa division, channel cocok) | **2** | |
| **Default** (`is_default = true`, tanpa channel, tanpa division) | **1** | Fallback umum |

Kombinasi channel + division menghasilkan total score `4`, channel-only atau division-only `2`, dan default `1`.

Jika tidak ada policy aktif yang cocok sama sekali (score `< 0`), percakapan tidak akan memiliki SLA tracking dan tidak akan dihitung sebagai breach.

:::warning
Jika dua policy menghasilkan score yang sama (mis. dua channel-only untuk WhatsApp), *yang pertama ditemukan di list* akan dipilih. Gunakan kolom `priority` dan pastikan hanya satu policy per kombinasi channel+division yang aktif.
:::

## Langkah-langkah mengelola SLA

### Membuat policy baru

1. Buka `/sla-policies` dari sidebar.
2. Klik tombol **+ New Policy**.
3. Isi form:
   - **Name** (wajib) — contoh: `VIP WhatsApp Fast Track`
   - **Description** — konteks singkat untuk tim
   - **First Response Time** — dalam menit, contoh `5` untuk 5 menit
   - **Resolution Time** — dalam menit, contoh `60` untuk 1 jam
   - **Warning Threshold %** — default `80` (peringatan pada 80% waktu terpakai)
   - **Priority** — biasanya `0`, naikkan hanya jika perlu tie-breaker
   - **Channel** — pilih `whatsapp`, `instagram`, `email`, atau kosongkan
   - **Division** — pilih dari dropdown divisi atau kosongkan
   - **Is Default** — centang jika ini fallback organisasi
   - **Is Active** — centang untuk mengaktifkan
4. Klik **Save**. Backend akan memanggil `POST /api/sla-policies` (tag **SLA**).

### Mengubah atau menonaktifkan policy

1. Temukan baris policy di tabel.
2. Klik ikon **pensil** untuk mengedit atau **trash** untuk menghapus. Menonaktifkan lewat toggle `Is Active` lebih aman daripada menghapus — data breach lama tetap punya referensi ke policy_id.
3. Backend menggunakan `PUT /api/sla-policies/{id}` dan `DELETE /api/sla-policies/{id}`.

### Memantau breach

Percakapan yang sudah atau hampir melewati SLA diteruskan lewat WebSocket ke supervisor yang online. Supervisor biasanya melihat badge peringatan di sidebar inbox. Breach dapat diaudit lewat endpoint `GET /api/sla-policies/{id}/breaches` — lihat [API Reference](/api).

![Screenshot halaman SLA policies](/screenshots/sla-policies.png)

## Endpoint terkait (tag **SLA**)

| Aksi | Endpoint |
|---|---|
| List semua policy | `GET /api/sla-policies` |
| Detail satu policy | `GET /api/sla-policies/{id}` |
| Buat policy baru | `POST /api/sla-policies` |
| Update policy | `PUT /api/sla-policies/{id}` |
| Hapus policy | `DELETE /api/sla-policies/{id}` |
| Audit breach | `GET /api/sla-policies/{id}/breaches` |

Detail parameter dan skema respons tersedia di [API Reference — SLA](/api).

## Praktik terbaik

- **Mulai dengan satu policy default** yang longgar (mis. FRT 15 menit, resolution 4 jam) sebelum menambah policy ketat per kanal/divisi.
- **Selalu set `is_default = true` pada tepat satu policy** sehingga setiap percakapan selalu punya SLA tracking.
- **Uji kombinasi channel+division** dengan membuat percakapan test dan cek breach — sistem mengecek setiap 30 detik, jadi hasil muncul setelah siklus berikutnya.
- **Pantau tren breach** di halaman [Analytics](/panduan/supervisor/analytics) untuk mendeteksi pola chronic understaffing.

## Rute terkait

- [Dashboard Supervisor](/panduan/supervisor/dashboard) — melihat ringkasan KPI termasuk resolution rate
- [Kinerja Agent](/panduan/supervisor/kinerja-agent) — lihat apakah breach terkonsentrasi di agent tertentu