Belajar IT Support - Support Process & SLA

#Pendahuluan

Setelah di episode 1 kalian mengenal peran, level tier, dan jalur karir IT support, sekarang kita masuk ke proses yang membedakan tim support profesional dari "teknisi yang ditelepon saat ada masalah". Proses inilah yang membuat layanan bisa diukur, diandalkan, dan diperbaiki.

Mengapa ini penting dipelajari sejak awal? Karena hampir semua pertanyaan interview untuk posisi helpdesk menyentuh topik ini: "bagaimana Anda menentukan prioritas tiket?", "apa yang Anda lakukan jika SLA hampir terlanggar?", "kapan Anda eskalasi?". Lebih dari itu — di dunia nyata, kalian akan dinilai bukan hanya dari masalah yang kalian selesaikan, tapi dari seberapa tertib prosesnya.

#Ticket Lifecycle

Tiket adalah unit kerja resmi di dunia support. Setiap tiket melewati siklus hidup yang baku:

100%

Mari bedah tiap tahap:

Tahap	Arti	Kewajiban Kalian
New	Tiket baru dibuat user/telepon/email	Konfirmasi penerimaan, isi detail yang kurang
Assigned	Ada pemilik (agent)	Pemilik wajib merespons dalam target response time
In Progress	Sedang dikerjakan	Update log setiap langkah diagnosis
Pending	Menunggu balasan user/vendor	Tetap follow-up berkala; pending ≠ selesai
Resolved	Solusi diberikan	Tuliskan resolusi yang bisa dibaca orang lain
Closed	User konfirmasi atau auto-close	Setelah closed, buka ulang lewat tiket baru

Kesalahan paling umum pemula: melompat langsung ke solusi tanpa mengisi log perjalanan. Padahal kolom log adalah memori kolektif tim — dan bahan baku KB article (episode 17).

#Prioritas: Impact × Urgency

Tidak semua tiket sama. Tim profesional menentukan prioritas dengan dua sumbu:

Impact: seberapa luas dampaknya? (satu user, satu departemen, seluruh perusahaan)
Urgency: seberapa cepat harus ditangani? (bisa menunggu vs menghambat pekerjaan sekarang)

Hasil kali keduanya membentuk matriks klasik:

	Urgency Tinggi	Urgency Rendah
Impact Tinggi	P1 — Critical	P2 — High
Impact Rendah	P3 — Medium	P4 — Low

Contoh penerapan:

Email server mati untuk semua karyawan → impact tinggi + urgency tinggi = P1, langsung kerjakan.
Monitor satu user berkedip → impact rendah + urgency rendah = P4, antre normal.
Kabel proyektor di ruang rapat direksi rusak menjelang rapat penting → impact kecil tapi urgency tinggi = P3 naik sementara, tangani cepat dengan catatan.
Permintaan install software standar minggu depan → P4/P3, masuk antrian sesuai SLA.

Tip

Saat dua tiket P3 berebut perhatian, gunakan pertanyaan penentu: "apa yang terjadi jika ini ditunda 24 jam?" Jawaban itu biasanya langsung memecah kebuntuan prioritas.

#SLA: Response Time vs Resolution Time

SLA (Service Level Agreement) adalah kesepakatan terukur tentang seberapa cepat layanan merespons dan menyelesaikan masalah. Dua metrik inti yang wajib kalian bedakan:

Metrik	Definisi	Contoh Target
Response Time	Waktu sampai agent menanggapi tiket (bukan menyelesaikan)	P1: 15 menit, P3: 8 jam kerja
Resolution Time	Waktu sampai tiket resolved	P1: 4 jam, P2: 8 jam kerja, P4: 5 hari kerja

Poin yang sering salah dipahami: menanggapi bukan menyelesaikan. Merespons P1 dalam 10 menit dengan kalimat "kami sedang menganalisis, update berikutnya jam 11" sudah memenuhi response SLA — dan yang terpenting, memberi user kepastian. Diam tanpa kabar adalah pelanggaran SLA paling murah namun paling merusak reputasi.

Praktik baik lainnya:

Jam kerja vs 24×7: banyak SLA dihitung dalam business hours; tiket Sabtu malam mulai dihitung Senin pagi kecuali kontrak bilang lain.
Auto-notification: manfaatkan reminder tool ticketing sebelum SLA mendekati batas.
Breach itu bukan akhir dunia — yang fatal adalah breach diam-diam. Komunikasikan lebih awal ke supervisor.

#Eskalasi yang Benar

Eskalasi adalah memindahkan tiket ke lapisan yang lebih tepat. Ada dua jenis:

#Eskalasi Fungsional

Ke tim dengan keahlian berbeda: dari Tier 1 ke Tier 2, ke vendor software, atau ke network team. Syaratnya tiket harus "lengkap":

Template handover eskalasi

Tiket #2041 — Excel crash saat open file >50 MB
Pelapor: Budi (Finance), mulai terjadi sejak Office update 12 Agustus
Sudah dicoba:
  1. Repair Office (Online Repair) — masih crash
  2. Add-in dimatikan semua (safe mode) — masih crash
  3. File sama dibuka di PC lain — normal
Dugaan: profil Windows user, bukan file maupun instalasi
Butuh: cek profil user / reinstall dengan cleanup registry

Handover seperti ini menghemat waktu Tier 2 berjam-jam dan membuat nama kalian dipercaya.

#Eskalasi Hierarkis

Naik ke atasan/supervisor karena otoritas, bukan keahlian: permintaan exception kebijakan, biaya penggantian hardware, atau konflik ekspektasi user. Aturan emasnya: eskalasi dengan rekomendasi, bukan hanya masalah. Bawa dua opsi plus implikasinya.

Warning

Jangan eskalasi sebagai pelarian. Tiket yang dinaikkan tanpa satu pun upaya diagnosis akan kembali ke kalian — kali ini dengan catatan buruk. Minimal satu langkah diagnosis dan satu data objektif (pesan error, screenshot) wajib ada sebelum eskalasi.

#Memetakan Proses Tim Kalian

Sebagai latihan, petakan proses support di tempat kalian bekerja (atau lab osTicket dari episode 0):

Bagaimana tiket masuk? (portal, email, telepon, WhatsApp?)
Siapa yang assign, dan berdasarkan apa?
Berapa target response/resolution per prioritas?
Kapan tiket boleh pending, dan siapa yang memantau pending?
Ke mana eskalasi fungsional dan hierarkis pergi?

Kalimat jawaban atas kelima pertanyaan itu adalah peta proses support kalian. Di perusahaan matang, dokumen ini disebut service catalogue + SOP; di episode 23 (ITIL) kita formalisasi lebih jauh.

#Penutup

Inti yang harus dibawa pulang:

Setiap pekerjaan support dibungkus ticket lifecycle: New → Assigned → In Progress → (Pending) → Resolved → Closed.
Prioritas lahir dari impact × urgency — bukan dari suara user yang paling keras.
SLA punya dua metrik berbeda: response time dan resolution time; memberi kabar itu murah tapi bernilai besar.
Eskalasi fungsional butuh konteks lengkap; eskalasi hierarkis butuh opsi dan rekomendasi.
Petakan proses tim kalian — peta proses adalah fondasi perbaikan berkelanjutan.

Di episode 3 selanjutnya kita turun ke lapangan teknis: computer hardware fundamentals — komponen inti PC, urutan perakitan yang benar, cara membaca beep code POST, dan metode troubleshooting saat komputer mati total atau gagal boot. Siapkan obeng kalian! Sampai jumpa!