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:

Lapis 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.

Lapis 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.

Lapis 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.

Soal Biaya — Ini yang Paling Sering Ditanya

Jujur, ini yang bikin saya awalnya ragu. Tapi setelah dihitung detail, angkanya masuk akal untuk skala UMKM:

  • Hosting VPS kecil: di bawah Rp500 ribu/bulan
  • Platform WhatsApp resmi: mulai Rp150 ribu/bulan per nomor, tanpa markup per pesan
  • API untuk jawab pertanyaan (pakai model yang murah, bukan yang paling canggih): biasanya di bawah Rp300 ribu/bulan untuk volume ribuan chat

Totalnya bisa ditekan di bawah sejuta rupiah per bulan untuk UMKM dengan ribuan kontak. Yang justru lebih mahal biasanya bukan komponen teknisnya, tapi kalau salah pilih — misalnya nekat self-host model AI sendiri butuh GPU yang sewanya bisa berkali-kali lipat dari budget total sistem ini.

Yang Saya Masih Ragu-Ragu

Saya nggak mau pura-pura semua ini sempurna. Beberapa hal yang masih saya pikirkan:

Pakai tech provider pihak ketiga untuk WhatsApp berarti ada dependency tambahan — kalau layanan mereka bermasalah, sistem saya ikut kena. Trade-off-nya: setup jadi jauh lebih cepat dibanding urus semuanya langsung ke Meta sendirian. Untuk UMKM yang timnya kecil, saya rasa ini trade-off yang masuk akal, tapi saya tetap simpan opsi migrasi kalau suatu saat perlu.

Follow-up otomatis juga saya batasi keras — maksimal dua kali per leads yang nggak respon, lalu berhenti. Saya pernah lihat sistem lain yang follow-up terus-terusan sampai orang block nomornya. Itu bukan otomasi, itu spam yang kebetulan pakai AI.

Dan untuk lini bisnis yang lebih sensitif — misalnya urusan haji/umroh yang menyangkut dokumen dan uang dalam jumlah besar — saya sengaja bikin ambang batasnya lebih rendah untuk alihkan ke admin manusia. RAG bagus untuk jawab FAQ soal fasilitas hotel, tapi untuk urusan pembayaran besar dan dokumen jamaah, saya lebih percaya manusia yang pegang.

Apa yang Saya Pelajari

Yang paling saya sadari dari proses ini: bagian tersulit bukan di kode atau arsitektur, tapi di menentukan kapan sistem harus diam dan menyerahkan ke manusia. Terlalu banyak otomasi bikin customer merasa ngobrol sama tembok. Terlalu sedikit, ya kembali ke masalah awal — admin kewalahan.

Kalau Anda sedang mempertimbangkan hal serupa untuk bisnis sendiri, saran saya: mulai dari satu alur paling sederhana dulu (misal cuma jawab FAQ), baru tambah reminder dan follow-up leads setelah yang dasar jalan stabil. Saya sempat tergoda bangun semuanya sekaligus di awal, dan itu bikin debugging jauh lebih ribet daripada perlu.

Modernisasi Legacy PHP Autoresponder Menjadi Lightweight Self-Hosted Email Automation Platform

Pendahuluan

Banyak aplikasi web yang masih digunakan hingga saat ini dibangun menggunakan pendekatan yang lazim pada masanya: struktur file sederhana, koneksi database langsung dari script PHP, penggunaan fungsi mysql_*, konfigurasi hardcoded, serta proses pengiriman email menggunakan fungsi bawaan mail().

Pendekatan tersebut tidak selalu salah jika dilihat dari konteks sejarahnya. Justru banyak aplikasi legacy yang berhasil bertahan karena desainnya sederhana, mudah dipahami, dan memiliki business logic yang jelas.

Salah satu contoh yang sedang saya kembangkan kembali adalah sebuah aplikasi PHP Autoresponder sederhana yang memiliki fungsi utama untuk menyimpan leads, mengirim welcome email, menjalankan drip email berdasarkan jumlah hari sejak user melakukan subscription, serta menyediakan mekanisme unsubscribe.

Project ini awalnya dibangun sebagai aplikasi PHP monolitik sederhana. Sekarang saya berencana memodernisasinya menjadi sebuah:

Lightweight, self-hosted email automation platform yang modern, aman, mudah di-deploy, dan dapat diintegrasikan dengan berbagai platform automation tanpa vendor lock-in.

Modernisasi ini tidak dilakukan dengan membuang seluruh aplikasi lama dan menulis ulang semuanya dari nol. Fokus utamanya adalah mempertahankan business logic yang masih relevan, lalu melakukan refactoring secara bertahap.

Mengenal tmux: Senjata Wajib Administrator Sistem di Era Cloud

Kalau Anda pernah kehilangan proses penting karena koneksi SSH tiba-tiba putus di tengah deployment, Anda pasti paham betapa menyebalkannya itu. Setelah lebih dari dua dekade bergelut dengan server fisik, VM, dan berbagai platform cloud — dari VMware vSphere on-premise sampai instance di AWS, Alibaba Cloud, dan Huawei Cloud — salah satu tool sederhana yang tidak pernah saya tinggalkan adalah tmux.

Artikel ini membahas apa itu tmux, cara instalasinya, shortcut yang paling sering dipakai, serta bagaimana tool ini benar-benar membantu pekerjaan sehari-hari sebagai administrator sistem maupun cloud engineer.

Apa Itu tmux?

tmux (terminal multiplexer) adalah aplikasi yang memungkinkan satu koneksi terminal menjalankan banyak sesi shell sekaligus, masing-masing berjalan independen. Setiap sesi bisa dipecah lagi menjadi beberapa window dan pane, sehingga satu layar terminal bisa menampung banyak “ruang kerja” terisolasi tanpa saling mengganggu.

Keunggulan utamanya dibanding terminal biasa: proses yang berjalan di dalam sesi tmux tetap hidup meskipun koneksi SSH terputus. Ini krusial ketika mengelola server remote atau VPS — pekerjaan seperti restore database besar, kompilasi, atau monitoring log tidak akan berhenti hanya karena laptop Anda kehilangan koneksi WiFi di tengah jalan.

Instalasi tmux

Di server berbasis Debian/Ubuntu, instalasi cukup dengan dua baris perintah:

sudo apt update
sudo apt install tmux

Untuk distro berbasis RHEL/CentOS, ganti apt dengan yum atau dnf sesuai versinya. Setelah proses selesai, verifikasi instalasi dengan mengecek versinya:

tmux -V

Jika muncul nomor versi, instalasi berhasil. Praktik baik: jangan menjalankan tmux sebagai root pada server produksi — gunakan user biasa dengan su username atau sudo -u username terlebih dahulu, sesuai standar keamanan yang biasa saya terapkan di lingkungan enterprise.

Konsep Dasar: Sesi, Window, dan Pane

Ada tiga tingkatan struktur di tmux:

  • Sesi (session) — wadah paling luar, biasanya satu sesi untuk satu konteks pekerjaan (misalnya satu sesi untuk maintenance database, satu lagi untuk monitoring log).
  • Window — mirip tab di browser, satu sesi bisa berisi banyak window.
  • Pane — pembagian layar di dalam satu window, bisa horizontal atau vertikal.

Semua interaksi dengan tmux memakai kombinasi tombol prefix, yang secara default adalah Ctrl-b. Artinya, hampir semua shortcut diawali dengan menekan Ctrl-b, lepas, baru menekan tombol berikutnya.

Shortcut yang Paling Sering Dipakai

Berikut kombinasi yang paling sering saya gunakan di lapangan:

ShortcutFungsi
Ctrl-b dDetach dari sesi aktif (proses tetap berjalan di background)
Ctrl-b cMembuat window baru
Ctrl-b n / Ctrl-b pPindah ke window berikutnya / sebelumnya
Ctrl-b %Split pane secara vertikal
Ctrl-b "Split pane secara horizontal
Ctrl-b + panahBerpindah antar-pane
Ctrl-b xMenutup pane aktif (dengan konfirmasi)
Ctrl-b ,Mengganti nama window
Ctrl-b wMenampilkan daftar semua window dalam sesi
Ctrl-b ?Menampilkan seluruh daftar shortcut

Alur Kerja Praktis

Memulai sesi baru dengan nama. Alih-alih membiarkan tmux memberi nomor ID default, biasakan memberi nama sesi yang jelas — misalnya per proyek atau per klien:

tmux new-session -s deploy-amt-dw

Ini sangat membantu ketika Anda mengelola banyak sesi sekaligus untuk klien atau proyek berbeda, sesuatu yang lumrah terjadi kalau sehari-hari menangani beberapa environment cloud sekaligus.

Detach dan attach kembali. Setelah pekerjaan berjalan, tekan Ctrl-b d untuk keluar tanpa menghentikan proses. Untuk kembali:

tmux attach-session -t deploy-amt-dw

Melihat semua sesi aktif:

tmux ls

Mengakhiri sesi tertentu:

tmux kill-session -t deploy-amt-dw

Kustomisasi lewat tmux.conf

Konfigurasi tmux bisa disesuaikan lewat file ~/.tmux.conf (per user) atau /etc/tmux.conf (global). Dua kustomisasi yang paling umum dilakukan administrator berpengalaman:

Mengubah prefix default dari Ctrl-b menjadi Ctrl-a (lebih mudah dijangkau, mengikuti gaya GNU Screen):

unbind C-b
set-option -g prefix C-a
bind-key C-a send-prefix

Mengubah penomoran window dan pane agar dimulai dari 1, bukan 0 — supaya lebih intuitif saat menekan shortcut angka:

set -g base-index 1
setw -g pane-base-index 1

Mengapa tmux Penting untuk Pekerjaan Cloud dan Presales Teknis

Dalam konteks pekerjaan yang berhubungan dengan ECS, VPS, atau instance compute di berbagai penyedia cloud, tmux punya beberapa manfaat konkret:

  1. Proses long-running tetap aman. Deploy aplikasi, instalasi dependency besar, atau backup data tidak akan terputus hanya karena koneksi SSH putus.
  2. Multitasking dalam satu koneksi. Anda bisa memonitor log aplikasi di satu pane, menjalankan command di pane lain, tanpa membuka banyak sesi SSH terpisah — menghemat resource, penting terutama di VPS dengan spesifikasi terbatas.
  3. Kolaborasi tim. Sesi tmux bisa di-share antar-user yang login ke server yang sama, memudahkan pair troubleshooting saat insiden produksi.
  4. Konsistensi lintas platform cloud. Baik Anda mengelola instance di Huawei Cloud ECS, Alibaba Cloud ECS, atau EC2 di AWS, cara kerja tmux sama persis — tidak tergantung penyedia cloud tertentu.

Penutup

tmux adalah salah satu tool yang dampaknya sering diremehkan sampai Anda benar-benar mengandalkannya saat koneksi tidak stabil atau harus menjalankan proses berjam-jam di server remote. Investasi waktu belajar shortcut dasarnya — detach, split pane, rename window — akan langsung terasa manfaatnya di pekerjaan sehari-hari, baik sebagai system administrator, cloud engineer, maupun presales yang sering demo langsung dari terminal.

Referensi: Tutorial tmux — Hostinger