Cara Tahu Website Error Sebelum Pelanggan Komplain
Kebanyakan pelanggan tidak melapor saat website error; mereka langsung pergi. Pemantauan yang sederhana membuat Anda tahu lebih dulu dan bisa memperbaiki lebih cepat.
Banyak pemilik bisnis baru tahu website-nya bermasalah setelah pelanggan mengeluh di chat. Itu pun pelanggan yang sabar. Sebagian besar langsung menutup halaman dan membeli di tempat lain. Kabar baiknya, Anda tidak perlu tim besar untuk tahu lebih dulu. Artikel ini membahas lapisan pemantauan yang masuk akal untuk bisnis kecil, dan apa yang sudah kami terapkan di Numekara, bisnis pendidikan yang kami jalankan.
1. Catat setiap galat di server
Galat 500 berarti server gagal memproses permintaan karena masalah di sisi aplikasi, bukan kesalahan pengguna. Setiap galat seperti ini sebaiknya tercatat lengkap: kapan, di halaman apa, dan apa pesan errornya. Tanpa catatan, developer hanya bisa menebak.
Di Numekara, setiap galat 500 langsung disimpan ke database. Alamat email dan nilai isian database dihapus sebelum disimpan, dan catatannya terhapus sendiri setelah 30 hari. Pemilik bisa mencari galat di halaman admin dan mengekspor daftarnya ke CSV.
2. Pantau ketersediaan dari luar
Pencatatan galat tidak menolong bila servernya mati total, karena server yang mati tidak bisa melapor. Untuk itu ada pemantauan ketersediaan (uptime): layanan eksternal yang membuka website Anda setiap beberapa menit dari luar, lalu mengirim peringatan bila tidak ada jawaban. Banyak layanan seperti ini punya paket gratis; cek batas dan aturannya sebelum memilih.
Jujur saja, halaman sistem Numekara saat ini belum mencakup pemantauan uptime. Kami punya skrip pemeriksaan uptime, tetapi sengaja tidak menjalankannya di GitHub Actions, karena bila berjalan setiap 10 menit, pemakaiannya melebihi seluruh kuota menit gratis bulanan. Pelajarannya: pemeriksaan ketersediaan paling cocok dijalankan oleh layanan pemantau eksternal yang memang dibuat untuk itu.
3. Kirim notifikasi ke tempat yang benar-benar dibaca
Peringatan yang masuk ke kotak email yang jarang dibuka sama saja dengan tidak ada. Kirim ke kanal yang dibaca tim setiap hari, misalnya Telegram, dengan email sebagai cadangan. Di Numekara, admin menerima pesan Telegram dan email saat ada prospek baru, pembayaran, atau laporan masalah. Satu kejadian dikirim ke semua kanal aktif bersamaan, jadi bila satu kanal gagal, kanal lain tetap berjalan. Data bisnisnya disimpan dulu ke database, baru notifikasi dikirim.
4. Formulir laporan masalah dengan konteks otomatis
Laporan seperti "websitenya error" sulit ditindaklanjuti. Formulir laporan yang baik mengisi detail teknis sendiri, supaya pengguna cukup menjelaskan apa yang terjadi. Di Numekara, tombol laporkan masalah ada di setiap halaman, dan formulirnya:
- Otomatis menyertakan halaman, perangkat, ukuran layar, versi aplikasi, dan kode galat terakhir.
- Menerima tangkapan layar yang diunggah langsung ke penyimpanan privat.
- Dilindungi pembatasan jumlah kiriman, jebakan bot, dan Cloudflare Turnstile.
- Masuk ke dashboard admin untuk diberi status dan prioritas, dan pelapor menerima email saat laporannya selesai ditangani.
5. Kode korelasi: jembatan antara laporan dan log
Kode korelasi adalah nomor unik untuk satu permintaan ke server, mirip nomor resi. Di Numekara, kode yang sama muncul di catatan galat server, di pesan galat yang dilihat pengguna, dan di laporan masalah. Jadi saat pengguna mengirim tangkapan layar pesan galat, pemilik cukup menempelkan kodenya di halaman sistem untuk melihat galat yang cocok, tanpa menyisir ribuan baris log.
6. Halaman kesehatan sistem
Halaman kesehatan merangkum kondisi sistem di satu tempat. Halaman sistem Numekara menampilkan galat terbaru, status backup, pemakaian email, dan kuota database, sehingga pemilik bisa mengecek tanpa masuk ke server. Saat rilis versi baru, server juga menjalani cek kesehatan otomatis, dan pengunjung baru diarahkan ke versi baru setelah lolos.
Menentukan prioritas penanganan
- Segera: website tidak bisa dibuka, pembayaran gagal, atau pengguna tidak bisa login.
- Hari ini: fitur penting rusak untuk sebagian pengguna, misalnya formulir tidak terkirim di satu jenis ponsel.
- Terjadwal: tampilan berantakan, salah ketik, atau masalah yang ada jalan pintasnya.
Tentukan juga siapa yang bertugas menanggapi, dan beri kabar ke pelanggan yang melapor meski perbaikannya belum selesai.
Mulai dari yang sederhana
Untuk website statis tanpa login, pemantau uptime eksternal dan satu jalur kontak yang jelas sering sudah cukup. Pencatatan galat, kode korelasi, dan formulir laporan lengkap baru sepadan bila website Anda punya akun pengguna, pembayaran, atau data yang terus berubah.
Pelanggan yang melapor sedang memberi Anda kesempatan kedua. Yang tidak melapor biasanya tidak kembali.
