Prototipe jalan — satu platform, banyak toko

Katalog tim, lengkap sampai nama punggung.

Isi ukuran, nama punggung, dan nomor per pemain. Bayar transfer lewat sistem, atau konfirmasi di WhatsApp — pesanannya tetap tercatat.

Nomor penjual

Cetak biru pengembangan

Satu platform, banyak toko, satu catatan pesanan.

Rencana ini menyesuaikan yang kamu tetapkan: produk jadi dengan kustom nama & nomor, dimulai dari Projee dan Lumove, dan checkout empat pintu — QRIS, virtual account, transfer manual, atau konfirmasi lewat WhatsApp.

Soal WhatsApp: alasanmu benar, tapi separuh

Betul bahwa orang tidak percaya situs asing. Tapi yang menyembuhkan itu bukan WhatsApp-nya — yang menyembuhkan adalah adanya manusia yang bisa dimintai tanggung jawab. WhatsApp cuma bukti termurah bahwa manusia itu ada. Artinya kamu bisa mendapatkan kepercayaan yang sama tanpa memaksa semua orang lewat chat, asal empat hal ini kelihatan di halaman:

Nama rekening = nama toko. Ini sinyal terkuat di transfer manual. Rekening pribadi bernama lain langsung menaikkan kecurigaan.
Identitas nyata: kota, tahun berdiri, jumlah pesanan selesai, nomor yang bisa dihubungi — sudah saya pasang di prototipe sebagai baris kecil di bawah judul.
Kejelasan sebelum bayar: ongkir, kebijakan tukar ukuran, estimasi produksi. Ketidakjelasan dibaca sebagai risiko.
Nomor nota + halaman status. Pembeli yang bisa mengecek pesanannya sendiri tidak perlu percaya — dia bisa memverifikasi.

Jadi jangan buang WhatsApp, tapi turunkan perannya dari satu-satunya jalan menjadi jalan untuk yang butuh ngobrol dulu. Di prototipe, dua-duanya sekarang menghasilkan satu hal yang sama: baris pesanan bernomor. Itu perubahan terpentingnya — tombol WhatsApp tidak lagi melewati pencatatan.

Pembeli yang ragu butuh bukti, bukan chat. Chat cuma cara tercepat menyediakan bukti kalau bukti lain belum ada. Ini juga alasan kenapa toko yang sudah punya reputasi bisa pindah ke checkout sistem tanpa kehilangan closing

“Otomatis bakal mahal?” — tidak, dan ini angkanya

Verifikasi otomatis jauh lebih murah dari yang biasanya dibayangkan. Yang mahal bukan biayanya, tapi urusan lain yang saya bahas di bagian berikutnya. Kisaran tarif penyedia pembayaran di Indonesia untuk satu transaksi Rp 450.000 — cek angka terbaru di masing-masing penyedia sebelum dipakai berhitung serius:

Cara	Biaya per transaksi	Beban di Rp 450 rb
Transfer manual + cek mutasi sendiri	Gratis, tapi makan waktu admin	Rp 0
Baca mutasi otomatis (layanan macam Moota)	Langganan bulanan flat	± Rp 0
QRIS lewat agregator	Sekitar 0,7% dari nilai	± Rp 3.150
Virtual account bank	Flat per transaksi	± Rp 4.500
E-wallet (OVO/DANA/ShopeePay)	Sekitar 1,5–2%	± Rp 7.900

Bandingkan dengan ongkosnya kalau manual: admin mengecek mutasi, mencocokkan nominal, membalas chat. Tiga menit per order, 30 order sehari, itu 1,5 jam kerja hilang setiap hari — jauh lebih mahal dari Rp 3.150.

Karena kamu memilih langsung memakai QRIS dan virtual account, itu keputusan yang masuk akal di angka segini — dan prototipe sudah menyediakan keduanya. Tetap pertahankan transfer manual sebagai pilihan ketiga: sebagian pembeli lebih percaya mengirim ke rekening bernama toko, dan pilihan itu gratis biaya layanan buatmu. Kode unik tiga digit pada transfer manual tetap dipakai (Rp 520.000 jadi Rp 520.137) supaya pencocokannya bisa diotomatiskan lewat pembaca mutasi rekening tanpa biaya per transaksi.

Satu hal yang jarang disebut: gateway mencairkan dana T+1 sampai T+2, sementara transfer langsung masuk detik itu juga. Untuk toko kecil yang belanja bahan harian, jeda itu terasa. Itu alasan sah untuk menahan gateway, bukan biayanya.

Pakai NIB PT Bosublim, atau NIB perorangan?

Secara teknis, NIB PT Bosublim Pabrik Amanah bisa dipakai mendaftarkan merchant, dengan Projee dan Lumove sebagai nama dagang. Tapi yang berpindah bukan cuma berkasnya — yang berpindah adalah siapa pemilik penghasilannya.

Rekening pencairan harus atas nama PT. Rencana rekening terpisah per brand otomatis gugur.
Seluruh omzet Projee dan Lumove menjadi omzet PT: masuk pembukuan PT, mengikuti tarif pajak badan, dan kena PPN kalau PT sudah dikukuhkan sebagai pengusaha kena pajak.
Menarik uang itu ke kantong pribadi tidak bisa sekadar transfer — harus lewat jalur yang sah seperti gaji atau dividen, dengan konsekuensi pajaknya sendiri.
KBLI pada NIB PT harus mencakup perdagangan eceran daring. Kalau isinya baru manufaktur pakaian, tambahkan dulu lewat OSS.

Yang paling merusak, dan ini khas sistemmu perhatikan

Seluruh ERP-mu dibangun di atas satu asumsi: Projee dan Lumove adalah customer Bosublim. Mereka punya record customer sendiri, invoice sendiri, bahkan mekanisme deposit jaminan khusus untuk brand tingkat enterprise. Kalau kedua brand itu ditarik masuk ke dalam PT yang sama dengan pabriknya, penjualan pabrik kepada mereka bukan penjualan lagi — itu perpindahan barang di dalam satu badan usaha.

Akibatnya: piutang dan invoice yang sekarang tercatat jadi janggal secara akuntansi, margin pabrik jadi semu karena menagih diri sendiri, dan laporan laba per brand kehilangan artinya.

Tindakan: ambil NIB perorangan atas namamu, dan biarkan Projee serta Lumove tetap di luar PT. Gratis, cepat, dan yang lebih penting — batas antara pabrik dan brand yang sudah kamu bangun di ERP tetap benar.

Sisi baiknya memakai PT tetap ada: pengajuan virtual account lebih mudah disetujui, dan administrasinya satu pintu. Tapi jangan mengubah struktur badan usaha hanya demi satu kanal pembayaran. Kalau VA ditolak karena berstatus perorangan, jalan dengan QRIS dulu — itu sudah menutup sebagian besar kebutuhan, dan VA bisa menyusul kalau memang volumenya menuntut.

Konsekuensi pajak dan pembukuan di atas adalah gambaran umum, bukan nasihat pajak. Sebelum memutuskan, konfirmasikan ke konsultan pajakmu — terutama soal status PKP PT dan cara menarik penghasilan brand ke pribadi.

Yang perlu disiapkan sebelum QRIS & VA menyala

Pendaftaran ke penyedia pembayaran jarang gagal karena teknis — hampir selalu karena berkas atau halaman kebijakan yang belum ada. Siapkan empat kelompok ini.

1. Berkas & entitas — untuk struktur perorangan

Projee dan Lumove sama-sama usaha perorangan atas namamu sendiri, dengan rekening masing-masing. Itu menyederhanakan banyak hal.

Berkas dasar yang hampir selalu diminta: KTP, NPWP, rekening atas namamu sendiri, plus keterangan singkat jenis usaha dan tautan situs atau akun jualan.
Soal NIB: jangan dihindari, ambil saja. Untuk usaha perorangan skala mikro, NIB diurus sendiri lewat OSS secara daring dan gratis, biasanya selesai dalam hitungan menit begitu NIK dan NPWP siap. Karena melekat pada dirimu sebagai pelaku usaha, satu NIB cukup untuk dua brand — tidak perlu satu-satu.
QRIS untuk merchant perorangan umumnya bisa tanpa badan usaha. Virtual account lebih sering mensyaratkan badan usaha — tanyakan ini di awal, dan kalau ditolak, nyalakan QRIS dulu sambil VA menyusul.
Syarat tiap penyedia berbeda dan berubah dari waktu ke waktu. Tanyakan daftar berkas terbaru langsung ke calon penyedia sebelum mengumpulkan apa pun, jangan berpatokan pada daftar ini.

Dua rekening, satu pemilik — ada tiga cara:

Satu akun merchant, satu rekening pencairan (paling cepat): semua masuk ke satu rekening, pemisahan brand lewat awalan nota PRJ- dan LMV- serta laporan per brand. Karena kedua brand milikmu sendiri, tidak ada soal hukum di sini — larangan menampung dana pihak lain hanya berlaku kalau uang itu milik toko orang lain.
Dua akun merchant terpisah, masing-masing dengan rekeningnya sendiri. Berkasnya sama persis, cuma diulang dua kali, dan ada dua jadwal pencairan yang harus dipantau.
Sebagian penyedia mengizinkan beberapa unit usaha dalam satu akun dengan rekening pencairan berbeda. Tanyakan; kalau ada, ini yang paling rapi.

Saran saya: mulai dari cara pertama. Satu proses verifikasi, satu rekonsiliasi, dan pemisahan brand tetap terbaca rapi di laporan. Pecah jadi dua akun nanti saja kalau salah satu brand naik jadi badan usaha sendiri, atau kalau ada orang lain yang ikut memilikinya.

2. Halaman yang harus ada di situs

Ini yang dibuka petugas verifikasi saat meninjau pengajuanmu, dan penyebab penolakan paling sering. Semuanya halaman biasa, bukan aplikasi — drafnya sudah tersedia di repo (shop-site/), tinggal isi bagian yang ditandai.

Kebijakan privasi.
Syarat & ketentuan.
Kebijakan pengembalian, penukaran, dan pembatalan — termasuk aturan untuk barang yang sudah dicetak nama dan nomornya, karena itu tidak bisa dijual ulang.
Halaman kontak: alamat fisik, nomor telepon, email.
Harga, ongkir, cara pesan, dan estimasi pengiriman yang terbaca jelas.
Domain sendiri dengan HTTPS, bukan subdomain gratisan. Sertifikatnya sudah otomatis dari layanan hosting yang kamu pakai, jadi yang perlu dibeli benar-benar cuma nama domainnya.

3. Teknis — dan ini perubahan arsitektur terbesarnya

Yang dibutuhkan bukan aplikasi baru, bukan pula server sewaan — hanya dua fungsi kecil di infrastruktur yang sudah kamu punya. Repo ERP kamu sudah memakai Netlify Functions untuk notifikasi, jadi polanya sudah ada. Yang berubah cuma satu prinsip: aplikasi kamu selama ini berjalan penuh di browser, dan pembayaran otomatis tidak bisa begitu.

Kunci rahasia penyedia tidak boleh ada di index.html. Siapa pun bisa membukanya lewat view-source. Ia harus tinggal di Netlify Function atau Supabase Edge Function.
Dua endpoint: satu untuk membuat tagihan, satu untuk menerima notifikasi (webhook) dari penyedia.
Webhook wajib memverifikasi tanda tangan dan tahan kiriman ganda — notifikasi yang sama bisa datang berkali-kali. Jangan pernah percaya status “sudah bayar” yang dikirim dari browser.
Simpan di pesanan: id pembayaran, kanal, nominal, status, waktu kedaluwarsa, dan payload mentahnya untuk penelusuran.
Masa berlaku QRIS/VA (mis. 15–60 menit) plus tugas berkala yang menutup tagihan yang lewat waktu.
Uji di sandbox untuk semua jalur: berhasil, gagal, kedaluwarsa, nominal tidak sama, dan webhook dobel.
Rekonsiliasi harian: laporan pencairan dari penyedia dibandingkan dengan pesanan berstatus lunas.

4. Keputusan kebijakan yang harus kamu ambil

QRIS: biaya layanannya tidak boleh dibebankan ke pembeli — itu ketentuan Bank Indonesia. Masukkan ke dalam harga jual, jangan ditambahkan saat checkout.
Virtual account: biaya admin lazim dibebankan ke pembeli dan sudah ditampilkan terpisah di prototipe. Pastikan ketentuan penyedianya mengizinkan.
Pencairan T+1 sampai T+2. Uang QRIS hari ini baru bisa dipakai belanja bahan besok atau lusa — siapkan modal kerja untuk jeda itu, terutama kalau produksi jalan begitu pesanan masuk.
Refund ditanggung toko — keputusanmu, dan sudah tertulis di halaman pengembalian: pembeli menerima kembali persis sejumlah yang ia bayarkan. Konsekuensinya: pada banyak penyedia, biaya layanan yang sudah terpotong tidak ikut kembali saat refund, jadi satu pembatalan Rp 450 rb berarti kehilangan biaya layanannya plus ongkir yang sudah jalan. Kecil per kejadian, tapi pantau angkanya — kalau pembatalan mulai sering, penyebabnya biasanya foto produk atau tabel ukuran yang kurang jelas, bukan kebijakan refundnya.

Mekanisme sistemnya — dan kabar baiknya

Pertanyaannya “dibuat sendiri atau diintegrasikan ke ERP?” ternyata tidak perlu dijawab, karena mekanisme yang kamu bayangkan sudah berjalan di portal Bosublim. Projee dan Lumove sudah terdaftar sebagai tenant, cockpit-nya sudah ada, dan alur pesanan publik sudah tersambung ke produksi.

Pesanan dari pengunjung anonim berhenti di kotak kedua sampai brand mengonfirmasinya. Batas itu yang membuat orang iseng tidak bisa menjalankan mesin produksi pabrik — dan batas itu sudah terpasang di sistemmu sekarang.

Yang sudah ada, persis seperti yang kamu gambarkan

Kamu sebagai admin menambahkan brand. Di ERP, brand dibuat sebagai tenant dan ditautkan ke record customer Bosublim miliknya, lalu aksesnya dinaikkan ke tingkat enterprise. Projee dan Lumove sudah dalam keadaan itu.
Brand punya login sendiri. Masuk ke portal pakai nomor WhatsApp dan kata sandi mereka sendiri; sistem otomatis hanya menampilkan data brand miliknya, karena pembatasan barisnya dipasang di tingkat basis data, bukan di tampilan.
Brand menambah produknya sendiri di cockpit — nama, harga jual, ukuran, grup pilihan seperti kerah dan lengan, plus resep produksinya.
Pesanan publik sudah jalan. Ada form order terbuka per brand yang bisa dipesan tanpa login, dan halaman lacak tanpa login yang menampilkan progres produksi tanpa menyebut Bosublim sebagai pabriknya.
Konfirmasi brand sudah jadi syarat. Pesanan anonim masuk berstatus masuk dan baru menembak SO produksi setelah brand menyetujuinya di cockpit.

Yang belum ada — ini daftar kerja sebenarnya

Profil toko di cockpit. Sekarang tenant baru menyimpan nama, slug, nomor WhatsApp, dan logo. Untuk jadi toko sungguhan perlu ditambah: rekening pencairan, alamat dan jam operasional, tarif ongkir per zona, tautan kebijakan, serta pengaturan pembayaran. Inilah “informasi wajib” yang kamu maksud — satu formulir profil di cockpit, dan toko tidak bisa dipublikasikan sebelum semuanya terisi.
Kolom pembayaran di pesanan — metode, status bayar, id pembayaran, nomor VA atau kode unik, bukti transfer.
Roster nama & nomor di dalam item pesanan. Item sekarang hanya menyimpan produk, ukuran, jumlah, harga.
Stok per ukuran di produk brand — sumber tunggal yang menentukan jalur dan estimasi, bukan penanda manual.
Alamat terstruktur dan ongkir — sekarang alamat masih satu kolom teks bebas.
Wajah toko yang baru menggantikan form order lama, memakai fungsi katalog dan kirim-pesanan yang sudah ada, bukan tabel baru.

Godaan yang harus kamu tolak penting

Karena toko baru ini lebih enak dilihat, akan terasa masuk akal memberinya tabel pesanan sendiri supaya cepat jadi. Jangan. Begitu ada dua tempat penyimpanan pesanan, laporan penjualan brand tidak akan pernah cocok lagi dengan produksi, dan tidak ada yang bisa menjelaskan angka mana yang benar.

Tindakan: toko baru ini hanya boleh jadi tampilan. Semua penyimpanan tetap lewat fungsi yang sudah ada, dan kolom yang kurang ditambahkan ke tabel yang sudah ada — bukan ke tabel baru.

Urutan mengerjakannya

Empat langkah, berurutan, masing-masing bisa dipakai sebelum langkah berikutnya selesai:

Satu. Tambah kolom profil toko di tenant, dan formulir pengisiannya di cockpit. Projee dan Lumove mengisi sendiri — kamu tidak perlu jadi juru ketik.
Dua. Tambah stok per ukuran dan roster nama/nomor. Toko baru dipasang menggantikan form order lama, memakai katalog dari basis data, bukan hardcode.
Tiga. Tambah kolom pembayaran, lalu sambungkan QRIS dan virtual account lewat dua fungsi kecil tadi.
Empat. Baru sesudah semuanya stabil untuk dua brand sendiri, pikirkan pendaftaran toko luar — dan pada titik itu, yang perlu dibangun tinggal alur pendaftaran, karena mesinnya sudah terbukti.

Sudah terpasang di Supabase

Langkah satu dan sebagian langkah dua sudah jadi satu migrasi: diuji lebih dulu di Postgres lokal, lalu diterapkan ke proyek Supabase dan diperiksa langsung ke skema aslinya — 12 kolom baru di tenant, 2 di produk, 16 di pesanan, 6 fungsi. Kedua toko sengaja masih ditandai belum publik, jadi belum ada katalog yang tersaji.

Profil toko di tenant: rekening, alamat, jam operasional, awalan virtual account, zona ongkir, tabel lead time, dan penanda publik — toko baru tidak tampil sebelum profilnya diisi.
Stok per ukuran di produk brand, plus penanda produk bercetak nama/nomor.
Katalog toko untuk pengunjung tanpa login, membawa stok per ukuran.
Penerimaan pesanan yang menghitung sendiri harga, ongkir, jalur pemenuhan, estimasi, dan tanggal jatuh tempo dalam hari kerja — isian harga dari browser tidak pernah dipercaya.
Penandaan lunas khusus webhook: idempoten (webhook dobel tidak mengurangi stok dua kali) dan stok baru berkurang di sini, bukan saat pesanan masuk.
Batas pengaman: 5 pesanan toko per menit per brand, dan pesanan di atas 500 pcs ditolak dengan pesan untuk menghubungi langsung.

Sisa yang manual: isi profil tiap toko (rekening, alamat, awalan virtual account), isi stok per produk, baru tandai publik. Yang belum dikerjakan: formulir profil toko di cockpit, penggantian tampilan toko lama, dan dua fungsi pembayaran yang memegang kunci rahasia penyedia.

Ready, kustom, atau pre-order — tiga jalur, bukan dua

Betul, akan ada barang ready dan ada pre-order. Tapi pembagian yang benar bukan dua, melainkan tiga — dan yang membedakan bukan cepat atau lambatnya, melainkan apakah baris pesanan itu memakan kapasitas pabrik.

Yang membedakan ketiganya bukan cepat atau lambat, melainkan apakah baris pesanan itu memakan kapasitas pabrik. Jalur pertama tidak — tapi stoknya harus diisi lebih dulu lewat pesanan produksi terpisah yang modalnya keluar dari kantong brand.

Jersey yang dijual di sini masuk jalur kedua: barangnya sudah jadi, yang dikerjakan cuma cetak nama dan nomornya. Itu bukan produksi dari nol, dan tidak boleh diperlakukan sebagai SO jahit — kalau disamakan, papan produksimu akan penuh oleh pekerjaan yang sebenarnya hanya butuh beberapa jam di bagian finishing, dan estimasi ke pembeli jadi kelewat lama tanpa alasan.

“Pre-order langsung masuk order ke Bosublim?” — hampir, tapi jangan langsung

Urutan yang benar ada tiga pintu, dan pintu tengah itu yang menyelamatkanmu:

Satu: dibayar. Sebelum uang masuk, pesanan tidak boleh menyalakan apa pun. Ini gunanya QRIS dan virtual account — statusnya berubah sendiri tanpa menunggu admin.
Dua: dikonfirmasi brand. Brand mengecek slot produksi, ketersediaan bahan, dan desain nama/nomornya. Sistemmu sudah mensyaratkan ini sekarang, dan pertahankan.
Tiga: baru jadi SO produksi. Sesudah itu pesanan masuk papan pabrik seperti order lain.

Otomatiskan sebagian, jangan seluruhnya. Untuk jalur pertama dan kedua — barang ready, stok cukup, sudah lunas — konfirmasi boleh berjalan sendiri; tidak ada keputusan yang perlu diambil manusia di situ. Untuk pre-order, biarkan tetap manual: yang diputuskan di sana bukan “uangnya sudah masuk atau belum”, tapi “kapasitas minggu ini cukup atau tidak”, dan itu tidak bisa dijawab basis data.

Stok itu tidak muncul sendiri — ada jalur keempat yang sering terlupa modal kerja

Barang ready ada di rak karena sebelumnya brand memesan produksi satu batch ke pabrik. Itu SO produksi tersendiri, bukan hasil pesanan pelanggan, dan uangnya keluar dari kantong brand duluan — berbulan-bulan sebelum barangnya laku. Beda arah dengan pre-order, yang modalnya justru datang dari pembeli.

Tindakan: mulai dari jalur kedua dan ketiga, di mana modal datang dari pembeli. Tambahkan stok ready hanya untuk barang yang perputarannya sudah terbukti dari data penjualan — ukuran M dan L biasanya, bukan seluruh rentang ukuran. Stok mati di ukuran XXL adalah cara paling umum brand kecil kehabisan modal.

Yang perlu ditambahkan di sistem untuk ini

Tabel lead time per brand dan penanda produk berkustom nama/nomor. Jenis pemenuhannya sendiri dihitung dari stok, tidak disimpan — lihat bagian berikutnya.
Stok per ukuran, dan pengurangannya saat pesanan dikonfirmasi — bukan saat pesanan masuk, supaya pesanan yang tidak jadi dibayar tidak mengunci stok.
Penanda di tiap baris pesanan: butuh SO produksi atau tidak. Ini yang menentukan pesanan masuk ke papan pabrik atau langsung ke antrean kemas.
Alur restock yang terpisah dari pesanan retail, supaya laporan margin tidak mencampur barang yang dibiayai brand dengan barang yang dibiayai pembeli.

Jenis pemenuhan itu dihitung, bukan diisi

Betul sekali — dan ini menyederhanakan banyak hal. Jangan simpan “ready atau pre-order” sebagai pilihan di produk, karena begitu ada dua sumber kebenaran (stok bilang A, penanda bilang B), yang salah selalu penandanya. Cukup satu rumus:

dari_stok = min(diminta, stok[ukuran])
produksi = diminta − dari_stok

produksi > 0 → jadwal produksi menurut jumlah pcs
produksi = 0 → pakai nama/nomor? finishing 3 hari : kirim 1 hari

Prototipe sudah memakai rumus ini. Coba di Jersey Printing Pro: ukuran XXL sisa 4, minta 6 — hasilnya “4 pcs dari stok, 2 pcs diproduksi dulu”. Hoodie yang semua ukurannya kosong otomatis jadi pre-order tanpa penanda apa pun.

Efek sampingnya bagus: ukuran yang habis tidak perlu lagi dimatikan. Dulu pembeli yang mau M lihat tulisan “habis” lalu pergi; sekarang dia lihat “pre-order, ± 10 hari kerja” dan tetap bisa memesan. Untuk barang yang toh diproduksi sendiri, mematikan pilihan itu membuang pesanan tanpa alasan.

Tabel aturan lead time

Persis seperti yang kamu maksud — satu tabel per brand, diisi sendiri di cockpit, dan sistem menjanjikan tanggal tanpa bertanya ke siapa pun:

Jumlah yang harus diproduksi	Janji ke pembeli	Perlu manusia?
1 – 12 pcs	10 hari kerja	tidak
13 – 50 pcs	14 hari kerja	tidak
51 – 100 pcs	18 hari kerja	tidak
di atas 100 pcs	dikonfirmasi tim	ya

Angka di atas cuma contoh yang sudah jalan di prototipe — ganti dengan angka Bosublim yang sebenarnya. Yang penting bentuknya: ada batas di mana sistem berhenti berjanji sendiri. Pesanan 300 pcs tidak boleh mendapat tanggal otomatis, karena itu bukan pesanan retail lagi.

“Tidak perlu konfirmasi ke Bosublim lagi” — benar sebagai janji, berbahaya sebagai asumsi ini yang jebol duluan

Tabel lead time diam-diam mengandaikan satu hal: pabrik sedang senggang. Kalau lima pesanan 50 pcs masuk di minggu yang sama, kelimanya dijanjikan 14 hari, sementara kapasitas cuma cukup untuk sebagian. Yang jebol bukan satu pesanan — kelimanya sekaligus, dan kamu baru tahu di hari kesepuluh, saat sudah tidak ada ruang memperbaiki.

Tindakan: ganti konfirmasi manusia dengan kuota, jangan hapus begitu saja. Beri jalur brand kapasitas mingguan (misalnya 400 pcs). Tiap pesanan yang lunas memesan slot dari kuota minggu itu; kalau minggu ini penuh, sistem otomatis memberi tanggal minggu berikutnya — tidak menolak, tidak bertanya, tapi janjinya jujur. Tetap otomatis seperti maumu, hanya saja tidak buta.

Empat hal yang membuat “sesuai deadline” jadi nyata

Bawa tanggalnya ke SO. Kabar baik: orders di ERP-mu sudah punya kolom deadline, status deadline, bahkan urutan produksi yang secara bawaan mengurut berdasarkan deadline. Jadi SO dari pesanan retail tinggal membawa tanggal hasil hitungan tadi, dan papan produksi otomatis mengurutkannya di tempat yang benar. Tanpa itu, “minta selesai sesuai deadline” cuma harapan yang disampaikan lewat chat.
Beri buffer, jangan jual angka terbaik. Kalau pabrik sanggup 10 hari saat lancar, janjikan 12–14. Selisih itu yang menyerap kain telat datang dan mesin ngadat. Brand yang menjanjikan angka terbaiknya akan telat di sepertiga pesanannya, dan reputasinya rusak justru karena jujur soal kecepatan.
Kurangi stok saat lunas, bukan saat pesanan masuk — dan lakukan di dalam satu transaksi basis data yang mengunci baris stoknya. Kalau tidak, dua orang bisa sama-sama membeli ukuran M terakhir dalam detik yang sama, dan dua-duanya dijanjikan “siap kirim”.
Tulis siapa menanggung keterlambatan. Sekarang terasa tidak penting karena pabrik dan brand sama-sama milikmu — uangnya pindah dari kantong kiri ke kanan. Begitu ada toko luar yang memakai sistem ini, aturan itu harus sudah ada sebelum keterlambatan pertama, bukan sesudahnya.

Kenapa orang pakai ini, bukan Shopify atau Lynk

Ini bagian yang paling perlu kamu jawab jujur. Pembuat toko online berbasis WhatsApp sudah banyak sekali di Indonesia, sebagian gratis. Kalau posisinya “bikin toko online + tombol WA”, kamu masuk ke pasar padat dengan modal paling kecil di antara semua pemain — dan pemenang di pasar itu ditentukan biaya akuisisi, bukan fitur.

Tapi ada satu hal yang toko online umum kerjakan dengan buruk, dan kebetulan itu justru inti bisnismu: pesanan yang isinya daftar orang, bukan daftar barang. Satu jersey tim = 18 baris ukuran, nama punggung, dan nomor. Di Shopify atau marketplace, itu berubah jadi neraka catatan tambahan; di WhatsApp, jadi tangkapan layar spreadsheet yang diketik ulang admin. Di prototipe ini, itu adalah tabel biasa yang ikut sampai ke nota.

Posisikan begitu: bukan pembuat toko online, tapi tempat jualan apparel tim yang mengerti roster. Pasarnya lebih sempit — dan justru itu yang membuat kamu bisa menang di dalamnya. Konveksi, brand jersey lokal, dan penjual seragam adalah calon pengguna yang jelas, dan mereka sudah ada di sekitar Bosublim.

Angka yang dipantau mingguan

Empat baris ini cukup untuk tahu sehat atau tidak. Kolom kanan adalah patokan awal yang wajar untuk katalog kecil — ganti dengan angka kamu sendiri setelah 4 minggu.

Tahap	Artinya	Patokan
Buka detail produk	Foto & harga cukup menarik	35–50%
Sampai layar cara bayar	Form & roster tidak bikin kabur	8–15%
Pilih bayar sistem	Penanda kepercayaan bekerja	ukur, jangan tebak
Closing berbayar	Harga, ongkir, respons penjual	30–50%

Kalau saya yang kerjakan minggu ini

Pasang prototipe ini untuk satu brand sendiri, dengan rekening dan nomor asli, lalu kumpulkan 30 pesanan pertama. Sambil jalan, kerjakan hanya dua hal dari fase 01: tabel pesanan di Supabase beserta RLS per toko, dan halaman status pesanan. Panel admin, pendaftaran toko, dan gateway pembayaran jangan disentuh sampai brand kedua kamu sendiri berjalan mulus di atasnya. Membangun untuk toko orang lain sebelum tokomu sendiri lancar adalah cara paling rapi untuk sibuk tanpa maju.