Cara Membuat PRD Bot WhatsApp/Telegram & Automasi: Mengunci Hal yang Tidak Kelihatan

Bot pesanan WhatsApp milik Pak Hendra sudah dua minggu jalan mulus. Kamis sore, Bu Sari pesan dua kotak brownies lewat chat seperti biasa. Malamnya, rekap harian mencatat dua pesanan kembar atas nama Bu Sari, #A107 dan #A108, isi dan jamnya persis sama, dan dapur kadung memanggang empat kotak. Tidak ada yang salah ketik. Server WhatsApp memang sesekali mengirim webhook pesan yang sama dua kali, dan bot-nya mencatat keduanya sebagai pesanan baru karena tidak ada satu kalimat pun di PRD-nya yang menyuruh mengecek apakah pesan itu sudah pernah diproses.

Bot itu aplikasi tanpa layar. Tidak ada halaman yang bisa dibuka, tidak ada tombol yang bisa diklik, dan justru karena itu hampir semua kegagalannya terjadi tanpa ada yang menonton. Kalau konsep PRD-nya sendiri masih samar buatmu, mulai dari apa itu PRD dulu. Untuk bot, isi PRD-nya bergeser: bukan menggambar tampilan, tapi mengunci perilaku yang tidak terlihat, siapa yang boleh memerintah bot, kapan bot bergerak sendiri, dan bot harus berbuat apa waktu keadaan di sekitarnya rusak.

Bot tidak punya halaman login, dan itu bukan kekurangan

Kalau di PRD bot-mu ada bagian "halaman login" atau "registrasi user", itu tanda PRD-nya ditulis pakai cetakan aplikasi web, bentuknya salah dari awal. Bot tidak butuh login karena identitas pengirim sudah dibawa platformnya: tiap pesan WhatsApp datang bersama nomor pengirim, tiap pesan Telegram datang bersama chat id. Kontrol aksesnya bukan username dan password, tapi allowlist: daftar nomor atau chat id yang dikenal, plus peran masing-masing. Tulis eksplisit di PRD, misalnya nomor owner boleh semua perintah termasuk yang berbahaya, dua nomor kasir hanya boleh mencatat pesanan dan mengecek stok, dan nomor di luar daftar diperlakukan sebagai pelanggan biasa yang cuma bisa memesan.

Sebutkan juga jawaban bot untuk orang yang memanggil perintah di luar haknya: diam saja atau membalas sopan, dua-duanya sah, asal kamu yang memutuskan dan bukan agent yang menebak. Tanpa allowlist yang tertulis, perintah /laporan yang berisi omzet harianmu bisa dipanggil siapa pun yang kebetulan tahu nomor bot-nya.

"Endpoint" bot itu tiga pemicu, tulis ketiganya

Aplikasi web punya daftar halaman, dan daftar itu otomatis jadi peta fitur. Bot tidak punya halaman. Penggantinya adalah tiga pemicu, dan PRD bot yang lengkap menuliskan ketiganya satu per satu, bukan cuma yang pertama.

• Webhook pesan masuk: pelanggan atau anggota tim mengirim chat, bot memutuskan membalas apa. Ini satu-satunya pemicu yang hampir semua orang ingat waktu membayangkan bot.
• Perintah chat: pesan berformat khusus seperti /saldo, /laporan, /stop. Daftarkan semua perintahnya, formatnya, dan siapa saja yang boleh memakai tiap perintah.
• Jadwal alias cron: bot bergerak sendiri tanpa ada pesan masuk sama sekali, misalnya kirim rekap penjualan tiap jam 9 malam atau menagih cicilan tiap tanggal 1. Tulis jamnya, zona waktunya, dan penerimanya.

Kalau PRD-mu cuma bilang "bot yang membalas chat pelanggan", agent hanya akan membangun pemicu pertama. Perintah /stop yang tidak pernah ditulis artinya tidak ada rem darurat. Rekap malam yang cuma ada di kepalamu tidak akan pernah terkirim. Cara paling aman: perlakukan tiap pemicu sebagai fitur tersendiri yang dipecah jadi tugas terpisah, polanya sama dengan cara memecah fitur aplikasi jadi tugas untuk AI.

Anti-eksekusi ganda: kunci kecil bernama id pesan

Kembali ke empat kotak brownies Pak Hendra. Webhook itu kiriman lewat jaringan, dan jaringan bisa lambat. Waktu server WhatsApp atau Telegram tidak menerima jawaban dari bot-mu dalam beberapa detik, dia mengirim ulang pesan yang sama. Ini perilaku normal dan terdokumentasi, bukan bug, jadi bot-mulah yang wajib kebal. Tanpa perlindungan, kasus teringannya bot membalas dobel dan terlihat rusak di mata pelanggan. Kasus terberatnya, order dieksekusi dua kali, dan kalau bot-mu bot trading, itu dua posisi terbuka dengan uang sungguhan. Untungnya tiap pesan membawa id unik dari platformnya, dan satu aturan pendek di PRD sudah cukup menutup celah ini.

Aturan idempotensi (masukkan ke PRD, bagian aturan bisnis):

Setiap pesan masuk membawa message_id unik dari platform.
Sebelum pesan diproses:
1. Cek message_id di tabel processed_messages
2. Sudah ada?  -> berhenti. Jangan balas, jangan eksekusi apa pun
3. Belum ada?  -> simpan message_id dulu, baru proses

Wajib untuk SEMUA aksi yang mengubah data:
catat pesanan, kirim broadcast, eksekusi transaksi.

Bot mati diam-diam, dan tidak ada yang tahu

Aplikasi web yang mati langsung ketahuan: halamannya tidak bisa dibuka. Bot yang mati tidak menampilkan apa-apa. Chat pelanggan cuma tidak terbalas, dan pelanggan mengira dicuekin. Karena itu PRD bot wajib memuat tiga tugas yang sering dianggap "urusan teknis nanti" padahal menentukan hidup-matinya. Pertama, proses dijaga tetap hidup oleh process manager seperti PM2 atau systemd yang otomatis menyalakan ulang saat crash. Kedua, panggilan ke API pihak ketiga diberi retry dengan backoff: dicoba lagi dengan jeda yang membesar, misalnya 5 detik, 30 detik, lalu 2 menit, bukan menghajar terus tiap detik sampai kena blokir. Ketiga, notifikasi ke owner lewat kanal terpisah saat bot restart berulang atau error beruntun. Kanal terpisah itu penting: kalau kabar "bot mati" dikirim lewat bot yang sama yang sedang mati, kabar itu tidak akan pernah sampai.

Kalau bot menyentuh uang, tulis rem-nya satu per satu

Di aplikasi web, transaksi berisiko dilindungi halaman review dan tombol konfirmasi yang harus diklik sadar. Bot tidak punya semua itu. Perintah satu baris bisa langsung menggerakkan uang, jadi rem-nya harus dituliskan sebagai perilaku di PRD. Untuk bot trading, bot pembayaran, atau bot apa pun yang bisa memindahkan nilai, empat rem ini minimum, bukan opsional.

1. Mode uji dulu: paper trading atau sandbox pembayaran. Bot berjalan penuh dan mencatat semua keputusannya, tapi tidak menyentuh uang sungguhan. Pindah ke mode live hanya setelah kamu sendiri memeriksa hasil mode ujinya, dan PRD menyebut perpindahan ini sebagai langkah sadar, bukan default.
2. Kill switch: satu perintah, misalnya /stop dari nomor owner, yang menghentikan seluruh eksekusi detik itu juga tanpa syarat tambahan. Perintah untuk menyalakan lagi harus perintah berbeda, supaya tidak ada yang menghidupkan ulang tanpa sengaja.
3. Batas nominal: maksimum per transaksi dan maksimum akumulasi per hari. Begitu batas tersentuh, bot berhenti dan lapor ke owner, bukan diam-diam melanjutkan sisa antrean.
4. Konfirmasi untuk perintah berisiko: perintah seperti "jual semua" dijawab bot dengan ringkasan (aset apa, berapa banyak, perkiraan nilainya) dan baru dieksekusi setelah dibalas YA. Tidak dibalas dalam beberapa menit, perintahnya hangus.

Khusus WhatsApp: nomormu bisa kena banned

Ada satu risiko yang tidak dipunyai bot Telegram: bot WhatsApp yang jalan lewat nomor biasa bisa membuat nomornya diblokir permanen kalau pola kirimnya terbaca seperti spam oleh sistem WhatsApp. Sinyalnya klasik: ratusan pesan berangkat dalam hitungan menit, isinya identik semua, jedanya nol, dan sebagian besar penerimanya tidak pernah sekali pun chat duluan ke nomor itu. PRD bot WhatsApp wajib menulis pola kirim sebagai aturan, bukan menyerahkannya ke selera agent: jeda acak antar pesan (misalnya 20 sampai 60 detik, bukan tembakan beruntun), variasi isi lewat beberapa versi template yang dirotasi, dan larangan keras mengirim ke nomor yang belum pernah menghubungi duluan. Ini bukan fitur pemanis. Nomor yang kena banned berarti bot-nya tamat, beserta seluruh riwayat chat pelanggannya.

Semua yang dibahas di atas, allowlist, tiga pemicu, kunci id pesan, rem uang, pola kirim, paling kuat kalau dituliskan sebagai acceptance criteria yang bisa dicek per fitur, misalnya "kalau webhook mengirim message_id yang sama dua kali, pesanan yang tercatat tetap satu". Kalimat sependek itu yang membedakan bot yang sekadar jalan waktu demo dengan bot yang masih bisa dipercaya di minggu ketiga, waktu webhook dobel pertamanya datang.