šŸ“‹ Auto-Assignment & Monitoring ā€” Skenario Lengkap

Bagian A: Pembagian Tiket (Auto-Assignment)

Skenario 1: Pembagian Rata ā€” Kondisi Normal

Kondisi: 3 agent online (A, B, C) dengan beban awal 0. 3 tiket masuk satu per satu.

Tiket A (Load) B (Load) C (Load) Terpilih Alasan
#1 0 0 0 A Semua beban 0, A paling lama idle
#2 1 0 0 B B (0) < A (1)
#3 1 1 0 C C (0) < A,B (1)

āœ… Hasil: Beban merata 1 : 1 : 1

Skenario 2: Penyeimbangan Beban (Leveling)

Kondisi: agent A baru menyelesaikan semua tiketnya (load 0). agent B masih pegang 3 tiket. Tiket baru masuk.

agent Load Last Assigned Terpilih?
A 0 2 menit lalu āœ… Ya
B 3 15 menit lalu āŒ Tidak

Penjelasan: Meskipun B sudah lebih lama idle, A dipilih karena beban lebih sedikit (0 vs 3). Sistem selalu mengisi yang paling kosong dulu.

Skenario 3: Tiebreaker ā€” Beban Sama

Kondisi: agent A dan B sama-sama punya 2 tiket. Tiket baru masuk.

agent Load Last Assigned Terpilih?
A 2 20 menit lalu āœ… Ya
B 2 5 menit lalu āŒ Tidak

Penjelasan: Beban sama (2 vs 2), jadi sistem pakai LRU: A sudah lebih lama tidak dapat tiket ā†’ A dipilih.

Skenario 4: Filter Wilayah (Region Match)

Kondisi: Tiket masuk dari region Sulawesi.

agent Region Load Match? Terpilih?
A Kalimantan 0 āŒ Mismatch āŒ
B KTI 1 āœ… KTI = Sulawesi + Papua-Maluku Kandidat
C ALL 0 āŒ Mismatch āŒ

Penjelasan: A (Kalimantan) dan dan C (ALL Wilayah) ditolak karena regionnya tidak cocok. B lolos filter. jadi B yang terpilih.

Skenario 5: Tiket Tanpa Region

Kondisi: Tiket masuk tanpa region (field kosong).

agent Region Load Match?
A Kalimantan 1 āœ…
B KTI 0 āœ…
C ALL 2 āœ…

Penjelasan: Tiket tanpa region bisa diberikan ke agent mana saja. B dipilih karena load paling kecil (0).

Skenario 6: Lonjakan Trafik (Dynamic Capacity)

Kondisi: 50 tiket menumpuk di antrian. 5 agent online (semua unlocked).

Demand = Tiket Aktif (15) + Queue (50) = 65
Per agent = 65 / 5 = 13 ā†’ dibatasi MAX_LIMIT = 12
Situasi Base Limit Effective Limit
Normal (queue < 15) 3 3
Trafik Tinggi (queue = 50) 3 12

Penjelasan: Kapasitas per agent otomatis naik dari 3 ke 12 untuk menguras antrian. Begitu antrian menurun, limit kembali ke 3.

Skenario 7: Locked vs Unlocked agentt

Kondisi: Trafik tinggi (effective limit = 12). agent Junior (A) di-lock max 1 tiket. agent Senior (B) tidak dikunci.

agent Locked? Max Tickets Load Bisa Terima?
A (Junior) āœ… Locked 1 1 āŒ Kapasitas penuh (1/1)
B (Senior) āŒ Unlocked 12 5 āœ… Masih bisa (5/12)

Penjelasan: Junior dilindungi dari overload. Senior menangani lonjakan karena kapasitasnya mengikuti dynamic scaling.

Skenario 8: Semua agent Penuh

Kondisi: 2 agent online, keduanya sudah di kapasitas maksimal.

agent Load Limit Status
A 3 3 āŒ Penuh
B 3 3 āŒ Penuh

Hasil: Tiket tetap di Queue. Sistem akan coba assign lagi setiap 1 menit (monitoring loop). Begitu salah satu agent menyelesaikan tiket, tiket baru langsung masuk.

Bagian B: Pemantauan & SLA (Monitoring)

Skenario 9: Peringatan SLA ā€” 15 Menit

Kondisi: Tiket #TIKET-001 di-assign ke agent A jam 09:00. Sampai jam 09:15 belum solved.

Timeline:

Waktu Event
09:00 Tiket di-assign ke agent A
09:15 āš ļø Sistem kirim peringatan SLA ke agent A (bell) dan Admin (Telegram + bell)

Penjelasan: Ini hanya peringatan, bukan tindakan otomatis. agent tetap bisa melanjutkan pengerjaan.

Skenario 10: Auto-Solve ā€” 30 Menit Tanpa Respons User

Kondisi: agent A sudah chat ke user di jam 09:10. User tidak merespons sampai 09:40.

Timeline:

Waktu Event
09:00 Tiket di-assign ke agent A
09:10 agent A mengirim chat ke user (last_agentt_comment_at = 09:10)
09:15 āš ļø Peringatan SLA (15 menit sejak assign)
09:40 āœ… Sistem auto-solve (30 menit sejak chat agent terakhir, user tidak respons)

Penjelasan: Sistem melihat last_agentt_comment_at = 09:10. Sekarang 09:40 (sudah 30 menit). User tidak ada balasan ā†’ tiket ditutup otomatis. Notifikasi dikirim ke user dan grup.

Skenario 11: User Merespons ā€” Auto-Solve Tidak Terjadi

Kondisi: agent A chat jam 09:10. User membalas jam 09:25. agent chat lagi jam 09:30.

Timeline:

Waktu Event
09:10 agent chat ā†’ last_agentt_comment_at = 09:10
09:25 User membalas (tiket tetap in_progress)
09:30 agent chat lagi ā†’ last_agentt_comment_at = 09:30 (di-reset)
10:00 Cek auto-solve: 30 menit sejak 09:30, user tidak respons ā†’ āœ… Auto-solve

Penjelasan: Setiap kali agent chat, timer 30 menit reset ulang. Auto-solve hanya terjadi jika user diam 30 menit sejak chat agent terakhir.

Skenario 12: Eskalasi Antrian ā€” 2 Jam di Queue

Kondisi: Tiket #TIKET-005 masuk jam 08:00 tapi tidak ada agent online yang cocok (misal: region khusus).

Timeline:

Waktu Event
08:00 Tiket masuk Queue
10:00 šŸ”” Eskalasi Level 1: "Tiket belum diassign > 2 jam!"
11:00 šŸšØ Eskalasi Level 2: "Reminder ke-2: Tiket belum diassign!"
12:00 šŸšØ Eskalasi Level 3: dst.

Penjelasan: Admin mendapat reminder setiap jam setelah 2 jam pertama, agar tiket tidak terlupakan di antrian.

Skenario 13: Re-Assign agent Offline ā€” 2 Jam

Kondisi: agent A menerima tiket jam 09:00 lalu koneksi putus (offline) jam 09:30. Tidak ada aktivitas apapun.

Timeline:

Waktu Event
09:00 Tiket di-assign ke agent A
09:30 agent A offline (koneksi putus / auto-offline)
11:30 šŸ”„ Sistem re-assign: Tiket dilepas dari A, masuk kembali ke Queue, di-assign ke agent online lain

Penjelasan: Hanya terjadi jika agent offline DAN tidak ada progres selama 2 jam. Jika agent masih online, tiket tetap di agent tersebut.

Alur Tiket

[Diagram]

Bagian C: Status agent (Online/Offline)

Skenario 14: Cooldown Offline ā€” 15 Menit

Kondisi: agent A pencet "Online" jam 08:00. Jam 08:05 dia coba pencet "Offline".

Timeline:

Waktu Event
08:00 agent A pencet Online (online_since = 08:00)
08:05 agent A coba pencet Offline ā†’ āŒ DITOLAK
Pesan: "Cooldown aktif. Anda baru bisa offline dalam 10 menit 0 detik."
08:15 agent A coba lagi ā†’ āœ… Berhasil Offline (sudah lewat 15 menit)

Penjelasan: Setelah pencet Online, agent wajib online minimal 15 menit sebelum bisa pencet Offline atau Logout. Ini agar agent tidak toggle on-off terus menerus atau kabur dari tanggung jawab. Jika mencoba Logout sebelum 15 menit, sistem akan menolak dan menampilkan peringatan waktu cooldown.

Skenario 15: Auto-Offline ā€” Batas Shift 9 Jam

Kondisi: agent A login jam 08:00. Lupa pencet Offline.

Timeline:

Waktu Event
08:00 agent A pencet Online (first_online_today = 08:00)
17:00 ā° Sistem auto-offline: 9 jam sejak login. agent A otomatis Offline.

Penjelasan: Sistem memantau setiap 1 menit. Jika agent sudah online > 9 jam, status langsung diubah ke Offline agar tidak terus menerus menerima tiket di luar jam kerja. Tiket yang sedang dipegang tetap di agent tersebut (tidak dilepas).

Skenario 16: Heartbeat ā€” Koneksi Putus

Kondisi: agent A online tapi internet tiba-tiba mati jam 10:00.

Timeline:

Waktu Event
09:50 Heartbeat terakhir (last_activity_at = 09:50)
10:00 Internet mati (frontend berhenti kirim heartbeat)
10:00 Monitoring: Cek last_activity_at. Sudah 10 menit tanpa heartbeat ā†’ Auto-Offline

Penjelasan: Frontend mengirim heartbeat secara berkala. Jika tidak ada heartbeat selama 10 menit, sistem menganggap koneksi putus dan mengubah status agent ke Offline. Tiket tetap di agent tersebut (tidak dilepas).

Skenario 17: Admin Force Offline

Kondisi: Admin melihat agent A terlihat online tapi tidak responsif.

Aksi Detail
Admin pencet "Force Offline" agent A langsung Offline
Pilihan "Lepas Tiket?" Jika Ya ā†’ tiket A dikembalikan ke Queue. Jika Tidak ā†’ tiket tetap di A.
Cooldown? Tidak berlaku ā€” Admin bypass semua aturan.