Cara Membuat PRD Internal Tool & Dashboard: Kunci Rumus, Bukan Cuma Nama Metrik

Dashboard bilang "Total Penjualan Bulan Ini: Rp48 juta". Tim finance iseng menghitung ulang manual dari data mentahnya, hasilnya Rp51 juta. Dua-duanya kelihatan masuk akal, tidak ada error, tidak ada yang crash, tapi salah satunya pasti keliru, dan tidak ada yang tahu yang mana, karena PRD-nya cuma menulis "tampilkan total penjualan bulan ini" tanpa bilang persis apa yang dihitung sebagai penjualan.

Internal tool dan dashboard kelihatan seperti proyek paling sederhana untuk dibriefkan ke AI coding agent, tinggal tabel, filter, dan beberapa angka ringkasan. Padahal dua hal ini justru yang paling sering bikin runyam: siapa boleh lihat data siapa, dan apakah angka yang tampil bisa dipertanggungjawabkan kalau dihitung ulang manual.

Hak akses: siapa lihat data siapa

Hampir semua internal tool punya lapisan data yang berbeda per peran, tapi lapisan ini sering tidak tertulis eksplisit karena dianggap "sudah jelas dari konteks bisnisnya". Padahal agent AI tidak tahu struktur organisasimu kecuali kamu tuliskan. Ini bukan cuma soal keamanan data, tapi juga soal aplikasinya kepakai atau tidak - sales yang tiap hari harus menyaring data satu cabang penuh dari daftar besar biasanya berhenti membuka dashboard-nya sama sekali.

• Sales - hanya melihat data miliknya sendiri, seperti leads, transaksi, dan komisi
• Supervisor atau manager cabang - melihat seluruh data di cabang atau tim yang dipimpinnya
• Owner atau HO - melihat gabungan seluruh cabang, termasuk perbandingan antar cabang

Kenapa "role: admin" atau "role: user" saja tidak cukup

Banyak internal tool cuma punya dua level akses: admin dan user biasa. Begitu bisnisnya punya struktur cabang, tim, atau wilayah, dua level itu langsung kurang - supervisor cabang Jakarta seharusnya tidak melihat data cabang Surabaya, padahal keduanya sama-sama "bukan admin". PRD perlu menyebutkan struktur ini eksplisit, apakah aksesnya dibatasi berdasarkan cabang, tim, atau kombinasi keduanya, supaya agent tahu kolom apa yang harus dipakai untuk membatasi tiap query.

Tuliskan batasan ini per halaman atau per laporan, bukan cuma sekali di bagian umum. Laporan komisi misalnya, mungkin aturannya beda dari laporan performa tim, dan kalau tidak dirinci, agent cenderung menyamakan semua laporan pakai satu aturan akses yang sama.

Rumus tiap metrik, ditulis eksplisit

Nama metrik doang, "Total Penjualan", "Rata-Rata Nilai Transaksi", "Tingkat Konversi", tidak cukup buat agent membangun angka yang benar, karena tiap orang bisa punya definisi berbeda soal apa yang dihitung. PRD yang baik menuliskan rumusnya persis sampai ke syarat filternya, bukan cuma judul kotaknya.

Total Penjualan Bulan Ini
= SUM(transaksi.total)
  WHERE bulan = bulan_ini
  AND status = 'lunas'

Rata-Rata Nilai Transaksi
= Total Penjualan Bulan Ini / COUNT(transaksi WHERE status = 'lunas')

Dengan rumus setegas ini, agent tidak perlu menebak apakah transaksi yang statusnya masih "menunggu pembayaran" ikut terhitung atau tidak. Tanpa rumus eksplisit, agent akan menebak versi yang "kelihatan masuk akal", dan versi itu belum tentu sama dengan yang selama ini dipakai tim finance.

Detail kecil lain yang layak ditulis di PRD: apa yang ditampilkan kalau pembaginya nol, misalnya belum ada satu pun transaksi lunas di bulan berjalan. Angka error atau "NaN" yang tiba-tiba muncul di kartu dashboard terlihat tidak profesional dan gampang disalahartikan sebagai bug, padahal cuma soal rumus yang belum menangani kasus kosong.

Metrik yang sama di dua halaman harus pakai rumus yang sama

Kasus yang sering kejadian: "Total Penjualan" muncul di halaman ringkasan dan juga di halaman laporan cabang, tapi dibangun terpisah oleh agent di waktu yang berbeda, dengan rumus yang sedikit beda, satu menghitung transaksi berstatus lunas saja, satu lagi ikut menghitung yang masih menunggu pembayaran. Dua angka itu jadi tidak pernah cocok kalau dijumlahkan manual, dan kepercayaan ke dashboard-nya yang kena getahnya. PRD yang menuliskan rumus sekali di satu tempat, lalu mereferensikannya di tiap halaman yang memakai metrik sama, mencegah kejadian ini.

Filter dan rentang tanggal: default-nya apa

Setiap dashboard yang punya filter tanggal butuh perilaku default yang jelas: begitu halaman dibuka tanpa filter apa pun, rentang apa yang otomatis tertampil, bulan berjalan, 30 hari terakhir, atau hari ini saja? Ini perlu ditulis di PRD, bukan diserahkan ke selera agent.

Yang juga sering luput: apakah "hari ini" ikut terhitung dalam rentang "bulan ini", dan jam berapa batas pergantian harinya kalau bisnismu buka sampai lewat tengah malam. Kalau dashboard-mu juga menampilkan perbandingan seperti "naik 12% dari bulan lalu", tuliskan juga persis periode pembandingnya, bulan kalender sebelumnya atau 30 hari sebelum tanggal yang sama, karena dua definisi itu menghasilkan angka persentase yang berbeda.

Kalau tim atau pelanggannya tersebar di beberapa zona waktu, sebutkan juga zona waktu mana yang jadi acuan "hari ini" - server, kantor pusat, atau lokasi masing-masing cabang - supaya batas pergantian harinya tidak ikut berubah-ubah tergantung siapa yang sedang membuka dashboard.

Kenapa hak akses dan rumus metrik saling terkait

Dua masalah ini kelihatan terpisah tapi sering muncul bersamaan: dashboard yang menampilkan "Total Penjualan Tim" untuk supervisor sebenarnya harus dihitung dari transaksi anak buahnya saja, bukan seluruh cabang. Kalau hak aksesnya tidak jelas, rumus yang sudah benar sekalipun bisa menghasilkan angka yang salah karena menghitung data dari orang yang salah. Aturan hak akses dan rumus yang sama ini juga berlaku kalau dashboard-mu punya fitur ekspor atau cetak laporan - laporan yang diunduh sales tidak boleh diam-diam berisi data seluruh tim hanya karena fitur ekspornya lupa memakai filter yang sama dengan tampilan di layar.

Dashboard yang kelihatan simpel dari luar sering kali punya lebih banyak keputusan tersembunyi dibanding aplikasi dengan tampilan yang lebih ramai, justru karena kesederhanaan tampilannya membuat orang lupa merinci apa yang terjadi di baliknya.

Rumus dan hak akses paling efektif kalau dituliskan sebagai acceptance criteria yang bisa dicek per metrik atau per halaman, misalnya "kalau login sebagai Sales, kartu Total Penjualan hanya menjumlahkan transaksi milik sendiri", bukan cuma catatan umum di bagian awal PRD.