Pukul sembilan malam, tim support sebuah perusahaan fintech baru sadar ada 40 tiket yang sudah lewat batas waktu penyelesaian. Bukan karena timnya malas. Mereka cuma nggak punya cara untuk tahu tiket mana yang mendekati deadline. Akibatnya, semua menumpuk jadi krisis sebelum sempat ditangani.
Skenario ini bukan kasus langka. Riset dari Salesforce mencatat bahwa 80 persen pelanggan menilai pengalaman layanan sama pentingnya dengan kualitas produk yang mereka beli.
Begitu ekspektasi itu dilanggar, kepercayaan yang dibangun bertahun-tahun bisa runtuh dalam beberapa hari saja. Inilah kenapa Service Level Agreement, atau yang lebih akrab disingkat SLA, jadi elemen yang nggak bisa ditawar.
SLA sendiri secara sederhana adalah kesepakatan formal antara penyedia layanan dan pelanggan. Dokumen ini menetapkan standar kinerja terukur, lengkap dengan konsekuensi jika standar itu tidak tercapai.
Tapi punya kesepakatan ini di atas kontrak saja tidak cukup. Tim layanan juga harus tahu cara menghitung SLA dengan benar dan memantaunya setiap hari.
Komponen SLA yang Wajib Dipantau Sebelum Bisa Dihitung
Sebelum masuk ke rumus, ada baiknya kita pastikan dulu komponen mana saja dari sebuah SLA yang sebenarnya bisa diukur. Tanpa komponen yang jelas, perhitungan SLA hanya akan jadi angka kosong.
- Metrik kinerja. Angka-angka spesifik seperti response time, resolution time, dan uptime yang jadi dasar perhitungan.
- Periode pengukuran. Rentang waktu yang dipakai sebagai acuan, biasanya per bulan atau per kuartal.
- Ambang batas toleransi. Persentase downtime atau keterlambatan yang masih diperbolehkan sebelum dianggap melanggar target.
- Cara pelaporan. Format dan frekuensi laporan yang dipakai untuk menyajikan hasil perhitungan ke semua pihak terkait.
Ambil contoh perusahaan e-commerce yang menetapkan SLA respons pertama dalam 30 menit untuk keluhan pembayaran gagal. Kalau periode pengukuran dan ambang toleransinya tidak jelas, tim customer service tidak punya patokan.
Mereka jadi tidak bisa menilai apakah performa bulan ini benar-benar sudah sesuai target atau belum.
Cara Menghitung SLA dengan Rumus yang Tepat
Bagian ini sering jadi titik kebingungan. Target SLA biasanya ditulis dalam bentuk persentase, bukan satuan jam atau menit.
Padahal, mengubah persentase itu menjadi durasi konkret justru jadi langkah penting. Tim operasional jadi tahu berapa banyak “ruang toleransi” yang mereka punya dalam sebulan.
Soal alat hitungnya sendiri, sebagian besar tim masih pakai spreadsheet manual di awal. Excel atau Google Sheets cukup buat bisnis kecil dengan volume tiket rendah, asal rumusnya sudah benar dan di-update rutin.
Masalahnya muncul begitu volume tiket naik. Hitung manual jadi rawan salah ketik, telat update, atau lupa exclude jam non-operasional dari total jam layanan.
Di titik ini, kebanyakan tim beralih ke tools khusus seperti helpdesk software (Zendesk dan Freshdesk) yang punya fitur SLA tracking otomatis,
atau ke platform SLA management terpisah seperti Adaptist PROSE yang langsung menghitung compliance rate dan toleransi downtime secara real-time tanpa perlu rumus manual tiap bulan.
Menghitung Total Jam Layanan dalam Sebulan
Rumus dasarnya cukup sederhana. Total jam dalam satu bulan dihitung dari jumlah hari dikali 24 jam, dan angka itulah yang merepresentasikan service level 100 persen. Ini berlaku untuk layanan yang memang jalan 24 jam, misalnya infrastruktur cloud atau penyedia internet.
Total jam (100%) = Jumlah hari dalam bulan x 24 jam
Sebagai contoh, bulan dengan 30 hari memiliki total 720 jam (30 x 24). Bulan dengan 31 hari punya 744 jam.
Tapi rumus ini berubah kalau bisnisnya tidak beroperasi 24 jam. Anggap saja sebuah klinik kesehatan buka customer service dari jam 8 pagi sampai 8 malam, 7 hari seminggu. Jam operasionalnya cuma 12 jam per hari, bukan 24.
Total jam (100%) = Jumlah hari dalam bulan x Jam operasional per hari
Untuk bulan dengan 30 hari, totalnya jadi 30 x 12, yaitu 360 jam. Bukan 720 jam seperti contoh layanan 24 jam tadi.
Kesalahan yang sering terjadi: tim tetap pakai basis 720 jam padahal layanannya cuma jalan 12 jam sehari. Akibatnya, toleransi downtime yang dihitung jadi dua kali lebih besar dari yang seharusnya, dan compliance rate yang dilaporkan ke klien jadi tidak akurat.
Menghitung Toleransi Downtime
Setelah angka dasar ini didapat, langkah berikutnya adalah menghitung toleransi downtime berdasarkan persentase SLA yang disepakati.
Toleransi downtime = (100% – persentase SLA) x Total jam dalam bulan
Misalnya, sebuah penyedia layanan internet menjamin SLA sebesar 99,5 persen untuk bulan dengan 30 hari (720 jam). Toleransi downtime yang diperbolehkan adalah 0,5% x 720 jam.
Hasilnya yaitu 3,6 jam, atau sekitar 3 jam 36 menit dalam sebulan.
Bandingkan dengan SLA 99,9 persen pada bulan yang sama. Toleransi downtime-nya cuma 0,1% x 720 jam, yaitu 0,72 jam atau sekitar 43 menit saja.
Selisih 0,4 persen ternyata berdampak besar. Selisih kecil ini menentukan berapa lama sistem boleh “diam” sebelum dianggap melanggar kontrak.
Menghitung SLA Compliance Rate
Selain perhitungan uptime, banyak tim layanan juga perlu menghitung SLA compliance rate. Metrik ini mengukur seberapa konsisten tim memenuhi target dari waktu ke waktu.
SLA Compliance Rate = (Jumlah tiket yang memenuhi SLA / Total tiket) x 100%
Contohnya, dari 500 tiket yang masuk dalam sebulan, 460 tiket berhasil diselesaikan sesuai target SLA. Compliance rate-nya adalah (460/500) x 100%, yaitu 92 persen.
Angka ini jadi acuan penting untuk evaluasi kinerja tim secara berkala.
Metrik yang Perlu Dipantau untuk Menjaga Kepatuhan SLA
Menghitung SLA di atas kertas hanya separuh dari pekerjaan. Separuh lainnya adalah memantau metrik yang relevan secara konsisten.
Dengan begitu, tim tahu posisi mereka sebelum target benar-benar terlewat.
| Metrik | Definisi | Contoh Target |
| Response Time | Waktu yang dibutuhkan tim untuk merespons tiket pertama kali | Respons dalam 30 menit |
| Resolution Time | Waktu total yang dibutuhkan untuk menyelesaikan tiket sepenuhnya | Selesai dalam 4 jam |
| First Call Resolution (FCR) | Persentase tiket yang selesai pada interaksi pertama tanpa eskalasi | FCR di atas 70% |
| Mean Time to Repair (MTTR) | Rata-rata waktu untuk memulihkan layanan setelah gangguan | MTTR di bawah 2 jam |
| Uptime/Availability | Persentase waktu sistem beroperasi tanpa gangguan dalam periode tertentu | Uptime 99,9% per bulan |
Setiap baris di tabel di atas punya cara baca yang berbeda tergantung jenis bisnisnya. Platform e-commerce, misalnya, mungkin lebih menitikberatkan pada uptime.
Setiap menit sistem down berarti transaksi yang batal bagi mereka.
Sementara perusahaan jasa konsultasi mungkin lebih fokus pada resolution time. Klien mereka menilai kualitas layanan dari seberapa tuntas masalah diselesaikan, bukan sekadar seberapa cepat direspons.
Strategi Memantau SLA agar Tidak Kebobolan Deadline
Punya metrik yang jelas tidak ada gunanya kalau tidak ada mekanisme untuk memantaunya secara aktif. Banyak tim baru sadar SLA terlanggar setelah klien komplain.
Padahal seharusnya sistem sudah memberi peringatan jauh sebelum itu terjadi.
Gunakan Dashboard Real-Time
Dashboard yang menampilkan status setiap tiket secara langsung memungkinkan tim melihat mana yang mendekati deadline. Tim tidak perlu mengecek satu per satu secara manual.
Indikator warna seperti hijau, kuning, dan merah biasanya dipakai untuk menandai tingkat urgensi.
Contohnya, tim helpdesk sebuah perusahaan logistik menggunakan dashboard yang otomatis berubah warna menjadi kuning. Perubahan ini terjadi ketika tiket mencapai 70 persen dari batas waktu SLA.
Dengan begitu, supervisor bisa langsung mengalihkan tiket itu ke agen yang lebih senior sebelum benar-benar terlambat.
Terapkan Notifikasi Bertingkat
Satu kesalahan umum dalam pemantauan SLA adalah mengatur notifikasi hanya muncul tepat di deadline. Padahal saat notifikasi itu sampai, kesempatan untuk mencegah pelanggaran sudah hilang.
Pendekatan yang lebih efektif adalah membuat dua lapis peringatan. Peringatan awal muncul saat 50 persen dari waktu toleransi terpakai, dan eskalasi kedua saat mencapai 80 sampai 90 persen.
Sebagai contoh, untuk tiket dengan SLA resolusi 4 jam, peringatan pertama muncul di jam ke-2. Peringatan kedua muncul di jam ke-3,2.
Pendekatan ini memberi tim waktu cukup untuk bertindak sebelum waktu benar-benar habis.
Buat Laporan Berkala
Laporan mingguan atau bulanan memberi gambaran menyeluruh tentang tren kepatuhan SLA, bukan cuma snapshot satu hari saja. Laporan ini juga jadi bahan diskusi objektif antara penyedia layanan dan klien.
Sebagai ilustrasi, sebuah tim IT internal menemukan dari laporan bulanan bahwa compliance rate mereka turun dari 95 persen ke 88 persen. Penurunan ini khusus terjadi pada kategori tiket “integrasi API”.
Temuan ini mengarahkan mereka untuk menambah satu spesialis di area tersebut. Mereka tidak perlu menambah jumlah staf secara merata di semua kategori.
Tetapkan Jalur Eskalasi yang Jelas
Tidak semua tiket bisa diselesaikan di level pertama. Jalur eskalasi yang terstruktur menentukan siapa yang harus dihubungi, kapan, dan dengan cara apa.
Sebagai contoh, perusahaan SaaS menetapkan aturan: jika tiket prioritas tinggi belum direspons dalam 1 jam, sistem otomatis mengirim notifikasi ke team lead.
Jika dalam 2 jam masih belum tertangani, eskalasi naik ke level manajer.
Alur seperti ini mencegah tiket “menggantung” tanpa ada yang bertanggung jawab.
Apa yang Terjadi Jika Tidak Memenuhi Target SLA?
Dari sisi agen yang pegang tiket, konsekuensinya kerasa duluan di level personal. Tiket yang lewat SLA biasanya masuk daftar evaluasi performa bulanan. Beberapa perusahaan mengikat bonus atau insentif langsung ke compliance rate individu. Agen dengan SLA breach tinggi bisa kena coaching tambahan, atau dalam kasus berulang, jadi pertimbangan saat review kontrak.
Ada juga efek yang jarang dibahas: tiket yang sudah telat sering ditangani dengan terburu-buru. Agen jadi fokus “menutup” tiket secepat mungkin biar nggak makin lewat target, bukan benar-benar menyelesaikan masalah pelanggan. Ujungnya, tiket itu dibuka lagi beberapa hari kemudian karena solusinya cuma tambal sulam.
Dari sisi perusahaan, dampaknya lebih besar dan lebih mahal. Sebagian besar kontrak SLA, terutama di B2B, mencantumkan klausul penalti finansial. Bentuknya bisa berupa kredit layanan atau potongan biaya bulanan, dihitung berdasarkan persentase pelanggaran.
Penyedia layanan cloud, misalnya, umumnya memberi kredit 10 persen dari biaya bulanan untuk setiap penurunan 1 persen di bawah SLA uptime yang dijanjikan.
Kalau pelanggaran terjadi berulang dalam periode kontrak, klien biasanya punya hak untuk membatalkan kontrak lebih cepat tanpa penalti pemutusan, sesuatu yang jarang terjadi kalau SLA dijaga konsisten.
Ada juga kerugian yang tidak langsung tercatat di invoice. Klien yang kecewa karena SLA berkali-kali tidak tercapai biasanya tidak langsung pergi. Mereka mulai mencari vendor cadangan, mengurangi volume kerja sama secara bertahap, sampai akhirnya kontrak tidak diperpanjang.
Riset Salesforce yang disebutkan di awal relevan di sini: begitu pengalaman layanan dianggap setara penting dengan produk, pelanggaran SLA berulang otomatis dianggap sebagai cacat produk itu sendiri.
Kesimpulan
Menghitung SLA sebenarnya bukan soal rumus yang rumit. Ini soal konsistensi menerjemahkan persentase di kontrak menjadi angka operasional yang bisa dipakai sehari-hari.
Begitu rumus itu dipahami, pekerjaan sesungguhnya baru dimulai. Tim harus memantau setiap tiket secara real-time agar tidak ada satupun yang lolos dari radar.
Tim yang berhasil menjaga SLA bukan tim yang paling banyak orangnya. Tim itu adalah yang punya visibilitas penuh terhadap setiap proses yang berjalan.
Notifikasi bertingkat, dashboard yang jelas, dan jalur eskalasi yang terstruktur adalah fondasinya.
Ketiga elemen itu yang membuat kepatuhan SLA jadi kebiasaan, bukan kebetulan.
Kalau saat ini tim Anda masih mengandalkan spreadsheet atau pengecekan manual untuk memantau SLA, Adaptist PROSE dari Accelist Adaptist Consulting dirancang untuk mengambil alih beban itu.
Lewat dashboard real-time, notifikasi otomatis, dan laporan kepatuhan yang terstruktur, Adaptist PROSE membantu tim Anda bekerja lebih tenang.
Tim Anda bisa mendeteksi potensi pelanggaran SLA sebelum benar-benar terjadi, bukan setelah klien yang memberi tahu lebih dulu.
Optimalkan Layanan Pelanggan Anda
Jadwalkan demo Adaptist Prose dan lihat bagaimana Ticketing System terintegrasi membantu menyatukan tiket, percakapan, dan data pelanggan dalam satu dashboard. Dengan alur kerja yang lebih terstruktur, tim dapat merespons lebih cepat, mengurangi beban operasional, dan menjaga kualitas layanan tetap konsisten seiring pertumbuhan bisnis.
FAQ
Standar layanan yang disepakati antara penyedia dan pelanggan.
Bandingkan target SLA dengan kinerja aktual.
Untuk menjaga kualitas layanan dan kepuasan pelanggan.
