Abstract
Hierarki model dukungan IT (IT Support / Helpdesk) dipecah menjadi 5 level utama — dari Level 1 (self-service & user troubleshooting) sampai Level 5 (IT Service Management / ITIL process ownership). Catatan ini melengkapi
hierarchy-it-domain.mdyang hanya menyebut IT Management secara buram tanpa meng-keruk sub-domain support. Fokus khusus pada model Tiered Support (Tier 0–3) yang dipakai industri, mapping ke jalur karir, dan keterkaitannya dengan operasional tim korporat (incident response & infra administration). Vault sudah punyainfrastructure-administrator.mddanincident-response-framework.md— catatan ini mengisi sisi support operasional harian yang belum terpetakan.
Daftar Isi
- 1. Premise — Kenapa IT Support Punya Hierarki?
- 2. Level 1 — Self-Service & End-User Troubleshooting
- 3. Level 2 — Tier-1 Service Desk
- 4. Level 3 — Tier-2 / Tier-3 Technical Support
- 5. Level 4 — Incident Management & Escalation Ownership
- 6. Level 5 — IT Service Management (ITIL Process Owner)
- 7. Peta Visual — Abstraction vs Response Time
- 8. Trade-off Matrix per Level
- 9. Decision Tree — Saya Mau Mulai dari Mana?
- 10. Anti-Pattern Table
- 11. Koneksi ke Vault
- 12. References
1. Premise — Kenapa IT Support Punya Hierarki?
Model support IT tidak asal dibagi “ada yang nanya, ada yang jawab”. Semua organisasi (dari startup 5 orang sampai enterprise 10.000 karyawan) pada akhirnya meniru struktur yang sama karena satu alasan teknis: biaya resolusi naik tajam di setiap level. Semakin jauh sebuah ticket dari titik kontak awal, semakin mahal waktu ahli, semakin lama Mean Time To Resolution (MTTR), dan semakin besar dampak ke business continuity.
Hierarki ini bukan sekadar pengorganisasian tim — ia adalah escalation slope yang dirancang agar masalah sederhana diselesaikan dengan resource termurah dulu, dan hanya yang benar-benar sulit yang naik ke tangan spesialis. Setiap level punya batas sla ownership berbeda, tool yang berbeda, dan skill set yang berbeda.
Kenapa relevan
Untuk tim DevOps/IT yang mengelola sistem (lihat
infrastructure-administrator.md), memahami model ini bukan hanya soal karir — tetapi soal bagaimana men-design layanan support yang bisa menghitung cost per ticket dan escalation path saat user melapor.
2. Level 1 — Self-Service & End-User Troubleshooting
Level pertama, paling dekat dengan user, dan paling murah. Di sini belum ada interaksi manusia-to-manusia — user menyelesaikan masalahnya sendiri (atau setidaknya diarahkan) sebelum ticket masuk.
| Karakteristik | Detail |
|---|---|
| Pelaku | End-user (karyawan), kadang chatbot |
| Tool | Knowledge base, FAQ portal, wiki, automated password reset, AI/chatbot self-service |
| Waktu respons | Detik (kontekstual) |
| Biaya resolusi | Paling rendah per interaksi |
| Contoh | Reset password lewat portal, cek status layanan, panduan install printer, FAQ VPN |
| Konsep kunci: Level ini menggeser beban dari helpdesk ke user. Setiap dokumen self-service yang bagus = satu ticket yang tidak perlu dibuat. Metrik pentingnya adalah deflection rate — persentase permintaan yang berhasil diselesaikan tanpa masuk pipeline ticket. |
Level 1: user self-service
user → SPSS (Self-Service Portal) → resolve ✓
↘ (gagal / butuh manusia) → naik ke Level 2Trap
Self-service yang buruk justru menciptakan “phantom tickets” — user mencoba portal, gagal, lalu nge-double-report ke helpdesk. Kebanyakan masalah di sini bukan teknologi, tapi UX portal & dokumentasi yang tidak up-to-date.
3. Level 2 — Tier-1 Service Desk
Level pertama dengan interaksi manusia. Tier-1 adalah gerbang semua permintaan — penerima ticket, klasifikator, dan pemecah masalah sederhana/repetitif.
| Karakteristik | Detail |
|---|---|
| Pelaku | Service Desk Analyst / Helpdesk (entry-level) |
| Tool | ITSM ticketing (Jira Service Management, ServiceNow, Zendesk, Freshservice), RDP, script reset |
| Cakupan | ~70–80% dari semua ticket (password, akses aplikasi, printer, email, koneksi) |
| SLA target | Menjawab dalam menit; resolve dalam 1–4 jam |
| Skill | Troubleshooting dasar, proses, cara berkomunikasi dengan user |
Peran penting Tier-1: tiga hal — triage (mengklasifikasikan severity/urgency), first-contact resolution (menyelesaikan langsung kalau bisa), dan accurate dispatch (meneruskan ke Tier-2/3 kalau memang di luar kapasitas). Kesalahan dispatch di sini paling mahal karena memboroskan waktu spesialis.
Level 2: Tier-1 Service Desk
ticket → triage → bisa diresolve? → resolve ✓ (first-contact resolution)
↘ tidak → categorize + assign → naik Level 3Metrik utama Tier-1: First Contact Resolution (FCR), ticket volume, backlog age, dan resolution SLA compliance.
4. Level 3 — Tier-2 / Tier-3 Technical Support
Spesialisasi dimulai. Di sini orang tidak lagi “generalist” — mereka menangani kategori teknologi tertentu.
| Tingkat | Pelaku | Cakupan |
|---|---|---|
| Tier-2 | Technical Support / Systems Analyst | Masalah yang butuh akses sistem lebih dalam: reset & konfigurasi akun, perbaikan OS/software, jaringan LAN, hardware imaging, antivirus |
| Tier-3 | Specialist / Senior Engineer | Root-cause di luar ticket biasa: network core, server config, directory services (AD/Entra ID), security incidents, masalah yang butuh vendor L1/L2 |
Perbedaan kunci Tier-2 vs Tier-3:
| Dimensi | Tier-2 | Tier-3 |
|---|---|---|
| Kedalaman | Menyelesaikan masalah sistem individual | Menyelesaikan masalah yang mencakup banyak sistem / akar |
| Akses | Admin pada endpoint & beberapa server | Admin server core, infrastructure, security |
| Output | Ticket resolved | Root Cause Analysis (RCA) + perubahan permanen |
| Vendor lift | Jarang | Sering — kolaborasi dengan vendor untuk bug/covery |
Definisi masalah yang "escalate ke Tier-3"
Masalah naik ke Tier-3 bukan karena susah, tetapi karena gejalanya tidak bisa dipisahkan dari akar — misalnya satu segmen LAN sekarat bukan karena satu PC, tapi karena switch config / spanning-tree issue. Tier-3 bekerja di level infrastructure, bukan endpoint.
Level 3: Tier-2 / Tier-3
Tier-2: resolve per-endpoint / per-system issue
Tier-3: RCA + fix permanen (config, infra core, security)
↘ masih open / butuh vendor → naik Level 4 (incident mgmt)5. Level 4 — Incident Management & Escalation Ownership
Di Level 4, fokus bergeser dari “menyelesaikan ticket” ke mengelola kejadian (incident) sebagai entitas bisnis. Ini titik transisi dari technical support ke coordinated incident response.
| Karakteristik | Detail |
|---|---|
| Pelaku | Incident Manager / On-call lead / Bridge lead |
| Fokus | Tidak menyelesaikan teknis secara langsung — mengorkestrasi siapa yang menyelesaikan |
| Tool | Incident bridge, war room, statuspage, communications plan |
| Output | Severity classification, escalation tree, post-incident review (PIR) |
| Hubungan | Nyambung langsung ke incident-response-framework.md |
Mengapa Level 4 terpisah dari Teknis: saat incident besar terjadi (outage, security breach), orang teknis sibuk memperbaiki, tapi butuh satu pihak yang hanya fokus pada komunikasi, prioritas, dan kronologi — siapa yang boleh berubah apa, kapan harus naik ke manajemen, kapan declare severity besar. Kalau tidak ada Level 4, semua orang menyerbu masalah yang sama dan tidak ada yang update stakeholder.
Level 4: Incident Management
incident detected → severify → assemble bridge → triage resources
→ fix → verify → close → Post-Incident Review (PIR)6. Level 5 — IT Service Management (ITIL Process Owner)
Level paling atas — kepemilikan proses, bukan per-ticket. Di sini IT Support berubah menjadi IT Service Management (ITSM) yang dikelola lewat framework ITIL.
| Proses ITIL | Fungsi di level ini |
|---|---|
| Incident Management | Mengelola semua kejadian untuk restore service cepat |
| Problem Management | Menyelidiki akar penyebab berulang (mengurangi incident jangka panjang) |
| Change Management | Mengendalikan perubahan agar tidak bikin incident baru |
| Service Request Fulfilment | Standard request (akses, hardware baru) |
| Asset & Configuration Mgmt (CMDB) | Catatan apa yang dimiliki & konfigurasinya |
| Knowledge Management | Menyimpan artikel resolusi agar ke Level 1–2 bisa reuse |
Konsep pembeda: di Level 5, metrik tidak lagi “berapa ticket selesai”, tetapi dampak ke bisnis — service availability, cost per ticket, problem recurrence rate, dan continuous improvement. Ini level di mana keputusan diambil berdasarkan data dari semua level di bawahnya (ticket trend, recurring problems).
Level 5: ITSM / ITIL
masing-masing proses memiliki owner
data ticket dari L1-L4 → Problem Mgmt → knowledge → feed balik ke L1/L27. Peta Visual — Abstraction vs Response Time
Diagram gabungan bahwa setiap level naik, abstraksi naik tapi response time turun (spekulasi per level: makin dalam makin mahal per aksi).
Cost per action ↑ Kepemilikan proses ↑
Level 5: ITSM/ITIL ████ (proses & data)
Level 4: Incident ███ (orkestrasi, bridge)
Level 3: Tier-2/3 ██ (RCA, infra core)
Level 2: Tier-1 █ (ticket, triage)
Level 1: Self-svc ░ (deflection, portal)
Volume ticket ↑ Jarak dari user ↑ (abstraksi naik)8. Trade-off Matrix per Level
| Level | Kecepatan resolve | Biaya | Kebutuhan skill | Risiko salah |
|---|---|---|---|---|
| 1 | Sangat cepat (self) | Rendah | Rendah (user) | Deflection gagal |
| 2 | Cepat (menit-jam) | Sedang-rendah | Dasar | Mis-dispatch |
| 3 | Sedang (jam-hari) | Tinggi | Spesialis | RCA salah / fix menular |
| 4 | Lambat (incident) | Sangat tinggi | Orkestrasi | Komunikasi gagal |
| 5 | Jangka panjang (perbaikan) | Tertinggi | Proses & data | Over-proses |
9. Decision Tree — Saya Mau Mulai dari Mana?
Poin karir / kebutuhan tim:
Budget terbatas, org kecil? → Level 1 (self-service) dulu
Butuh operasional cepat? → invest di Tier-1 (FCR tinggi) − Level 2
Sudah sering incident serius? → bangun Level 4 (incident mgmt)
Problem berulang tak berujung? → naik ke Level 5 (problem mgmt + knowledge)
Mau fokus karir teknis? → Tier-2 → Tier-3 (spesialis)
Mau karir manajerial/ops? → Tier-1 → Incident Mgr → ITSM owner
10. Anti-Pattern Table
| Anti-pattern | Fall-out |
|---|---|
| Tier-1 doyan “lempar ke atas” tanpa triage benar | Tier-3 kebanjiran ticket sepele → MTTR naik |
| Tidak ada knowledge base | Solusi di level 3 berulang-ulang di Level 2 |
| Level 4 dipegang orang teknis penuh | Tidak ada yang update stakeholder saat incident |
| Level 5 tanpa data dari bawah | ITSM jadi “proses kosong” tanpa metrik real |
| Level 1 (self-service) dibiarkan outdated | User frustrasi → phantom tickets |
11. Koneksi ke Vault
| Catatan | Hubungan |
|---|---|
| hierarchy-it-domain | Induk hierarki IT — catatan ini mengisi sub-domain IT Management yang sebelumnya buram |
| infrastructure-administrator | Level 2–3 dari sisi technical execution (admin yang mengeksekusi) |
| incident-response-framework | Level 4 — sisi koordinasi & escalation |
| hierarchy-cybersecurity-defense-architecture | Level 3–5 untuk ranah security incidents |
| hierarchy-abstraction-layers | Pola abstraction yang sama (semakin tinggi level, semakin dekat ke user intent) |
12. References
- ITIL 4 Foundation — Axelos ITIL 4 framework (process ownership model)
- Gartner — IT Service Management (ITSM) tools market guide (tiered ticket model)
- HDI — Support Center Practices & Standards (tiering & metrics: FCR, MTTR)
- ServiceNow / Jira Service Management vendor docs — ticket lifecycle & escalation
- Axelos — Incident & Problem Management practice guides (ITIL 4)