Cara Membuat PRD Aplikasi Marketplace: Apa Saja yang Harus Didefinisikan

Penjual belum sempat konfirmasi pesanan, tapi pembeli sudah transfer duluan. Tiga hari kemudian pembeli komplain karena barangnya belum dikirim, penjual bilang baru lihat notifikasinya sekarang, dan admin platform bingung siapa yang harus disalahkan serta uang itu sekarang statusnya apa. Ini bukan bug di kode. Ini PRD yang dari awal cuma menulis "ada fitur checkout dan pembayaran" tanpa merinci siapa boleh melakukan apa dan pesanan itu berstatus apa di tiap tahap.

Marketplace itu bukan aplikasi dengan satu jenis pengguna. Ada tiga sisi yang jalan bersamaan: pembeli yang mencari dan membayar, penjual yang menerima pesanan dan mengurus stok atau jasanya, dan operator atau admin platform yang mengawasi semuanya, termasuk saat ada masalah. Begitu PRD-nya tidak memisahkan ketiganya secara eksplisit, agent AI yang mengerjakannya akan menebak siapa boleh apa, dan tebakan itu baru ketahuan salah setelah aplikasinya dipakai orang sungguhan.

Kalau ini pertama kalinya kamu menulis PRD, ada baiknya kenalan dulu dengan strukturnya lewat cara membuat PRD untuk aplikasi. Artikel ini fokus ke empat hal yang bikin PRD marketplace beda dari PRD aplikasi biasa: peran, alur transaksi, skema komisi, dan penanganan dispute.

Tiga peran yang jangan sampai kabur

Sebelum menulis satu fitur pun, PRD marketplace wajib punya bagian yang menjabarkan siapa saja penggunanya dan apa saja yang boleh mereka lakukan. Jangan berasumsi agent AI akan "ngerti sendiri" bahwa penjual tidak boleh mengubah status pesanan jadi selesai sebelum barang benar-benar diterima, atau bahwa admin butuh akses buat membatalkan transaksi yang bermasalah. Kalau itu tidak tertulis, itu tidak akan ada.

• Pembeli - menelusuri katalog, checkout, membayar, melihat status pesanannya sendiri, dan memberi rating setelah selesai
• Penjual - mengelola listing atau jasanya, menerima dan memproses pesanan masuk, memantau pendapatan dan riwayat transaksinya sendiri
• Admin/operator - memverifikasi penjual baru, memantau seluruh transaksi platform, dan menjadi pihak berwenang saat terjadi dispute

Tulis dalam bentuk tabel akses, bukan paragraf

Cara paling gampang: buat tabel dengan kolom fitur di satu sisi dan peran di sisi lain, isi tiap selnya dengan boleh atau tidak boleh. Fitur seperti "membatalkan pesanan yang sudah dibayar" misalnya, kemungkinan besar cuma boleh dilakukan admin, bukan penjual atau pembeli sendiri-sendiri. Begitu juga fitur "mengubah harga di listing yang sudah punya pesanan berjalan" - siapa yang boleh, dan apa yang terjadi ke pesanan yang sudah telanjur dibuat dengan harga lama. Setiap fitur yang kamu daftarkan sesudah ini, checkout, chat, penarikan dana, harus jelas peran mana saja yang boleh mengaksesnya.

Alur transaksi lengkap, bukan cuma "pending" dan "selesai"

Kesalahan paling umum di PRD marketplace pemula adalah status pesanan yang cuma dua: pending dan selesai. Padahal antara pembeli klik "pesan" dan transaksi benar-benar tuntas, ada banyak tahap yang masing-masing harus punya nama status sendiri supaya agent tahu logika apa yang harus dibangun di tiap perpindahannya.

1. Pembeli menelusuri katalog dan memilih produk atau jasa
2. Checkout: pembeli mengunci detail pesanan, alamat, atau jadwal
3. Pembayaran: pembeli membayar, sistem mencatat dana masuk
4. Konfirmasi penjual: penjual menerima dan memproses pesanan
5. Selesai dan rating: pembeli mengonfirmasi barang atau jasa diterima, lalu memberi rating

Setiap perpindahan di alur itu adalah keputusan yang perlu kamu kunci di PRD: apa yang terjadi kalau penjual tidak merespons dalam waktu tertentu, dan apakah pembeli bisa membatalkan sendiri sebelum penjual konfirmasi. PRD yang menjawab pertanyaan seperti ini di depan akan menghasilkan kode yang jauh lebih sedikit revisinya dibanding PRD yang cuma menyebut "alur pemesanan standar".

Skema komisi: siapa dapat berapa, kapan dipotong

Komisi adalah bagian yang paling sering ditulis samar, "platform ambil komisi dari tiap transaksi", padahal ini logika bisnis yang langsung menyentuh uang sungguhan. PRD-mu perlu menjawab tiga hal secara eksplisit: berapa persen komisinya dan apakah beda per kategori penjual, pada momen apa komisi itu dipotong (saat pembayaran masuk, atau saat pesanan dinyatakan selesai), dan ke mana sisa dananya mengalir setelah dipotong.

Kalau kamu berencana memakai payment gateway seperti Midtrans, sebutkan juga bagaimana skema ini terhubung dengan fitur penahanan dana di gateway tersebut, supaya agent tidak membangun logika pemotongan komisinya sendiri dari nol.

Penanganan dispute: siapa yang berhak memutuskan

Komplain pasti muncul cepat atau lambat: barang tidak sesuai, jasa tidak selesai sesuai janji, atau pembeli mengklaim belum menerima padahal penjual bilang sudah kirim. PRD marketplace yang baik menuliskan alur ini sebagai fitur tersendiri, bukan berharap tim support menyelesaikannya manual di luar sistem selamanya.

• Siapa yang bisa membuka dispute - biasanya pembeli, kadang juga penjual
• Apa yang terjadi ke dana selama dispute berlangsung - idealnya tertahan, tidak ditransfer ke penjual maupun dikembalikan ke pembeli sampai ada keputusan
• Siapa yang berhak memutuskan hasil akhirnya - biasanya admin, dengan akses melihat bukti dari kedua pihak

Tanpa bagian ini di PRD, agent biasanya cuma membangun tombol "Ajukan Komplain" yang mengirim pesan ke suatu tempat, tanpa status, tanpa alur keputusan, dan tanpa yang mengunci dana selama prosesnya berjalan.

Kasus tepi yang sering luput

Tiga skenario ini yang paling sering bikin marketplace buatan AI berantakan begitu dipakai pengguna sungguhan, karena jarang masuk ke PRD versi pertama.

• Penjual belum konfirmasi tapi pembeli sudah bayar - PRD harus menyatakan dana itu tertahan di platform dan ada batas waktu sebelum pesanan otomatis dibatalkan dan direfund
• Dua pembeli checkout hampir bersamaan untuk stok yang tersisa satu - PRD harus menyatakan siapa yang menang, biasanya yang berhasil membayar lebih dulu, bukan yang checkout lebih dulu, dan apa yang terjadi ke pembeli yang kalah
• Refund sebagian - PRD harus menyatakan apakah komisi yang sudah terpotong ikut dikembalikan atau tidak, dan pesanan itu berstatus apa setelah refund sebagian tadi

Ketiganya soal uang dan kepercayaan, dua hal yang paling mahal diperbaiki lewat "eh ternyata harusnya gini" setelah aplikasinya live. Menuliskannya di PRD sejak awal jauh lebih murah daripada menjelaskannya ke pengguna yang sudah kadung komplain.

Salah satu bentuk jadinya bisa kamu lihat di template Marketplace Jasa Rumah, PRD marketplace jasa on-demand yang sudah menuliskan peran, alur transaksi, dan skema komisinya secara konkret sejak awal.