Kenapa Saya Akhirnya Membangun Sistem Follow-Up WhatsApp Sendiri untuk UMKM

Ada satu pola yang saya lihat berulang kali di UMKM: chat WhatsApp menumpuk, admin lupa follow-up invoice yang jatuh tempo, dan leads yang tadinya antusias jadi dingin karena tidak ada yang balas dalam dua hari. Bukan karena timnya malas. Mereka cuma kewalahan menjawab pertanyaan yang sama berulang kali sambil mengejar pekerjaan lain.

Jadi saya coba bikin sistemnya sendiri. Bukan chatbot generik yang jawab template kaku, tapi sesuatu yang benar-benar bisa jawab pertanyaan dari data produk asli, dan tetap ingat siapa yang harus di-follow-up dan kapan.

Kenapa Bukan Cuma “Pasang WA Bot” Saja

Godaan pertama biasanya langsung cari WhatsApp gateway murah, colok autoreply, selesai. Masalahnya, autoreply kaku itu cepat kelihatan bodoh begitu customer nanya sesuatu yang sedikit di luar skrip. Dan untuk follow-up invoice atau leads yang belum closing, autoreply statis nggak cukup — butuh sesuatu yang tahu status tiap orang, kapan terakhir dia dihubungi, dan berapa kali sudah di-follow-up supaya nggak spam.

Jadi arsitekturnya saya pecah jadi tiga lapis yang masing-masing punya tugas jelas:

Layer pengiriman pesan — pakai tech provider resmi (bukan WhatsApp Web yang di-automate, itu jalan cepat menuju nomor kena banned). Ini cuma urusan kirim-terima pesan ke WhatsApp, titik.

Layer logika bisnis — di sinilah n8n masuk. Cek database, tentukan siapa yang perlu direminder, panggil mesin RAG kalau ada pertanyaan produk. WA gateway-nya sendiri nggak tahu apa-apa soal bisnis saya; dia cuma kurir.

Layer pengetahuan — knowledge base yang bisa dicari (RAG), supaya jawaban soal produk/FAQ diambil dari data asli, bukan dikarang model.

Saya sempat mikir apa perlu tiga lapis ini repot-repot dipisah. Ternyata perlu, begitu saya coba bayangkan satu UMKM yang jualan hosting, umroh, DAN produk digital dari satu nomor CS yang sama. Kalau semuanya digabung jadi satu blob pengetahuan, RAG-nya gampang salah jawab — pertanyaan soal cicilan umroh kejawab pakai info hosting. Jadi tiap lini bisnis dapat folder pengetahuan sendiri, dan ada langkah kecil di awal percakapan yang nanya “mau tanya soal apa” sebelum masuk ke jawaban otomatis.

Menutup Celah Keamanan Lama: Update jQuery 3.2.1 ke 3.4.0

Salah satu hal yang sering luput dari perhatian ketika sebuah project sudah lama tidak disentuh adalah dependency pihak ketiga yang diam-diam menua — dan seiring waktu, menjadi pintu masuk bagi celah keamanan yang sudah diketahui publik. Itulah yang saya temukan minggu ini, melalui kiriman email GitHub security alert digest, di salah satu repository GitHub saya, Dockerproject.

Temuan Awal

GitHub Dependabot menandai repository ini dengan status “known security vulnerabilities detected”. Setelah ditelusuri lebih dalam melalui GitHub Security Advisory dan Dependency Graph, sumbernya adalah file:

pesbuk/web/js/jquery-3.2.1.slim.min.js

File ini adalah bundel jQuery versi 3.2.1 yang di-vendor langsung ke dalam project (tidak dikelola lewat package manager seperti npm), sehingga tidak pernah ter-update secara otomatis.

Detail Vulnerability

ItemDetail
CVECVE-2019-11358
AdvisoryGHSA-6c3j-c64m-qhgq
JenisCross-Site Scripting (XSS) via Prototype Pollution
SeverityMedium (CVSS 6.1)
Versi terdampakjQuery >= 1.1.4 dan < 3.4.0
Versi perbaikanjQuery 3.4.0

Inti masalahnya ada pada fungsi jQuery.extend(true, {}, ...). Jika sebuah objek sumber yang tidak disanitasi memiliki properti __proto__ yang enumerable, fungsi ini bisa “mencemari” Object.prototype bawaan JavaScript. Dalam skenario tertentu, ini bisa dimanfaatkan penyerang untuk menyisipkan skrip berbahaya ke halaman (XSS) — sebuah teknik yang dikenal sebagai prototype pollution.