TL;DR
SLA tim data satu orang adalah kesepakatan tertulis soal berapa lama tiap jenis permintaan data dijawab dan dikerjakan. Isinya minimal tiga hal: form intake wajib, tiga tingkat prioritas dengan waktu respons yang beda, dan batas kapasitas jam per minggu. Tanpa SLA, urutan kerja kamu ditentukan siapa yang paling berisik di grup WhatsApp.
SLA tim data satu orang adalah kesepakatan tertulis soal berapa lama tiap jenis permintaan data bakal dijawab dan diselesaikan. Isinya angka, bukan janji.
Kalau kamu satu-satunya orang yang ngerti SQL di kantor, kamu udah tau masalahnya. Permintaan datang dari lima arah. Semuanya ditandain urgent. Yang paling berisik yang dikerjain duluan.
SLA ngubah urutan itu dari siapa-paling-keras jadi apa-paling-berdampak. Dan yang lebih penting: kamu punya dokumen buat nunjukin kenapa permintaan seseorang belum kesentuh.
Di bawah ini aku pakai contoh dari log permintaan sebuah distributor FMCG di Bekasi. 214 permintaan masuk selama 6 bulan, dikerjain satu analis.
SLA (service level agreement) adalah dokumen yang nyebutin layanan apa yang kamu kasih, berapa lama waktu responsnya, dan apa yang di luar cakupan. Buat tim data, isinya biasanya tiga bagian: cara ngirim permintaan, tingkat prioritas dengan waktu tunggu masing-masing, dan daftar hal yang nggak kamu kerjain.
Konsepnya dipinjam dari tim IT support. Atlassian punya penjelasan resmi soal SLA di Jira Service Management yang bagus buat lihat strukturnya.
Bedanya buat tim data satu orang: kamu nggak punya backup. Jadi SLA kamu harus jujur soal kapasitas, bukan nyalin angka dari tim yang isinya delapan orang.
Aku ngitung ulang log 214 permintaan tadi. Hasilnya bikin kaget dua kali.
Pertama, 88 permintaan (41%) sebenernya minta angka yang sama dengan permintaan sebelumnya, cuma beda periode atau beda orang yang minta. Itu 88 kali ngerjain ulang hal yang udah pernah dikerjain.
Kedua, median waktu pengerjaan cuma 3,5 jam per permintaan. Tapi median waktu dari permintaan masuk sampai selesai: 6 hari kerja. Selisihnya bukan kerja. Itu antre, klarifikasi bolak-balik, dan permintaan yang kepotong permintaan lain.
Angka kedua itu yang bikin stakeholder ngerasa tim data lambat. Padahal kerjaannya cuma 3,5 jam.
SLA nutup selisih itu dengan dua cara. Klarifikasi dipindah ke depan lewat form. Dan antrean jadi transparan, jadi orang tau posisinya di nomor berapa.
Ini bagian yang paling nggak enak buat dijalanin, dan paling besar dampaknya.
Satu pintu masuk. Google Form, Notion form, atau channel khusus. Terserah, asal satu.
Enam pertanyaan yang aku pakai:
Pertanyaan nomor 5 yang paling banyak nyaring. Dari 214 permintaan tadi, cuma 19 yang punya kerugian nyata kalau telat sehari.
Simpan semua submission-nya di satu spreadsheet. Ini yang nanti jadi bukti waktu kamu ngobrolin kapasitas sama atasan.
Tiga cukup. Lima terlalu ribet buat dijalanin sendirian.
| Tingkat | Kriteria | Dijawab dalam | Selesai dalam |
|---|---|---|---|
| P1 | Angka salah lagi dipakai buat keputusan, atau pipeline mati | 2 jam kerja | Hari yang sama |
| P2 | Ada deadline eksternal yang nyata (rapat, laporan ke klien, audit) | 1 hari kerja | 3 hari kerja |
| P3 | Berguna, tapi nggak ada yang rugi kalau minggu depan | 1 hari kerja | Masuk backlog, direview tiap Senin |
Perhatiin kolom "dijawab" kepisah dari "selesai". Ini yang sering kelewat.
Balasan dalam 2 jam yang isinya "udah aku terima, masuk P3, target Rabu depan" nurunin tensi jauh lebih efektif daripada diem tiga hari lalu ngirim hasil sempurna. Orang nggak marah karena nunggu. Orang marah karena nggak tau lagi nunggu apa.
Satu aturan tambahan: yang nentuin tingkat prioritas kamu, bukan yang minta. Kalau semua orang boleh nandain P1, dalam dua minggu semuanya P1.
SLA yang nggak dihitung dari kapasitas cuma daftar keinginan.
Mulai dari 40 jam seminggu, lalu potong:
| Pos | Jam | Catatan |
|---|---|---|
| Rapat dan koordinasi | 6 | Standup, rapat divisi, 1-on-1 |
| Laporan rutin | 8 | Refresh dashboard, laporan mingguan |
| Perbaikan dan cek kualitas data | 5 | Pipeline gagal, angka nggak cocok |
| Proyek roadmap | 8 | Dikunci, nggak boleh dipotong permintaan dadakan |
| Sisa buat permintaan ad-hoc | 13 | Ini angka SLA kamu |
13 jam. Dengan median pengerjaan 3,5 jam per permintaan, kapasitas realistis kamu sekitar 3-4 permintaan baru per minggu.
Distributor tadi rata-rata nerima 8,9 permintaan per minggu. Selisihnya bukan masalah kemalasan. Itu masalah aritmatika.
Angka ini yang kamu bawa ke rapat. Bukan "aku kewalahan", tapi "kapasitas 4, masuk 9, jadi 5 permintaan tiap minggu numpuk".
Buat ngitung median waktu pengerjaan dari log kamu sendiri, pakai MEDIAN, bukan rata-rata. Satu proyek yang makan 40 jam bisa narik rata-ratanya jadi nggak masuk akal.
Hitung volume per kategori pakai COUNTIFS:
=COUNTIFS(log!$D$2:$D;"P2";log!$A$2:$A;">="&DATE(2025;11;1))Bagian ini yang bikin SLA kamu punya gigi.
Daftar yang aku pakai:
Poin terakhir itu nyelametin 11 jam kerja di bulan pertama distributor tadi nerapin SLA-nya.
Tulis juga apa yang jadi tanggung jawab peminta. Definisi metrik disepakati sebelum query jalan. Perubahan permintaan di tengah jalan berarti masuk antrean lagi dari belakang. Ini yang bikin scope creep berhenti tanpa kamu harus berdebat tiap kali.
Satu halaman, bisa diakses semua orang, isinya tiga kolom: lagi dikerjain, antre minggu ini, backlog.
Update tiap Senin pagi. Lima menit.
Efeknya lebih besar dari yang aku kira. Waktu orang lihat permintaan mereka nomor 6 dari 11, mereka berhenti nanya "udah sampai mana?". Sebagian malah narik permintaannya sendiri setelah lihat antreannya.
Kalau kamu udah punya dashboard yang jalan, tempel ringkasan antreannya di situ. Nggak perlu tool baru.
Tambahin satu kolom kecil: berapa permintaan yang selesai minggu lalu. Ini bikin kerja kamu keliatan, dan bikin orang paham kenapa antreannya panjang.
Analis di sana nerapin lima langkah di atas mulai Agustus 2025. Perbandingan 3 bulan sebelum dan sesudah:
| Ukuran | Sebelum | Sesudah |
|---|---|---|
| Permintaan masuk per minggu | 8,9 | 5,2 |
| Median waktu tunggu sampai selesai | 6 hari | 2,5 hari |
| Permintaan duplikat | 41% | 12% |
| Jam roadmap yang kepakai per minggu | 1,5 | 7 |
Yang bikin volume turun dari 8,9 ke 5,2 bukan orang jadi males minta. Pertanyaan nomor 5 di form ("kalau telat sehari apa yang rugi?") bikin sebagian orang sadar sendiri permintaannya nggak penting.
Duplikat turun soalnya form-nya nampilin daftar laporan yang udah ada. Setengah dari duplikat selesai sebelum masuk antrean.
Dan 7 jam roadmap per minggu itu yang paling berharga. Di situ dashboard stok akhirnya kelar, yang lalu motong permintaan soal stok jadi hampir nol.
Janji terlalu cepat di awal. Semangat bikin orang nulis "semua permintaan selesai 24 jam". Tiga minggu kemudian meleset terus, dan SLA-nya nggak dipercaya lagi. Mulai dari angka yang kamu yakin bisa penuhi 90% waktu.
Nggak ngelog apa-apa. Tanpa catatan permintaan, kamu nggak punya bukti apa pun waktu diminta kerja lebih banyak. Log itu satu-satunya argumen yang kebal opini.
Ngerjain permintaan chat "cuma sebentar". Sekali dilanggar, formnya mati. Konsistensi lebih penting daripada aturannya sendiri.
SLA ditulis sendiri lalu diumumkan. Ajak minimal dua kepala divisi yang paling sering minta buat review draftnya. Orang lebih patuh ke aturan yang mereka ikut bikin.
Nggak pernah direview. Cek ulang tiap kuartal pakai data log. Kalau P2 meleset 30% dari waktu, angkanya yang salah, bukan kamu.
Bikin draftnya duluan tanpa izin, itu cuma dokumen. Yang butuh persetujuan adalah waktu tunggu di dalamnya, soalnya itu yang ngikat departemen lain. Bawa ke atasan sebagai usulan berbasis data antrean kamu, bukan sebagai keluhan. Biasanya lebih gampang disetujui kalau kamu tunjukin berapa jam kapasitas yang ada dan berapa jam permintaan yang masuk.
Jawab ramah, lalu minta dia isi form. Jangan kerjain permintaannya sebelum formnya masuk, walaupun cuma lima menit. Kalau kamu kerjain sekali, form itu jadi opsional selamanya. Aku biasanya siapin satu balasan template dua kalimat plus link form biar nggak capek ngetik ulang.
Yang aku pakai: P1 dijawab dalam 2 jam kerja dan selesai hari itu juga, P2 dijawab 1 hari kerja dan selesai 3 hari, P3 masuk backlog dan direview tiap Senin. Sesuaikan sama jam kerja kamu. Jangan janjiin angka yang cuma bisa kamu penuhi kalau lembur, soalnya SLA yang sering meleset lebih buruk daripada nggak ada SLA.
SLA ngatur permintaan yang masuk dan berapa lama dijawab. Roadmap ngatur proyek yang kamu rencanakan sendiri, misalnya bikin dashboard baru atau rapiin tabel. Keduanya rebutan jam yang sama. Makanya di SLA kamu perlu nyebut berapa persen waktu mingguan yang dikunci buat roadmap, biar nggak habis kemakan permintaan dadakan.
Cek dulu penyebabnya dari log permintaan. Kalau yang meleset cuma satu jenis permintaan, biasanya estimasi waktunya yang salah, jadi ubah kategorinya. Kalau melesetnya merata, berarti volume permintaan udah lewat kapasitas kamu. Itu bukan masalah disiplin, itu data buat minta tambahan orang atau ngurangin cakupan.
Tiga hal yang paling ngaruh. Satu pintu masuk lewat form, tiga tingkat prioritas dengan waktu respons yang kepisah dari waktu selesai, dan angka kapasitas jam yang dihitung jujur.
Jangan tulis dokumen 10 halaman. Satu halaman yang dipatuhi kalahin sepuluh halaman yang nganggur di Drive.
Minggu ini, catat semua permintaan yang masuk beserta jam pengerjaannya. Dua minggu data aja udah cukup buat nyusun SLA versi pertama yang angkanya beneran, bukan tebakan.
Habis SLA-nya jalan, langkah berikutnya biasanya lebih berat: membangun budaya data di perusahaan yang belum siap.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kerja data analyst di luar negeri bukan soal ijazah luar negeri. Yang nentuin: sponsorship visa, portfolio, dan negara yang kamu incar.
Financial analyst kerja di angka uang, data analyst kerja di angka apa pun. Tapi di 2026 tools-nya makin sama. Ini beda dan irisannya.
Apa itu marketing analyst, metrik apa yang tiap hari dipegang, tools yang wajib bisa, dan jalur masuk yang paling realistis buat orang non-teknis di Indonesia.