Service Level Agreement (SLA) dengan vendor aplikasi pembayaran sekolah adalah "kontrak janji" tertulis yang mendefinisikan secara terukur apa yang menjadi hak sekolah dan kewajiban vendor. Tanpanya, Anda bergantung pada itikad baik — dan itikad baik tidak enforceable. Faktanya, 73% sekolah di Indonesia tidak memiliki SLA formal dengan vendor aplikasi, dan 89% dari mereka mengalami setidaknya 1 insiden sistem down lebih dari 4 jam tanpa kompensasi apapun. Artikel ini menjelaskan 5 komponen SLA yang wajib ada — dari uptime guarantee, response time, kepemilikan data, hingga klausul terminasi — dalam bahasa yang dipahami kepsek dan bendahara, bukan pengacara.
Hari Selasa, tanggal 7 — tiga hari sebelum deadline SPP. Tiba-tiba sistem pembayaran sekolah error: orang tua tidak bisa melakukan pembayaran, notifikasi WhatsApp tidak terkirim. Bu Ratna, bendahara, langsung chat vendor via WhatsApp: "Pak, sistem error. Bisa dibantu?" Dibalas 2 jam kemudian: "Maaf Bu, tim teknis sedang istirahat. Nanti kami cek ya." Jam 5 sore belum ada update. Jam 8 malam masih error. Besoknya, 15 orang tua komplain. Bu Ratna panik, kepsek ikut panik, dan vendor — tetap slow response. Ini terjadi karena TIDAK ADA SLA. Tanpa SLA, vendor tidak punya kewajiban kontraktual untuk merespons cepat. Mereka "membantu" atas dasar itikad baik — dan itikad baik tidak bisa Anda tuntut saat sistem down di jam kritis.
SLA bukan dokumen 50 halaman penuh istilah hukum. SLA yang baik justru singkat, terukur, dan jelas — sehingga kedua pihak memahaminya. Artikel ini memberi Anda kerangka untuk menyusun SLA yang adil: melindungi sekolah tanpa menjadi tidak masuk akal bagi vendor. Karena hubungan vendor-sekolah yang profesional dimulai dari ekspektasi yang jelas.
Apa Itu SLA? Bukan Dokumen Rumit — Tapi "Janji Tertulis" yang Terukur
SLA (Service Level Agreement) adalah perjanjian layanan antara sekolah dan vendor aplikasi. Isinya sederhana — hanya 4 elemen:
- Apa yang akan diberikan vendor (layanan — misal: sistem pembayaran SPP online)
- Seberapa bagus layanannya (target — misal: sistem online 99,5% setiap bulan)
- Bagaimana mengukurnya (metrik — misal: uptime diukur oleh monitoring tool independen)
- Apa yang terjadi jika target tidak tercapai (konsekuensi — misal: kredit layanan 5% dari biaya bulanan)
Bandingkan dengan "perjanjian lisan" yang sering terjadi: vendor bilang "tenang Bu, kami fast response kok" — tapi tidak ada definisi "fast." Apakah 5 menit? 1 jam? 1 hari? Inilah mengapa SLA harus TERTULIS dan terukur. SLA yang baik melindungi KEDUA BELAH PIHAK: sekolah dapat layanan yang terjamin, vendor dapat ekspektasi yang jelas — tidak ada dispute "saya kira maksudnya..." di kemudian hari.
SLA biasanya menjadi LAMPIRAN dari kontrak utama — dirujuk dengan kalimat: "Layanan akan diberikan sesuai Service Level Agreement sebagaimana tercantum dalam Lampiran A." Ini penting karena: (1) lampiran memiliki kekuatan hukum yang sama dengan kontrak, (2) SLA bisa direvisi lebih sering (setiap triwulan) tanpa mengubah kontrak utama, dan (3) jika terjadi dispute, SLA adalah acuan tertulis yang bisa diverifikasi.
Komponen 1 — Uptime & Availability: Seberapa Sering Sistem Boleh Down?
Uptime adalah metrik SLA paling dasar: persentase waktu sistem berfungsi normal dalam periode tertentu (biasanya bulanan). Semakin tinggi persentase, semakin sedikit toleransi untuk down. Untuk sistem pembayaran sekolah, berikut standar yang direkomendasikan:
- 99,5% uptime = maksimal 3,6 jam down per bulan — standar realistis untuk vendor SaaS pendidikan. Ini adalah keseimbangan terbaik antara ketersediaan dan biaya.
- 99,9% uptime = maksimal 43 menit down per bulan — standar enterprise-level. Lebih mahal, umumnya tidak diperlukan untuk sekolah.
- 99% atau di bawahnya — tidak dapat diterima untuk sistem pembayaran. Ini berarti bisa down 7+ jam per bulan.
Yang WAJIB ada di klausul uptime:
- Definisi "down": Sistem tidak bisa diakses sama sekali? Atau transaksi pembayaran gagal 100%? Definisikan dengan jelas.
- Periode pengukuran: Bulanan (direkomendasikan) atau triwulanan.
- PENGECUALIAN (important!): Maintenance terjadwal — harus diberitahu minimal 48 jam sebelumnya dan dilakukan di luar jam sibuk (Minggu 00:00-06:00 WIB). Force majeure (bencana alam, pemadaman listrik massal, serangan DDoS besar).
- Konsekuensi: Jika uptime di bawah target, apa kompensasinya? Saran: kredit layanan proporsional. Contoh: uptime 98% (di bawah 99,5%) → kredit 5% dari biaya bulanan. Uptime di bawah 95% → kredit 15% atau opsi terminasi kontrak tanpa penalti.
- Metode pengukuran: HARUS oleh pihak ketiga independen (UptimeRobot, Pingdom, Better Uptime) — BUKAN klaim vendor sendiri. Minta akses read-only ke dashboard monitoring.
Komponen 2 — Response & Resolution Time: Berapa Lama Sampai Masalah Selesai?
Ini adalah komponen SLA yang paling sering digunakan sehari-hari. Ada dua metrik yang berbeda:
- Response Time: Berapa cepat vendor MERESPONS — mengakui bahwa laporan diterima dan sedang ditangani.
- Resolution Time: Berapa cepat masalah SELESAI — sistem kembali normal.
Keduanya dibedakan berdasarkan severity level (tingkat keparahan). Berikut standar yang direkomendasikan:
| Level | Deskripsi | Response | Resolution | Eskalasi |
|---|---|---|---|---|
| P1 — Critical | Sistem down total, transaksi gagal 100%, semua user terdampak | <30 menit | <4 jam | Otomatis ke VP Engineering jika >2 jam |
| P2 — High | Fitur utama error (notifikasi gagal, laporan tidak bisa generate) | <1 jam | <8 jam | Eskalasi ke Tech Lead |
| P3 — Medium | Fitur non-kritis error (filter lambat, export CSV error) | <4 jam | <24 jam | Standard queue |
| P4 — Low | Cosmetic, pertanyaan umum, request minor | <24 jam | <72 jam atau next release | Standard queue |
Tips penting: SLA harus mendefinisikan BAGAIMANA melaporkan masalah — bukan sekadar "chat WhatsApp." Harus ada sistem tiket formal (email ke support@vendor.com, portal helpdesk, atau form khusus) yang memberikan NOMOR TIKET dan timestamp otomatis. Tanpa tiket, tidak ada bukti kapan masalah dilaporkan — dan SLA tidak bisa ditegakkan.
Komponen 3 — Dukungan & Eskalasi: Siapa yang Bertanggung Jawab Saat Sistem Error?
SLA harus mendefinisikan struktur dukungan dengan jelas — siapa yang dihubungi, kapan, dan apa yang terjadi jika orang tersebut tidak merespons.
Single Point of Contact (SPOC)
Sekolah harus memiliki SATU kontak utama ke vendor, biasanya Customer Success Manager (CSM) atau Account Manager — BUKAN nomor WhatsApp sales yang sudah pindah jabatan 3 bulan lalu. SPOC bertanggung jawab memastikan semua tiket ditangani sesuai SLA.
Jam Operasional Support
Untuk sistem pembayaran, support 24/7 sangat disarankan — pembayaran orang tua tidak kenal jam kerja. Jika vendor hanya support business hours (Senin-Jumat 08:00-17:00), harus ada on-call system: satu orang teknisi stand-by di luar jam kerja untuk masalah P1-Critical.
Struktur Eskalasi 3-Tingkat
- Tingkat 1 — CSM/Account Manager: Kontak pertama. Jika tidak merespons dalam SLA →
- Tingkat 2 — Team Lead / VP Product: Kontak jika CSM tidak merespons. Memiliki otoritas lebih besar untuk mengerahkan sumber daya.
- Tingkat 3 — CTO / CEO: Eskalasi tertinggi. Hanya untuk insiden P1-Critical yang unresolved lebih dari 4 jam.
Setiap tingkat harus memiliki response time yang LEBIH PENDEK dari tingkat sebelumnya — karena masalah sudah lebih lama unresolved.
Quarterly Business Review (QBR)
SLA bukan dokumen statis — harus direview berkala. Jadwalkan QBR setiap 3 bulan: meeting 60 menit, evaluasi pencapaian SLA, bahas insiden 3 bulan terakhir, identifikasi perbaikan, dan update target SLA jika diperlukan. Sekolah yang melakukan QBR dengan vendor mengalami 60% lebih sedikit insiden kritis di tahun kedua — karena masalah sistemik terdeteksi dan diperbaiki lebih awal.
Komponen 4 — Data & Keamanan: Siapa Pemilik Data Sekolah Anda?
Ini adalah komponen SLA yang PALING SERING TERLEWATKAN — dan paling berbahaya jika diabaikan. Pastikan SLA/kontrak mencakup 5 klausul data berikut:
Kepemilikan Data
Data siswa, data pembayaran, dan data keuangan adalah MILIK SEKOLAH — bukan milik vendor. Klausul ini harus eksplisit tertulis di SLA. Tanpanya, saat kontrak berakhir, vendor bisa mengklaim data sebagai aset mereka. Untuk standar keamanan lengkap, baca standar keamanan sistem pembayaran.
Akses & Ekspor Data
Sekolah harus bisa mengakses dan mengekspor SEMUA data kapan saja, dalam format yang bisa dibaca (CSV, Excel, PDF), TANPA biaya tambahan. Ini bukan "fitur premium" — ini adalah hak dasar Anda sebagai pemilik data.
Retensi & Penghapusan
Berapa lama data disimpan setelah kontrak berakhir? Standar: vendor harus memberikan waktu minimal 30-60 hari bagi sekolah untuk mengekspor data sebelum dihapus permanen. Proses penghapusan harus disertifikasi (sertifikat data destruction).
Data Breach Response
Apa yang terjadi jika terjadi kebocoran data? SLA harus mencakup: (1) Notifikasi ke sekolah dalam 24 jam setelah breach terdeteksi, (2) Vendor menanggung biaya investigasi forensik, (3) Vendor menanggung biaya notifikasi ke orang tua yang terdampak — sesuai UU PDP. Terkait regulasi, baca juga panduan regulasi pembayaran sekolah di Indonesia.
Hak Audit
Apakah sekolah atau auditor independen bisa mengaudit keamanan vendor? Minimal: hak audit 1 kali per tahun. Vendor yang menolak hak audit = red flag — apa yang mereka sembunyikan?
Komponen 5 — Kompensasi & Terminasi: Apa yang Terjadi Jika Vendor Gagal Memenuhi Janji?
SLA tanpa konsekuensi = tidak berguna. Ini adalah "gigi" dari SLA — yang membuat vendor serius memenuhinya.
Service Credit (Kompensasi Finansial)
Untuk setiap kegagalan memenuhi SLA, sekolah menerima kredit layanan — potongan tagihan bulan berikutnya. Contoh struktur service credit:
- Uptime <99,5% → kredit 5% dari biaya bulanan
- Response time P1 >30 menit → kredit 2% per jam keterlambatan (maksimum 20%)
- Resolution time P1 >4 jam → kredit 5% per jam keterlambatan
Service credit BUKAN penalti yang membuat vendor bangkrut — tapi cukup "sakit" sehingga vendor termotivasi memenuhi SLA. Untuk memahami struktur biaya vendor, baca panduan biaya aplikasi pembayaran sekolah 2026.
Klausul Terminasi
Ini adalah klausul PALING PENTING dalam SLA. Standar yang direkomendasikan:
- Jika vendor gagal memenuhi SLA untuk 3 bulan berturut-turut ATAU 4 dari 6 bulan → sekolah berhak memutus kontrak TANPA PENALTI.
- Jika uptime di bawah 95% dalam 1 bulan → opsi terminasi langsung tanpa penalti (insiden sangat serius).
JANGAN tanda tangan kontrak yang tidak memiliki klausul terminasi yang adil. Kontrak yang mengunci sekolah 3-5 tahun tanpa opsi keluar jika vendor buruk — apapun alasannya — adalah RED FLAG.
Exit Plan
Apa yang terjadi saat kontrak berakhir secara normal? Prosedur harus jelas: ekspor data (format, timeline), penghapusan data (sertifikasi), dan serah terima ke vendor baru jika diperlukan. Untuk panduan menyusun proposal ke yayasan, lihat template proposal digitalisasi untuk yayasan.
Template SLA 2 Halaman: Contoh yang Bisa Anda Adaptasi
Berikut kerangka SLA sederhana yang bisa langsung Anda gunakan sebagai titik awal. Ingat: template ini adalah DRAFT — konsultasikan dengan konsultan hukum untuk finalisasi, terutama untuk kontrak di atas Rp 100 juta/tahun.
Halaman 1 — Layanan & Metrik:
- Pihak: Nama Sekolah & Nama Vendor
- Periode: 1 Januari 2026 — 31 Desember 2026 (auto-renewal kecuali ada pemberitahuan tertulis 30 hari sebelumnya)
- Layanan Tercakup: Sistem pembayaran SPP online, notifikasi WhatsApp otomatis, dashboard laporan keuangan, ekspor data, API integrasi (jika ada)
- Tabel Metrik SLA: Uptime (target, pengukuran, konsekuensi), Response Time (per severity), Resolution Time (per severity)
- Jam Dukungan & Eskalasi: 24/7 untuk P1, business hours untuk P2-P4. Struktur eskalasi 3 tingkat
Halaman 2 — Data, Kompensasi & Review:
- Kepemilikan Data: Data adalah milik sekolah. Akses ekspor kapan saja tanpa biaya
- Data Breach: Notifikasi 24 jam, vendor tanggung investigasi dan notifikasi
- Hak Audit: 1 kali per tahun oleh auditor independen
- Kompensasi: Tabel service credit per kegagalan
- Terminasi: Kegagalan SLA 3 bulan berturut-turut → terminasi tanpa penalti
- QBR: Review triwulanan, 60 menit, evaluasi dan update SLA
- Tanda tangan kedua pihak + tanggal
SLA yang baik bukan senjata untuk "menyerang" vendor — ini adalah fondasi hubungan profesional yang dewasa. Sekolah tahu apa yang diharapkan, vendor tahu apa yang harus dipenuhi. Jika Anda ingin melihat seperti apa SLA yang transparan dalam praktiknya, jadwalkan demo Seqolah — kami akan tunjukkan SLA kami beserta dashboard monitoring uptime real-time yang bisa Anda akses sendiri.
Pertanyaan Yang Sering Diajukan
Apakah SLA ini berlaku untuk semua vendor — termasuk vendor kecil?
YA, semua vendor harus bisa memberikan SLA. Yang membedakan adalah ANGKA dalam SLA, bukan ADA/TIDAKnya SLA. Vendor kecil mungkin tidak bisa menjamin 99,9% uptime (butuh infrastruktur mahal), tapi mereka HARUS bisa menjamin minimal 99% uptime dan response time yang realistis. Justru vendor kecil yang tidak mau memberikan SLA adalah red flag — artinya mereka tidak percaya diri dengan layanan sendiri.
Apakah SLA perlu dicantumkan di kontrak utama atau cukup dokumen terpisah?
SLA sebaiknya menjadi LAMPIRAN kontrak utama — dirujuk dengan kalimat eksplisit. Ini penting karena lampiran memiliki kekuatan hukum sama dengan kontrak, SLA bisa direvisi lebih sering tanpa mengubah kontrak utama, dan jika terjadi dispute, SLA adalah acuan tertulis yang bisa diverifikasi. Jangan biarkan SLA hanya sebagai janji lisan atau email konfirmasi.
Bagaimana jika vendor menolak memberikan SLA dengan target yang kami minta?
Tanyakan MENGAPA — jawabannya akan mengungkap kapasitas vendor sebenarnya. Jika vendor menolak 99,5% uptime dan hanya sanggup 98%, artinya sistem mereka sering down. Jika menolak response time <1 jam, artinya tim support kecil. Gunakan informasi ini untuk evaluasi risiko. Jika tidak bisa diterima: (1) negosiasikan kompensasi lebih besar, atau (2) cari vendor lain. Lebih baik tidak ada kontrak daripada kontrak dengan vendor yang tidak bisa diandalkan.
Berapa biaya membuat SLA dengan bantuan konsultan hukum?
Untuk SLA sederhana menggunakan template di artikel ini, Anda bisa membuat sendiri dan minta review oleh konsultan hukum — biaya review biasanya Rp 2-5 juta untuk dokumen 2-5 halaman. Untuk kontrak lengkap (kontrak utama + SLA + DPA) yang dibuat dari awal oleh firma hukum, biaya berkisar Rp 10-25 juta — biasanya untuk sekolah besar atau yayasan multi-sekolah. Alternatif hemat: gunakan template, minta vendor mengisi angka SLA yang mereka sanggupi, lalu bawa ke LBH kampus untuk verifikasi.
Apa yang terjadi jika vendor melanggar SLA — apakah kami bisa langsung mengakhiri kontrak?
TIDAK langsung — harus mengikuti mekanisme yang ditentukan. Standar: (1) Kegagalan pertama: peringatan tertulis + service credit. (2) Kegagalan berulang: performance improvement plan — vendor diberi 30-60 hari untuk memperbaiki. (3) Jika setelah improvement plan masih gagal 3 bulan berturut-turut atau 4 dari 6 bulan: terminasi tanpa penalti. Jangan terminasi sepihak tanpa prosedur — bisa dianggap wanprestasi dan berbalik merugikan sekolah. Jika situasi darurat (vendor bangkrut, menghilang), konsultasikan dengan pengacara.