Pernah menerima permintaan akses aplikasi yang seharusnya selesai hari itu, tetapi tertahan berhari-hari karena approver tidak merespons? Rute eskalasi yang jelas membuat proses persetujuan tidak bergantung pada kebetulan siapa yang sedang online. Dengan desain yang terstruktur, tim layanan bisa menjaga SLA, mengurangi bolak-balik, dan tetap menjaga keamanan saat permintaan menyentuh data sensitif atau biaya.
Mulai dari klasifikasi permintaan dan tingkat risikonya
Rute eskalasi yang baik dimulai dari pemetaan jenis IT request, bukan semata struktur organisasi. Dua permintaan yang sama-sama berupa akses bisa memiliki konsekuensi berbeda: akses Wi‑Fi tamu jauh berbeda risikonya dibanding akses ke sistem payroll.
Praktiknya, Anda perlu skema klasifikasi yang sederhana dan tegas agar helpdesk bisa memilih workflow yang sesuai sejak awal. Ini mengurangi eskalasi yang muncul karena permintaan salah jalur.
- Jenis layanan: akses, perubahan konfigurasi, pengadaan, permintaan terkait insiden.
- Dampak bisnis: rendah, sedang, tinggi (misalnya memengaruhi proses penagihan).
- Sensitivitas data: publik, internal, rahasia, sangat rahasia.
- Nilai biaya: tanpa biaya, di bawah batas tertentu, melewati batas dan perlu otorisasi finansial.
- Kebutuhan pemisahan tugas: siapa yang meminta tidak boleh menyetujui, terutama untuk hak akses.
Contoh praktis: membuat akun email karyawan baru bisa berisiko sedang, sedangkan reset MFA untuk eksekutif termasuk risiko tinggi karena membuka potensi pengambilalihan akun. Dari situ, Anda bisa menetapkan aturan approval dan eskalasi yang berbeda.
Rancang jalur eskalasi: siapa, kapan, dan kriteria naik level
Dalam approval workflow IT request, eskalasi bukan hanya “naik ke atasan” saat terlambat. Eskalasi harus menjawab tiga hal: siapa penerima eskalasi, kapan pemicunya, dan kriteria yang membuat kasus harus dinaikkan meski belum melewati batas waktu.
Mulailah dengan definisi peran yang konsisten di semua layanan. Hindari menggunakan nama individu karena rotasi, cuti, dan perubahan jabatan sering menjadi sumber hambatan.
- Approver utama: pemilik layanan atau atasan peminta sesuai kebijakan.
- Approver pengganti: delegasi saat approver utama cuti atau tidak aktif.
- Penerima eskalasi: service owner, manajer IT, atau komite akses untuk sistem kritikal.
- Pihak konsultasi: Security/Compliance untuk permintaan yang menyentuh data sensitif.
Berikut pola pemicu waktu yang umum dan mudah diaudit. Sesuaikan dengan jam kerja organisasi di Indonesia (misalnya 08.00–17.00 WIB) agar perhitungan SLA akurat.
Eskalasi berbasis waktu (time-based) biasanya berlangsung dua tahap. Tahap pertama pengingat otomatis saat mendekati batas, tahap kedua eskalasi ke peran di atasnya bila melewati batas.
- T-25% dari SLA approval: pengingat ke approver utama.
- T-0 (melewati SLA): eskalasi ke approver pengganti dan tembusan ke service owner.
- T+1 hari kerja: eskalasi ke manajemen layanan untuk keputusan cepat atau penetapan prioritas.
Eskalasi berbasis kondisi (condition-based) dipakai agar isu berisiko tinggi naik segera tanpa menunggu waktu habis. Contohnya permintaan akses admin, akses data pelanggan, atau perubahan firewall yang berdampak luas.
Agar notifikasi tidak berlebihan, buat kriteria condition-based yang ketat dan terukur. Misalnya: akses admin selalu butuh persetujuan Security, atau biaya di atas Rp10.000.000 selalu butuh persetujuan Finance.
Jika organisasi Anda menilai dampak finansial dan kepatuhan, referensi seperti cara mengukur ROI dan kepatuhan pada workflow persetujuan bisa membantu menyelaraskan indikator tanpa mencampur peran dan tanggung jawab.
Terakhir, putuskan apakah eskalasi boleh menggantikan approver (auto-approve) atau hanya memindahkan keputusan ke peran lain. Banyak organisasi di Indonesia memilih tidak melakukan auto-approve untuk akses sensitif karena risiko audit dan keamanan, kecuali ada kontrol kompensasi seperti approval berlapis dan pencatatan alasan.
Bangun guardrail: SLA, delegasi, audit trail, dan pengecualian yang terkendali
Rute eskalasi akan gagal tanpa guardrail operasional. Tujuannya bukan menambah birokrasi, melainkan memastikan workflow tetap berjalan saat orang yang ditunjuk tidak tersedia.
SLA dan jam operasional perlu didefinisikan berdasarkan kategori risiko. Approval untuk akses aplikasi standar dapat punya SLA berbeda dibanding permintaan pengadaan perangkat yang perlu cek stok dan vendor.
- Low risk: SLA approval 4 jam kerja, eskalasi setelah 4 jam.
- Medium risk: SLA 1 hari kerja, eskalasi setelah 1 hari kerja.
- High risk: SLA 2–4 jam kerja, tetapi selalu melibatkan Security sebelum eksekusi.
Delegasi dan fallback harus jelas. Setidaknya setiap approver utama memiliki pengganti berbasis jabatan, bukan orang, serta aturan aktif saat status out of office atau tidak ada respons dalam waktu tertentu.
Audit trail adalah pengaman utama saat eskalasi terjadi. Pastikan sistem merekam siapa menyetujui, kapan, dari perangkat atau saluran mana (jika tersedia), serta catatan alasan untuk kasus khusus seperti percepatan karena kebutuhan bisnis.
Pengecualian (exception handling) sebaiknya dibatasi dan transparan. Banyak tim menambahkan jalur urgent tanpa kriteria jelas, lalu semua orang menandai request sebagai urgent dan workflow runtuh.
Buat aturan sederhana untuk urgent: hanya untuk insiden yang berdampak langsung pada operasional atau onboarding yang terikat tanggal mulai kerja. Minta bukti ringan, misalnya nomor tiket insiden atau tanggal efektif, lalu lakukan audit berkala untuk mencegah penyalahgunaan.
Uji dengan skenario nyata dan perbaiki dari data
Sebelum meluncurkan rute eskalasi, uji dengan 5–10 skenario yang sering muncul di helpdesk. Tujuannya memastikan jalur tidak buntu dan tidak menciptakan lingkaran persetujuan yang membingungkan.
Contoh skenario 1: karyawan baru butuh akses Microsoft 365 dan aplikasi internal. Alur bisa berupa atasan menyetujui kebutuhan, IT provisioning mengeksekusi, dan Security hanya terlibat bila akses ke grup sensitif.
Contoh skenario 2: permintaan akses database produksi untuk troubleshooting. Karena risikonya tinggi, tambahkan persetujuan service owner dan Security, serta batasi masa berlaku akses (misalnya 24–72 jam) agar kontrol tetap ketat.
Setelah berjalan, gunakan data untuk mengkalibrasi: titik bottleneck, rata-rata waktu approval per peran, dan frekuensi eskalasi. Jika 60% eskalasi terjadi pada peran yang sama, masalah mungkin pada kapasitas, penunjukan approver, atau notifikasi yang tidak efektif.
Perbaikan kecil yang sering berdampak besar adalah memperjelas form request agar approver tidak perlu bertanya ulang. Isian seperti sistem yang diminta, alasan bisnis singkat, periode akses, dan level akses mengurangi penundaan yang memicu eskalasi.
Rute eskalasi yang dirancang dari risiko, ditopang SLA yang realistis, dan diaudit dengan baik akan membuat persetujuan lebih cepat tanpa mengorbankan kontrol.
Jika diperlukan, jadwalkan sesi singkat untuk memetakan kategori permintaan dan titik macet terbesar di proses saat ini.
Pelajari lebih lanjut: https://epruvo.com