03 · Panduan Onboarding Wakil Ketua Tim (Playbook Operasional Shift)¶
Pembaca sasaran: Wakil Ketua Tim (Supervisor Shift) baru, rekan lama yang perlu menyelaraskan SOP shift, dan penerima estafet berikutnya Pertanyaan inti: Pada hari pertama bertugas mandiri, sudah jelas apa yang harus dilakukan di setiap titik waktu, bagaimana setiap tugas dituntaskan, dan siapa yang dihubungi saat terjadi anomali Posisi: Playbook operasional jabatan, bukan deskripsi pekerjaan (JD). Digunakan bersama 01-Dasar Manajemen Tim, 02-Kolaborasi Tim Jarak Jauh Penulis: Bob ｜ Terakhir diperbarui: 2026-04-12
📚 Buku panduan pendamping: 11-平台手册/非凡包网/ — 12 dokumen topik + 9 subdirektori dengan 79 sub-panduan (Member & Risiko 14 / Keuangan & Pembayaran 10 / Konfigurasi Aktivitas 13 / Alat Pemasaran 5 / Catatan Aktivitas 18 / Saluran Promosi 11 / Manajemen Game 3 / Admin Sistem 4 / Frontend User 1), total 91 dokumen
Daftar Isi¶
- Satu, Posisi Peran & Garis Merah
- Dua, Timeline Kerja Harian (Waktu Indonesia UTC+7)
- Peta Tanggung Jawab · Ringkasan Satu Halaman
- Tiga, Alur Kerja Tugas Berirama (Jalur A)
- 3.1 Alur Lengkap Notifikasi Push
- 3.2 Pengelolaan Kode Penukaran
- 3.3 Paket Tugas Batch Shift Siang (SMS + Bonus gabungan)
- 3.4 Tarik Balik Mingguan (Persiapan Jumat + Pengiriman Sabtu)
- 3.5 Inspeksi Selisih Deposit-Penarikan + Cashback Bersyarat
- 3.6 Pengelolaan Saluran Penagihan & Pencairan Pembayaran
- Empat, Alur Kerja Tugas Responsif (Jalur B)
- 4.1 Audit Pesanan Penarikan
- 4.2 Proses Pemotongan
- 4.3 Perubahan Hak Akses Member
- 4.4 Penanganan Callback Pesanan
- 4.5 Pemeriksaan Persyaratan Turnover
- 4.6 Investigasi Masalah Larangan Taruhan
- 4.7 Penyesuaian RTP Hari Event
- 4.8 Pemrosesan Pesanan Chargeback/Reversal
- 4.12 Bantuan Buka Situs Baru (Membantu Ketua Tim)
- 4.13 Inspeksi Pesanan Pencairan Anomali dari Keuangan
- Lima, Penanganan Masalah Umum
- 5.1 Member Lupa Kata Sandi Login
- 5.2 Member Lupa Kata Sandi Penarikan
- 5.3 Jawaban Cepat Keluhan Aturan Aktivitas
- Enam, Standar Kolaborasi & Komunikasi
- Tujuh, Daftar Periksa Serah Terima Shift
- Delapan, Saran Otomatisasi
- Sembilan, Daftar Masalah yang Perlu Dikonfirmasi
- Sepuluh, Akumulasi Pengalaman & Pelajaran
- Lampiran A · Kartu Referensi Cepat
- Lampiran B · Indeks Dokumen Terkait
- Lampiran C · Panduan Penggunaan Toolbox Wakil Ketua Tim
Satu, Posisi Peran & Garis Merah¶
1.1 Profil Peran Tiga-dalam-Satu¶
Wakil Ketua Tim pada dasarnya adalah peran tiga-dalam-satu "Eksekusi Pemasaran + Peninjauan Awal Kontrol Risiko + Koordinasi Kolaborasi":
┌──────────────────────────────┐
│ Wakil Ketua Tim (Shift) │
└──────────┬───────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
┌───────▼───────┐ ┌──────▼────────┐ ┌──────▼───────┐
│ Eksekusi │ │ Peninjauan │ │ Koordinasi │
│ Pemasaran ~45% │ │ Awal Risiko │ │ Kolaborasi │
│ Lapisan output │ │ ~30% │ │ ~25% │
│ Jangkauan user │ │ Lapisan │ │ Lapisan │
│ + insentif │ │ keputusan │ │ proses │
│ │ │ Audit dana / │ │ Koord lintas │
│ │ │ akun │ │ tim + jejak │
└───────────────┘ └───────────────┘ └──────────────┘
Matriks tanggung jawab tiga-dalam-satu (mencakup semua bab di dokumen ini):
| Eksekusi Pemasaran (lapisan output) | Peninjauan Awal Risiko (lapisan keputusan) | Koordinasi Kolaborasi (lapisan proses) |
|---|---|---|
| Notifikasi push (Firebase / JPush 5x/hari, Pesan Dalam Aplikasi 1x/hari) → 3.1 | Audit pesanan penarikan (deteksi pola perilaku bawahan anti-arbitrase agen) → 4.1 | Klaim tugas (anti-duplikasi, prasyarat semua aksi Jalur B) → Empat |
| Pengelolaan kode penukaran (atur / ganti) → 3.2 | Eksekusi pemotongan (Audit menemukan → CS komunikasi → user setuju → Wakil Ketua Tim eksekusi) → 4.2 | Penanganan callback pesanan (sesuai notifikasi CS / keuangan / risiko) → 4.4 |
| SMS follow-up user (daftar belum deposit + tarik balik loss) → 3.3 | Perubahan hak akses member (buka/tutup taruhan / penarikan / login) → 4.3 | Pengelolaan saluran pay-in/pay-out (tugas pertama shift + inspeksi tiap jam) → 3.6 |
| Distribusi Peti Harta batch (tarik balik depositor kemarin / kemarin lusa tidak kemarin, harian) → 3.3.4 / 3.3.5 | Pemeriksaan turnover → 4.5 | Monitoring tingkat keberhasilan deposit (tiap 30 menit) → 4.9 |
| Tarik balik mingguan (daftar 30 hari + tidak login 10+ hari + ≥ 2 deposit, mingguan) → 3.4 | Investigasi larangan taruhan → 4.6 | Penanganan penarikan 30 menit belum callback → 4.10 |
| Cashback bersyarat selisih deposit-penarikan (20:00 · rasio 0.02 · persetujuan supervisor) → 3.5 | Reset kata sandi (login + penarikan · pertahanan social engineering) → 5.1 / 5.2 | Penanganan pesanan refund/pembatalan → 4.8 |
| On/Off saluran deposit terbaik jam sibuk (hanya user baru, buka 19:00 / tutup 03:00) → 3.6 sub-tugas | Buka kunci Daftar Penguncian User (saat reset kata sandi + setelah arbitrase) → 5.2.2 | Penanganan pesanan timeout antarmuka pencairan → 4.11 |
| Penyesuaian tingkat RTP hari event → 4.7 | Inspeksi pesanan pencairan anomali dari Keuangan (identifikasi kesalahan manusia) → 4.13 | Bantuan buka situs baru (binding domain + konfigurasi otomatisasi Salesmartly / bot Telegram) → 4.12 |
| — | — | Laporan Grup Keuangan (wajib untuk setiap aksi terkait dana) + respon Grup CS + serah terima shift (10:00 pagi / 22:00 malam) |
📝 Sumber: Pembelajaran & diskusi
1.2 Batasan Tanggung Jawab—Saya Bukan Siapa¶
| Peran | Bukan | Alasan |
|---|---|---|
| Perencana Aktivitas | Tidak menentukan strategi jumlah/nominal/copywriting kode penukaran | Kode penukaran diatur sendiri oleh Wakil Ketua Tim; parameter jumlah/nominal mengikuti aturan tim |
| Auditor Keuangan | Tidak memulai keputusan pemotongan secara mandiri | Pemotongan dimulai oleh Tim Audit → CS berkomunikasi → pengguna setuju → Wakil Ketua Tim mengeksekusi, setelah selesai dilaporkan di Grup Keuangan |
| CS Garis Depan | Tidak langsung membalas pertanyaan pengguna | Masalah pengguna ditangani tim CS, hanya menangani hak akses/pemotongan yang diteruskan CS |
📝 Sumber: Pembelajaran & diskusi
1.3 Tiga Garis Merah yang Tidak Boleh Dilanggar¶
┌──────────────────────────────────────────────────────────────┐
│ Tiga Garis Merah │
│ │
│ ① Cegah Duplikasi │
│ Tugas di grup harus "diklaim dulu baru dikerjakan", │
│ terutama hak akses member, pemotongan, callback pesanan │
│ Operasi ganda = kerugian finansial │
│ │
│ ② Cegah Penipuan │
│ Penarikan agen wajib melalui deteksi pola bawahan │
│ Gagal bayar otomatis → baik penarikan pertama atau bukan │
│ wajib cek status order asli dan tangani sesuai status │
│ │
│ ③ Cegah Putusnya Rantai │
│ Setiap tindakan harus meninggalkan jejak: catatan │
│ back-office / pengumuman grup / pencatatan spreadsheet / │
│ notifikasi keuangan & CS, untuk serah terima shift dan │
│ review pasca-kejadian │
└──────────────────────────────────────────────────────────────┘
📝 Sumber: Pembelajaran & diskusi
Dua, Timeline Kerja Harian (Waktu Indonesia UTC+7)¶
Ritme kerja Wakil Ketua Tim adalah dua jalur paralel:
- Jalur A (Tugas Berirama): Dilaksanakan pada titik waktu tetap, 5 kali push + komisi + SMS + inspeksi + cashback
- Jalur B (Tugas Responsif): Penarikan/hak akses/pemotongan/callback dll ditangani segera
Waktu(UTC+7) Shift Malam Shift Siang Keterangan
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
00:00 ████████ ░░░░░░░░ Jalur A Push ①(satu-satunya shift malam)
Firebase otomatis + Jpush manual (PWA/bookmark)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📌 Puncak pasar Indonesia 19:00–03:00, push malam sangat krusial
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
02:00~10:00 ░░░░░░░░ ░░░░░░░░ Jalur B Jendela responsif: Penarikan/Hak Akses/Pemotongan/Callback
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10:00 >> Shift siang mulai + konfirmasi serah terima
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10:00~10:15 ████████ Jalur A Pengelolaan Saluran Penagihan & Pencairan (hal pertama shift siang)
Cek saldo CP/ATM → Konfigurasi pencairan → Verifikasi urutan saluran
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10:15~11:00 ████████ Jalur A Paket Tugas Batch Shift Siang (SMS Follow-up + Bonus, 4 sub-tugas)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
11:00 ████████ Jalur A Push ② (Firebase + Jpush)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
15:00 ████████ Jalur A Push ③ (Firebase + Jpush)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
19:00 ████████ Jalur A Push ④ (Firebase + Jpush + Pesan Dalam Aplikasi, tiga saluran)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
20:00 ████████ Jalur A Inspeksi Selisih Deposit-Penarikan (semua platform)
+-- Platform >10% → Beritahu supervisor
+-- Platform >10% → Picu cashback hari ini (0.02)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
20:00~20:40 Inspeksi (<=15mnt) + Cashback (<=25mnt)
Harus selesai sebelum push 21:00
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
21:00 ████████ Jalur A Push ⑤ (terakhir shift siang, Firebase + Jpush)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
22:00 >> Shift malam mulai + konfirmasi serah terima
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Prinsip Utama: Firebase otomatis terjadwal, cukup diatur sekali dan berjalan sendiri; Jpush harus dikirim secara manual tepat waktu di semua 5 slot (tidak bisa dijadwalkan); Pesan Dalam Aplikasi hanya dikirim manual di 19:00 (1 kali/hari). Pastikan setel alarm 1 jam sebelum setiap push.
📝 Sumber: Pembelajaran & diskusi
Referensi Cepat Tugas Jalur A¶
| # | Tugas | Frekuensi | Titik Waktu | Lihat |
|---|---|---|---|---|
| 1 | Notifikasi Push (Firebase + Jpush + Pesan Dalam Aplikasi) | Firebase/Jpush 5 kali/hari, Pesan Dalam Aplikasi 1 kali/hari | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 (Pesan Dalam Aplikasi hanya 19:00) | 3.1 |
| 2 | Pengelolaan Kode Penukaran | Saat kode perlu diperbarui | Wakil Ketua Tim mengatur per platform | 3.2 |
| 3 | Paket Tugas Batch Shift Siang (SMS Follow-up + Distribusi Bonus, 4 sub-tugas) | 1 batch/hari | Setelah mulai shift siang | 3.3 |
| 4 | Tarik Balik Mingguan (daftar 30 hari + tidak login 10+ hari + deposit ≥ 2 → 0.88 + SMS) | 1 kali/minggu | Siapkan Jumat, kirim Sabtu (dengan 3.3) | 3.4 |
| 5 | Inspeksi Selisih Deposit-Penarikan + Cashback Bersyarat | 1 kali/hari | 20:00 | 3.5 |
| 6 | Pengelolaan Saluran Penagihan & Pencairan Pembayaran | Setiap hari | Hal pertama shift siang | 3.6 |
Referensi Cepat Tugas Jalur B¶
| Tugas | Cara Pemicu | Lihat |
|---|---|---|
| Audit Pesanan Penarikan | Saat pesanan masuk | 4.1 |
| Proses Pemotongan | Saat ada umpan balik dari CS | 4.2 |
| Buka/Tutup Hak Akses Member | Saat ada umpan balik dari CS | 4.3 |
| Penanganan Callback Pesanan | Saat notifikasi muncul di grup | 4.4 |
| Monitoring Tingkat Keberhasilan Deposit | Setiap 30 menit (terjadwal) | 4.9 |
| Penarikan 30 Menit Belum Callback | Saat peringatan back-office | 4.10 |
| Pesanan Timeout Antarmuka Pencairan | Saat peringatan back-office | 4.11 |
Peta Tanggung Jawab · Ringkasan Satu Halaman¶
Baca peta ini sebelum shift pertama — semua tanggung jawab Wakil Ketua Tim ada di sini. Jalur A / Jalur B hanya dua dari empat kategori. Detail dijabarkan di bab-bab berikutnya.
Peta Tanggung Jawab Wakil Ketua Tim (4 kategori)
│
├─ Jalur A · Tugas Berirama (terjadwal, prioritas tertinggi, tidak boleh terganggu)
│ │
│ ├─ 📣 Push & jangkauan
│ │ ├─ 3.1 Notifikasi push (Firebase/JPush 5x/hari + Pesan Dalam Aplikasi 1x/hari)
│ │ └─ 3.2 Pengelolaan kode penukaran (saat perlu, ad-hoc)
│ │
│ ├─ 👥 Operasi user
│ │ ├─ 3.3 Paket batch shift siang (1 batch/hari · 4 sub-tugas: SMS + bonus)
│ │ └─ 3.4 Tarik balik mingguan (persiapan Jumat + kirim Sabtu)
│ │
│ └─ 💰 Operasi finansial
│ ├─ 3.5 Inspeksi selisih deposit-penarikan + cashback bersyarat (harian 20:00)
│ ├─ 3.6 Pengelolaan saluran pay-in/pay-out (tugas pertama + inspeksi tiap jam)
│ └─ 3.6 sub-tugas: On/Off saluran deposit terbaik jam sibuk (buka 19:00 / tutup 03:00)
│
├─ Jalur B · Tugas Responsif (dipicu event, 4 langkah: Klaim → Eksekusi → Balas → Lapor)
│ │
│ ├─ 🚨 Rantai keputusan penarikan
│ │ ├─ 4.1 Audit pesanan penarikan (risiko tertinggi)
│ │ ├─ 4.10 Penarikan 30 menit belum callback
│ │ └─ 4.11 Timeout antarmuka pencairan
│ │
│ ├─ 🔧 Intervensi akun
│ │ ├─ 4.2 Proses pemotongan
│ │ ├─ 4.3 Perubahan hak akses member
│ │ ├─ 5.1 Member lupa kata sandi login
│ │ └─ 5.2 Member lupa kata sandi penarikan
│ │
│ ├─ 🔁 Aliran dana
│ │ ├─ 4.4 Penanganan callback pesanan
│ │ └─ 4.13 Inspeksi pesanan pencairan anomali dari Keuangan (identifikasi kesalahan manusia)
│ │
│ └─ 📊 Monitoring / peringatan
│ └─ 4.9 Monitoring tingkat keberhasilan deposit (tiap 30 menit)
│
├─ 🤝 Kolaborasi (sepanjang hari + bantuan ad-hoc ke Ketua Tim)
│ ├─ Serah terima shift (10:00 pagi + 22:00 malam, lihat Tujuh)
│ ├─ Komunikasi grup (CS / risiko / keuangan / shift, lihat Enam)
│ ├─ Laporan grup keuangan (wajib untuk setiap tindakan terkait dana)
│ └─ 4.12 Bantuan buka situs baru (binding domain + otomatisasi CS + konfigurasi bot)
│
└─ 📚 Pertumbuhan (berkelanjutan)
├─ Pelajari manual platform (Lampiran B · indeks 91 sub-manual)
├─ Bangun pembelajaran sendiri (Sepuluh · jebakan & catatan efisiensi)
└─ Umpan balik otomatisasi (Delapan · inventaris tool)
Tabel induk berdasarkan frekuensi (semua deep link):
| Frekuensi | Tugas | Kategori | Lihat |
|---|---|---|---|
| Harian · 5 slot tetap | Notifikasi push (Firebase + JPush 5x/hari, Pesan Dalam Aplikasi 1x/hari) | Jalur A | 3.1 |
| Harian · tugas pertama shift | Pengelolaan saluran pay-in/pay-out | Jalur A | 3.6 |
| Harian · tiap jam | Inspeksi saldo merchant pay-out | Jalur A | 3.6 sub-tugas |
| Harian · setelah shift siang mulai | Paket batch shift siang (SMS + bonus, 4 jalur) | Jalur A | 3.3 |
| Harian · 20:00 | Inspeksi selisih deposit-penarikan + cashback | Jalur A | 3.5 |
| Harian · buka 19:00 / tutup 03:00 | Saluran deposit terbaik jam sibuk (hanya user baru) | Jalur A | 3.6 sub-tugas |
| Harian · tiap 30 menit | Monitoring tingkat keberhasilan deposit | Jalur B | 4.9 |
| Harian · dipicu event | Audit penarikan / pemotongan / hak akses / callback / reset kata sandi | Jalur B | 4.1 / 4.2 / 4.3 / 4.4 / 5.1 / 5.2 |
| Ad-hoc · dipicu grup keuangan | Inspeksi pesanan pencairan anomali dari Keuangan (identifikasi kesalahan manusia) | Jalur B | 4.13 |
| Ad-hoc (saat kode baru) | Pengelolaan kode penukaran | Jalur A | 3.2 |
| Ad-hoc · notifikasi Ketua Tim | Bantuan buka situs baru (binding domain + otomatisasi CS + konfigurasi bot) | Kolaborasi | 4.12 |
| Mingguan · Jumat+Sabtu | Tarik balik mingguan (30 hari + tidak login 10 hari + ≥2 deposit) | Jalur A | 3.4 |
| Berkelanjutan | Serah terima / grup / laporan keuangan | Kolaborasi | Enam / Tujuh |
| Berkelanjutan | Belajar / pembelajaran / umpan balik otomatisasi | Pertumbuhan | Delapan / Sepuluh / Lampiran B |
Tiga, Alur Kerja Tugas Berirama (Jalur A)¶
3.1 Alur Lengkap Notifikasi Push (Firebase + JPush + Pesan Dalam Aplikasi)¶
Seluruh tugas push dibagi menjadi tiga tahap. Setiap kali mendapat kode penukaran baru, laksanakan Tahap Satu dan Tahap Dua (satu kali), kemudian setiap hari jalankan Tahap Tiga berulang di titik-titik waktu yang dijadwalkan.
Tiga saluran push menargetkan segmen user berbeda; Firebase dan Jpush selaras 5 kali/hari, Pesan Dalam Aplikasi hanya 1 kali/hari (19:00):
| Saluran | User Target | Frekuensi | Titik Waktu |
|---|---|---|---|
| Firebase (FCM) | User APK (build Android native) | 5 kali/hari | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 |
| Jpush (Aurora Push) | User PWA / bookmark (iOS + Android — siapa pun yang memasang PWA kita) | 5 kali/hari | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 |
| Pesan Dalam Aplikasi | Semua user login (Web + App) | 1 kali/hari | hanya 19:00 |
Tentang "Jpush": Menu di back-office namanya "Aurora Push / Jpush", tapi target sebenarnya adalah user PWA / bookmark (user yang menambahkan situs ke home screen). Tidak dibatasi OS — user iOS maupun Android sama-sama menerima selama memasang PWA. Ini saluran independen, berbeda dengan Firebase (yang menargetkan APK native).
Kenapa titik waktu 00:00 / 11:00 / 15:00 / 19:00 / 21:00? Pasar Indonesia memiliki puncak aktivitas 19:00–03:00 (jam emas hiburan malam). Lima slot ini mencakup pemanasan pra-puncak, penjangkauan siang, dan jangkauan terpusat saat puncak. Firebase dan Jpush dikirim di semua 5 slot; Pesan Dalam Aplikasi hanya 19:00 — agar user dengan format perangkat berbeda masing-masing terjangkau. Pukul 11:00 adalah jam makan siang pegawai kantoran biasa — mereka sering cek HP di jam ini. Pukul 15:00 adalah jam pulang kantor banyak pejabat/PNS Indonesia — juga jam yang relatif mudah dijangkau.
┌─────────────────────────────────────────────────────────────────┐
│ Gambaran Alur Lengkap │
│ │
│ Tahap Satu: Persiapan (sekali setiap kode baru) │
│ Wakil Ketua Tim atur kode → Kirim ke UI untuk gambar → │
│ Unduh gambar → Rename → Buat kode di back-office → Perbarui │
│ bank copywriting │
│ │
│ Tahap Dua: Penjadwalan (sebelum push, konfigurasi titik waktu │
│ berikutnya saat luang) │
│ Belasan platform satu per satu dikonfigurasi di Firebase │
│ (bisa salin tugas lama lalu modifikasi) │
│ │
│ Tahap Tiga: Eksekusi (5 titik waktu harian) │
│ 00:00 → Firebase + Jpush │
│ 11:00 → Firebase + Jpush │
│ 15:00 → Firebase + Jpush │
│ 19:00 → Firebase + Jpush + Pesan Dalam Aplikasi (tiga saluran) │
│ 21:00 → Firebase + Jpush │
│ Catatan: setiap kirim yang baru, hapus Pesan Dalam Aplikasi │
│ yang lama terlebih dahulu │
└─────────────────────────────────────────────────────────────────┘
Tahap Satu · Persiapan: Dilakukan Saat Kode Perlu Diperbarui¶
Wakil Ketua Tim menentukan kode baru
│
│ (1) Atur kode penukaran (situs baru: gunakan nama situs
│ mis. SL888; selanjutnya: angka acak 4 digit)
▼
┌──────────────────────────────┐
│ (2) Kirim ke tim UI untuk │ ← Berikan kode, UI membuat
│ pembuatan gambar │ gambar pemasaran
└────────┬─────────────────────┘
│
▼
┌───────────────────────┐
│ (3) Unduh gambar │
│ ke lokal │
└────────┬──────────────┘
│
▼
┌────────────────────────────┐
│ (4) Rename gambar dengan │ ← Standarisasi, agar petugas
│ "nama platform" │ shift berikutnya mudah mengenali
└────────┬───────────────────┘
│
▼
┌───────────────────────┐
│ (5) Kirim ke grup tim │ ← Sinkronisasi info, hindari unduh ulang
└────────┬──────────────┘
│
▼
┌───────────────────────────────────────┐
│ (6) Masuk ke back-office tiap platform│
│ buat kode penukaran baru: │
│ · Jumlah Generasi: 1 │
│ · Jumlah Penggunaan per Kode: │
│ 50.000 │
│ · Target: user deposit hari ini │
│ · Nominal: acak antara 1-2 │
│ · Persyaratan Turnover = nominal │
│ · Verifikasi kode penukaran benar │
└────────┬──────────────────────────────┘
│
▼
┌───────────────────────────────────────┐
│ (7) Perbarui Google Spreadsheet │
│ "Bank Copywriting Promosi" │
│ Ganti kode baru ke template │
│ copywriting platform terkait │
└───────────────────────────────────────┘
Tabel Parameter Utama:
| Parameter | Nilai Saat Ini | Catatan |
|---|---|---|
| Jumlah Generasi | 1 | Hanya 1 kode dibuat sekaligus |
| Jumlah Penggunaan per Kode | 50.000 | Satu kode yang sama dipakai bersama sampai 50.000 kali |
| Target Penggunaan | User deposit hari ini | Hanya member yang sudah deposit hari ini yang bisa klaim |
| Rentang nominal | 1 ~ 2 (acak) | Platform baru mulai dari 2.2, turun bertahap ke 1.0, kemudian acak 1-2 |
| Kelipatan turnover | 1x (= nominal) | Persyaratan volume taruhan |
| Frekuensi push Firebase | 5 kali/hari (APK / Android native) | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 |
| Frekuensi Jpush | 5 kali/hari (user PWA/bookmark — iOS + Android) | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 |
| Frekuensi Pesan Dalam Aplikasi | 1 kali/hari (semua user login) | hanya 19:00 |
📝 Sumber: Pembelajaran & diskusi
🤖 Progres otomatisasi: Skrip otomatisasi Tampermonkey untuk Firebase dan JPush sudah dikembangkan, sangat mengurangi pekerjaan copy-paste mekanis dan meningkatkan efisiensi. Desain teknis didokumentasikan di 02-技术体系/16-firebase/. Catatan: titik waktu push saat ini (tepat jam) bertepatan dengan puncak lalu lintas global FCM, disarankan geser +3 menit untuk menghindari kemacetan.
Tahap Dua · Penjadwalan: Konfigurasi Tugas Terjadwal di Firebase¶
Penting: Bukan mengkonfigurasi 5 titik waktu sekaligus. Operasi sebenarnya adalah hanya mengkonfigurasi titik waktu berikutnya, memanfaatkan waktu luang untuk mempersiapkan lebih awal. Karena ada belasan platform yang harus dikonfigurasi satu per satu, beban kerjanya tidak sedikit, jadi setiap shift bertanggung jawab atas konfigurasi periode waktunya sendiri.
Setelah push saat ini selesai (atau waktu luang)
│
▼
┌───────────────────────────────────────────┐
│ Untuk setiap platform (belasan), │
│ konfigurasi titik waktu berikutnya: │
│ │
│ Masuk ke Firebase Console platform tsb │
│ │ │
│ ▼ │
│ Salin tugas terjadwal putaran sebelumnya │
│ (hemat waktu) │
│ │ │
│ ▼ │
│ Edit: │
│ · Judul → Salin dari Google Bank Copy │
│ · Konten → Salin dari Google Bank Copy │
│ · Gambar → Gambar platform tsb (cek!) │
│ · Waktu → Titik irama berikutnya │
│ │ │
│ ▼ │
│ Verifikasi: Nama platform↔Gambar↔Copy │
│ ↔Kode Penukaran konsisten? │
│ │ │
│ └→ Platform berikutnya, ulangi │
└───────────────────────────────────────────┘
Pembagian Tugas per Shift:
| Shift | Bertanggung Jawab Mengkonfigurasi | Waktu Konfigurasi |
|---|---|---|
| Shift Malam | Push jam 00:00 | Konfigurasi saat luang setelah mulai shift |
| Shift Siang | 11:00 / 15:00 / 19:00 / 21:00 | Setelah setiap push selesai, konfigurasi berikutnya saat luang |
Kesalahan Umum yang Sering Terjadi:
| Skenario Kesalahan | Dampak | Tindakan Pencegahan |
|---|---|---|
| Gambar tertukar | Push notifikasi platform A pakai gambar platform B | Setelah konfigurasi tiap platform, periksa ulang dengan mencocokkan nama platform |
| Kode penukaran di copywriting tidak diperbarui | Pengguna mendapat kode kadaluarsa | Gunakan Google Bank Copywriting sebagai satu-satunya sumber kebenaran (Single Source of Truth) |
| Zona waktu Firebase salah | Waktu push bergeser | Firebase diatur zona waktu Indonesia (UTC+7), tidak perlu konversi |
| Ada platform yang terlewat | Pengguna platform tersebut tidak menerima push | Setelah selesai, cocokkan dengan daftar platform satu per satu |
📝 Sumber: Pembelajaran & diskusi
Tahap Tiga · Eksekusi: Kirim Push di Setiap Slot¶
Prinsip: Firebase / Jpush 5 kali/hari, Pesan Dalam Aplikasi hanya 19:00 (1 kali/hari). Di slot 19:00 kirim tiga saluran; slot lainnya hanya Firebase + Jpush.
Tabel Aksi per Titik Waktu (seragam di semua slot):
| Waktu | Firebase (APK/Android) | Jpush (PWA/bookmark) | Pesan Dalam Aplikasi (semua) | Catatan |
|---|---|---|---|---|
| 00:00 | ✅ Otomatis | ✅ Kirim manual | — | Firebase + Jpush saja (satu-satunya push shift malam) |
| 11:00 | ✅ Otomatis | ✅ Kirim manual | — | Firebase + Jpush saja |
| 15:00 | ✅ Otomatis | ✅ Kirim manual | — | Firebase + Jpush saja |
| 19:00 | ✅ Otomatis | ✅ Kirim manual | ✅ Kirim manual | Tiga saluran (satu-satunya slot Pesan Dalam Aplikasi) |
| 21:00 | ✅ Otomatis | ✅ Kirim manual | — | Firebase + Jpush saja (push terakhir shift siang) |
T-60 menit (setel alarm persiapkan lebih awal)
│
│ Jpush / Pesan Dalam Aplikasi tidak bisa dijadwalkan —
│ harus dikerjakan manual tepat waktu
▼
Persiapkan push:
· Buka halaman Jpush back-office (draf siap)
· Buka halaman Pesan Dalam Aplikasi (HTML siap tempel)
· Firebase sudah dijadwalkan di Tahap Dua — tanpa aksi manual
│
▼
T-0: Waktunya! Kirim push:
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────────┐
│ ① Firebase │ │ ② Jpush │ │ ③ Pesan Dalam │
│ (otomatis) │ │ Klik tombol │ │ Aplikasi │
│ Semua 5 slot │ │ "Kirim" │ │ · Buka editor kode │
│ (APK/Android) │ │ Semua 5 slot │ │ · Tempel HTML │
│ │ │ (PWA/bookmark) │ │ · Klik kirim │
│ │ │ │ │ · Hapus pesan lama │
│ │ │ │ │ Hanya 19:00 │
└──────────────────┘ └──────────────────┘ └──────────────────────┘
│
▼
T+5: Kirim pesan di Grup Shift "Push HH:MM sudah terkirim
(Firebase + Jpush [+ Pesan Dalam Aplikasi jika 19:00])"
— tercatat sebagai jejak audit
Hal yang Harus Dihindari:
- Slot 19:00 adalah satu-satunya slot tiga saluran (Firebase + Jpush + Pesan Dalam Aplikasi) — melewatkan salah satu saluran berarti user di format perangkat tersebut tidak terjangkau pada ronde itu
- Jpush (5 slot) & Pesan Dalam Aplikasi (hanya 19:00) tidak bisa dijadwalkan, wajib dikirim manual tepat waktu — setel alarm 1 jam sebelumnya
- Hapus Pesan Dalam Aplikasi lama sebelum mengirim yang baru, hindari penumpukan
- Saat serah terima shift, pastikan penerima tahu "Firebase+Jpush 5 slot, Pesan Dalam Aplikasi hanya 19:00"
📝 Sumber: Pembelajaran & diskusi
3.2 Pengelolaan Kode Penukaran¶
Kode penukaran diatur oleh Wakil Ketua Tim untuk setiap platform. Setelah diatur, kirim ke tim UI untuk pembuatan gambar, lalu masuk ke alur notifikasi push.
Aturan Penamaan¶
| Skenario | Cara Penamaan | Contoh |
|---|---|---|
| Situs baru | Gunakan nama situs secara langsung | SL888 |
| Perubahan selanjutnya | Angka acak 4 digit | 3847 |
Alur Lengkap¶
Wakil Ketua Tim mengatur kode penukaran untuk setiap platform
(situs baru pakai nama situs, selanjutnya pakai angka acak 4 digit)
【Sudah ada tool otomatis untuk membuat & mengelola kode secara batch】
│
▼
┌───────────────────────────────┐
│ (1) Buat kode penukaran │
│ di back-office │
│ (parameter lihat tabel │
│ di bawah) │
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────┐
│ (2) Kirim kode ke tim UI │
│ UI membuat gambar push │
│ untuk platform terkait │
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────┐
│ (3) Unduh gambar yang diterima │
│ + ganti nama sesuai │
│ platform, kirim ke grup │
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────┐
│ (4) Perbarui Google Spreadsheet│
│ "Bank Copywriting Promosi" │
│ Ganti kode di template │
│ copywriting platform │
└────────┬──────────────────────┘
│
▼
Masuk ke 3.1 Tahap Dua (Penjadwalan Firebase)
📝 Sumber: Pembelajaran & diskusi
Parameter Pembuatan di Back-Office¶
| Parameter | Nilai | Catatan |
|---|---|---|
| Jumlah Generasi | 1 | Hanya 1 kode yang dibuat sekaligus (bukan 50.000 kode). Kode tunggal ini dibagikan ke semua user yang memenuhi syarat hari itu |
| Nominal yang Bisa Ditukar | 1 ~ 2 (acak) | Diisi rentang di back-office. Satuan platform Indonesia pakai K — 1 setara dengan 1.000 IDR. |
| Jumlah Penggunaan per Kode | 50.000 | Satu kode yang sama bisa dipakai sampai 50.000 kali (setara batas kuota harian semua penerima). |
| Target Penggunaan | User deposit hari ini | Hanya member yang sudah melakukan deposit di hari yang sama yang bisa klaim — bukan untuk user yang belum deposit |
| Persyaratan Turnover | = nominal (1 kali lipat) | Persyaratan volume taruhan sama dengan nominal |
| Masa Berlaku | 1 hari | Kode biasanya dibuat saat serah terima shift malam, sekitar pukul 22:00 ke atas, masa berlakunya diatur sampai hari berikutnya 23:59:59 |
Catatan penting: Saat membuat kode, back-office akan otomatis men-generate kode 4 karakter berisi huruf + angka. Tapi karena user pasar Indonesia tidak terbiasa dengan kode beralfabet, setelah kode dibuat Wakil Ketua Tim wajib klik tombol "Custom Code" dan mengganti kode auto-generated tersebut menjadi kode terpadu yang sudah ditetapkan di awal.
Strategi Platform Baru: Untuk platform yang baru diluncurkan, nominal yang bisa ditukar dari kode mulai dari 2.2, turun bertahap ke 1.0, setelah stabil acak di rentang 1-2.
📝 Sumber: Pembelajaran & diskusi
Kaitan dengan Teks Push¶
Setelah kode penukaran selesai dibuat, wajib memperbarui template copywriting platform terkait di Google Spreadsheet "Bank Copywriting Promosi" secara bersamaan, memastikan kode penukaran dalam teks push adalah yang terbaru. Bank Copywriting adalah Single Source of Truth—teks untuk Tahap Dua penjadwalan dan Tahap Tiga eksekusi semuanya disalin dari sini.
🤖 Peluang otomatisasi: Alat rotasi teks push—setiap platform memilih satu teks secara acak, tidak digunakan ulang dalam 24 jam, memastikan setiap website tidak mengirim teks yang sama berulang. Sudah dibangun di tools/t1-promo-copy/ — kode bisa dibaca langsung dan dipakai ulang.
3.3 Paket Tugas Batch Shift Siang (SMS Follow-up + Distribusi Bonus)¶
Yang harus dilakukan: Setelah shift siang serah terima, jalankan paket batch — tarik data dari back-office → split ke 4 jalur filter → setiap jalur menghasilkan TXT nomor HP; 3 di antaranya (sub-tugas 1/3/4) juga menghasilkan Excel bonus untuk Import Peti Harta, sedangkan sub-tugas 2 (tarik balik loss) hanya menghasilkan TXT + laporan jumlah loss → akhirnya kirim semua SMS di platform.
Tujuan: Menjangkau 4 segmen user (daftar-belum-deposit / loss / depositor kemarin / deposit kemarin lusa tidak kemarin) lewat bonus + SMS untuk mendorong konversi deposit pertama dan retensi.
Waktu: Sekali sehari, tepat setelah shift siang serah terima (setelah Pengelolaan Saluran Pembayaran selesai).
3.3.1 Matriks Ikhtisar 4 Sub-Tugas¶
| # | Nama | Sumber data | Filter | Logika nominal | Nama file TXT (nomor HP) | Nama file XLSX (template bonus) | Teks SMS final |
|---|---|---|---|---|---|---|---|
| 1 | Daftar belum deposit | Halaman Follow-up User · daftar kemarin | Deposit=0 + Taruhan=0 + catatan kosong | Senin–Jumat 0.2 / Sabtu–Minggu 0.3 | MMDD+sms+platform.txt (mis. 0108smsRPRR.txt) |
MMDD kemarin+daftar belum deposit+platform.xlsx (mis. 0107注册未充值RPRR.xlsx) |
Follow-up Belum Deposit |
| 2 | Tarik balik loss | Pakai ulang tabel mentah Sub-tugas 1 | Ada deposit + 0 taruhan + catatan kosong | — (tidak kasih bonus, hanya SMS + statistik jumlah loss) | MMDD+kslh+platform.txt (mis. 0108kslhRPRR.txt) |
platform-MMDD loss:XXX (tabel jumlah, setelah semua platform selesai kirim ke supervisor) |
Tarik Balik Loss |
| 3 | Tarik balik depositor kemarin | Halaman Statistik User · kemarin | Pakai rumus; selisih deposit-penarikan<0 kasih flat 0.38; buang bonus=0 | Rumus Excel tim (⚠️ mulai tingkat ke-5 rumus "bisa lipat ganda vs tanpa lipat ganda" berbeda, standar sekarang bisa lipat ganda, kalau ganti wajib swap rumus) | MMDD+czlh+platform.txt (mis. 0108czlhRPRR.txt) |
MMDD kemarin+czlh+platform.xlsx (mis. 0107czlhRPRR.xlsx) |
Tarik Balik Loss |
| 4 | Tarik balik deposit kemarin lusa tapi tidak kemarin | Halaman Statistik User · kemarin lusa | Bandingkan dengan daftar "deposit kemarin" di Sub-tugas 3, hapus duplikat; sisa pakai rumus sama dengan Sub-tugas 3; buang bonus=0 | Rumus sama dengan Sub-tugas 3 | MMDD+lh+platform.txt (mis. 0108lhRPRR.txt) |
MMDD kemarin+lh+platform.xlsx (mis. 0107lhRPRR.xlsx) |
Tarik Balik Loss |
📝 Sumber: Pembelajaran & diskusi
Aturan penamaan file:
- TXT (daftar nomor HP) = tanggal hari ini (hari kirim) + kode tipe + nama platform
- XLSX (template bonus) = tanggal kemarin (hari sumber data) + deskripsi tipe + nama platform
- Kode tipe: sms (daftar belum deposit) / kslh (loss) / czlh (deposit kemarin) / lh (deposit kemarin lusa tidak kemarin)
3.3.2 Sub-Tugas 1 · Daftar Belum Deposit¶
Back-office Marketing Tools → Follow-up User → filter daftar kemarin → Export
│
▼
Di tabel hasil export, filter: deposit=0 + taruhan=0 + catatan kosong
│
├─ Salin [nomor HP] → notepad baru 0108smsRPRR.txt
│
└─ Salin [ID user] → tempel ke template Excel "Import Peti Harta"
│
▼
Nominal: Senin–Jumat 0.2 / Sabtu–Minggu 0.3
│
▼
Save Excel sebagai 0107注册未充值RPRR.xlsx
│
▼
Back-office Ops Config → Activity Config → baris Invite Activity → "Activity Config"
│
▼
Side nav → halaman "Import Peti Harta Config"
│
▼
Baris [Jumlah Peti Belum Diklaim] → "Lihat" → "Import Peti Harta Reward"
│
▼
Pilih file 0107注册未充值RPRR.xlsx → Import selesai
Catatan template bersama: Template Excel Import Peti Harta bisa di-download sekali dari back-office dan disimpan lokal. Setiap kali jalan, hapus data lama isi data baru — template dipakai ulang.
📝 Sumber: Pembelajaran & diskusi
3.3.3 Sub-Tugas 2 · Tarik Balik Loss¶
Pakai ulang tabel mentah yang di-export di Sub-tugas 1 (tidak perlu export lagi), cuma ganti filter.
Di tabel mentah Sub-tugas 1, filter ulang:
[Ada deposit] + [0 taruhan] + [catatan kosong]
│
├─ Hitung jumlah loss → catat di tabel terpisah
│ Nama file: platform-0108loss:XXX (XXX = jumlah)
│ Setelah semua platform selesai, konsolidasi & kirim ke supervisor
│
└─ Salin [nomor HP] → notepad baru 0108kslhRPRR.txt
Beda dengan Sub-tugas 1: Tarik balik loss tidak kasih bonus (tidak lewat Import Peti Harta); hanya SMS + laporan jumlah ke supervisor.
📝 Sumber: Pembelajaran & diskusi
3.3.4 Sub-Tugas 3 · Tarik Balik Depositor Kemarin¶
Back-office Marketing Tools → Statistik User → export data member kemarin
│
▼
Tempel "rumus bonus yang tim pelihara" (dari dok/Google Sheets) ke tabel export
⚠️ Mulai tingkat ke-5 rumus "bisa lipat ganda vs tanpa lipat ganda" berbeda
Standar sekarang [bisa lipat ganda]; kalau ganti jadi tanpa lipat ganda, swap rumusnya
│
▼
Terapkan rumus ke semua baris → otomatis hitung bonus per member
│
├─ Filter [selisih deposit-penarikan < 0] → flat 0.38 bonus
│ (member ini "menang", kasih nominal balik tetap)
│
▼
Hapus semua filter → filter ulang [bonus ≠ 0] (buang baris bonus=0)
│
▼
Salin [ID user + nominal] → tempel ke template Import Peti Harta
Save sebagai 0107czlhRPRR.xlsx
│
├─ Salin juga [nomor HP] → notepad 0108czlhRPRR.txt
│
▼
Ikuti jalur sama dengan 3.3.2: "Ops Config → Activity Config → Invite Activity → Import Peti Harta Reward"
pilih 0107czlhRPRR.xlsx → Import distribusi
Lokasi formula: kedua versi formula "bisa lipat ganda" dan "tanpa lipat ganda" sudah masuk ke tool kecil di tools/ — bisa dibaca langsung di kode atau dijalankan via tool; tidak perlu paste formula manual tiap kali.
📝 Sumber: Pembelajaran & diskusi
3.3.5 Sub-Tugas 4 · Deposit Kemarin Lusa Tapi Tidak Kemarin¶
Tujuan: menarik kembali member yang deposit kemarin lusa tapi skip kemarin (user peringatan churn). Kuncinya "dedup" — member yang deposit di dua hari tersebut sudah di-cover Sub-tugas 3, jangan kirim dobel. Logika dedup (bandingkan daftar kemarin lusa vs kemarin) juga sudah ada di tool kecil tools/.
Back-office Marketing Tools → Statistik User → export data member [kemarin lusa]
│
▼
Ekstrak daftar member yang deposit kemarin lusa
│
▼
Bandingkan dengan daftar "member deposit kemarin" dari Sub-tugas 3
│
▼
Filter yang overlap → [hapus] duplikat
(Deposit di dua hari = sudah dikirim di Sub-tugas 3, di sini tidak kirim lagi)
│
▼
Sisa = deposit kemarin lusa + tidak deposit kemarin → target user
│
▼
Terapkan [rumus sama dengan Sub-tugas 3] untuk hitung bonus
│
▼
Hapus filter → filter ulang buang baris [bonus=0]
│
▼
Salin [ID user + nominal] → tempel ke template Import Peti Harta
Save sebagai 0107lhRPRR.xlsx
│
├─ Salin [nomor HP] → notepad 0108lhRPRR.txt
│
▼
Ikuti jalur "Import Peti Harta" sama dengan 3.3.2 → import distribusi
📝 Sumber: Pembelajaran & diskusi
3.3.6 SMS Kirim Terpadu (Setelah Semua Sub-Tugas Selesai)¶
Pada tahap ini, Wakil Ketua Tim seharusnya punya 4 file TXT (sms / kslh / czlh / lh), plus 3 import XLSX bonus selesai (sub-tugas 1/3/4), dan tabel jumlah loss Sub-tugas 2 sudah dikirim ke supervisor.
Di tangan: 4 TXT + tabel jumlah loss sub-tugas 2 sudah ke supervisor
│
▼
┌─────────────────────────────────────────────────┐
│ ① Sisip nomor tes │
│ Campur beberapa nomor tes yang bisa │
│ diverifikasi ke setiap TXT secara acak │
│ Sumber: tanya di grup CS / serah terima dari │
│ shift sebelumnya (situs biasanya sudah │
│ punya set tetap yang tercatat) │
│ Posisi: campur dengan nomor asli — jangan │
│ menumpuk di awal atau akhir file │
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ② Total volume │
│ Jumlahkan baris 4 TXT = total hari ini │
│ (dipakai untuk penawaran saluran) │
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ③ Pre-check copywriting │
│ Kirim dua template (Follow-up Belum Deposit + │
│ Tarik Balik Loss) ke saluran SMS untuk cek │
│ kata blok → perbaiki copywriting per feedback │
│ ⚠️ Daftar kata blok berubah, wajib tiap kali │
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ④ Penawaran saluran + persetujuan supervisor │
│ Volume → penawaran saluran → ajukan supervisor │
│ Kirim hanya setelah supervisor setujui │
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ⑤ Kirim sebenarnya │
│ Pakai mapping TXT ↔ teks (lihat tabel bawah) │
│ Submit tiap TXT di platform SMS │
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ⑥ Verifikasi nomor tes │
│ ├─ Semua diterima → saluran OK, batch selesai │
│ └─ Sebagian tidak diterima → hubungi saluran │
│ (down / saldo kurang / terkena kata blok) │
└─────────────────────────────────────────────────┘
Mapping daftar nomor ↔ teks SMS (untuk Langkah ⑤):
| Tipe daftar nomor | Teks SMS terkait |
|---|---|
MMDD+sms+platform (sub-tugas 1) |
Follow-up Belum Deposit |
MMDD+kslh+platform (sub-tugas 2) |
Tarik Balik Loss |
MMDD+czlh+platform (sub-tugas 3) |
Tarik Balik Loss |
MMDD+lh+platform (sub-tugas 4) |
Tarik Balik Loss |
Format file daftar nomor: beda vendor SMS beda persyaratan — ada yang minta format
.txt, ada yang minta tabel.xlsx. Ikuti persyaratan vendor saja, aturan penamaan tetap konsisten.Isi teks sebenarnya (termasuk varian per platform dan versi leet-speak anti-filter) ada di 09-SMS回访文案库; jangan enumerasi di bagian ini.
Tentang dua jenis teks SMS: Teks dibagi menjadi dua arah utama — "follow-up user yang belum deposit" dan "tarik balik user yang sudah deposit tapi loss" — terutama untuk menghindari munculnya informasi sensitif di SMS; dua skenario ini perlu diekspresikan dengan cara yang berbeda. Teks spesifik bisa dioptimalkan dari waktu ke waktu berdasarkan feedback kata-terlarang vendor, penyesuaian kampanye, dll.
📝 Sumber: Pembelajaran & diskusi
3.3.7 Parameter Bersama & Referensi Cepat Jalur Back-Office¶
Parameter keras template Import Peti Harta (berlaku untuk semua sub-tugas yang pakai Import Peti Harta):
| Parameter | Nilai | Catatan |
|---|---|---|
| Kelipatan turnover | 1x | Ditetapkan tim |
| Lipat ganda deposit | ON | Ditetapkan tim (dipasangkan dengan rumus "tingkat ke-5 bisa lipat ganda") |
Kalau parameter perlu diubah, konfirmasi ke supervisor dulu — jangan ubah sendiri.
Referensi cepat jalur back-office:
| Aksi | Jalur |
|---|---|
| Export daftar kemarin (data dasar sub-tugas 1) | Marketing Tools → Follow-up User → pilih daftar kemarin → Export |
| Export data member kemarin / kemarin lusa (data dasar sub-tugas 3/4) | Marketing Tools → Statistik User → pilih tanggal → Export |
| Download template Import Peti Harta (pertama kali pakai) | Ops Config → Activity Config → Invite Activity → Activity Config → side nav → Import Peti Harta Config |
| Import reward Peti Harta (setiap jalankan bonus) | Halaman Import Peti Harta Config di atas → baris [Jumlah Peti Belum Diklaim] → "Lihat" → "Import Peti Harta Reward" |
3.3.8 Reward yang Wakil Ketua Tim Tidak Perlu Tangani¶
Aktivitas berikut di-settle otomatis oleh sistem — TIDAK masuk paket batch ini:
| Aktivitas | Waktu Settle | Jendela Klaim |
|---|---|---|
| Reward VIP Naik Level | Instan saat capai kriteria | — |
| Reward VIP Mingguan | Senin 04:00 (UTC+7) | 7 hari, hangus jika lewat |
| Reward VIP Bulanan | Tanggal 1 tiap bulan 04:00 (UTC+7) | 30 hari, hangus jika lewat |
| Tantangan Taruhan | Instan saat target taruhan tercapai | Sesuai config aktivitas |
| Red-Packet Rain | Dipicu setelah deposit harian, reset pukul 0:00 hari berikutnya | Valid hanya pada run tersebut |
"Manual batch" di bagian ini khusus untuk bonus Peti Harta berbasis data deposit harian (sub-tugas 1/3/4) + SMS loss (sub-tugas 2).
📘 Sumber: 06-VIP奖励活动配置 + 07-投注闯关活动详解 + 08-红包雨活动功能
3.3.9 Peluang Otomatisasi 🤖¶
Status saat ini: Pemrosesan data otomatis (penerapan rumus, perbandingan dedup, penamaan file seragam) sudah diimplementasikan di toolkit kecil tools/. Saluran SMS sudah dikonfirmasi tidak menyediakan API, jadi export, Import Peti Harta, dan paste platform SMS masih perlu langkah manual.
Peluang lebih lanjut: 1. Scheduled job back-office tag member yang memenuhi kriteria (daftar-belum-deposit / loss / deposit kemarin / deposit kemarin lusa tidak kemarin); Wakil Ketua Tim cukup export by tag — butuh dukungan back-office 2. Otomatisasi tarik data: butuh back-office membuka API; saat ini hanya export manual yang bekerja
Integrasi API SMS tertutup (saluran sudah konfirmasi tidak ada API) — tidak lagi terdaftar sebagai kandidat.
Inventaris peluang lengkap: 12-自动化路线图/02-自动化机会盘点.
3.4 Tarik Balik Mingguan (Sekali Seminggu · Persiapan Jumat + Pengiriman Sabtu)¶
Yang harus dilakukan: Setiap minggu, filter member diam kriteria "daftar dalam 30 hari terakhir, tidak login lebih dari 10 hari, minimal 2 kali deposit" — kirim bonus 0.88 + SMS untuk tarik balik.
Tujuan: Reaktivasi member nilai menengah yang pernah deposit tapi belakangan tidak aktif.
Irama: - Jumat: Export data → filter → siapkan Excel bonus dan TXT nomor HP - Sabtu: Import Peti Harta untuk distribusi 0.88, kirim SMS (dikerjakan bersamaan dengan batch harian 3.3)
3.4.1 Jumat · Filter dan Export¶
Jalur back-office: Marketing Tools → Halaman Follow-up User
Kondisi filter (tiga kondisi bersamaan):
| # | Dimensi | Kondisi | Contoh (hari proses = Jumat 4/1, sehari sebelumnya = Kamis 3/31) |
|---|---|---|---|
| 1 | Waktu pendaftaran | Hitung mundur 30 hari dengan hari sebelum hari proses (Kamis) sebagai cutoff | Filter member yang terdaftar antara 3/1 00:00 – 4/1 00:00 |
| 2 | Waktu online terakhir | Tidak login lebih dari 10 hari | Waktu online terakhir sebelum 3/22 00:00 |
| 3 | Jumlah deposit | Hilangkan yang belum pernah deposit + hilangkan yang hanya 1 kali deposit | Jumlah deposit ≥ 2 (anti-arbitrase / anti-farming) |
Export hasil filter sebagai spreadsheet.
3.4.2 Jumat · Siapkan Dua File Output¶
① Excel Bonus (untuk Import Peti Harta hari Sabtu)
| Field | Nilai |
|---|---|
| ID User | Salin dari hasil filter |
| Nominal bonus | 0.88 (default saat ini; bisa disesuaikan atau aktivitas dapat dijeda tergantung kondisi operasi platform / hasil kampanye — ikuti notifikasi supervisor) |
Save sebagai spreadsheet baru.
② TXT Nomor HP (untuk SMS hari Sabtu)
| Item | Nilai |
|---|---|
| Isi | Nomor HP dari hasil filter |
| Format penamaan | <nama situs>+zlh+<tanggal> (zlh = tarik balik mingguan) |
3.4.3 Sabtu · Distribusi (Dikerjakan Bersama dengan 3.3)¶
- Import Peti Harta: Jalur sama dengan sub-tugas 3/4 di 3.3 (Ops Config → Activity Config → Invite Activity → Activity Config → side nav → Import Peti Harta Config → baris "Jumlah Peti Belum Diklaim" → "Lihat" → "Import Peti Harta Reward"); pilih Excel bonus yang disiapkan Jumat → Import
- Kirim SMS: Submit TXT tarik balik mingguan bersamaan dengan 4 TXT dari 3.3 ke platform SMS
📝 Sumber: Pembelajaran & diskusi
3.5 Inspeksi Selisih Deposit-Penarikan + Cashback Bersyarat (setiap hari 20:00)¶
Alur singkat: Setiap hari pukul 20:00, scan rasio selisih di laporan harian tiap platform → untuk platform yang > 10%, kirim daftarnya ke supervisor dulu → supervisor putuskan apakah cashback dengan rasio 0.02 → hanya setelah disetujui, jalankan cashback batch. Harus selesai sebelum 20:40 untuk menyisakan waktu push 21:00.
Parameter Utama¶
| Item | Nilai |
|---|---|
| Waktu inspeksi | Setiap hari 20:00 (Waktu Indonesia UTC+7, deadline keras) |
| Jalur inspeksi | Back-office tiap platform → Manajemen Laporan → Laporan Harian → klik tombol [Query] untuk refresh data hari ini |
| Sumber data user | Back-office tiap platform → Marketing Tools → Statistik User → export data user hari ini |
| Ambang | Satu platform rasio selisih deposit-penarikan > 10% (kolom "Rasio Selisih" di laporan harian back-office menampilkan persentase langsung — tidak perlu hitung manual) |
| Definisi "platform" | Satu platform = satu website; tiap website berbeda dihitung sebagai platform tersendiri |
| Rasio cashback | 0.02 (tetap) |
| Pemicu cashback | Hanya platform > 10%, dan WAJIB persetujuan supervisor sebelum cashback |
| Pintu masuk operasi cashback | Jalur sama dengan "Import Peti Harta" 3.3 (Ops Config → Activity Config → Invite Activity → Import Peti Harta Config → Import Peti Harta Reward) |
| Nominal maksimum Peti Harta | Cek dulu nominal maksimum di template cashback; kalau melebihi konfigurasi Peti saat ini → naikkan sementara → setelah user klaim, kembalikan ke nilai semula |
| Jendela waktu | 20:00 ~ 20:40 (inspeksi + lapor supervisor + tunggu persetujuan + cashback batch, semuanya selesai) |
📝 Sumber: Pembelajaran & diskusi
Perbedaan Mendasar dengan 3.3 Paket Batch¶
| Dimensi | 3.3 Paket Batch (sub-tugas 3/4 bonus) | 3.5 Cashback Selisih Deposit-Penarikan |
|---|---|---|
| Cakupan data | Kemarin / kemarin lusa (historis) | T0 hari ini |
| Kondisi pemicu | Tidak ada (wajib setiap hari) | Hanya selisih > 10% DAN disetujui supervisor |
| Cara perhitungan | Formula bertingkat selisih deposit-penarikan | Rasio 0.02 tetap |
| Perlu persetujuan atasan | Tidak (eksekusi langsung) | Ya (wajib tunggu persetujuan supervisor) |
| Sifat | Kompensasi selisih deposit-penarikan | Insentif retensi bersyarat |
Alur Lengkap¶
20:00 (Waktu Indonesia · deadline keras · setel alarm 19:50)
│
▼
==============================
Langkah 1: Scan tiap platform
==============================
│
▼
┌────────────────────────────────────┐
│ (1) Login back-office tiap platform │
│ Manajemen Laporan → Laporan │
│ Harian │
│ Klik [Query] untuk refresh data │
│ hari ini │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (2) Lihat langsung kolom "Rasio │
│ Selisih" │
│ · > 10% → catat nama platform │
│ · ≤ 10% → lewati, ke platform │
│ berikutnya │
│ (back-office sudah tampilkan % │
│ — tidak perlu hitung manual) │
└──────────┬─────────────────────────┘
│
▼
Ulangi (1)(2) untuk setiap platform sampai semua terscan
│
▼
==============================
Langkah 2: Kumpulkan + tanya supervisor
==============================
│
▼
Ada platform di atas ambang?
│
┌────┴────┐
│ │
Tidak Ada
│ │
▼ ▼
┌──────────┐ ┌─────────────────────────────────┐
│ Posting │ │ (3) Susun daftar platform di │
│ di grup: │ │ atas ambang dan kirim ke │
│ "Scan │ │ supervisor — minta keputusan │
│ 20:00 │ │ apakah cashback dengan │
│ selesai,│ │ rasio 0.02 │
│ tanpa │ └──────────┬──────────────────────┘
│ isu" │ │
│ │ ▼
│ → Siap- │ Keputusan supervisor?
│ siap │ │
│ push │ ┌────┴────┐
│ 21:00 │ │ │
│ │ Tidak Setujui
│ │ cashback cashback
│ │ │ │
│ │ ▼ ▼
│ │ ┌──────────┐ ┌─────────────────┐
│ │ │ Lewati │ │ Langkah 3: │
│ │ │ cashback │ │ Cashback batch │
│ │ │ Catat di │ └────────┬────────┘
│ │ │ grup │ │
│ │ └──────────┘ │
└──────────┘ │
▼
=================================================================
Langkah 3: Cashback batch (hanya setelah persetujuan supervisor)
=================================================================
│
▼
┌────────────────────────────────────┐
│ (4a) Buat template Excel cashback │
│ · Rasio: 0.02 (tetap) │
│ · Cakupan: user platform itu │
│ hari yang sama yang memenuhi │
│ aturan cashback back-office │
│ · Hitung nominal tiap user │
│ │
│ ⚠️ Setelah hitung, **cek │
│ nominal maksimum** dari semua │
│ user di template │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4b) Cek konfigurasi "nominal │
│ maksimum Peti Harta" │
│ Maks cashback > maks Peti │
│ Harta saat ini? │
│ ├─ Ya → **naikkan sementara │
│ │ maks Peti Harta** │
│ │ agar bisa cover │
│ └─ Tidak → langsung ke (4c) │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4c) Jalur sama dengan 3.3 sub- │
│ tugas 3/4 │
│ Ops Config → Activity Config → │
│ Invite Activity → Activity │
│ Config → side nav → Import │
│ Peti Harta Config → baris │
│ "Jumlah Peti Belum Diklaim" │
│ "Lihat" → "Import Peti Harta │
│ Reward" │
│ → Pilih file cashback dari (4a)│
│ → Import │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4d) Setelah user klaim peti, │
│ **kembalikan maks Peti Harta │
│ ke nilai semula** (kalau di │
│ 4b dinaikkan) │
│ ⚠️ JANGAN dilewati! Maks yang │
│ dinaikkan hanya untuk cashback │
│ kali ini — kalau tidak dipulih │
│ kan, akan pengaruhi konfigurasi│
│ Peti Harta aktivitas lain │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (5) Posting grup + catat di shift │
│ spreadsheet │
│ · Platform yang di-cashback │
│ · Rasio 0.02 │
│ · Nama supervisor yang setuju │
│ · Maks Peti dinaikkan? (sudah │
│ dipulihkan?) │
└──────────┬─────────────────────────┘
│
▼
Siap-siap push 21:00 ⑤
Logika Bisnis¶
Pukul 8 malam, putuskan berdasarkan rasio selisih hari itu — > 10% berarti user kalah lebih banyak hari ini (penarikan jauh lebih sedikit daripada deposit). Cashback 0.02 (2%) dari platform adalah insentif retensi: berikan sedikit balik agar user terus bermain, tukar pembayaran kecil dengan aktivitas berkelanjutan dan deposit ulang.
📝 Sumber: Pembelajaran & diskusi
Catatan:
- 20:00 adalah deadline keras Waktu Indonesia, zona waktu sama dengan push Firebase — tidak perlu konversi
- Selalu posting hasil scan di grup, bahkan ketika tidak ada pelanggaran: "Scan 20:00 selesai, tidak ada isu"
- Di atas ambang ≠ otomatis cashback — tunggu persetujuan supervisor, JANGAN putuskan sendiri
- Saat beberapa platform melanggar bersamaan, kirim satu daftar konsolidasi ke supervisor (satu kali tanya, bukan banyak ping)
- Screenshot tiap pertukaran "lapor supervisor / persetujuan supervisor"
- Kalau semua platform ≤ 10%, lewati langkah cashback sepenuhnya; shift spreadsheet catat "tidak ada platform terpicu"
- Cashback lewat pintu "Import Peti Harta" yang sama dengan 3.3 — jalur sama, isi template beda saja (nominal cashback)
- ⚠️ Nominal maksimum Peti Harta mungkin perlu dinaikkan sementara: kalau ada user di template cashback yang nominalnya melebihi konfigurasi Peti saat ini, naikkan dulu sebelum import; setelah user klaim, langsung pulihkan ke nilai semula agar aktivitas selanjutnya tidak terpengaruh
- Periksa template cashback dengan mata sebelum upload (ID user / nominal / jumlah baris) untuk hindari salah kirim uang
📝 Sumber: Pembelajaran & diskusi
🤖 Peluang otomatisasi: Scan bisa dibuat skrip otomatis menarik kolom "Rasio Selisih" laporan harian semua platform, otomatis menyusun daftar di atas ambang dan @ Wakil Ketua Tim + supervisor di grup shift — Wakil Ketua Tim cukup teruskan pertanyaan. Generasi template cashback bisa pakai toolchain yang sama dengan sub-tugas 3/4 di 3.3 (tools/ sudah implementasikan penerapan formula). Aksi "naikkan lalu pulihkan" maks Peti Harta sebaiknya dibuat reminder otomatis agar langkah pulihkan tidak terlewat.
3.6 Pengelolaan Saluran Penagihan & Pencairan Pembayaran (hal pertama shift siang)¶
Prioritas: Hal pertama setelah shift siang dimulai, sebelum SMS follow-up dan pencairan komisi.
Tujuan inti: Memastikan saluran pembayaran pihak ketiga dana cukup, konfigurasi benar, tingkat keberhasilan memadai, menjamin kelancaran deposit dan penarikan pengguna.
Parameter Utama¶
| Item | Nilai |
|---|---|
| Waktu pelaksanaan | Segera setelah shift siang dimulai (10:00) + inspeksi setiap jam sepanjang hari |
| Peran merchant | Peran CP/ATM sebagai penagihan/pencairan ditentukan secara dinamis, BUKAN tetap |
| Referensi saldo | Saldo saluran ≥ 20 juta Rupiah lebih baik (di bawah ini, turunkan bobot) |
| Prinsip inti | Merchant yang banyak menagih juga banyak mencairkan ("yang masuk juga keluar") |
| Urutan saluran | Urutan penagihan = urutan pencairan (jaga konsisten — aturan inti) |
| Monitoring keberhasilan | Tim Audit memeriksa setiap jam → Umpan balik ke supervisor → Supervisor memutuskan |
Mengapa peran CP/ATM ditentukan secara dinamis?
Merchant pihak ketiga yang sama bisa menjadi penagih (menerima deposit user) DAN pencair (membayar penarikan user). Merchant mana yang lebih banyak menagih/mencairkan di satu shift tertentu TIDAK tetap — ditentukan secara dinamis berdasarkan tingkat keberhasilan dan saldo real-time.
Prinsip inti: merchant yang banyak menagih harus juga banyak mencairkan. Alasan:
- ✅ Uang yang ditagih segera disalurkan via pencairan → perputaran dana lancar
- ✅ Hindari saldo menumpuk di satu merchant (hanya menagih → saldo merchant menumpuk tak terpakai, mengikat kuota kita)
- ✅ Hindari saldo merchant cepat habis (hanya mencairkan → saldo cepat terkuras, tidak bisa menangani penarikan besar)
- ✅ Urutan penagihan dan pencairan umumnya sejajar → merchant sama di posisi yang sama di kedua sisi, keseimbangan masuk/keluar alami
Jadi setiap inspeksi memerlukan evaluasi ulang — bukan "merchant ini selamanya penagih", tetapi "siapa yang banyak menagih jam ini, juga banyak mencairkan jam ini".
📝 Sumber: Pembelajaran & diskusi
Alur Lengkap¶
Shift siang dimulai (10:00 · Hal pertama)
│
▼
==============================
Langkah Pertama: Cek Saldo Saluran
==============================
│
▼
┌─────────────────────────────────────────┐
│ (1) Cek saldo melalui perintah bot │
│ di grup Telegram masing-masing │
│ channel │
│ Periksa saldo channel CP/ATM │
│ Catat saldo terkini setiap channel │
└──────────┬──────────────────────────────┘
│
▼
Saldo >= 20 juta Rupiah?
│
┌────┴────┐
│ │
Ya Tidak
│ │
▼ ▼
┌──────────┐ ┌─────────────────────────────┐
│ Normal │ │ Tandai saluran saldo kurang │
│ → Masuk │ │ → Beritahu supervisor untuk │
│ langkah │ │ tambah dana │
│ kedua │ │ → Sementara sesuaikan bobot │
│ │ │ pencairan, hindari saluran │
│ │ │ tsb untuk pencairan │
└──────────┘ └──────────┬──────────────────┘
│
▼
==============================
Langkah Kedua: Konfigurasi Strategi Pencairan
==============================
│
▼
┌────────────────────────────────────┐
│ (2) Lihat arus penagihan tiap │
│ saluran │
│ Konfirmasi saluran mana yang │
│ banyak menerima │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (3) Sesuaikan konfigurasi pencairan│
│ Prinsip: Saluran yang banyak │
│ menerima diprioritaskan untuk │
│ pencairan │
│ Hindari satu saluran kehabisan │
│ dana │
└──────────┬─────────────────────────┘
│
▼
==============================
Langkah Ketiga: Verifikasi Urutan Saluran
==============================
│
▼
┌────────────────────────────────────┐
│ (4) Bandingkan urutan konfigurasi │
│ saluran penagihan/pencairan │
│ Kedua urutan harus pada │
│ dasarnya konsisten │
│ Jika tidak → Sesuaikan agar │
│ selaras │
└──────────┬─────────────────────────┘
│
▼
==============================
Langkah Keempat: Eksekusi Perubahan dari Supervisor (jika ada)
==============================
│
▼
┌────────────────────────────────────┐
│ (5) Periksa apakah ada perubahan │
│ saluran dari supervisor │
│ · Buka/tutup saluran tertentu │
│ · Sesuaikan bobot saluran │
│ Eksekusi sesuai instruksi │
└──────────┬─────────────────────────┘
│
▼
┌──────────────────┐
│ Selesai → Masuk │
│ SMS Follow-up / │
│ Komisi │
└──────────────────┘
─────────────────────────────────────
Monitoring Berkelanjutan (sepanjang hari)
─────────────────────────────────────
┌────────────────────────────────────┐
│ Tim Audit memeriksa tingkat │
│ keberhasilan saluran pihak ketiga │
│ setiap jam │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ Umpan balik ke supervisor │
└──────────┬─────────────────────────┘
│
▼
Anomali tingkat keberhasilan?
│
┌────┴────┐
│ │
Tidak Ya
│ │
▼ ▼
┌──────────┐ ┌─────────────────────────────┐
│ Lanjut │ │ Supervisor memutuskan apakah │
│ monitor │ │ perlu pindah saluran │
│ │ │ │ │
│ │ │ ▼ │
│ │ │ Instruksikan Wakil Ketua Tim │
│ │ │ / tim terkait untuk eksekusi │
│ │ │ │ │
│ │ │ ▼ │
│ │ │ Eksekusi buka/tutup saluran │
│ │ │ / sesuaikan bobot │
│ │ │ → Konfirmasi aktif │
│ │ │ → Lapor di grup │
└──────────┘ └─────────────────────────────┘
Catatan:
- Ini adalah tugas paling prioritas shift siang, selesaikan sebelum SMS follow-up dan pencairan komisi
- Saluran dengan saldo di bawah 20 juta Rupiah bukan berarti tidak boleh dipakai — melainkan turunkan bobotnya supaya diantrikan setelah saluran dengan saldo lebih besar untuk pencairan. Selalu prioritaskan saluran dengan saldo lebih tinggi terlebih dulu.
- Buka/tutup saluran dan penyesuaian bobot harus dilakukan sesuai instruksi supervisor, tidak boleh memutuskan sendiri
- Monitoring keberhasilan adalah tanggung jawab Tim Audit, Wakil Ketua Tim bertanggung jawab mengeksekusi pergantian
- Semua operasi perubahan saluran di-screenshot untuk arsip, dilaporkan di grup
- Pemberitahuan maintenance bank dari pihak ketiga: Penyedia pencairan pihak ketiga kadang memberitahu bahwa layanan pencairan bank ditangguhkan sementara karena maintenance sistem bank Indonesia atau gangguan jaringan. Setelah menerima pemberitahuan, nonaktifkan sementara tipe pencairan bank di saluran pencairan back-office; aktifkan kembali setelah penyedia mengonfirmasi layanan sudah pulih
📝 Sumber: Pembelajaran & diskusi
🤖 Peluang otomatisasi: Pengecekan saldo saluran dan monitoring keberhasilan bisa dibuat dashboard otomatis, setiap jam otomatis menarik data saldo dan keberhasilan tiap saluran, di bawah ambang langsung kirim peringatan ke grup, mengurangi waktu pengecekan manual satu per satu. Pengecekan konsistensi urutan saluran juga bisa di-skrip-kan—bandingkan konfigurasi penagihan/pencairan, otomatis mengingatkan jika tidak konsisten.
Sub-Tugas · Inspeksi Saldo Merchant Penagihan Setiap Jam¶
Tujuan: Memastikan saluran pencairan selalu punya saldo cukup untuk menangani penarikan pengguna, mencegah saldo habis yang menyebabkan penarikan gagal. Ini adalah tugas penjaga berulang sepanjang hari SETELAH konfigurasi awal 3.6 di awal shift.
Mengapa setiap jam?
- Saldo pencairan terpakai secara real-time (setiap penarikan user langsung mengurangi saldo), bukan statis
- Jika merchant pencairan peringkat #1 kehabisan saldo, penarikan berikutnya menumpuk di merchant tersebut → user komplain, tingkat keberhasilan anjlok
- Mengganti slot teratas ke "merchant dengan saldo lebih tinggi" mendistribusikan tekanan ke semua merchant pencairan
- Interval 1 jam adalah nilai empiris: cukup cepat untuk menangkap masalah (tidak ada merchant yang sepenuhnya kering), tidak terlalu cepat sehingga Wakil Ketua Tim tenggelam dalam pengecekan tanpa arti
Alur Inspeksi per Jam:
Setiap jam (tepat jam, atau 5 menit sebelumnya)
│
▼
┌────────────────────────────────────┐
│ (1) Query saldo pencairan di grup │
│ Telegram masing-masing │
│ merchant via perintah bot │
│ Catat saldo top-3 merchant │
└──────────┬─────────────────────────┘
│
▼
Saldo merchant pencairan peringkat #1 terlalu rendah?
│
┌────┴────┐
│ │
Tidak Ya
│ │
▼ ▼
┌──────────┐ ┌────────────────────────────────────┐
│ Jaga │ │ (2) Sesuaikan urutan saluran │
│ konfigu- │ │ penagihan/pencairan │
│ rasi, │ │ · Pindahkan merchant saldo │
│ lanjut │ │ tinggi ke depan │
│ monitor │ │ · Selaraskan urutan penagihan │
│ │ │ (jaga penagihan = pencairan) │
│ │ │ ← aturan inti │
│ │ └──────────┬─────────────────────────┘
│ │ │
│ │ ▼
│ │ ┌────────────────────────────────────┐
│ │ │ (3) Ini adalah penyesuaian │
│ │ │ SEMENTARA → setel pengingat │
│ │ │ untuk meninjau kembali │
│ │ │ · Inspeksi ulang dalam 1-2 jam │
│ │ │ · Sesuaikan kembali / biarkan │
│ │ │ · Laporan singkat di grup shift│
│ │ └──────────┬─────────────────────────┘
│ │ │
│ │ ▼
│ │ Ada penarikan besar +
│ │ saldo pencairan tidak cukup?
│ │ │
│ │ ┌────┴────┐
│ │ │ │
│ │ Tidak Ya
│ │ │ │
│ │ ▼ ▼
│ │ ┌──────────┐ ┌────────────────────────────┐
│ │ │ Lanjut di│ │ (4) BERITAHU KETUA TIM │
│ │ │ konfigu- │ │ segera untuk koordinasi│
│ │ │ rasi yang│ │ · Mungkin perlu top-up │
│ │ │ sudah │ │ darurat │
│ │ │ disesuai-│ │ · Atau aktivasi │
│ │ │ kan │ │ merchant cadangan │
│ │ │ │ │ · Atau negosiasi │
│ │ │ │ │ dana muka merchant │
│ │ │ │ │ Wakil Ketua Tim TIDAK │
│ │ │ │ │ memutuskan sendiri │
│ │ └──────────┘ └────────────────────────────┘
└──────────┘
│
▼
Catat hasil inspeksi jam ini → tunggu jam berikutnya
Poin Penting:
- Aturan inti: Urutan penagihan = urutan pencairan (konsisten dengan prinsip 3.6 — jangan dilanggar karena penyesuaian sementara)
- Penyesuaian sementara butuh aksi "kembalikan": Setiap kali sementara menurunkan/menaikkan merchant, setel pengingat (kalender HP / bot Telegram) untuk evaluasi ulang
- Penarikan besar + saldo tidak cukup = eskalasi: Wakil Ketua Tim TIDAK memutuskan sendiri — beritahu ketua tim segera. Ini menyangkut penambahan dana / negosiasi merchant, di luar wewenang Wakil Ketua Tim
- Catat inspeksi: Laporan singkat di grup shift tiap jam ("Inspeksi XX:00: ATM-A peringkat #1 saldo XX, normal") — berguna untuk serah terima dan peninjauan
- Inspeksi + konfigurasi awal shift = pipeline berkelanjutan: Konfigurasi awal 10:00 juga menjadi baseline inspeksi pertama; kemudian 11:00 / 12:00 / ... berjalan setiap jam
📝 Sumber: Pembelajaran & diskusi
🤖 Peluang otomatisasi: Inspeksi setiap jam bisa dibuat menjadi tugas terjadwal bot Telegram — otomatis query saldo tiap merchant di jam, otomatis deteksi jika peringkat #1 di bawah ambang, otomatis @Wakil Ketua Tim di grup shift dengan saran ("ganti slot atas ke merchant XX"), Wakil Ketua Tim hanya perlu konfirmasi eksekusi.
Sub-Tugas · On/Off Saluran Deposit Terbaik Jam Sibuk (Hanya User Baru)¶
Tujuan: Selama jam sibuk pasar Indonesia biaya bukan prioritas (biaya sedikit lebih tinggi tidak masalah) — aktifkan saluran yang saat ini memberikan pengalaman deposit terbaik untuk user baru, menukar biaya yang lebih tinggi dengan retensi user baru di jam sibuk.
Parameter kunci:
| Item | Nilai |
|---|---|
| Waktu buka | Sekitar Indonesia 19:00 ⚠️ Waktu pasti perlu dikonfirmasi dengan supervisor / rekan |
| Waktu tutup | Sekitar 03:00 dini hari ⚠️ Waktu pasti perlu dikonfirmasi dengan supervisor / rekan |
| Target | Hanya user baru (batasi via izin grup / visibilitas saluran — jangan biarkan user reguler dialihkan ke saluran biaya tinggi ini) |
| Pilihan saluran | Saluran dengan pengalaman deposit terbaik saat ini — saluran spesifik mengikuti konfigurasi aktual situs ini, bisa berubah seiring penyesuaian platform |
| Frekuensi | Sekali sehari (buka malam, tutup sebelum dini hari) |
Operasi:
Sebelum jam sibuk (~Indonesia 19:00 ± TBC)
│
▼
┌────────────────────────────────────┐
│ (1) Back-office → Konfigurasi │
│ saluran pay-in → cari saluran │
│ deposit terbaik yang dipakai │
│ untuk user baru jam sibuk │
│ (mengikuti konfigurasi situs) │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (2) Aktifkan saluran │
│ Izin: hanya terlihat / dapat │
│ dipakai user BARU │
│ (jangan biarkan user reguler │
│ pakai — biaya bisa membengkak)│
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (3) Lapor singkat di grup shift: │
│ "HH:MM aktif <nama saluran> │
│ (hanya user baru)" │
└──────────┬─────────────────────────┘
│
▼
Jam sibuk berjalan
(~19:00 sampai ~03:00 TBC)
│
▼
Jam sibuk berakhir (~03:00 ± TBC)
│
▼
┌────────────────────────────────────┐
│ (4) Nonaktifkan saluran jam sibuk │
│ Lapor singkat: "HH:MM │
│ <nama saluran> dinonaktifkan" │
└────────────────────────────────────┘
Catatan: - JANGAN biarkan aktif 24 jam: biaya lebih tinggi dari saluran standar — aktif sepanjang hari membuat biaya membengkak - Hanya user baru: saat mengaktifkan, periksa ulang konfigurasi izin / grup; user reguler harus tetap di saluran standar - Saluran spesifik tidak tetap: saluran mana yang saat ini "terbaik" berubah mengikuti konfigurasi platform. Saat serah terima shift wajib konfirmasi saluran apa yang sedang dipakai untuk jam sibuk; setiap platform bisa beda — jangan salin nama dari platform lain - Jendela waktu TBC: 19:00 / 03:00 di atas adalah nilai tebakan saat ini — konfirmasi waktu pasti buka/tutup dengan supervisor sebelum live, lalu update bagian ini dengan nilai yang dikonfirmasi - Tinggalkan jejak: screenshot konfigurasi sebelum/sesudah + lapor timestamp di grup shift - Jika ada anomali: jika tingkat keberhasilan saluran turun selama jam sibuk, segera sync dengan supervisor — mungkin perlu tutup sementara atau switch ke saluran cadangan
📝 Sumber: Pembelajaran & diskusi
🤖 Peluang otomatisasi: Kalau waktu buka/tutup sudah pasti, bisa dibuat tugas terjadwal bot Telegram — otomatis aktif jam 19:00 + otomatis nonaktif jam 03:00, Wakil Ketua Tim hanya menerima notifikasi. Lapisan izin ("hanya user baru") + nama saluran dinamis butuh dukungan back-office untuk "buka saluran tertentu berdasarkan grup user".
Empat, Alur Kerja Tugas Responsif (Jalur B · Ditangani Segera)¶
Karakteristik Jalur B: Tidak ada waktu tetap, dipicu oleh pesan dari grup CS, grup kontrol risiko, Grup Keuangan. Ditangani segera begitu diterima, mengikuti kerangka umum empat langkah "Klaim → Eksekusi → Balas → Lapor".
4.1 Audit Pesanan Penarikan (risiko tertinggi, keputusan paling kompleks)¶
Audit penarikan adalah tugas dengan risiko tertinggi dan cabang keputusan paling banyak dalam pekerjaan harian Wakil Ketua Tim. Satu kesalahan penilaian bisa mengakibatkan kerugian uang nyata, atau meloloskan pengguna penipu.
4.1.1 Langkah Awal Umum¶
Menerima notifikasi pesanan penarikan
│
▼
┌───────────────────────────────┐
│ Tindakan pertama: 【Kunci │ ← Cegah rekan lain memproses
│ pesanan】 │ berulang
│ (Klik tombol "Kunci" │
│ di back-office) │
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────┐
│ Baca field 【Catatan】pesanan │
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────────────┐
│ Tentukan jenis pesanan │
│ ├─ Catatan berisi "penarikan agen" │
│ │ → Agen │ → Ikuti 4.1.5 Alur penarikan agen
│ └─ Lainnya → Pengguna biasa │ → Ikuti 4.1.4 Alur pengguna biasa
└───────────────────────────────────────┘
4.1.2 Empat Lapisan Saklar Pencairan Otomatis (Pengetahuan Prasyarat)¶
Sistem memiliki empat lapisan saklar, semuanya harus aktif agar bisa pencairan otomatis, jika satu lapisan saja tidak lolos maka masuk audit manual:
┌─────────────────────────────────────────────┐
│ Empat Lapisan Saklar Pencairan │
│ Otomatis │
│ │
│ Lapisan 1: Saklar utama situs ON │
│ │ │
│ ▼ │
│ Lapisan 2: Saluran pencairan pihak │
│ ketiga tsb ON │
│ │ │
│ ▼ │
│ Lapisan 3: Level member mengizinkan │
│ otomatis │
│ │ │
│ ▼ │
│ Lapisan 4: Saklar personal member ON │
│ │ │
│ ▼ │
│ Semua lolos → Pencairan otomatis │
│ │
│ Satu lapisan tidak lolos → Masuk audit │
│ manual │
└─────────────────────────────────────────────┘
Situasi yang dipaksa masuk manual (terlepas dari empat lapisan saklar): Melebihi batas pencairan otomatis, volume taruhan deposit pertama tidak cukup, mengandung bonus agen, interval penarikan terlalu pendek.
📘 Sumber: 01-自动出款功能详解
4.1.3 Panduan Penanganan Catatan Pesanan Penarikan (8 Aturan)¶
Tabel Ringkasan Catatan¶
| # | Isi Catatan | Ringkasan Tindakan | Alur Detail |
|---|---|---|---|
| 1 | Penarikan agen | Deteksi pola perilaku bawahan + audit catatan taruhan | Ikuti 4.1.5 Alur audit penarikan agen |
| 2 | Level pengguna tidak mengizinkan pencairan otomatis | User level Observasi Arbitrase / Konfirmasi Arbitrase; fokus jenis bonus + pola taruhan + kelipatan, alur pemeriksaan lengkap. Juga level Verifikasi Sekunder / Data; verifikasi akun WD lama vs baru | Lihat detail Catatan 2 di bawah |
| 3 | Pencairan otomatis gagal | Cek status pesanan sebenarnya, tangani sesuai status | Lihat detail Catatan 3 + tabel status pesanan |
| 4 | Melebihi batas maksimal pencairan otomatis | Ambang back-office = 5000; dialihkan ke audit manual (kecurangan game / abuse bonus / cek keaslian user) | Lihat detail Catatan 4 |
| 5 | 4 kali penarikan dalam 2 menit | Peringatan pertama berdasarkan saldo; jika arbitrase bug game → tutup darurat pencairan otomatis | Lihat detail Catatan 5 |
| 6 | Volume taruhan deposit pertama tidak cukup | Aturan saat ini DINONAKTIFKAN, langsung lolos audit | Lihat detail Catatan 6 |
| 7 | Batas nominal saluran pencairan | Biasanya "tidak ada saluran tersedia" — semua merchant gagal diputar; konfirmasi ke merchant apakah maintenance/fluktuasi atau tidak support, lalu arahkan member ganti wallet atau tangani sesuai feedback merchant | Lihat detail Catatan 7 |
| 8 | Pencairan gagal | Pencairan manual juga memicu; cek status + konfirmasi pihak ketiga (mirip Catatan 3) | Lihat detail Catatan 8 |
📝 Sumber: Pembelajaran & diskusi
Catatan 1: Penarikan Agen¶
Pemicu: User telah mengklaim salah satu dari bonus undangan / bonus Pinduoduo / bonus Peti Harta, dan penarikan pertama setelah klaim akan otomatis ditandai "Penarikan Agen".
Tujuan audit: Memutuskan apakah agen ini agen asli (bawahan nyata + game normal) atau agen arbitrase (akun boneka farming bonus).
Cara penanganan: Ikuti 4.1.5 alur audit penarikan agen (deteksi pola perilaku bawahan + hukuman P1/P2).
📝 Sumber: Pembelajaran & diskusi
Catatan 2: Level Pengguna Tidak Mengizinkan Pencairan Otomatis¶
Pemicu: Level user saat ini dikonfigurasi di back-office sebagai "tidak izinkan pencairan otomatis" — level tipikal termasuk: - "Level Observasi Arbitrase" (sebelumnya dicurigai arbitrase) atau "Konfirmasi Arbitrase" (sudah dinilai arbitrase) - "Verifikasi Sekunder / Data" (verifikasi keamanan reset kata sandi, lihat 5.2.3)
Fokus audit (berbeda sesuai jenis level):
Level Observasi Arbitrase: - Jenis bonus yang diklaim user (undangan / Pinduoduo / Peti Harta / lainnya) - Pola taruhan (fokus ke permainan risiko rendah / cashback tinggi?) - Kelipatan taruhan (baru pas mencapai turnover langsung tarik?)
Level Verifikasi Sekunder / Data: - Cek catatan — apakah tertulis "WD perlu konfirmasi sekunder, apakah data penarikan lama" - Verifikasi akun penarikan — apakah akun WD lama atau akun WD baru? - Akun lama → Hapus catatan + cairkan + keluarkan dari level - Akun baru → Tolak + tutup penarikan + minta verifikasi rekaman layar (lihat 5.2.3)
Menerima pesanan Catatan 2
│
▼
Periksa sesuai 4 standar 4.1.5
│
▼
Pemeriksaan riwayat akun
│
├─ Filter catatan deposit, lihat distribusi nominal dan waktu
│
▼
Pemeriksaan catatan taruhan
│
├─ Lihat apakah taruhan normal (interval waktu, nominal, jenis permainan)
│
▼
Penilaian komprehensif
│
├─ Member normal → Lolos audit, cairkan
└─ Ada perilaku arbitrase/anomali → Tangani sesuai hasil pemeriksaan
(tolak/laporkan/bekukan)
📝 Sumber: Pembelajaran & diskusi
Catatan 3: Pencairan Otomatis Gagal¶
Menerima pesanan Catatan 3
│
▼
Ambil nomor pesanan, cek status pesanan sebenarnya
│
▼
Berdasarkan status yang dikembalikan, lihat【Tabel Status Pesanan Sebenarnya】
│
├─ 1. Akun tidak valid/format salah → ⚠️ Jalankan Cek Pintar Error Akun
│ dulu (lihat di bawah), JANGAN
│ langsung tandai tidak valid
├─ 2. Status akun anomali → Konfirmasi dengan pihak ketiga
│ dulu, tangani sesuai situasi
├─ 3. Diblokir risk control → Konfirmasi: masalah akun user
│ → tandai tidak valid;
│ masalah channel → tangani
│ sesuai situasi
├─ 4. Melebihi limit → Konfirmasi: bukan masalah user
│ → tolak untuk submit ulang;
│ limit akun user → ikuti Alur
│ Optimasi Limit (lihat di bawah)
├─ 5/6/8/9. Kegagalan sistem/jaringan → ⚠️ Cek riwayat dulu (lihat Mekanisme Anti-Loop Penolakan di bawah)
├─ 7. Verifikasi info akun gagal → Konfirmasi: masalah akun user
│ → proses akun tidak valid;
│ lainnya → tangani sesuai
│ situasi
└─ 10. Limit transaksi → Ikuti Alur Optimasi Limit
(lihat di bawah); lainnya →
tangani sesuai situasi
⚠️ Mekanisme Anti-Loop Penolakan (berlaku untuk status 5/6/8/9 — kegagalan sistem/jaringan)
Masalah: Alasan kegagalan dari API cek pesanan pihak ketiga tidak selalu akurat, dan penjelasan dari CS pihak ketiga juga belum tentu mencerminkan status sebenarnya. Jika terus-menerus menolak dan minta user submit ulang, user bisa terjebak dalam loop "tarik → gagal → tolak → submit ulang → gagal lagi", sangat merusak pengalaman pengguna.
Prosedur: Sebelum menolak, cek riwayat penarikan user pada hari itu:
Akan menolak (kegagalan sistem/jaringan) │ ▼ Cek catatan penarikan: apakah user ini punya pesanan lain yang ditolak hari ini? │ ┌───┴───┐ │ │ Tidak Ya (pertama) (kegagalan berulang) │ │ ▼ ▼ Tolak Cek: apakah penarikan berulang menggunakan wallet/rekening bank yang sama? normal, │ minta ┌───┴───┐ submit │ │ ulang Akun Akun yang sama ditolak berkali-kali berbeda │ │ ▼ ▼ Konfirmasi ke staf pihak ketiga masalah spesifiknya: Tolak · Apakah info akun user salah? normal, · Apakah limit akun? minta · Apakah gangguan sementara saluran? submit · Atau penyebab lain? ulang │ ▼ Tangani sesuai penyebab yang dikonfirmasi: · Masalah akun → tutup hak penarikan + notifikasi CS, minta user hubungi CS untuk ganti wallet/bank · Masalah saluran → ganti saluran, pencairan manual · Tidak bisa dikonfirmasi → tangguhkan hak penarikan + notifikasi CS, minta user ganti metode penarikanPrinsip inti: User yang sama, akun yang sama, ditolak 2 kali atau lebih dalam satu hari → tidak boleh langsung tolak lagi; harus investigasi penyebab sebelum bertindak.
⚠️ Cek Pintar Error Akun (untuk status 1/3/7 — "akun tidak valid / error akun / info tidak cocok")
Masalah: Pihak ketiga mengembalikan "error info penerima" tidak selalu berarti akun user benar-benar salah — terutama saat kegagalan massal di banyak platform, kemungkinan besar fluktuasi saluran.
Alur:
Pihak ketiga mengembalikan "akun tidak valid / error akun / info tidak cocok" │ ▼ Apakah user pernah berhasil tarik ke akun ini sebelumnya? │ ┌───┴───────────────────────┐ │ │ Ya (ada riwayat berhasil) Tidak (pertama kali pakai akun ini) │ │ ▼ ▼ Kemungkinan besar Masuk ke halaman detail user fluktuasi saluran Cek info wallet/kartu bank yang terikat (sebelumnya bisa, sekarang │ error = kemungkinan kecil ▼ masalah akun, bisa jadi Metode penarikan apa? maintenance antar bank / │ fluktuasi API pihak ketiga / ┌──┴──────────┐ limit kartu bank dll) │ │ → Tolak untuk submit ulang Dompet Kartu bank │ │ ▼ ▼ No. HP vs Info kartu bank akun cocok? wajar? │ (jumlah digit/ ┌───┴───┐ format normal?) │ │ │ Berbeda Sama persis ┌───┴───┐ 1-2 atau sama │ │ digit sekali Format Format (kemung- berbeda tidak normal kinan │ normal │ typo) ▼ │ ▼ │ Kemungkinan ▼ Kemungkinan ▼ fluktuasi Masuk fluktuasi Masuk saluran alur saluran alur → Tolak akun → Tolak akun untuk tidak untuk tidak submit valid submit valid ulang ulangSinyal bantu: - Kegagalan massal di banyak platform bersamaan = hampir pasti fluktuasi saluran - User penarikan pertama kali = cek info binding dengan teliti, jangan langsung tandai tidak valid (memengaruhi retensi) - Akun sama pernah berhasil sebelumnya = hampir pasti fluktuasi saluran (maintenance antar bank / fluktuasi API pihak ketiga / limit kartu bank dll), bukan error info akun - Penarikan kartu bank mengembalikan "error info akun" → alasan error dari pihak ketiga sering tidak akurat; penyebab sebenarnya bisa maintenance transaksi antar bank, limit kartu bank, atau gangguan saluran sementara — jangan langsung proses berdasarkan pesan "error info akun" - Prinsip inti: Jangan langsung bertindak berdasarkan alasan error pihak ketiga; lihat akun user dan riwayat pencairan sebelumnya untuk membuat penilaian komprehensif, meminimalkan hambatan penarikan bagi user
⚠️ Alur Optimasi Limit: Bank dan dompet yang berbeda memiliki limit harian/bulanan yang berbeda, dan apakah user sudah menyelesaikan KYC juga memengaruhi limit. Saat menangani masalah limit, cek dulu berapa metode penarikan yang terikat ke akun user sebelum menentukan pendekatan:
Dikonfirmasi sebagai masalah limit │ ▼ Cek jumlah metode penarikan yang terikat ke akun user │ ┌───┴───┐ │ │ Beberapa Hanya satu (≥2 kartu bank/ kartu dompet bank/ dompet) │ │ ▼ ▼ JANGAN Ikuti alur asli: tutup Tutup hak hak penarikan penarikan + Tambah catatan Langsung tanggal limit tolak (misal DANA LIMIT 4/25) pesanan + Tolak pesanan dengan + Notifikasi grup CS catatan: Minta user hubungi CS "Limit XX saat ini tercapai, silakan ganti ke metode lain"Logika inti: User yang terikat beberapa metode penarikan biasanya paham soal limit — cukup beritahu untuk ganti metode lain dan submit ulang, tidak perlu tutup hak, tidak perlu hubungi CS, tidak perlu tunggu kita buka lagi — menghilangkan 3 langkah, meningkatkan pengalaman pengguna. Hanya user dengan satu metode penarikan yang perlu alur lengkap tutup hak + hubungi CS.
⚠️ Bank yang tidak didukung sistem pencairan: Bank-bank berikut tidak didukung oleh sistem pencairan. Sistem akan langsung menampilkan "pencairan otomatis gagal" (tanpa menyebutkan pihak ketiga): - BANK JAGO SYARIAH - BANK JAGO UUS - BANK ALADIN SYARIAH - SUPERBANK - BANK MANDIRI TASPEN
📝 Sumber: Pembelajaran & diskusi
Tabel Penanganan Status Order (digunakan setelah cek status pesanan Catatan 3):
| # | Status | Penyebab | Operasi Backend | Prinsip Utama |
|---|---|---|---|---|
| 1 | Akun tidak valid / Format salah | Akun tidak ada / format salah / tidak cocok dengan saluran | ⚠️ Jalankan Cek Pintar Error Akun dulu: pernah berhasil → fluktuasi saluran, tolak untuk submit ulang; pertama kali → cek info binding; dikonfirmasi masalah user → tandai tidak valid + tolak | Penilaian pintar |
| 2 | Status akun penerima anomali | Akun dibekukan / tidak aktif / ditutup | Konfirmasi dengan pihak ketiga dulu, tangani sesuai situasi | Perlu konfirmasi dulu |
| 3 | Diblokir risk control | Akun diblokir sistem kontrol risiko | Konfirmasi: masalah akun user → tandai tidak valid; masalah channel → tangani sesuai situasi | Perlu konfirmasi dulu |
| 4 | Melebihi limit | Melebihi limit bank atau akun | Konfirmasi: bukan masalah user → tolak untuk submit ulang; limit akun user → ikuti Alur Optimasi Limit (beberapa metode penarikan → tolak dengan catatan ganti metode; satu metode penarikan → tutup hak + notifikasi CS) | Optimasi limit |
| 5 | Sistem sibuk / Timeout | Kepadatan atau fluktuasi pemrosesan sistem / bisa juga masalah akun/wallet penarikan user | ⚠️ Jalankan cek anti-loop penolakan dulu (cek riwayat hari ini); pertama kali → tolak untuk submit ulang; akun sama gagal berulang → konfirmasi penyebab sebenarnya ke pihak ketiga | Anti-loop penolakan |
| 6 | Request gagal / Transaksi gagal | — | ⚠️ Jalankan cek anti-loop penolakan dulu; pertama kali → tolak untuk submit ulang; gagal berulang → investigasi penyebab | Anti-loop penolakan |
| 7 | Verifikasi info akun gagal | Info akun tidak sesuai aturan verifikasi bank/e-wallet | Konfirmasi: masalah akun user → proses akun tidak valid; lainnya → tangani sesuai situasi | Perlu konfirmasi dulu |
| 8 | Error jaringan | Fluktuasi jaringan | ⚠️ Jalankan cek anti-loop penolakan dulu; pertama kali → tolak untuk submit ulang; gagal berulang → investigasi penyebab | Anti-loop penolakan |
| 9 | Request terlalu sering | — | ⚠️ Jalankan cek anti-loop penolakan dulu; pertama kali → tolak untuk submit ulang; gagal berulang → investigasi penyebab | Anti-loop penolakan |
| 10 | Limit transaksi | Nominal transaksi melebihi batas | Ikuti Alur Optimasi Limit: beberapa metode penarikan → tolak dengan catatan ganti metode; satu metode penarikan → tutup hak penarikan + tambah catatan tanggal limit + notifikasi CS; lainnya → tangani sesuai situasi | Optimasi limit |
Prinsip utama penanganan: - Status 1 (akun tidak valid): ⚠️ JANGAN langsung tandai tidak valid — jalankan Cek Pintar Error Akun dulu (akun sama pernah berhasil → fluktuasi saluran; pertama kali → cek info binding) - Status 5/6/8/9 (masalah sistem/jaringan): Pertama kali → tolak untuk submit ulang; akun sama gagal berulang di hari yang sama → harus investigasi penyebab sebelum bertindak (lihat Mekanisme Anti-Loop Penolakan) - Status 2/3/4/7/10 (perlu konfirmasi): Harus konfirmasi dulu dengan channel pihak ketiga
⚠️ Alasan kegagalan dari API cek pesanan pihak ketiga tidak selalu akurat, respons CS pihak ketiga juga belum tentu mencerminkan status sebenarnya. Saat menghadapi kegagalan berulang, jangan percaya begitu saja nilai return API — gunakan penilaian komprehensif.
📝 Sumber: Pembelajaran & diskusi
Notifikasi ke Grup CS Setelah Penolakan (saat meminta user submit ulang)¶
Logika dasar: Saat kita menolak pesanan penarikan dan meminta user submit ulang, kita harus mem-posting penolakan ke grup CS. Dengan begitu, ketika CS kemudian menerima pertanyaan dari user dan mencari user ID tersebut, mereka langsung tahu kenapa ditolak dan bisa merespons secara efisien dan akurat, tanpa perlu kembali ke Wakil Supervisor untuk konfirmasi ulang.
Skenario yang berlaku (penolakan apa pun yang meminta user submit ulang harus di-post): - Status 4 nominal melebihi limit → tolak dan biarkan user submit ulang - Status 5/6/8/9 kegagalan sistem/jaringan pertama kali → tolak dan biarkan user submit ulang - Status 10 limit transaksi (multi metode penarikan) → tolak dan ganti metode - Fluktuasi channel dikonfirmasi bukan dari sisi user → tolak dan biarkan user submit ulang
Format pesan grup standar:
Platform: [nama platform]
User ID: [akun member]
Alasan penolakan: [penjelasan singkat, dengan "mohon user submit ulang pesanan penarikan"]
Contoh:
Platform: 7777W
User ID: 6281234567890
Alasan penolakan: Nominal melebihi limit (pihak ketiga konfirmasi bukan masalah akun user), mohon submit ulang pesanan penarikan
Platform: RP55
User ID: 6289876543210
Alasan penolakan: Fluktuasi jaringan menyebabkan kegagalan pencairan (pertama kali), mohon submit ulang pesanan penarikan
⚠️ Kasus yang TIDAK perlu diposting ke grup CS: Berikut adalah penolakan final (tidak meminta user submit ulang) — tangani sesuai alur catatan yang ada, tidak perlu di-post ke grup CS: - Akun tidak valid (Status 1, dikonfirmasi masalah sisi user) → tutup hak akses dan jalankan alur error akun - Pelanggaran arbitrase (BH BAT / BH RK) → jalankan alur catatan P1/P2, posting ke grup audit yang sesuai - Metode penarikan tunggal dengan limit akun (Status 10 metode tunggal) → tutup hak akses + notifikasi CS untuk alur optimasi limit
📌 Tindakan padanan dari sisi CS: Setelah CS menerima notifikasi penolakan, mereka mengarsipkannya ke daftar follow-up. Saat user datang menanyakan "kenapa penarikan saya gagal/ditolak", CS langsung membalas sesuai alasan penolakan: "mohon submit ulang pesanan penarikan". Jika kasus tidak jelas, @ Wakil Supervisor untuk konfirmasi.
📝 Sumber: Pembelajaran & diskusi
Catatan 4: Melebihi Batas Maksimal Pencairan Otomatis¶
Pemicu: Back-office saat ini menetapkan nominal maksimum pencairan otomatis = 5000; apa pun di atas ini otomatis dialihkan ke audit manual.
Tujuan audit: Dialihkan ke audit manual untuk mengecek apakah perilaku user mencakup kecurangan game / abuse bonus / apakah perilaku user asli.
Menerima pesanan Catatan 4
│
▼
Pemeriksaan riwayat dana akun
│
├─ Filter catatan deposit: lihat distribusi nominal dan waktu hari ini
│ (Apakah ada deposit besar dalam waktu singkat? Nominal anomali?)
│
▼
Pemeriksaan catatan taruhan
│
├─ Lihat interval waktu antar taruhan
│ (Apakah taruhan padat seperti bot?)
│
▼
Pemeriksaan laba-rugi platform
│
├─ Filter catatan kerugian, lihat nominal taruhan dan kemenangan
│ Apakah dalam rentang normal?
│ │
│ ├─ Tidak yakin → Cek aturan permainan di frontend/App,
│ │ bandingkan probabilitas kemenangan dan
│ │ odds apakah wajar
│ │
│ └─ Jelas anomali → Tangani sesuai hasil pemeriksaan
│
▼
Penilaian komprehensif
│
├─ Konfirmasi pengguna normal → Lolos audit, cairkan manual
└─ Ada perilaku anomali → Tangani sesuai hasil pemeriksaan
(tolak/laporkan/bekukan)
📝 Sumber: Pembelajaran & diskusi
Catatan 5: 4 Kali Penarikan dalam 2 Menit¶
Dua alasan bisnis (pahami dulu sebelum tahu kenapa harus diblok):
- Kurangi biaya transaksi: Memecah satu penarikan menjadi beberapa yang kecil menghasilkan beberapa biaya — beritahu user tarik sekaligus (hemat biaya buat platform maupun user)
- Blok arbitrase bug game: Saat game ada bug (misal "kalah tidak potong modal" yang membuat user untung tak terbatas), penarikan besar sekali akan memicu audit manual dan diblok — user lalu coba penarikan kecil berkali-kali untuk bypass blokir penarikan besar. Mekanisme ini justru menangkap pola nominal-kecil-frekuensi-tinggi itu
⚠️ Kalau teridentifikasi sebagai arbitrase bug game: mekanisme ini juga bisa menangkapnya dan menutup darurat pencairan otomatis.
Menerima pesanan Catatan 5
│
▼
Apakah pertama kali memicu peringatan penarikan frekuensi tinggi?
│
├─ Bukan (pelanggaran ulang) → Eskalasi penanganan sesuai situasi
│
└─ Ya (pertama kali)
│
▼
Cek saldo akun penarikan terakhir pengguna
│
├─ Ada saldo → Tolak penarikan ini
│ Catatan: "Silakan tarik seluruh saldo sekaligus"
│
└─ Tidak ada saldo → Langsung loloskan penarikan, cairkan
(Jika teridentifikasi arbitrase bug → mekanisme ini juga bisa
menangkap dan menutup darurat pencairan otomatis)
📝 Sumber: Pembelajaran & diskusi
Catatan 6: Volume Taruhan Deposit Pertama Tidak Cukup¶
Pemicu: Back-office awalnya menetapkan "turnover penarikan pertama di bawah 1.5x" otomatis dialihkan ke audit manual.
Alasan bisnis awal: User yang farming bonus di deposit pertama lalu tarik dengan turnover rendah butuh dilihat manusia.
Status saat ini: aturan ini sudah DINONAKTIFKAN. Alasan: banyak user baru deposit lalu melakukan penarikan kecil uji coba untuk menguji reliabilitas situs (bisa nggak sih saya tarik?) — memblok ini akan membunuh pengalaman deposit pertama dan membuat user baru churn.
Cara penanganan saat ini: Langsung lolos audit, izinkan penarikan.
Aturan umum: di kasus lain, member yang belum mencapai turnover sama sekali tidak bisa menarik dana (front-end memblok langsung), jadi tidak perlu pertimbangan Wakil Ketua Tim. Catatan 6 ini fallback warisan platform lama; platform baru jarang memicunya.
📝 Sumber: Pembelajaran & diskusi
Catatan 7: Batas Nominal Saluran Pencairan¶
Penyebab: Catatan ini biasanya muncul karena tidak ada saluran yang tersedia — sistem memutar semua merchant secara otomatis; jika ada saluran (misal DANA) sedang maintenance atau fluktuasi, kemungkinan besar semua merchant gagal diputar, lalu sistem mengkategorikan pesanan sebagai "batas nominal saluran pencairan". Catatan: Dukungan merchant terhadap wallet yang sama bisa berbeda — misalnya DANA, ada merchant yang punya konfigurasi internal, ada yang tidak.
Cara penanganan: 1. Konfirmasi ke merchant: saluran sedang maintenance / fluktuasi, atau tidak support sama sekali? 2. Bertindak sesuai feedback merchant: - Maintenance / fluktuasi sementara → minta member tunggu, atau ganti ke wallet lain - Merchant tidak support saluran itu → arahkan member pakai wallet / kartu bank lain - Merchant melaporkan anomali → tangani sesuai feedback spesifik mereka
📝 Sumber: Pembelajaran & diskusi
Catatan 8: Pencairan Gagal¶
Pemicu: Saat Wakil Ketua Tim manual menggunakan saluran pencairan untuk cairkan penarikan dan pencairan gagal, sistem otomatis menandai "Pencairan Gagal".
Penyebab kegagalan umum (mirip dengan Catatan 3 "Pencairan Otomatis Gagal"): - Fluktuasi API merchant - Info wallet user salah - Limit, dll
Cara penanganan:
Tetap perlu menanyakan feedback pesanan ke merchant terkait, lalu tangani sesuai feedback.
📝 Sumber: Pembelajaran & diskusi
Tabel Referensi Cepat Aturan Ketat Nominal/Durasi:
| Aturan Ketat | Nilai | Skenario Penerapan |
|---|---|---|
| Limit bulanan e-wallet (Dana/Ovo/Linkaja/Gopay/ShopeePay) | Perlu konfirmasi ke saluran pihak ketiga (bukan nilai tetap) | Catatan 3 |
| Batas per transaksi saluran pencairan | Perlu konfirmasi ke saluran pihak ketiga (bukan nilai tetap) | Catatan 7 |
| Nominal maksimum pencairan otomatis | 5000 (satuan sesuai konfigurasi back-office) | Catatan 4 |
| Ambang penarikan frekuensi tinggi | 4 kali dalam 2 menit | Catatan 5 |
| Penarikan frekuensi tinggi pelanggaran pertama (ada saldo) | Tolak, minta tarik sekaligus | Catatan 5 |
| Penarikan frekuensi tinggi pelanggaran pertama (tanpa saldo) | Langsung lolos, cairkan | Catatan 5 |
| Ambang turnover penarikan pertama kurang (OFF) | 1.5x turnover ke manual (saat ini dinonaktifkan) | Catatan 6 |
📝 Sumber: Pembelajaran & diskusi
🤖 Peluang otomatisasi: Dari 8 aturan catatan, Catatan 6 (langsung lolos) bisa diproses otomatis oleh skrip. Catatan 2 dan Catatan 4 memerlukan alur pemeriksaan lengkap, cocok untuk semi-otomatisasi (bot otomatis menarik data riwayat akun/taruhan, manusia membuat keputusan akhir). Desain lengkap mesin aturan lihat 12-自动化路线图/.
4.1.4 Pohon Keputusan Penarikan Pengguna Biasa¶
Penarikan pengguna biasa (catatan bukan "penarikan agen")
│
▼
Baca field 【Catatan】pesanan
│
├─ Catatan 2: "Level pengguna tidak mengizinkan pencairan otomatis"
│ │
│ ▼
│ Alur pemeriksaan lengkap
│ │
│ ├─ 1. Periksa sesuai standar 4.1.5
│ ├─ 2. Riwayat akun: Distribusi nominal dan waktu deposit normal?
│ └─ 3. Catatan taruhan: Apakah perilaku taruhan normal?
│ │
│ ├─ Normal → Lolos audit, cairkan
│ └─ Anomali → Tangani sesuai hasil pemeriksaan
│
├─ Catatan 3: "Pencairan otomatis gagal"
│ │
│ ▼
│ Cek status pesanan sebenarnya (dengan nomor pesanan)
│ │
│ └─ Cocokkan dengan【Tabel Status Pesanan Sebenarnya】
│ ├─ Masalah akun/format → Verifikasi atau coba ulang
│ ├─ Akun beku/ditutup → Ganti akun atau hubungi pengguna
│ ├─ Kontrol risiko → Ganti akun/turunkan frekuensi/nominal
│ ├─ Melebihi limit → Pecah/ganti akun/KYC
│ ├─ Masalah sistem/jaringan → Coba ulang setelah jeda
│ └─ Transaksi gagal → Coba ulang atau ganti metode
│
├─ Catatan 4: "Melebihi batas maksimal pencairan otomatis"
│ │
│ ▼
│ Alur pemeriksaan lengkap (lebih ketat dari Catatan 2)
│ │
│ ├─ 1. Riwayat dana: Distribusi nominal dan waktu deposit hari ini
│ ├─ 2. Catatan taruhan: Interval waktu antar taruhan normal?
│ └─ 3. Laba-rugi platform: Nominal taruhan/kemenangan normal?
│ │
│ ├─ Konfirmasi normal → Lolos audit, cairkan manual
│ └─ Ada anomali → Tangani sesuai hasil pemeriksaan
│
├─ Catatan 5: "4 kali penarikan dalam 2 menit"
│ │
│ ▼
│ Apakah pertama kali?
│ │
│ ├─ Pertama → Cek saldo akun penarikan terakhir
│ │ │
│ │ ├─ Ada saldo → Tolak, catatan "tarik sekaligus"
│ │ └─ Tanpa saldo → Langsung lolos, cairkan
│ │
│ └─ Ulangan → Eskalasi penanganan sesuai situasi
│
├─ Catatan 6: "Volume taruhan deposit pertama tidak cukup"
│ └─ Langsung lolos audit, izinkan penarikan
│
├─ Catatan 7: "Batas nominal saluran pencairan"
│ └─ Biasanya terjadi karena "tidak ada saluran tersedia" —
│ sistem memutar semua merchant dan semuanya gagal (misal
│ DANA sedang maintenance/fluktuasi). Konfirmasi ke
│ merchant: maintenance/fluktuasi atau tidak support?
│ Maintenance → member tunggu atau ganti wallet.
│ Tidak support → arahkan pakai wallet/kartu bank lain.
│
├─ Catatan 8: "Pencairan gagal"
│ └─ Cek status pesanan dulu, lalu konfirmasi penyebab
│ gagal spesifik ke pihak ketiga, dan tangani sesuai
│ penyebab.
│
└─ Catatan lainnya → Rujuk panduan catatan, eskalasi jika perlu
Prinsip Utama: 1. Catatan 2 dan Catatan 4 tidak boleh langsung diloloskan—harus melalui alur pemeriksaan lengkap (riwayat akun + taruhan), konfirmasi pengguna normal baru diizinkan. 2. Catatan 3 cek status sebenarnya dulu—jangan menebak penyebab dari catatan, cek status pesanan sebenarnya dengan nomor pesanan baru tangani sesuai masalah. 3. Catatan 8 langsung tolak—back-office sudah mencoba semua saluran, ganti saluran pun tidak berguna, minta pengguna kirim ulang. Tapi tetap perhatikan anti-loop penolakan—jika user dan akun yang sama sudah ditolak 2 kali atau lebih di hari yang sama, harus investigasi penyebabnya. 4. Aturan limit tidak ada angka tetap—limit e-wallet, batas saluran pencairan semua harus dikonfirmasi ke saluran pihak ketiga terkait. Saat menangani limit, ikuti Alur Optimasi Limit: beberapa metode penarikan → tolak dengan catatan ganti metode; satu metode penarikan → tutup hak + notifikasi CS.
📝 Sumber: Pembelajaran & diskusi
4.1.5 Alur Audit Penarikan Agen¶
Asal catatan "Penarikan Agen": Begitu user mengklaim bonus undangan atau bonus Pinduoduo, penarikan pertama setelah klaim akan otomatis ditandai dengan catatan "Penarikan Agen", memaksa audit manual.
Perilaku Agen yang sah (diizinkan): User yang klaim bonus undangan biasanya memang Agen (punya bawahan); Agen boleh tidak deposit, tidak taruhan sama sekali, hanya mengembangkan user bawahan, menerima komisi dari deposit dan taruhan bawahan, lalu langsung menarik bonus. Syaratnya: bawahan harus merupakan user independen yang asli.
Hakikat arbitrase: Agen mendaftarkan sekumpulan akun boneka sendiri sebagai bawahan, lalu memakai boneka-boneka itu untuk deposit & taruhan demi memancing komisi ke akun utama, kemudian menariknya. Penilaian arbitrase bukan dilihat dari apakah Agen sendiri bermain atau tidak — melainkan dari apakah bawahannya adalah user independen yang asli.
Masa simpan data riwayat akun: Riwayat perubahan akun hanya disimpan 60 hari terakhir; catatan lebih dari 3 bulan tidak bisa di-query lagi. Untuk user yang tanggal klaim bonusnya sudah lama, data awal mungkin tidak tersedia saat pemeriksaan — kerjakan dengan data yang tersedia di rentang yang bisa di-query.
Empat Standar Audit Arbitrase (versi 2026-04)¶
Prinsip audit keseluruhan: Member yang bukan pelaku curang Peti Harta, usahakan dipertahankan. Berdasarkan kualitas atasan, aktivitas bawahan, tentukan secara fleksibel apakah potong/tidak potong, masukkan ke/keluarkan dari tingkat Observasi Arbitrase. Lebih baik salah lepas, jangan salah bunuh — usahakan pertahankan member.
📝 Sumber: Pembelajaran & diskusi
Standar Pertama · Deteksi Pola P2 (Kriteria Utama)
Periksa pola perilaku user bawahan Agen:
| Item Deteksi | Kondisi |
|---|---|
| Jumlah deposit bawahan | 50–60 (unit back-office (K IDR)) |
| Turnover bawahan | Sekitar 600 (unit back-office, pas cukup untuk klaim Peti Harta) |
| Proporsi bawahan yang memenuhi pola di atas | ≥70% |
Ketiga item terpenuhi bersamaan → dinyatakan memicu arbitrase P2.
Penanganan khusus Agen kecil: Bawahan ≤3 orang, jika hanya mengklaim satu bonus undangan, bisa dipertimbangkan untuk diloloskan — biarkan sedikit untung agar punya motivasi mengembangkan bawahan.
📝 Sumber: Pembelajaran & diskusi
Standar Kedua · Syarat Mempertahankan Member Normal (tidak potong, tidak masukkan ke tingkat)
Prasyarat: Tidak memicu Standar Pertama.
| Syarat Pertahankan | Penjelasan |
|---|---|
| Minimal satu bawahan | Deposit besar, turnover besar, aktif baru-baru ini (ada deposit dalam 3~5 hari terakhir) ❓ Angka pasti "besar" menunggu penjabaran dari atasan |
| Dan tidak memicu Standar Pertama | Secara keseluruhan tidak memenuhi pola "deposit 50-60 + turnover 600 + ≥70%" |
Memenuhi syarat → tidak masukkan ke tingkat Observasi Arbitrase, berhak menikmati semua promo, hapus catatan P2 yang ada, beri catatan ulang "tidak potong, tanggal+penanggung jawab" (contoh: tidak potong, bisa keluar 4.21 AA).
📝 Sumber: Pembelajaran & diskusi
Standar Ketiga · Keluarkan dari tingkat Observasi Arbitrase (Pulihkan Normal)
Berlaku untuk: pelanggan lama (pernah dimasukkan ke tingkat Observasi Arbitrase).
| Syarat Keluar | Penjelasan |
|---|---|
| Deposit + penarikan | ≥40 transaksi |
| Masih ada deposit baru-baru ini | Masih aktif melakukan deposit |
| Bawahan aktif | Bawahan memiliki deposit aktif, dan waktu aktif lebih dari 1 bulan |
Memenuhi syarat → hapus semua catatan, dianggap member normal, mulai pengamatan ulang.
Member yang dipulihkan, jika kembali mengklaim bonus undangan/Pinduoduo dan menarik dana, tetap diperiksa sesuai standar member P1.
📝 Sumber: Pembelajaran & diskusi
Standar Keempat · Double Review Wakil Ketua Tim (Penilaian Ulang Sebelum Pemotongan)
Baik P2 ditandai oleh Tim Audit maupun ditemukan sendiri oleh Wakil Ketua Tim, sebelum eksekusi pemotongan, Wakil Ketua Tim wajib menilai ulang berdasarkan Standar Pertama sampai Ketiga:
- Memenuhi standar P2 → Lanjutkan proses pemotongan, setelah potong buka kembali hak taruhan/penarikan (tetap di tingkat observasi, hak komisi tetap terbuka)
- Tidak memenuhi standar P2 → Tidak potong, batalkan catatan P2, keluarkan dari tingkat Observasi Arbitrase, ubah ke tingkat retensi 7 hari atau 30 hari sesuai tanggal pendaftaran user, beri catatan "tidak potong, tanggal+penanggung jawab"
📝 Sumber: Pembelajaran & diskusi
Referensi Pendukung Penilaian Perilaku Arbitrase (Pelengkap Standar Pertama)¶
| # | Pola Perilaku | Kesimpulan Penilaian |
|---|---|---|
| 1 | Setelah klaim bonus, tanpa taruhan game normal, deposit satu kali → taruhan untung → tarik dana | Diduga arbitrase |
| 2 | Setelah klaim bonus, taruhan game normal dengan keuntungan → tarik dana (sepenuhnya menggunakan bonus untuk arbitrase) | Diduga arbitrase |
| 3 | Lebih dari 5 member bawahan memiliki data kumulatif deposit dan turnover efektif yang sama persis atau selisihnya sangat kecil (terutama jumlah deposit yang identik) | Diduga arbitrase |
3 pola di atas sebagai referensi pendukung, membantu penilaian lebih lanjut; kriteria utama tetap berdasarkan Standar Pertama.
Alur Kerja Lengkap Audit Penarikan Agen¶
═══════════════════════════════════════════
Alur Lengkap Audit Penarikan Agen (Standar Baru 2026-04)
═══════════════════════════════════════════
Melihat catatan "Penarikan Agen"
│
▼
Kunci pesanan → Buka halaman detail info member
│
▼
========================================
Langkah Pertama: Periksa pola perilaku bawahan
berdasarkan Standar Pertama (Kriteria Utama)
========================================
│
▼
┌───────────────────────────────────────┐
│ Periksa user bawahan Agen: │
│ · Jumlah deposit dan turnover bawahan │
│ · Apakah memenuhi pola "deposit 50-60 │
│ + turnover ~600" │
│ · Proporsi bawahan tersebut dari total│
└────────┬──────────────────────────────┘
│
▼
========================================
Langkah Kedua: Periksa Riwayat Akun
========================================
│
▼
┌───────────────────────────────────────┐
│ Periksa【Riwayat Akun】: │
│ · Apakah mengklaim bonus undangan / │
│ bonus Pinduoduo │
│ · Apakah ada deposit normal │
│ · Apakah ada taruhan game normal │
│ · Referensi standar pendukung penilaian│
│ (3 pola perilaku) │
└────────┬──────────────────────────────┘
│
▼
========================================
Langkah Ketiga: Penilaian Keseluruhan
========================================
│
▼
┌─────────────────────────────────────┐
│ Apakah memicu Standar Pertama? │
│ (≥70% bawahan memenuhi pola │
│ arbitrase) │
└────────┬────────────────────────────┘
│
┌─────┴─────────┐
│ │
Tidak memicu Memicu
│ │
▼ ▼
Periksa Standar Masuk penanganan
Kedua P1/P2
(Syarat pertahankan)
│
▼
┌──────────────┐
│ Memenuhi │
│ Standar │
│ Kedua? │
│ (≥1 bawahan │
│ deposit │
│ besar+ │
│ turnover │
│ besar+ │
│ aktif baru- │
│ baru ini) │
└──────┬───────┘
┌───┴───┐
│ │
Ya Tidak
│ │
▼ ▼
Lolos audit Lolos audit
+ tidak (lolos biasa)
masukkan
ke tingkat
+ hapus
catatan P2
═══════════════════════════════════════════
Memicu Arbitrase → Alur Penanganan P1 / P2
═══════════════════════════════════════════
│
▼
Lihat kolom【Catatan】member
│
┌─────┴────────────────────────────┐
│ │
Ada catatan P1 Tidak ada catatan
(pernah diperingatkan) (pertama kali ditemukan)
│ │
▼ ▼
Tanggal P1 hari ini? ┌──────────────┐
│ │ Peringatan P1 │
┌──┴──┐ │ · Catatan "P1 │
│ │ │ peringatan │
Ya Tidak │ tanggal+ │
│ │ │ penanggung │
▼ ▼ │ jawab" │
┌────┐ Periksa riwayat │ · Tolak │
│Lang│ akun │ penarikan │
│sung│ │ │ · User ajukan │
│lol │ ┌──┴──┐ │ ulang → │
│os │ │ │ │ langsung │
│(ti │ Sudah Masih │ lolos │
│dak │ ber- arbitrase └──────────────┘
│dup │ ubah │
│li- │ │ │
│kat)│ ▼ ▼
└────┘ Lolos Masuk penanganan P2 ↓
Bawahan ≤3 + hanya klaim satu bonus undangan
→ dipertimbangkan untuk diloloskan
(beri motivasi mengembangkan bawahan)
========================================
Alur Penanganan P2
========================================
P2 bisa dipicu melalui dua jalur:
┌─────────────┬──────────────────┐
│ Jalur A │ Jalur B │
│ Tim Audit │ Wakil Ketua Tim │
│ menemukan │ sendiri menemukan │
│ masih │ saat audit masih │
│ arbitrase │ arbitrase │
└──────┬──────┴──────┬───────────┘
│ │
▼ ▼
Tindakan P2 (sama terlepas siapa yang memicu):
┌───────────────────────────────────────┐
│ (1) Tutup hak taruhan │
│ (2) Tutup hak penarikan │
│ ⚠️ Hak komisi tetap terbuka │
│ (3) Masukkan ke tingkat Observasi │
│ Arbitrase │
│ (4) Catatan "P2 peringatan │
│ tanggal+penanggung jawab" │
│ (5) Tolak pesanan │
│ (6) Notifikasi CS │
└────────┬──────────────────────────────┘
│
▼
User menghubungi CS → Konfirmasi bisa dipotong
→ CS notifikasi Wakil Ketua Tim eksekusi pemotongan
│
▼
╔══════════════════════════════════╗
║ Standar Keempat · Double Review ║
║ Wakil Ketua Tim ║
║ Nilai ulang berdasarkan Standar ║
║ Pertama~Ketiga ║
╚══════════════════════════════════╝
│
┌─────┴─────┐
│ │
Memenuhi P2 Tidak memenuhi P2
│ │
▼ ▼
Proses Tidak potong:
pemotongan · Batalkan catatan P2
(lihat 4.2) · Keluarkan dari tingkat
· Potong Observasi Arbitrase
bonus · Ubah ke tingkat retensi
· Setelah 7 hari/30 hari sesuai
potong tanggal pendaftaran
buka hak · Catatan "tidak potong,
taruhan/ tanggal+penanggung jawab"
penarikan
· Tetap di
tingkat
observasi
· Hak komisi
tetap terbuka
· Lapor ke grup
Keuangan
📝 Sumber: Pembelajaran & diskusi
Format Catatan Standar¶
| Skenario | Template Catatan | Contoh |
|---|---|---|
| Peringatan P1 | ❓ Akan diisi | ❓ Akan diisi |
| P2 potong bonus | ❓ Akan diisi | ❓ Akan diisi |
| Double review membatalkan (tidak memenuhi P2) | tidak potong, bisa keluar {tanggal} {penanggung jawab} |
tidak potong, bisa keluar 4.21 AA |
| Keluar dari tingkat observasi dipulihkan | Hapus semua catatan, dianggap member normal | — |
Agen Normal vs Agen Arbitrase · Rumus Penilaian¶
Lihat user bawahan, bukan Agen-nya sendiri. - Agen boleh tidak deposit dan tidak taruhan — "Agen tanpa deposit tanpa game" bukan tanda arbitrase - Perilaku bawahan normal (tidak memenuhi pola "deposit 50-60 + turnover 600 + ≥70%") → Agen menarik bonus = sah - Perilaku bawahan sangat mirip (memenuhi pola di atas ≥70%) → diduga arbitrase
📘 Sumber: 04-禁止投注问题排查 (jalur operasi penguncian) 📝 Sumber: Pembelajaran & diskusi (alur audit lengkap dan standar penilaian arbitrase)
🤖 Peluang otomatisasi: Pemeriksaan pola perilaku bawahan + pengecekan riwayat akun adalah salah satu pekerjaan paling memakan waktu bagi Wakil Ketua Tim. Bisa melalui skrip otomatis memindai distribusi deposit/turnover bawahan, menghitung proporsi yang memenuhi pola arbitrase, menandai Agen yang mencurigakan. Dokumen kebutuhan API lengkap lihat 12-自动化路线图/01-代理提现审核API.md. Jika pemeriksaan ini bisa distandarisasi menjadi fitur satu klik di back-office, Wakil Ketua Tim hanya perlu mengonfirmasi hasil dan menjalankan tindakan; setelah masa uji coba bisa sepenuhnya diotomatisasi, dengan Wakil Ketua Tim melakukan pengecekan acak.
4.2 Proses Pemotongan¶
Wakil Ketua Tim bisa langsung mengeksekusi operasi pemotongan, tapi pemotongan bukan dimulai oleh Wakil Ketua Tim sendiri—alur lengkapnya adalah: Tim Audit menemukan masalah → Tutup hak akses terkait pengguna → CS berkomunikasi dengan pengguna → Pengguna setuju pemotongan → CS mengirim pesan ke Wakil Ketua Tim → Wakil Ketua Tim mengeksekusi pemotongan → Pulihkan hak akses → Notifikasi CS → Lapor Grup Keuangan.
Tim Audit menemukan masalah
(Tutup hak penarikan dll pengguna)
│
▼
CS berkomunikasi soal pemotongan dgn pengguna
│
▼
Pengguna setuju pemotongan?
├─ Tidak → CS umpan balik ke Tim Audit, jalur eskalasi
│
└─ Ya → CS mengajukan kebutuhan pemotongan di grup
│
▼
┌───────────────────────┐
│ (1) Klaim di grup │
└────────┬──────────────┘
│
▼
┌───────────────────────────────────────────┐
│ (2) Cek 【Riwayat Akun】pengguna │
│ Verifikasi nominal yang perlu dipotong: │
│ · Hadiah undangan │
│ · Hadiah Pinduoduo │
│ · Keuntungan yang dihasilkan dari │
│ bonus di atas │
│ Prinsip pemotongan: Hanya simpan │
│ nominal deposit sendiri dari pengguna, │
│ atau saldo akun sebelum mendapat bonus │
└────────┬──────────────────────────────────┘
│
▼
======================================================
(2.5) Verifikasi silang (WAJIB, konfirmasi
akurasi penilaian Tim Audit)
======================================================
┌───────────────────────────────────────────┐
│ · Periksa sesuai 4 standar 4.1.5 │
│ · Periksa apakah pola perilaku bawahan │
│ sesuai ciri-ciri arbitrase │
│ · Konfirmasi apakah penilaian Tim Audit │
│ akurat │
│ │
│ · Konfirmasi ada masalah → Lanjut eksekusi │
│ pemotongan │
│ · Ditemukan keberatan → Umpan balik ke │
│ Tim Audit, tunda pemotongan │
└────────┬──────────────────────────────────┘
│
▼
┌───────────────────────┐
│ (3) Eksekusi pemotongan│
│ di back-office │
│ Jalur: Manajemen │
│ Member → Daftar │
│ Member → Klik UID │
│ → Data Akun → │
│ Ubah Saldo │
└────────┬──────────────┘
│
▼
┌───────────────────────────────┐
│ (4) Pulihkan hak akses yang │
│ ditutup │
│ (penarikan/taruhan dll, │
│ sesuai instruksi Tim Audit)│
└────────┬──────────────────────┘
│
▼
┌───────────────────────┐
│ (5) Notifikasi CS │
│ di grup │
│ "Sudah dipotong │
│ + hak akses │
│ dipulihkan" │
└────────┬──────────────┘
│
▼
┌───────────────────────┐
│ (6) Lapor Grup │ ← Laporan wajib
│ Keuangan │
│ Berisi: Platform / │
│ ID Pengguna / │
│ Nominal Potong / │
│ Alasan │
└───────────────────────┘
Template laporan Grup Keuangan: tidak ada file template terpisah — cukup salin format laporan terbaru dari rekan di grup (4 field kunci dari alur di atas: Platform / ID Pengguna / Nominal Potong / Alasan).
Prinsip Perhitungan Nominal Pemotongan:
| Perlu Dipotong | Perlu Disimpan |
|---|---|
| Nominal hadiah undangan | Nominal deposit sendiri pengguna |
| Nominal hadiah Pinduoduo | Saldo akun sebelum mendapat bonus |
| Keuntungan dari bonus di atas | — |
Logika inti: Uang terkait bonus (termasuk keuntungan) semuanya dipotong, uang sendiri pengguna semuanya disimpan. Perlu cek riwayat akun per transaksi untuk verifikasi, tidak boleh memotong sekaligus berdasarkan saldo saat ini.
📝 Sumber: Pembelajaran & diskusi
⚠️ Pemotongan ≠ Pembatalan Deposit (Dua Tindakan yang Sama Sekali Berbeda)¶
| Dimensi | Pemotongan (bagian ini) | Pembatalan Deposit |
|---|---|---|
| Penyebab | Pelanggaran pengguna / tunggakan / pengurangan kontrol risiko | Satu transaksi deposit yang baru saja salah dikonfirmasi |
| Batas waktu | Tanpa batas, bisa dilakukan kapan saja | Dalam 30 menit setelah konfirmasi pesanan (tombol hilang setelah lewat) |
| Jalur operasi | Manajemen Member → Daftar Member → Klik UID → Data Akun → Ubah Saldo | Manajemen Keuangan → Catatan Deposit → Pembatalan Deposit |
| Objek yang terdampak | Saldo member saat ini | Pesanan deposit tersebut (saldo dikurangi + pesanan dibatalkan + volume taruhan di-rollback) |
| Siapa yang memicu | Umpan balik dari CS | Keuangan/admin menemukan kesalahan konfirmasi |
| Laporan keuangan | ✅ Wajib | ✅ Nominal besar atau pembatalan sering perlu koordinasi dengan keuangan |
Pedoman cepat: - CS bilang "pengguna ini ada pelanggaran perlu dipotong uangnya" → Ikuti Pemotongan - Admin/keuangan bilang "saya tadi salah konfirmasi satu deposit, cepat batalkan" → Ikuti Pembatalan Deposit (hitungan mundur 30 menit!)
📘 Sumber: 05-充值订单收回款项 + 13-会员与风控/01-会员列表
Dua Jenis "Penyesuaian" yang Harus Dibedakan¶
| Jenis | Dihitung ke Statistik Deposit? | Kegunaan |
|---|---|---|
| Penyesuaian Manual | ✅ Dihitung sebagai deposit | Tambah deposit, penyesuaian keuangan |
| Penyesuaian Bonus | ❌ Tidak dihitung sebagai deposit | Kompensasi aktivitas, bonus terlewat (sehari-hari pakai ini) |
Jalur operasi: Manajemen Member → Daftar Member → Klik UID → Data Akun → Ubah Saldo (pilih jenis di pop-up).
Poin tambahan:
- Semua penyesuaian manual otomatis tercatat di log operasi, berisi saldo sebelum / saldo sesudah / operator / catatan alasan
- Wakil Ketua Tim saat mengoperasikan WAJIB mengisi catatan (berisi nomor tiket / nomor keluhan)—ini adalah pelindung audit
- Batas per transaksi/per hari dikonfigurasi di Manajemen Sistem → Akun Back-Office, melebihi batas sistem langsung menolak
📘 Sumber: 13-会员与风控/01-会员列表 + 17-活动记录/10-彩金加减款记录
4.3 Perubahan Hak Akses Member¶
CS mengajukan kebutuhan di grup
│
▼
┌──────────────────────────────┐
│ Klaim di grup │
│ Format: Balas pesan dgn OK │
│ atau ✅ centang │
└────────┬─────────────────────┘
│
▼
┌───────────────────────┐
│ Eksekusi perubahan │
│ hak akses di │
│ back-office │
└────────┬──────────────┘
│
▼
┌───────────────────────────────────┐
│ Apakah melibatkan penambahan/ │
│ pemotongan dana? │
└────────┬──────────────────┬───────┘
│ Ya │ Tidak
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ WAJIB lapor Grup │ │ Balas di grup │
│ Keuangan │ │ "Sudah diproses" │
│ Tulis: Platform/ │ └──────────────────┘
│ ID Pengguna/ │
│ Jenis Operasi/ │
│ Nominal/Alasan │
└──────────────────┘
📘 Sumber: 13-会员与风控/01-会员列表 📝 Sumber: Pembelajaran & diskusi
4.4 Penanganan Callback Pesanan¶
Cakupan: Saat ini ada dua skenario yang memerlukan Wakil Ketua Tim mengeksekusi callback pesanan: promosi traffic dan pengujian jarak jauh. Keduanya menggunakan perintah callback yang sama (bot Telegram saluran pihak ketiga /testpay nomor_pesanan), tetapi penanganan hak akses setelah callback berbeda.
Tujuan inti: Membantu berbagai tim menyelesaikan tes, sekaligus memastikan dana tes yang ditambahkan melalui callback tidak bisa ditarik secara tidak sengaja.
⚠️ Aturan penting: Jika callback pesanan tes gagal atau muncul masalah apapun, harus daftar akun baru dan ajukan pesanan baru untuk callback. Tidak boleh menggunakan akun yang sama untuk mengajukan dua pesanan lalu callback dua kali.
Skenario 1 · Callback Pesanan Traffic Promosi¶
Menerima permintaan callback traffic di grup
(tim promosi)
│
▼
┌───────────────────────┐
│ Klaim di grup │
└────────┬──────────────┘
│
▼
┌───────────────────────────┐
│ Melalui bot Telegram │
│ saluran pihak ketiga: │
│ /testpay nomor_pesanan │
└────────┬──────────────────┘
│
▼
┌───────────────────────────┐
│ Back-office → Tutup hak │
│ penarikan │
│ Buat catatan: 【testpay】 │
│ │
│ ⚠️ Akun traffic TIDAK │
│ dibuka kunci setelahnya │
└────────┬──────────────────┘
│
▼
┌───────────────────────────┐
│ Balas di grup: "Sudah │
│ diproses" │
└───────────────────────────┘
Skenario 2 · Callback Tes Deposit/Penarikan Tester Jarak Jauh¶
Tester jarak jauh perlu menjalani alur lengkap tes deposit + penarikan. Perbedaan dari traffic: hak penarikan tetap dibuka (tester perlu mengajukan pesanan penarikan tes nanti), tapi auto-disbursement dinonaktifkan (mencegah dana tes benar-benar dicairkan).
Menerima permintaan callback tes jarak jauh
di grup (tim testing)
│
▼
┌───────────────────────┐
│ Klaim di grup │
└────────┬──────────────┘
│
▼
┌───────────────────────────┐
│ Melalui bot Telegram │
│ saluran pihak ketiga: │
│ /testpay nomor_pesanan │
│ (sama dengan callback │
│ traffic) │
└────────┬──────────────────┘
│
▼
┌────────────────────────────────┐
│ ⚠️ Penanganan hak akses │
│ (berbeda dari traffic) │
│ │
│ · Hak penarikan → TETAP BUKA │
│ · Auto-disbursement → │
│ NONAKTIFKAN │
│ (cegah pencairan nyata dana │
│ tes) │
│ │
│ Buat catatan: 【tes jarak jauh】│
└────────┬───────────────────────┘
│
▼
┌────────────────────────────────┐
│ Tester mengajukan pesanan │
│ penarikan tes │
│ │ │
│ ▼ │
│ Wakil Ketua Tim menerima │
│ pesanan → TOLAK │
│ (tes selesai, tidak dicairkan │
│ secara nyata) │
└────────┬───────────────────────┘
│
▼
Perbandingan cepat dua skenario:
| Dimensi | Callback Traffic | Callback Tes Jarak Jauh |
|---|---|---|
| Dipicu oleh | Tim promosi | Tester jarak jauh |
| Perintah callback | /testpay nomor_pesanan |
/testpay nomor_pesanan (sama) |
| Hak penarikan | Ditutup | Tetap buka (dibutuhkan untuk tes) |
| Auto-disbursement | Tidak relevan (penarikan sudah dikunci) | Dinonaktifkan (cegah pencairan nyata) |
| Pesanan penarikan lanjutan | Tidak ada (hak sudah dikunci) | Tester akan mengajukan → Wakil Ketua Tim menolak |
| Kata kunci catatan | testpay |
tes jarak jauh |
| Mekanisme anti-kerugian | Kunci hak penarikan | Nonaktifkan auto-disbursement + tolak manual |
📝 Sumber: Pembelajaran & diskusi
📘 Sumber: 20-系统管理/04-操作日志 (jejak operasi penguncian)
4.5 Pemeriksaan Persyaratan Turnover¶
Saat Wakil Ketua Tim mengaudit penarikan, alasan penolakan yang umum adalah persyaratan turnover (volume taruhan efektif) tidak cukup.
Empat Formula Perhitungan Turnover Efektif¶
| Mode | Formula | Penerapan Tipikal | Kecenderungan |
|---|---|---|---|
| ① Berdasarkan nominal taruhan | Turnover efektif = nominal taruhan |
Permainan risiko rendah (Slot dll) | Paling longgar |
| ② Berdasarkan nominal kemenangan | Turnover efektif = nominal kemenangan (0 jika tidak menang) |
Sangat jarang digunakan | Merugikan pengguna |
| ③ Mode campuran 1 | Tidak menang: Turnover efektif = jumlah taruhan; Menang: Turnover efektif = min(taruhan, kemenangan) |
Skenario seimbang | Seimbang |
| ④ Mode campuran 2 | Turnover efektif = min(taruhan, |taruhan-kemenangan|) |
Permainan risiko tinggi, anti-arbitrase | Paling ketat |
Perubahan aturan hanya berlaku untuk pesanan berikutnya, pesanan historis tidak berubah.
📘 Sumber: 03-有效打码计算方式
Jalur Pemeriksaan¶
Pesanan penarikan terkena kontrol risiko: diduga turnover tidak cukup
│
▼
Jalur back-office: Urutan Permainan → Daftar Grup Permainan
│
▼
Lihat grup permainan yang diikuti pengguna tersebut
│
▼
Lihat "Cara Perhitungan Turnover Efektif" grup tersebut
│
▼
Bandingkan dengan batas aktivitas/volume taruhan
├─ Memenuhi → Loloskan penarikan
└─ Tidak memenuhi → Tolak + catatan
"Sisa turnover XXX" → Notifikasi CS
Cara pintas: Back-office punya halaman "Sisa turnover" yang langsung ditampilkan (profil member → kolom sisa turnover), dalam kebanyakan kasus tidak perlu menghitung balik secara manual.
📘 Sumber: 03-有效打码计算方式 + 13-会员与风控/07-打码量变动记录
4.6 Investigasi Masalah Larangan Taruhan¶
Ketika CS melaporkan "pengguna bilang tidak bisa bertaruh":
CS meneruskan: Pengguna XXX tidak bisa bertaruh
│
▼
┌───────────────────────────────┐
│ Step 1: Klaim di grup │
└──────────┬────────────────────┘
│
▼
┌───────────────────────────────┐
│ Step 2: Investigasi di │
│ back-office │
│ Jalur: Manajemen Member → │
│ Daftar Penguncian Pengguna │
│ Periksa tiga jenis penguncian:│
│ ① Kunci login (tidak bisa │
│ akses sama sekali) │
│ ② Kunci taruhan (bisa login │
│ tidak bisa taruhan) │
│ ③ Kunci penarikan/komisi │
└──────────┬────────────────────┘
│
▼
Ditemukan item terkunci?
├─ Ya → Tentukan alasan penguncian
│ ├─ Anti-fraud agen → Tidak bisa dibuka,
│ │ jalur eskalasi kontrol risiko
│ ├─ Kunci manual pelanggaran → Konfirmasi
│ │ ke atasan baru buka
│ └─ Dipicu otomatis kontrol risiko →
│ Investigasi dulu baru buka
│
└─ Tidak → Bukan karena penguncian
(Batasan API/anomali perangkat/saldo tidak cukup)
→ Teruskan ke tim teknis
❌ Garis Merah: WAJIB investigasi alasan sebelum membuka kunci. Membuka kunci sembarangan akun yang pernah dikunci bisa meloloskan pengguna penipu nyata.
Fakta penting: - Kesalahan kata sandi penarikan melebihi batas akan secara bersamaan memicu "kunci taruhan" + "kunci penarikan" - Kata sandi penarikan hanya bisa "dihapus" tidak bisa "diubah", setelah dihapus member harus mengatur ulang
📘 Sumber: 04-禁止投注问题排查 + 13-会员与风控/11-用户锁定列表
4.7 Penyesuaian RTP Hari Event (Tugas Berkala)¶
Ini adalah tugas level manajer, tetapi kadang didelegasikan ke ketua tim atau wakil ketua tim yang memiliki akses backend.
Latar Belakang¶
Situs yang sudah mapan memiliki banyak pengguna veteran dengan level VIP tinggi. Pada hari event (biasanya Senin), bonus besar perlu didistribusikan. Tanpa menyesuaikan tingkat RTP (Return to Player) terlebih dahulu, selisih deposit-penarikan platform bisa menjadi negatif (kerugian platform). Menurunkan RTP untuk tier pengguna tertentu mengimbangi pengeluaran bonus.
Waktu Pelaksanaan¶
- Malam sebelum hari event (biasanya Minggu ~23:30)
- Harus selesai sebelum 00:00 di hari event
Prosedur¶
Minggu ~23:30: Persiapan penyesuaian RTP
│
▼
┌───────────────────────────────┐
│ Step 1: Backend → │
│ Manajemen Member → │
│ Tier Member │
└──────────┬────────────────────┘
│
▼
┌───────────────────────────────┐
│ Step 2: Sesuaikan RTP untuk │
│ tiga tier: │
│ ① User retensi 15 hari │
│ ② User retensi 30 hari │
│ ③ Pengamat arbitrase │
└──────────┬────────────────────┘
│
▼
┌───────────────────────────────┐
│ Step 3: Klik "Atur RTP │
│ Sekali Klik" │
│ (nilai spesifik ditentukan │
│ oleh manajer, wakil ketua │
│ tim hanya menjalankan) │
└──────────┬────────────────────┘
│
▼
┌───────────────────────────────┐
│ Step 4: Konfirmasi ketiga │
│ tier selesai → Lapor di grup │
│ chat: "RTP sudah disesuaikan" │
└───────────────────────────────┘
Catatan¶
- Hanya untuk situs yang sudah mapan (situs baru tidak perlu)
- Nilai RTP ditentukan oleh manajer — wakil ketua tim hanya menjalankan
- Sensitif waktu: harus selesai sebelum event dimulai
- Ketiga tier harus diatur, tidak boleh ada yang terlewat
📝 Sumber: Pembelajaran & diskusi
4.8 Pemrosesan Pesanan Chargeback/Reversal (Tugas Respons Jalur-B)¶
Latar Belakang¶
Setelah penarikan member berhasil, callback otomatis dari pihak ketiga pembayaran menunjukkan sukses. Namun 1–2 hari kemudian, pesanan pencairan mungkin gagal di bank (reversal/chargeback bank) — artinya uang belum pernah sampai ke pengguna. Diperlukan kompensasi manual.
Saluran Penemuan¶
- Bot pembayaran pihak ketiga mengirim notifikasi reversal di grup pembayaran Telegram
- Petugas yang ditunjuk mencari setiap hari menggunakan kata kunci "reversal/chargeback" (冲正) di setiap grup pembayaran
- Pesanan yang belum diproses dikumpulkan dan dikirim untuk pemrosesan batch
Alur Lengkap¶
┌─────────────────────────────────────────────┐
│ Langkah 1: Dapatkan nomor pesanan dari │
│ notifikasi reversal │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Langkah 2: Cari di grup pengecekan │
│ deposit/penarikan Signal — jika ditemukan, │
│ sudah diproses, lewati │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Langkah 3: Gunakan bot di grup pembayaran │
│ untuk memeriksa ulang status pesanan, │
│ catat waktu pemrosesan │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Langkah 4: Periksa riwayat transaksi user │
│ di backend, temukan pesanan penarikan │
│ (contoh: jumlah = 20) │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Langkah 5: Lihat kembali riwayat transaksi: │
│ apakah sudah ada catatan "tambah bonus 20"? │
│ │
│ Ya → sudah diproses, lewati │
│ Tidak → perlu kompensasi │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Langkah 6: Tambah bonus ke user sejumlah │
│ penarikan. Catatan: "Pesanan penarikan │
│ gagal, penambahan manual" │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Langkah 7: Laporan di grup Signal: │
│ nama platform / ID user / nomor pesanan / │
│ catatan / pemroses │
└─────────────────────────────────────────────┘
Poin Penting¶
- Verifikasi ganda mencegah kompensasi duplikat (pengecekan Signal + pengecekan riwayat transaksi)
- Catatan standar: "Pesanan penarikan gagal, penambahan manual"
- Gunakan tambah bonus (bukan deposit manual) — tidak dihitung dalam statistik deposit
- Laporan harus mencakup semua 5 elemen: nama platform / ID user / nomor pesanan / catatan / pemroses
📝 Sumber: Pembelajaran & diskusi
4.9 Monitoring Tingkat Keberhasilan Deposit (Setiap 30 Menit)¶
Latar Belakang¶
Tingkat keberhasilan deposit di pasar Indonesia secara langsung menentukan pendapatan platform. Tingkat keberhasilan rendah = banyak user gagal deposit = user langsung hilang (pengguna Indonesia tidak sabar — satu kali gagal banyak yang pindah platform). Maka wajib monitoring real-time dan intervensi langsung saat tingkat keberhasilan di bawah ambang — jangan menunggu komplain user.
Parameter Utama¶
| Item | Nilai |
|---|---|
| Frekuensi inspeksi | Setiap 30 menit |
| Jendela observasi | Tingkat keberhasilan deposit 10 menit terakhir |
| Ambang intervensi | Tingkat keberhasilan < 60% wajib intervensi |
| Aksi pertama | Beritahu merchant penagihan untuk optimasi saluran |
| Aksi cadangan | Ganti saluran penagihan (sesuaikan urutan metode deposit) |
Alur Lengkap Penanganan¶
Setiap 30 menit (:00 / :30)
│
▼
┌────────────────────────────────────┐
│ (1) Periksa tingkat keberhasilan │
│ deposit 10 menit terakhir di │
│ back-office │
│ Periksa tiap platform satu per │
│ satu │
└──────────┬─────────────────────────┘
│
▼
Tingkat keberhasilan < 60%?
│
┌────┴────┐
│ │
Tidak Ya
│ │
▼ ▼
┌──────────┐ ┌────────────────────────────────────┐
│ Jaga │ │ (2) Identifikasi merchant mana yang │
│ konfigu- │ │ bermasalah (tingkat keberhasilan│
│ rasi, │ │ terendah) │
│ lanjut │ └──────────┬──────────────────────────┘
│ monitor │ │
│ │ ▼
│ │ ┌────────────────────────────────────┐
│ │ │ (3) Di grup Telegram merchant │
│ │ │ tersebut, minta optimasi │
│ │ │ saluran │
│ │ │ Pesan: "Tingkat keberhasilan │
│ │ │ rendah, mohon dioptimasi" │
│ │ └──────────┬──────────────────────────┘
│ │ │
│ │ ▼
│ │ ┌────────────────────────────────────┐
│ │ │ (4) Pantau hasil optimasi │
│ │ │ Observasi 10-15 menit berikutnya│
│ │ └──────────┬──────────────────────────┘
│ │ │
│ │ ▼
│ │ Pulih?
│ │ │
│ │ ┌────┴────┐
│ │ │ │
│ │ Ya Tidak
│ │ │ │
│ │ ▼ ▼
│ │ ┌──────────┐ ┌────────────────────────────┐
│ │ │ Efektif! │ │ (5) Ganti saluran │
│ │ │ Jaga │ │ penagihan │
│ │ │ konfigu- │ │ · Sesuaikan urutan │
│ │ │ rasi, │ │ metode deposit │
│ │ │ lanjut │ │ · Turunkan merchant │
│ │ │ monitor │ │ bermasalah │
│ │ │ │ │ · Naikkan merchant │
│ │ │ │ │ cadangan │
│ │ │ │ │ · Jaga urutan penagihan │
│ │ │ │ │ = pencairan (lihat │
│ │ └──────────┘ │ aturan inti 3.6) │
│ │ └──────────┬─────────────────┘
│ │ │
│ │ ▼
│ │ ┌────────────────────────┐
│ │ │ (6) Laporan di grup │
│ │ │ shift + catat │
│ │ │ perubahan │
│ │ └────────────────────────┘
└──────────┘
Poin Penting¶
- Frekuensi 30 menit bukan sembarangan: jendela 10 menit memberikan data representatif (menyaring fluktuasi sementara); interval 30 menit menangkap masalah cepat (paling telat 30 menit)
- Beritahu merchant dulu, baru ganti: memberitahu merchant adalah opsi biaya terendah (merchant juga tidak ingin kehilangan volume) — hanya ganti saluran jika merchant benar-benar tidak bisa perbaiki
- Pergantian sejalan dengan prinsip 3.6: saat menyesuaikan urutan penagihan, sesuaikan urutan pencairan secara bersamaan — jaga konsistensi
- Catat setiap intervensi: laporan di grup shift "Inspeksi XX:30: Platform A tingkat keberhasilan 52%, sudah beritahu CP-X optimasi / sudah ganti ke CP-Y" — berguna untuk serah terima dan post-mortem
Referensi: 08-Urutan Metode Deposit
📝 Sumber: Pembelajaran & diskusi
🤖 Peluang otomatisasi: Bangun peringatan tingkat keberhasilan real-time — back-office hitung tingkat 10 menit terakhir setiap 5 menit, otomatis @Wakil Ketua Tim jika < 60% dengan merchant bermasalah ditandai, menghilangkan pemeriksaan manual setengah jam.
4.10 Penanganan Pesanan Penarikan 30 Menit Belum Callback¶
Latar Belakang¶
Normalnya, pesanan pencairan yang dikirim ke merchant pihak ketiga memberikan callback (sukses atau gagal) dalam beberapa menit. 30 menit tanpa callback = ada masalah di pihak pencairan, kemungkinan:
- Merchant masih "memproses" secara internal (pesanan macet)
- Saluran merchant bermasalah (bank lambat, pemblokiran kontrol risiko, sistem merchant bermasalah)
- Merchant sudah memproses tetapi callback hilang
Apapun kasusnya, Wakil Ketua Tim wajib intervensi aktif dan konfirmasi ke merchant — menunggu pasif menyebabkan komplain user langsung "penarikan sudah 30 menit belum sampai".
Saluran Penemuan¶
- Halaman catatan penarikan back-office memiliki kategori/peringatan khusus "Sudah dikirim 30 menit belum callback"
- Daftar tersebut menampilkan semua pesanan yang menumpuk
Alur Lengkap Penanganan¶
Peringatan back-office / pemeriksaan rutin catatan penarikan
Temukan daftar pesanan "30 menit belum callback"
│
▼
┌────────────────────────────────────┐
│ (1) Hitung jumlah pesanan │
└──────────┬─────────────────────────┘
│
▼
Jumlah pesanan?
│
┌────┴────┐
│ │
Sedikit Banyak
(<5) (>=5)
│ │
▼ ▼
┌──────────┐ ┌────────────────────────────────────┐
│ Salin │ │ (2') Kelompokkan berdasarkan │
│ nomor │ │ merchant pencairan dulu │
│ pesanan │ │ (satu batch bisa milik │
│ langsung │ │ beberapa merchant) │
│ ke grup │ │ Kirim batch per-merchant ke │
│ pembayar-│ │ grup masing-masing │
│ an terkait│ └──────────┬──────────────────────────┘
└────┬─────┘ │
│ │
└─────────┬─────────┘
▼
┌────────────────────────────────────┐
│ (3) Di grup pembayaran, konfirmasi │
│ dulu merchant pemilik pesanan │
│ (hindari salah rute) │
│ Gunakan bot untuk cek merchant │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4) Minta merchant investigasi & │
│ selesaikan │
│ · Merchant cek status internal │
│ · Merchant yang mampu akan │
│ push callback perbaikan │
└──────────┬─────────────────────────┘
│
▼
Merchant bisa selesaikan?
│
┌────┴────┐
│ │
Bisa Tidak
│ │
▼ ▼
┌──────────┐ ┌────────────────────────────────────┐
│ Tunggu │ │ (5) Merchant tolak pesanan │
│ callback │ │ → sistem otomatis proses tolak │
│ perbaikan│ │ → saldo otomatis dikembalikan │
│ Pesanan │ │ ke user │
│ selesai │ │ → user dapat coba penarikan │
│ │ │ ulang (pilih saluran lain) │
└──────────┘ └────────────────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (6) Laporan di grup shift / Signal │
│ grup pengecekan deposit- │
│ penarikan: │
│ · nomor pesanan / ID user / │
│ hasil │
│ · untuk audit & pelacakan │
└────────────────────────────────────┘
Poin Penting¶
- Konfirmasi kepemilikan merchant dulu: satu batch pesanan 30 menit tanpa callback bisa milik beberapa merchant — konfirmasi sebelum/saat posting ke grup, jangan lempar pesanan merchant A ke grup merchant B (buang waktu)
- Penolakan merchant ≠ kerugian finansial: setelah merchant menolak, sistem otomatis mengembalikan jumlah ke user (dengan syarat dana tidak pernah benar-benar sampai ke user); user bisa coba lagi
- JANGAN refund manual: melalui penolakan sistem adalah jalur standar — menambah bonus manual mudah menyebabkan pembayaran ganda
- Perbedaan dengan 4.11: 4.10 adalah "30 menit tanpa callback" (masih menunggu callback); 4.11 adalah "timeout antarmuka pencairan" (panggilan API yang timeout). Keduanya wajib ditangani tetapi sumbernya berbeda.
Referensi: 06-Catatan Penarikan
📝 Sumber: Pembelajaran & diskusi
🤖 Peluang otomatisasi: Kelompokkan otomatis pesanan 30 menit tanpa callback berdasarkan merchant dan batch-post ke grup pembayaran terkait; Wakil Ketua Tim hanya konfirmasi dan follow-up; pesanan yang pulih otomatis tertutup.
4.11 Penanganan Pesanan Timeout Antarmuka Pencairan¶
Latar Belakang¶
"Timeout antarmuka pencairan" adalah anomali berbeda dari "30 menit tanpa callback" di 4.10:
- 4.10 (30 menit tanpa callback): Panggilan API berhasil, tetapi merchant tidak pernah kirim callback → tunggu merchant
- 4.11 (timeout antarmuka): Panggilan API itu sendiri timeout (merchant mungkin tidak menerima permintaan, atau menerima tetapi gagal merespon tepat waktu) → status pesanan ambigu
Pesanan timeout memiliki status ambigu — baik merchant tidak pernah memprosesnya (dana masih di akun merchant kami), atau merchant memproses tetapi tidak dapat merespon tepat waktu (dana sudah dibayarkan). Anda WAJIB konfirmasi ulang dengan merchant sebelum memutuskan aksi — bertindak berdasarkan tebakan mudah memicu pembayaran ganda = kerugian finansial langsung.
⚠️ Penting: Halaman timeout antarmuka pencairan TIDAK memiliki tombol "tolak". Entry point aksi adalah tombol "Bayar Ulang". Alur: konfirmasi dana ada di akun kami → klik "Bayar Ulang" → pesanan otomatis masuk ke halaman pencairan → di halaman pencairan, pilih saluran pencairan lain dan submit ulang.
Saluran Penemuan¶
- Halaman catatan penarikan back-office → kategori "Pesanan timeout antarmuka pencairan"
Alur Lengkap Penanganan¶
Back-office menampilkan pesanan "Timeout antarmuka pencairan"
│
▼
┌────────────────────────────────────┐
│ (1) Untuk setiap pesanan, │
│ konfirmasi ulang dengan │
│ merchant terkait │
│ (biasanya merchant yang sama │
│ dengan 4.10) │
│ Di grup Telegram merchant, │
│ gunakan bot untuk cek status │
│ aktual │
└──────────┬─────────────────────────┘
│
▼
Status pesanan di sisi merchant?
│
┌──────────┼──────────────────────┐
│ │ │
Merchant Merchant tidak proses Merchant masih
sudah / proses gagal proses
bayar dana ada di akun kami (pending)
(sukses)
│ │ │
▼ ▼ ▼
┌──────────┐ ┌───────────────┐ ┌──────────────┐
│ Klik │ │ (2) Klik │ │ Tunggu │
│ tombol │ │ tombol │ │ callback │
│ "Merchant│ │ "Bayar │ │ JANGAN │
│ Sudah │ │ Ulang" │ │ terburu-buru │
│ Bayar" │ │ │ │ klik Bayar │
│ untuk │ │ │ │ Ulang │
│ callback │ │ │ │ (risiko │
│ status │ │ │ │ pembayaran │
│ order │ │ │ │ ganda) │
│ jadi │ │ │ │ │
│ sukses │ │ │ │ │
└──────────┘ └──────┬────────┘ └──────────────┘
▼
┌────────────────────────────────┐
│ (3) Pesanan otomatis masuk │
│ [Halaman Pencairan] │
│ (dok [05-Pencairan]) │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ (4) Di halaman Pencairan, pilih │
│ **saluran pencairan LAIN** │
│ (BUKAN yang baru saja │
│ timeout) │
│ Setujui manual │
│ Submit ke saluran baru │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ (5) Laporan hasil di grup shift │
│ · nomor pesanan │
│ · merchant asal (timeout) │
│ → merchant baru │
│ · pemroses │
└────────────────────────────────┘
Poin Penting (Garis Merah)¶
- WAJIB konfirmasi "dana kembali di akun merchant kami" sebelum klik "Bayar Ulang": ini adalah garis merah kerugian finansial — jika merchant sudah bayar dan Anda klik Bayar Ulang, sistem bayar lagi via saluran baru = pembayaran ganda = kerugian langsung
- Merchant masih proses → TERUS TUNGGU: jangan terburu-buru klik Bayar Ulang, tunggu status final merchant. Lebih baik biarkan user menunggu beberapa menit daripada mengambil risiko pembayaran ganda
- Pilih saluran pencairan BERBEDA saat submit ulang: setelah di halaman Pencairan, pilih saluran lain — yang tadi baru saja timeout, memilih yang sama kemungkinan besar timeout lagi
- "Bayar Ulang" BUKAN "Tolak": halaman ini tidak ada tombol tolak — jangan cari-cari. "Bayar Ulang" secara esensial memasukkan pesanan kembali ke antrian pencairan untuk Wakil Ketua Tim pilih saluran baru
- Hubungan dengan 4.10: saat menangani 4.11, merchant terkait kemungkinan adalah merchant yang sama yang bermasalah di 4.10. Alur tipikal adalah "tangani 4.10 tanpa callback dulu → baru tangani timeout 4.11"
Referensi: - 05-Pencairan - 06-Catatan Penarikan
📝 Sumber: Pembelajaran & diskusi
🤖 Peluang otomatisasi: Bangun bot status merchant untuk pesanan timeout — otomatis query status aktual di grup merchant, agregat hasil untuk Wakil Ketua Tim, yang hanya perlu klik "dana kembali → Bayar Ulang" untuk konfirmasi.
4.12 Bantuan Buka Situs Baru (Membantu Ketua Tim)¶
Pemicu: Saat Ketua Tim memberitahu ada situs baru yang akan diluncurkan. Ini tugas bantuan ad-hoc — tidak dilakukan setiap hari, hanya saat dapat notifikasi.
Ruang lingkup bantuan Wakil Ketua Tim (dua bagian):
4.12.1 Binding Domain Situs¶
Jalur back-office: Manajemen Domain → Domain Situs
Langkah operasi:
1. Terima daftar domain + tipe yang diberikan Ketua Tim (domain utama / domain cadangan / domain pengalihan, dll.)
2. Tambahkan binding satu per satu di back-office, tipe harus sama persis dengan yang diberikan Ketua Tim — jangan tebak sendiri
3. Setelah selesai, balas di notifikasi Ketua Tim: Binding XX domain selesai
4.12.2 Konfigurasi Alur Otomatisasi CS Salesmartly¶
Tujuan: Salin alur otomatisasi dari situs sebelumnya ke situs baru, lalu sesuaikan dengan situasi baru.
Langkah operasi:
1. Di back-office CS Salesmartly, berdasarkan alur otomatisasi situs sebelumnya, tambahkan set yang sama untuk situs baru
2. Sesuaikan untuk masalah baru yang mungkin muncul di situs baru, misalnya:
- Sediakan screenshot yang sesuai untuk masalah baru tertentu
- Tambahkan teks balasan otomatis
3. Konfigurasi alur otomatisasi untuk saluran self-media (misalnya bot Telegram)
4. Setelah selesai, sync ke Ketua Tim: Alur otomatisasi situs baru sudah selesai dikonfigurasi
📝 Sumber: Pembelajaran & diskusi
Catatan: - Tipe domain harus 100% sesuai daftar dari Ketua Tim — jangan ubah atau tambah sendiri - Alur otomatisasi CS berbasis template copy — jangan bangun dari nol, pakai template yang ada lebih cepat dan lebih sedikit error - Screenshot/teks baru harus konfirmasi isi ke Ketua Tim / CS — jangan karang sendiri
4.13 Inspeksi Pesanan Pencairan Anomali dari Keuangan (Responsif Jalur B)¶
Pemicu: Saat Keuangan mengirim pesanan anomali di grup (Keuangan sudah melakukan satu putaran perbandingan dan menemukan masalah).
Skenario anomali tipikal:
Wakil Ketua Tim sendiri (atau Wakil Ketua Tim lain) menolak manual pesanan saat pihak ketiga masih memproses — frontend akan mengembalikan jumlah penarikan ke akun member; tapi pihak ketiga di sisi lain sudah benar-benar mencairkan ke rekening penarikan member — artinya satu transaksi dibayar dua kali, platform langsung rugi. Ini yang disebut kesalahan manual pesanan.
Alur inspeksi:
Grup Keuangan kirim pesanan anomali
│
▼
┌────────────────────────────────────┐
│ (1) Temukan pesanan di back-office │
│ Konfirmasi No. Pesanan / Jumlah │
│ / User ID / status saat ini / │
│ riwayat operator │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (2) Buka grup pencairan terkait │
│ Pakai bot untuk query status │
│ aktual pesanan │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (3) Bandingkan silang kedua status │
│ · Back-office: "Ditolak / │
│ dikembalikan ke member" │
│ · Pencairan 3-pihak: "Sudah │
│ cair ke bank" │
│ Dua sisi tidak sama → risiko │
│ kerugian dana │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4) Bila perlu, konfirmasi detail │
│ langsung ke staf pencairan │
│ (kalau info bot kurang jelas) │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (5) Setelah inspeksi selesai, balas │
│ ke Keuangan sesuai hasil │
│ Contoh: │
│ · "Pesanan XXXX kesalahan │
│ manual" │
│ · "Pesanan XXXX 3-pihak masih │
│ diproses" │
│ · "Pesanan XXXX normal sudah │
│ cair" │
└────────────────────────────────────┘
Klasifikasi umum hasil inspeksi:
| Hasil | Arti | Tindak lanjut |
|---|---|---|
| Kesalahan manual | Pihak ketiga sudah cair, tapi back-office ditolak manual → member dapat dobel | Balas Keuangan "Pesanan XXXX kesalahan manual", Keuangan/Ketua Tim memutuskan cara recovery |
| 3-pihak masih diproses | Pesanan pencairan belum ada status final | Balas Keuangan "Pesanan XXXX 3-pihak masih diproses", tunggu status final baru dinilai |
| Normal sudah cair | Kedua sisi status & jumlah sama, tidak ada kerugian | Balas Keuangan "Pesanan XXXX normal sudah cair", kejadian ditutup |
📝 Sumber: Pembelajaran & diskusi
Catatan: - Jangan langsung balas Keuangan tanpa perbandingan back-office — status back-office dan status 3-pihak harus terlihat di kedua sisi sebelum bisa dikategorikan - Kesalahan manual adalah titik kerugian paling umum, terutama saat skenario timeout antarmuka pencairan 4.11 ketika keputusan manual salah - Kata-kata balasan ke Keuangan harus presisi ("kesalahan manual" / "3-pihak masih diproses" / "normal sudah cair") — jangan deskripsi yang ambigu - Semua hasil inspeksi catat di spreadsheet shift untuk rekap dan serah terima
🤖 Peluang otomatisasi: Status pesanan back-office + query bot grup pencairan + klasifikasi hasil — ketiga langkah ini bisa dibuat tool inspeksi satu-klik: Wakil Ketua Tim paste nomor pesanan, tool otomatis ambil status dari kedua sumber dan membandingkan, beri saran klasifikasi, Wakil Ketua Tim konfirmasi lalu satu-klik balas Keuangan.
Lima, Penanganan Masalah Umum¶
5.1 Member Lupa Kata Sandi Login¶
Prinsip inti: Verifikasi kepemilikan adalah gerbang pertama. Setiap permintaan perubahan kata sandi/hak akses, WAJIB verifikasi kepemilikan terlebih dahulu sebelum bertindak.
Cara penanganan (BUKAN hapus, melainkan reset): Di back-office, reset kata sandi login menjadi 6 digit angka acak → kirim "User ID + kata sandi acak" ke grup CS → CS arahkan member login dengan kata sandi baru → member login lalu mengubah sendiri kata sandinya.
| Status Member | Bukti yang Diperlukan | Tindakan |
|---|---|---|
| Belum pernah deposit | Tidak ada (tidak ada titik jangkar kepemilikan) | Langsung reset jadi 6 digit acak → kirim ke grup CS |
| Pernah deposit | Berikan bukti deposit terakhir (screenshot + nomor pesanan + bukti transfer bank) — pakai deposit sukses terakhir user; tidak ada batas jendela waktu | Setelah verifikasi lolos, alur sama: reset jadi 6 digit acak → kirim ke grup CS |
📝 Sumber: Pembelajaran & diskusi
CS meneruskan: "Member X lupa kata sandi login"
│
▼
┌────────────────────────────────┐
│ Masuk profil member → Cek │
│ catatan deposit │
└──────────┬─────────────────────┘
│
▼
Ada catatan deposit?
├─ Tidak → Reset kata sandi jadi 6 digit acak
│ → Kirim "User ID + kata sandi baru" ke grup CS
│ → CS arahkan member login dengan kata sandi baru
│ → Member ubah sendiri kata sandinya
│
└─ Ada → Minta bukti deposit terakhir
│
▼
Bukti terverifikasi?
├─ Ya → Reset kata sandi jadi 6 digit acak
│ → Kirim "User ID + kata sandi baru" ke grup CS
│ → CS arahkan member login dengan kata sandi baru
│ → Member ubah sendiri kata sandinya
└─ Tidak → Tolak + beritahu CS "bukti tidak cocok"
Catatan: 1. JANGAN hapus kata sandi — reset menjadi 6 digit acak supaya member masih bisa login dan ubah sendiri 2. "User ID + kata sandi acak" hanya dikirim ke grup CS, tidak ke grup lain 3. Setelah reset, instruksikan CS "arahkan member segera ubah kata sandi setelah login" — hindari penyalahgunaan kata sandi sementara
5.2 Member Lupa Kata Sandi Penarikan¶
Penting: Kata sandi penarikan di back-office hanya bisa "dihapus" tidak bisa "diubah", member harus mengatur ulang saat penarikan berikutnya.
5.2.1 Persyaratan Bukti (dibagi berdasarkan apakah member pernah menarik sebelumnya)¶
| Status Member | Bukti ① | Bukti ② |
|---|---|---|
| Pernah menarik | Screenshot penarikan terakhir — diambil dari APP game kita, menunjukkan halaman "catatan penarikan" member (nominal / waktu / akun penerima) | Screenshot halaman profile akun bank/ewallet yang digunakan untuk penarikan — harus terlihat nama bank + beberapa digit pertama dan terakhir nomor akun, untuk cross-check |
| Belum pernah menarik | Screenshot deposit terbaru — diambil dari APP bank / APP dompet yang member pakai untuk deposit, menunjukkan catatan pembayaran (nominal / waktu / akun lawan) | Screenshot halaman profile akun bank/ewallet yang digunakan untuk penarikan — harus terlihat nama bank + beberapa digit pertama dan terakhir nomor akun, untuk cross-check |
Kedua bukti wajib ada — satu screenshot saja tidak cukup untuk verifikasi kepemilikan.
📝 Sumber: Pembelajaran & diskusi 📘 Sumber: 13-会员与风控/11-用户锁定列表 (kata sandi penarikan hanya bisa dihapus tidak bisa diubah)
5.2.2 Alur Pemrosesan¶
| Langkah | Tindakan | Penjelasan |
|---|---|---|
| 1 | Cek apakah akun sudah mengikat kata sandi penarikan | Belum mengikat → Ikuti alur pengikatan (bukan "lupa") |
| 2 | Sudah mengikat → Cek apakah member punya riwayat penarikan | Menentukan jalur bukti yang mana |
| 3 | Minta Bukti ① + ② sesuai 5.2.1 | Keduanya wajib |
| 4 | Cross-check screenshot dengan catatan di back-office | Nominal / waktu / digit akun semua harus cocok |
| 5 | Terverifikasi → Hapus kata sandi penarikan | Bukan "ubah" — back-office hanya bisa hapus |
| 6 | Cek apakah member ada di Daftar Penguncian User | Kalau iya perlu di-unlock |
| 7 | Kalau terkunci → buka hanya kunci login / taruhan / penarikan yang terkait | Hanya buka yang relevan untuk kasus ini, jangan buka semua |
| 8 | Balas grup CS / thread eskalasi — konfirmasi eksplisit selesai (hapus kata sandi; sebut unlock kalau ada) | Tutup loop |
| 9 | CS beritahu member: harus atur kata sandi penarikan baru saat penarikan berikutnya | CS beritahu terlebih dahulu supaya member tidak bingung |
CS meneruskan: "Member X lupa kata sandi penarikan"
│
▼
Cek apakah akun sudah mengikat kata sandi penarikan
├─ Tidak → Bukan "lupa", arahkan member ikuti alur
│ pengikatan pertama kali
│
└─ Ya → Cek riwayat penarikan
│
┌───────┴────────┐
▼ ▼
Pernah menarik Belum pernah menarik
│ │
▼ ▼
Minta 2 bukti Minta 2 bukti
① Screenshot ① Screenshot deposit
penarikan terbaru (dari APP
terakhir bank/dompet catatan
(dari APP game) pembayaran)
② Screenshot ② Screenshot profile
profile akun akun bank/ewallet
bank/ewallet (nama bank + digit
(nama bank + pertama/terakhir)
digit pertama/
terakhir)
│ │
└───────┬────────┘
▼
Bukti cocok?
├─ Tidak → Tolak + "bukti tidak cocok" + log operasi
│ ⚠️ Tidak boleh "kurang satu tapi diloloskan"
│
└─ Ya → Hapus kata sandi penarikan
│
▼
Cek apakah member ada di [Daftar Penguncian User]
│
┌───────┴────────┐
▼ ▼
Tidak ada Terdaftar
│ │
│ ▼
│ Buka kunci yang terkait
│ (login / taruhan / penarikan —
│ hanya yang relevan kasus ini,
│ jangan buka semua)
│ │
└───────┬────────┘
▼
Balas grup CS: selesai (hapus kata sandi; sebut unlock kalau ada)
▼
CS beritahu member: atur kata sandi baru di penarikan berikutnya
Catatan: 1. Jangan pernah bertindak hanya karena "satu pesan di grup" — harus melalui penerusan CS 2. Kedua bukti wajib ada — satu screenshot bisa saja curian; halaman profile untuk cross-check 3. Nama bank + digit pertama/terakhir pada Bukti ② harus cocok dengan akun penarikan yang terikat di back-office — ini kunci pertahanan dari social engineering 4. Hanya buka kunci yang relevan kasus ini (login / taruhan / penarikan) — JANGAN buka kunci risk-control lain hanya karena menangani "lupa kata sandi penarikan" 5. Semua operasi reset / hapus kata sandi / buka kunci harus tercatat di log operasi 6. Wajib balas thread eskalasi untuk konfirmasi selesai — tanpa balasan = belum selesai, tutup loop 7. Saat risiko tinggi (menjelang penarikan besar, login dari IP asing) → Eskalasi ke supervisor untuk verifikasi ulang
5.2.3 Mekanisme Tingkat "Verifikasi Sekunder/Data" (Keamanan Reset Kata Sandi)¶
Latar Belakang: Pernah ditemukan ada pekerja jarak jauh yang memanfaatkan proses reset kata sandi untuk membajak akun member dan menarik dana ke akun mereka sendiri. Untuk mencegah kejadian serupa, ditambahkan tingkat "Verifikasi Sekunder/Data" — member yang dimasukkan ke tingkat ini akan memiliki semua permintaan penarikan dialihkan ke review manual, dengan verifikasi ketat oleh Wakil Ketua Tim.
Dua tim yang terlibat:
| Tim | Tanggung Jawab | Pemicu |
|---|---|---|
| Tim RESET | Saat mereset PIN penarikan, konfirmasi di Signal apakah operasi terjadi pada hari yang sama / baru-baru ini → setelah dikonfirmasi, nonaktifkan penarikan otomatis + masukkan member ke tingkat "Verifikasi Sekunder/Data" | Saat member meminta perubahan PIN |
| Wakil Ketua Tim (Tim WD) | Review pesanan penarikan dari member tingkat "Verifikasi Sekunder/Data", putuskan apakah disetujui | Saat member di tingkat ini mengajukan pesanan penarikan |
Alur Operasi Tim RESET:
Member meminta reset PIN penarikan
│
▼
┌────────────────────────────────────┐
│ Cari akun member di Signal — │
│ konfirmasi apakah ada perubahan │
│ PIN hari ini atau baru-baru ini │
└──────────┬─────────────────────────┘
│
▼
Terkonfirmasi valid?
├─ Tidak → Tangani sesuai alur normal
│
└─ Ya → Lakukan hal berikut:
│
▼
┌────────────────────────────────┐
│ (1) Nonaktifkan penarikan │
│ otomatis untuk member ini │
│ (2) Masukkan ke tingkat │
│ "Verifikasi Sekunder/Data" │
│ (3) Tambahkan catatan: │
│ "WD perlu konfirmasi │
│ sekunder, apakah data │
│ penarikan lama" │
└────────────────────────────────┘
⚠️ Hari yang sama ubah kata sandi login + kata sandi penarikan: Jika ditemukan member mengubah kata sandi login dan kata sandi penarikan pada hari yang sama, bisa langsung dimasukkan ke tingkat "Verifikasi Sekunder/Data".
📝 Sumber: Pembelajaran & diskusi
Alur Review Wakil Ketua Tim (Tim WD):
Setelah menerima pesanan penarikan dari member tingkat "Verifikasi Sekunder/Data":
Pesanan penarikan diterima, catatan:
"WD perlu konfirmasi sekunder,
apakah data penarikan lama"
│
▼
┌────────────────────────────────────┐
│ Verifikasi: ke akun mana member │
│ melakukan penarikan? │
└──────────┬─────────────────────────┘
│
┌───────┴───────┐
│ │
Akun WD lama Akun WD baru
(data penarikan (data penarikan
lama) baru)
│ │
▼ ▼
┌──────────┐ ┌──────────────────────┐
│ ✅ Setuju │ │ ❌ Tolak penarikan │
│ · Hapus │ │ · Nonaktifkan fungsi │
│ catatan │ │ penarikan │
│ · Proses │ │ · Saat CS menindak- │
│ pencair-│ │ lanjuti, minta │
│ an │ │ member memberikan │
│ normal │ │ verifikasi rekaman │
│ · Keluar- │ │ layar: buktikan │
│ kan dari│ │ akun penarikan baru│
│ "Verifi- │ │ milik mereka dan │
│ kasi │ │ dioperasikan │
│ Sekunder│ │ sendiri │
│ /Data" │ │ · Setelah rekaman │
└──────────┘ │ layar lolos │
│ → Proses pencairan │
│ → Keluarkan dari │
│ "Verifikasi │
│ Sekunder/Data" │
│ → Ubah ke tingkat │
│ member normal │
└──────────────────────┘
Tabel Referensi Cepat:
| Situasi | Tindakan | Alasan |
|---|---|---|
| Penarikan ke akun lama (data WD lama) | ✅ Hapus catatan + proses pencairan + keluarkan dari tingkat | Akun lama menunjukkan penarikan normal member sendiri |
| Penarikan ke akun baru (data WD baru) | ❌ Tolak + nonaktifkan penarikan + minta verifikasi rekaman layar | Akun baru mungkin diikat oleh pembajak akun; member harus membuktikan kepemilikan |
| Verifikasi rekaman layar lolos | ✅ Proses pencairan + keluarkan dari tingkat + ubah ke tingkat normal | Sudah dikonfirmasi sebagai operasi member sendiri |
📝 Sumber: Pembelajaran & diskusi
5.3 Jawaban Cepat Keluhan Aturan Aktivitas¶
Wakil Ketua Tim tidak merencanakan aktivitas, tapi CS akan meneruskan pertanyaan pengguna tentang aturan aktivitas. Berikut tabel jawaban cepat keluhan:
| Isi Keluhan | Jawaban Cepat | Poin Investigasi |
|---|---|---|
| "Tidak terima hadiah mingguan" | Cek penyelesaian Senin 04:00, batas deposit, periode kadaluarsa 7 hari | Sudah lewat kadaluarsa? |
| "Hadiah bulanan kadaluarsa bisa diisi ulang?" | Tidak bisa, kadaluarsa otomatis dari sistem | Jendela 30 hari adalah batas keras |
| "Kenapa harus turnover dulu baru bisa tarik?" | Semua bonus ada persyaratan volume taruhan, standar industri anti-arbitrase | Cek kelipatan spesifik |
| "Nominal hongbao berkurang" | Sistem membagikan nominal acak — bisa lebih besar atau lebih kecil, ini normal | Jelaskan mekanisme acak kepada user |
| "Sudah deposit tapi tidak dapat kualifikasi hongbao" | Baru diperbarui jam 00:00 keesokan hari | Konfirmasi titik waktu deposit |
| "Sudah capai target tantangan tapi tidak dapat hadiah" | Konfirmasi volume taruhan efektif | Tidak semua taruhan dihitung 100% |
📘 Sumber: 06-VIP奖励活动配置 + 07-投注闯关活动详解 + 08-红包雨活动功能
Titik Waktu Penting Hadiah VIP: - Hadiah Mingguan: Diselesaikan setiap Senin 04:00 Waktu Indonesia, klaim dalam 7 hari, kadaluarsa jika lewat - Hadiah Bulanan: Diselesaikan tanggal 1 setiap bulan 04:00 Waktu Indonesia, klaim dalam 30 hari, kadaluarsa jika lewat
Enam, Standar Kolaborasi & Komunikasi¶
6.1 Matriks Grup¶
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Grup Shift │ ←──→ │ Grup CS │ ←──→ │ Pengguna(App)│
│ (Kolaborasi │ │ │ │ │
│ internal) │ │ │ │ │
└──────┬───────┘ └──────────────┘ └──────────────┘
│
▼
┌──────────────┐
│ Grup Keuangan│ ← Pemotongan wajib dilaporkan
└──────────────┘
│
▼
┌──────────────┐
│ Grup Promosi│ ← Materi pemasaran, pemberitahuan aktivitas
└──────────────┘
📝 Sumber: Pembelajaran & diskusi
6.2 Matriks Notifikasi¶
| Skenario | Notif Grup CS | Notif Grup Keuangan | Pengumuman Grup |
|---|---|---|---|
| Buka/tutup hak akses (tanpa dana) | — | — | ✅ Klaim + selesai |
| Buka/tutup hak akses (termasuk penyesuaian) | — | ✅ Berisi nominal dan pengguna | ✅ |
| Tolak penarikan (bank maintenance) | ✅ | — | — |
| Tolak penarikan (akun tidak valid) | ✅ Berisi alasan penolakan | — | — |
| Tolak penarikan (kecurigaan arbitrase agen) | ✅ Format "review manual kontrol risiko" (jangan ungkap detail anti-fraud) | — | ✅ Jejak penguncian |
| Pemotongan selesai | ✅ Balas ke pengirim asli | ✅ Wajib lapor | — |
| Callback pesanan | — | — | ✅ Catat di spreadsheet |
| Push setiap shift selesai | — | — | ✅ Absen jejak |
📝 Sumber: Pembelajaran & diskusi
6.3 Konvensi Format Klaim¶
| Tindakan | Format | Penjelasan |
|---|---|---|
| Klaim | Balas pesan asli dengan OK atau ✅ centang |
Satu klik cepat, visual di grup |
| Selesai | Balas "Sudah diproses" + info penting | Seperti nama pengguna, nominal, jenis operasi |
| Terkait dana | Setelah selesai kirim juga ke Grup Keuangan | Penyesuaian wajib dilaporkan |
📝 Sumber: Pembelajaran & diskusi
Tujuh, Daftar Periksa Serah Terima Shift¶
7.1 Saat Menerima Shift (Anda adalah penerima)¶
- [ ] Baca spreadsheet shift sebelumnya, pahami pesanan/pemotongan/callback apa saja yang diproses
- [ ] Cek tugas yang belum diklaim/dituntaskan di grup
- [ ] Konfirmasi kode penukaran yang berlaku saat ini sudah diatur dan push sudah dikonfigurasi
- [ ] Periksa apakah tugas terjadwal Firebase sudah dikonfigurasi untuk titik waktu berikutnya
- [ ] Periksa apakah alarm pengingat sudah disetel (1 jam sebelum push)
7.2 Saat Menyerahkan Shift (Anda adalah penyerah)¶
- [ ] Lengkapi semua catatan pesanan / callback / pemotongan selama shift di spreadsheet
- [ ] Kirim rangkuman daftar callback pesanan dan total nominal ke grup
- [ ] Semua item yang belum dituntaskan diserahkan secara jelas ke penerima berikutnya dan dapatkan konfirmasi balasan
- [ ] Situasi anomali (seperti gangguan sistem, penarikan belum selesai) ditandai secara khusus
- [ ] Kode penukaran yang akan digunakan shift berikutnya sudah disiapkan
📝 Sumber: Pembelajaran & diskusi
Delapan, Saran Otomatisasi¶
8.1 Pemikiran Umum¶
Pekerjaan harian Wakil Ketua Tim banyak berisi operasi rutin N platform x M kali/hari, setiap langkah adalah peluang kesalahan. API/tooling bisa:
| Aspek | Manual | API/Tool |
|---|---|---|
| Format data | Dicatat manual, gaya berbeda tiap kali | Schema memaksa konsistensi |
| Konsistensi proses | Mengandalkan memori, orang baru mudah melewatkan langkah | Kode menjamin, setiap kali sama |
| Keterlacakan kesalahan | Cari di riwayat chat + tanya orangnya | Log audit tercatat lengkap |
| Konsumsi energi | Berulang membosankan → kelelahan → lebih banyak kesalahan | Mesin tidak lelah |
Tanpa dukungan API back-office, masih banyak tempat yang bisa dikurangi pengulangan dan kesalahan manualnya melalui tool lokal.
8.1.1 Analisis Biaya Waktu Operasional (Perspektif Langsung Wakil Ketua Tim)¶
Data di bawah ini berasal dari operasi langsung di lapangan, bukan perkiraan.
Notifikasi push adalah lubang waktu terbesar dalam satu shift. 13 platform, 5 titik waktu per hari, setiap kali adalah murni copy-paste mekanis + klik tombol. Nol keputusan yang perlu dibuat.
| Tugas | Platform | Waktu pemula/sesi | Waktu berpengalaman/sesi | Frekuensi harian | Total harian per grup (berpengalaman) |
|---|---|---|---|---|---|
| Push Firebase | 13 | ~60 menit | ~30 menit | 5x | 2,5 jam |
| JPush (5x) + Pesan Dalam Aplikasi (1x, digabung) | 13 | ~50 menit | ~30–40 menit | JPush 5x / PDA 1x | 2–2,7 jam |
| Pembuatan kode penukaran (sekali saat rotasi) | 13 | ~30 menit | ~15–20 menit | 1x | ~15–20 menit |
| Total terkait push | ~5–6 jam/hari |
📝 Sumber: Pembelajaran & diskusi
Wawasan utama: Dalam shift siang 12 jam, tugas mekanis terkait push saja menyita 40–50% waktu. Peran Wakil Ketua Tim dalam tugas-tugas ini pada dasarnya adalah mesin copy-paste manusia, bukan pengambil keputusan.
Perbandingan sebelum vs. sesudah otomatisasi:
| Tugas | Saat ini (manual) | Setelah otomatisasi | Pergeseran peran Wakil Ketua Tim |
|---|---|---|---|
| Push Firebase | 30 menit × 5 = 2,5 jam per sesi | ✅ Skrip otomatisasi Tampermonkey sudah dikembangkan, sangat mengurangi copy-paste | Atur teks + lihat hasil pengiriman |
| Push JPush | 13 platform per sesi | ✅ Skrip otomatisasi Tampermonkey sudah dikembangkan, sangat mengurangi copy-paste | Cek efektivitas pengiriman |
| Pesan Dalam Aplikasi | hanya 19:00 kirim manual | Upgrade back-office: centang satu-klik kirim terjadwal ~5 menit/hari | Cek efektivitas pengiriman |
| Kode penukaran | Buat manual 15–20 menit | Back-office otomatis buat terjadwal + terhubung ke push ~0 menit | Sesuaikan jumlah/nominal berdasarkan data klaim/jangkauan hari sebelumnya |
| Total | ~5–6 jam/hari | ~15–20 menit/hari | Dari eksekutor → pemantau + analis |
📝 Sumber: Pembelajaran & diskusi
Mengapa kode penukaran tidak perlu dibuat manual: Kode penukaran adalah kode 4 karakter yang dibuat secara acak. Manusia tidak lebih andal dari kode dalam "membuat angka acak" — justru sebaliknya, operasi copy-paste manual lebih rawan kesalahan (paste ke platform yang salah, salah ketik kode, lupa update kode lama di teks push). Back-office bisa: otomatis buat kode setiap hari sesuai jadwal → otomatis terhubung ke JPush dan Pesan Dalam Aplikasi → manusia cukup menyesuaikan jumlah dan nominal penukaran berdasarkan data klaim dan jangkauan setiap situs di hari sebelumnya.
Ke mana waktu yang dibebaskan harus diinvestasikan: - Monitoring tingkat keberhasilan saluran pay-in/pay-out — butuh penilaian manusia tentang kesehatan saluran dan identifikasi tren anomali - Investigasi mendalam audit penarikan — deteksi pola perilaku bawahan anti-arbitrase agen butuh pengalaman dan penilaian - Analisis pesanan anomali keuangan — identifikasi kesalahan manusia butuh perbandingan silang dua sistem - Analisis data dan optimasi operasional — menganalisis efektivitas push dan menyesuaikan strategi lebih berharga dari mengeksekusi push
Satu kalimat: Bebaskan manusia dari "mengerjakan hal yang seharusnya dikerjakan mesin" supaya bisa mengerjakan "hal yang hanya bisa dikerjakan manusia."
8.2 Tabel Ringkasan Tool¶
| # | Tool | Pain Point | Perlu API? | Prioritas | Catatan |
|---|---|---|---|---|---|
| T1 | Generator copywriting kode penukaran | N platform ganti copywriting manual | Tidak (murni frontend/Sheets) | ⭐⭐⭐ | Paling mudah menghasilkan efek |
| T2 | Pipeline data pencairan bonus | Ekspor→filter→hitung→isi template | Tidak (Python/Node) | ⭐⭐⭐ | Paling hemat waktu |
| T3 | Tool filter daftar SMS | Filter nomor HP manual | Tidak (Python/Excel macro) | ⭐⭐ | |
| T4 | Pengingat irama push | Mengingat waktu manual | Tidak (cron/alarm HP) | ⭐⭐ | |
| T5 | Detektor pola perilaku bawahan agen | Deteksi otomatis pola deposit/turnover bawahan | Perlu | ⭐⭐ | |
| T6 | Rotator teks push | Memilih teks tetap manual | Tidak (tool lokal) | ⭐⭐ | Tidak berulang dalam 24 jam |
| T7 | Otomatisasi push multi-platform | Firebase/JPush xN situs copy-paste mekanis | Tidak (Tampermonkey) | ⭐⭐⭐⭐ | ✅ Skrip Tampermonkey Firebase + JPush sudah siap |
| T8 | Monitoring peringatan selisih dep-pen | Cek laporan harian per platform+hitung manual | Perlu | ⭐⭐⭐⭐⭐ | |
| T9 | Automasi 20:00 (inspeksi+cashback) | Satu cron selesaikan inspeksi+cashback | Perlu | ⭐⭐⭐⭐⭐ | T8+T9 digabung |
| T10 | Mesin penentuan otomatis catatan penarikan | 8 catatan x 3 situasi x 4 aturan keras | Perlu | ⭐⭐⭐⭐ |
Implementasi Bertahap:
┌─────────────────────────────────────────────────┐
│ ✅ Sudah Siap (Sudah Berjalan) │
│ T7 Push Terpadu (Tampermonkey Firebase + JPush) │
└───────────────────┬─────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ Bisa Langsung Dikerjakan (Tanpa API) │
│ T1 Generator Copy T2 Pipeline Data │
│ T3 Filter Daftar T4 Pengingat Irama │
│ T6 Rotator Teks │
└───────────────────┬─────────────────────────────┘
│ Setelah akumulasi pengalaman
▼
┌─────────────────────────────────────────────────┐
│ Perlu Dukungan Back-Office (Perlu API) │
│ T5 Deteksi Pola Agen │
│ T8 Monitoring Selisih Dep-Pen │
│ T9 Automasi 20:00 T10 Penentuan Catatan │
└─────────────────────────────────────────────────┘
Detail desain teknis dan dokumen kebutuhan API lihat: 12-自动化路线图/
8.3 Ringkasan Anotasi Otomatisasi per Alur Kerja¶
| Bab | Peluang Otomatisasi | Tool Terkait |
|---|---|---|
| 3.1 Notifikasi Push | ✅ Skrip Tampermonkey Firebase + JPush sudah siap, copy-paste mekanis→otomatis | T7 |
| 3.2 Kode Penukaran | Rotator teks, tidak berulang dalam 24 jam | T6 |
| 3.3 SMS Pemasaran | Filter tetap+copy tetap, ekspor satu klik | T3 |
| 3.3 Paket Batch (SMS + Bonus) | Pipeline data full, paling hemat waktu | T2 |
| 3.5 Selisih Dep-Pen+Cashback | Baca angka→bandingkan ambang→kirim notifikasi, otomatisasi paling murni | T8+T9 |
| 4.1 Audit Penarikan | Mesin aturan ganti memori otak | T10 |
| 4.1.5 Audit Agen | Otomatis deteksi pola perilaku bawahan | T5 |
Sembilan, Daftar Masalah yang Perlu Dikonfirmasi¶
Hanya item yang benar-benar masih open. Item lain di daftar sebelumnya sudah diintegrasikan ke teks utama atau sudah ditangani oleh toolkit tools/.
9.1 Batas Reset Kata Sandi Penarikan¶
- [ ] Batas jumlah percobaan reset kata sandi penarikan? (Kemungkinan ada petunjuk di 11-Daftar Penguncian User)
9.2 Daftar Lengkap Jenis Penguncian¶
- [ ] Daftar lengkap semua jenis penguncian di Daftar Penguncian User yang dirujuk dari 5.2.2. (Teks utama hanya konfirmasi login / taruhan / penarikan sebagai jenis umum; rujuk manual platform untuk daftar lengkap.)
9.3 Timeout Pencairan¶
- [ ] Detail mekanisme retry / callback saluran pihak ketiga setelah 4.11 timeout antarmuka pencairan? (Wakil Ketua Tim saat ini hanya operasi UI "cek status + Re-payout / Merchant Sudah Bayar"; kebijakan retry pihak ketiga mendasar perlu di-align dengan tim teknis.)
Sepuluh, Akumulasi Pengalaman & Pelajaran¶
Disiapkan untuk terus ditambah dari pekerjaan sehari-hari. Setiap menemui pengalaman atau jebakan yang tidak jelas, catat satu entri.
10.1 Jebakan yang Pernah Dialami¶
| Tanggal | Skenario | Cara yang Salah | Cara yang Benar | Alasan |
|---|---|---|---|---|
| — | — | — | — | — |
10.2 Pengalaman Efisiensi¶
| Tanggal | Skenario | Cara | Efek |
|---|---|---|---|
| — | — | — | — |
10.3 Penilaian Batasan¶
| Tanggal | Situasi | Penilaian | Dasar |
|---|---|---|---|
| — | — | — | — |
Lampiran A · Kartu Referensi Cepat (Versi Cetak)¶
┌──────────────────────────────────────────┐
│ Jadwal Push │
│ ━━━━━━━━━━━━━━━━━━━━ │
│ Shift Malam 00:00 │
│ Shift Siang 11:00 / 15:00 / 19:00 / 21:00│
│ │
│ Setiap push = Firebase(otomatis) │
│ + Jpush(manual); Pesan Dalam Aplikasi │
│ hanya 19:00 (manual) + Hapus pesan lama │
│ │
│ Pesan Dalam Aplikasi WAJIB pakai editor │
│ kode untuk tempel HTML │
│ │
│ Setel alarm 1 jam sebelumnya! │
└──────────────────────────────────────────┘
┌──────────────────────────────────────────┐
│ Referensi Cepat Catatan Penarikan │
│ ━━━━━━━━━━━━━━━━━━━━ │
│ 1 Penarikan agen ... Alur 4.1.5 cek pola │
│ 2 Level tdk izinkan . Audit akun penuh │
│ 3 Otomatis gagal .... Cek status pesanan │
│ → tangani sesuai │
│ 4 Melebihi maks ..... Audit lengkap dulu │
│ 5 2mnt 4x ........... Pertama: cek saldo │
│ 6 Turnover deposit Langsung lolos │
│ pertama kurang │
│ 7 Limit saluran ..... Konfirmasi merchant│
│ → ganti wallet │
│ 8 Pencairan gagal ... Cek status pesanan │
│ + konfirmasi 3rd │
└──────────────────────────────────────────┘
┌──────────────────────────────────────────┐
│ Pesanan penarikan: Kunci dulu! │
│ ━━━━━━━━━━━━━━━━━━━━ │
│ Penarikan agen → Cek pola bawahan │
│ → Putusan berdasarkan Standar Pertama │
│ Gagal otomatis biasa → Cek status pesanan│
│ · Masalah akun → Tangani per status │
│ · Bank maintenance → Tolak+notif CS │
│ · Limit saluran → Konfirmasi merchant │
│ · Level larang otomatis → Audit dulu │
└──────────────────────────────────────────┘
┌──────────────────────────────────────────┐
│ Alur Proses Pemotongan │
│ ━━━━━━━━━━━━━━━━━━━━ │
│ Klaim → Cek saldo → Pemotongan → │
│ Balas CS │
│ → Lapor Grup Keuangan │
│ (Platform/ID/Nominal/Alasan) │
└──────────────────────────────────────────┘
Lampiran B · Indeks Dokumen Terkait¶
Pengetahuan Umum Industri (Segmen 00-10)¶
- 04-运营体系/03-奖励体系设计 — Nominal bonus, persyaratan volume taruhan, strategi anti-penyalahgunaan
- 04-运营体系/05-客服运营 — Alur lengkap kolaborasi dengan tim CS
- 06-合规法务/02-KYC与AML — Latar belakang kepatuhan audit penarikan
- 07-财务支付/02-支付体系与通道 — Latar belakang teknis mengapa penarikan otomatis bisa gagal
- 10-业务知识库/00-通用管理知识/01-团队管理基础 — Bagaimana Wakil Ketua Tim melakukan 1:1 dan pembangunan tim
- 10-业务知识库/00-通用管理知识/02-远程团队协作 — Komunikasi asinkron, rantai alat, manajemen zona waktu
Panduan Platform Feifan (11-平台手册/非凡包网/)¶
Indeks lengkap: 11-平台手册/非凡包网/README.md
| # | Dokumen | Bab Terkait dalam Panduan Ini |
|---|---|---|
| 01 | Penjelasan Detail Fungsi Pencairan Otomatis | 4.1.2 |
| 03 | Cara Perhitungan Turnover Efektif | 4.5 |
| 04 | Investigasi Masalah Larangan Taruhan | 4.6 |
| 05 | Pembatalan Deposit Pesanan | 4.2 |
| 06 | Konfigurasi Aktivitas Hadiah VIP | 5.3 |
| 07 | Penjelasan Detail Aktivitas Tantangan Taruhan | 5.3 |
| 08 | Fungsi Aktivitas Hujan Hongbao | 5.3 |
Peta Jalan Otomatisasi (12-自动化路线图/)¶
- README — Gambaran umum segmen
- 01-Dokumen Kebutuhan API Audit Penarikan Agen — API P1 paling prioritas
Lampiran C · Panduan Penggunaan Toolbox Wakil Ketua Tim¶
Alamat tool: https://igaming-t1.pages.dev/ Kata sandi akses: igaming2026 Teknologi: Cloudflare Pages + murni frontend (nol kebocoran data) Kata sandi admin: Hubungi Bob untuk mendapatkan (digunakan untuk mengedit konfigurasi platform)
Prinsip Utama¶
- Nol kebocoran data: CSV / nomor HP / nominal semuanya diproses secara lokal di browser, dihapus saat halaman di-refresh
- Sinkronisasi cloud untuk konfigurasi: Rumus tingkatan, informasi platform, dan aturan bisnis lainnya disinkronkan melalui CF KV, satu orang mengubah = semua orang mendapat pembaruan
- Tanpa instalasi: Langsung buka di browser, tidak perlu instalasi software apapun (kecuali skrip FCM)
C.1 Ringkasan Tool¶
Toolbox mencakup 14 Tab fungsi, mencakup seluruh operasi repetitif shift siang dan malam Wakil Ketua Tim:
| Nama Tab | Ikon | Alur Kerja Terkait | Deskripsi Singkat |
|---|---|---|---|
| 兑换码 (Kode Tukar) | 🎲 | §4.1 Manajemen kode tukar | Generate kode tukar 4 digit harian, tidak berulang 30 hari, sinkronisasi cloud |
| 兑换码站内信 (Surat Internal Kode Tukar) | ✉️ | §4.1 Push surat internal | Generate HTML surat internal per platform × tanggal (kode tukar + promosi deposit) |
| SMS 回访 (SMS Kunjungan Ulang) | 📱 | §4.2 SMS kunjungan ulang | 3 arah teks SMS salin sekali klik, termasuk Leet Speak anti-deteksi |
| 推送文案 (Teks Push) | 🔔 | §4.1 Push | Teks push Firebase/Jpush (dengan kode + 12 aktivitas umum) |
| 新人首充 (Bonus Deposit Pertama Member Baru) | 🎁 | Konsultasi member | Input nominal deposit → hitung bonus/syarat TO secara real-time, generate skrip bahasa Indonesia sekali klik |
| 回访彩金助手 (Asisten Bonus Kunjungan Ulang) | 🗄️ | §4.3 Pemberian bonus | Upload 3 CSV → otomatis terapkan rumus → hasilkan XLSX + TXT |
| 周拉回 (Tarik Balik Mingguan) | 🔄 | §4.2 Tarik balik mingguan | Persiapan Jumat kirim Sabtu, bonus 0.88 + nomor HP TXT |
| 每日返水 (Rebate Harian) | 🪙 | §4.13 Inspeksi selisih deposit-penarikan | Platform dengan selisih >10% pada 20:00, deposit × 2% rebate |
| 交班汇报 (Laporan Serah Terima) | 📋 | §4.7 Serah terima shift | Input nomor pesanan cepat, generate laporan serah terima + arsip cloud sekali klik |
| SMS 测试 (SMS Test) | 🧪 | Verifikasi SMS API | Kirim test satuan/massal, termasuk log kirim dan query status |
| SMS 监控 (SMS Monitoring) | 📡 | Operasi SMS | Ringkasan pengiriman hari ini, TOP gagal, status Cron polling, pelengkapan otomatis |
| 客损拉回 (Tarik Balik Kerugian Pelanggan) | 📊 | Pelacakan efektivitas | Upload CSV kunjungan ulang keesokan hari untuk hitung rasio tarik balik, tren 7/30 hari |
| FCM | 🔥 | §4.1 Jadwal push | Persiapkan Campaign Firebase push hari berikutnya, kerja sama dengan Tampermonkey auto-fill |
Fungsi tambahan (pojok kanan atas):
| Fungsi | Keterangan |
|---|---|
| Jam WIB | Menampilkan waktu Indonesia real-time (UTC+7), dengan hitung mundur tugas berikutnya |
| Ganti grup | Pilih grup platform yang sedang dioperasikan (A/B/...), hanya tampilkan platform grup tersebut |
| Ganti bahasa | 中文 / English / Indonesia tiga bahasa |
| Tombol管理 (Manajemen) | Masukkan kata sandi admin untuk membuka kunci dan mengedit konfigurasi platform |
| Sinkronisasi cloud | Klik untuk menarik konfigurasi terbaru dari cloud secara manual |
C.2 Panduan Penggunaan Setiap Tab¶
C.2.1 兑换码 (Manajemen Kode Tukar)¶
Fungsi: Generate kode tukar 4 digit hari ini/besok untuk semua platform.
Aturan utama: - 4 digit angka, ramah Indonesia (menghindari angka berulang / angka berurutan) - Tidak berulang 30 hari untuk platform yang sama - Tidak berulang antar platform pada hari yang sama - Bisa centang "优先双连数字" (prioritas angka ganda berurutan, misalnya 5588), jika tidak cukup gunakan tiga berurutan (misalnya 1888)
Langkah operasi: 1. Klik 「生成今日全部」 (Generate semua hari ini) → Semua platform otomatis generate kode hari ini 2. Klik 「生成明日全部」 (Generate semua besok) → Pre-generate kode besok (untuk desainer membuat gambar lebih awal) 3. Klik 「复制今日」 (Salin hari ini) → Semua kode platform disalin ke clipboard 4. Klik 「复制明日（给美工）」 (Salin besok untuk desainer) → Kode besok disalin untuk desainer membuat gambar 5. Jika perlu mengubah kode satu platform: Klik tombol 「修改」 (Ubah) pada kartu platform, masukkan kode baru yang sudah diatur di backend
Catatan penting: - Setelah generate ada kunci waktu, tidak bisa generate ulang di hari yang sama (terbuka setelah 22:00 WIB saat pergantian shift) - Generate ulang akan menimpa kode lama, mempengaruhi gambar desainer, konfigurasi backend, teks yang sudah dikirim — operasikan dengan hati-hati - Setelah kode di-generate, sinkronisasi cloud, rekan lain refresh halaman langsung bisa melihat
C.2.2 兑换码站内信 (Surat Internal Kode Tukar)¶
Fungsi: Generate dua konten surat internal per platform (notifikasi kode tukar + promosi deposit), bisa langsung salin-tempel ke backend.
Langkah operasi: 1. Pilih mode: 「单平台」 (Satu platform) atau 「批量全部」 (Batch semua) 2. Mode satu platform: Pilih platform → Klik「生成」(Generate) 3. Mode batch: Klik「一键生成全部」(Generate semua sekali klik) → Surat internal semua platform di-generate sekaligus 4. Setiap platform menghasilkan dua kartu: - Surat internal ① · Kode tukar: Berisi nama platform, kode tukar, link sosial, 15 set teks berrotasi otomatis berdasarkan tanggal - Surat internal ② · Promosi deposit: Template HTML berwarna (judul merah + teks tebal hitam) 5. Klik 「复制（带格式）」 (Salin dengan format) → Tempel ke editor rich text backend otomatis dengan warna/tebal/link 6. Klik 「源码」 (Kode sumber) → Salin HTML mentah, perlu beralih ke "mode kode" di backend untuk menempel
Catatan penting: - Kode tukar berasal dari Tab「兑换码」yang sudah di-generate, jika perlu ganti ubah dulu di sana - 15 set teks berrotasi berdasarkan tanggal 1-15 / 16-30 siklus ganda, berganti otomatis setiap hari - Jika suatu platform tidak punya template teks asli, akan menampilkan peringatan fallback
C.2.3 SMS 回访 (SMS Kunjungan Ulang)¶
Fungsi: Generate teks SMS per platform berdasarkan arah kunjungan ulang, termasuk pool pengiriman massal.
3 arah kunjungan ulang:
| Arah | Target Pengguna | Teks Terkait | Konten Utama |
|---|---|---|---|
| A · Belum deposit | Terdaftar tapi belum deposit | smsText1 | Deposit pertama 100% + kode tukar 88K + hujan hongbao 99K + roda putar 1000K |
| B · Sudah deposit | Ada riwayat deposit (kerugian pelanggan/deposit kemarin/deposit sebelumnya) | smsText2 | Bonus keberuntungan 30X + VIP 100,000K + misi 9,999K |
| ZLH · Tarik balik mingguan | Daftar 30 hari + tidak login 10 hari + deposit ≥2 kali | smsTextZlh | Persiapan Jumat kirim Sabtu, teks khusus |
Langkah operasi: 1. Pilih arah kunjungan ulang (A / B / ZLH) 2. Halaman otomatis menampilkan teks terkait semua platform + preview simulasi HP 3. Klik tombol salin pada setiap kartu platform untuk mendapatkan teks 4. Pool pengiriman massal (area ungu di bawah): - Pilih tanggal data → Tampilkan daftar pending kirim hari itu - Centang item yang ingin dikirim - Konfigurasi nomor test (verifikasi penerimaan) - Klik「一键发送已勾选」(Kirim yang dicentang sekali klik)
Aturan pencocokan otomatis teks SMS (pool pengiriman massal):
- Sumber sms → Teks A belum deposit
- Sumber kslh / czlh / lh → Teks B sudah deposit
- Sumber zlh → Teks tarik balik mingguan
Catatan penting:
- Teks sudah dilengkapi penulisan Leet Speak anti-deteksi (misalnya k0de, cuma2, ga..c0r), jangan "perbaiki" itu
- Sebelum kirim, verifikasi konektivitas API di Tab「SMS 测试」terlebih dahulu
- Fungsi impor TXT manual ada di panel lipat, untuk pengiriman ulang/koreksi input
C.2.4 推送文案 (Teks Push)¶
Fungsi: Generate teks push untuk Firebase (Android/PWA) dan Jpush (iOS).
Dua mode:
Mode 1 · Push dengan kode tukar (per platform × tanggal): 1. Pilih batch (5 batch per hari, setiap batch dialokasikan varian teks acak berbeda) 2. Setiap platform menampilkan dua jenis teks Firebase dan Jpush 3. Tidak berulang lintas batch untuk platform yang sama, tidak berulang lintas platform untuk batch yang sama 4. Klik tombol salin untuk mendapatkan judul / Firebase / Jpush teks masing-masing
Mode 2 · Teks aktivitas umum (12 item, tanpa kode tukar): - Gaji permanen VIP, Rebate 3%, Program agen 5%, Bonus bantuan harian 25% - Kode tukar umum, Check-in 128K, Undang teman 25K, Bonus deposit 2500K - Cashback mingguan 30%, Referensi teman 1000K, Download APP 5000K, Akumulasi deposit 2500K
Langkah operasi: 1. Beralih ke sub-Tab「推送文案」→ Pilih batch 2. Klik「标题」(Judul)「Firebase」「Jpush」pada setiap kartu platform untuk salin masing-masing 3. Lanjutan: Bisa menentukan varian teks secara manual (buka panel lipat)
C.2.5 新人首充 (Kalkulator Bonus Deposit Pertama Member Baru)¶
Fungsi: Saat konsultasi member, cepat query bonus dan syarat TO sesuai nominal deposit.
9 tingkatan aturan:
| Tingkat | Deposit Minimum(K) | Bonus% | Kelipatan TO |
|---|---|---|---|
| A | 10 | 20% | 3x |
| B | 30 | 25% | 5x |
| C | 50 | 30% | 6x |
| D | 100 | 35% | 7x |
| E | 300 | 50% | 9x |
| F | 500 | 60% | 11x |
| G | 1,000 | 70% | 12x |
| H | 5,000 | 80% | 13x |
| I | 10,000 | 100% | 15x |
Langkah operasi: 1. Input nominal deposit (satuan K, 1K = 1,000 IDR) 2. Tampilan real-time: Tingkat yang cocok, nominal bonus, modal bermain, syarat TO 3. Klik「复制印尼语话术」(Salin skrip bahasa Indonesia) → Langsung kirim ke member
Rumus TO: Syarat TO = (Deposit + Bonus) x Kelipatan TO
C.2.6 回访彩金助手 (Asisten Bonus Kunjungan Ulang — Tool Inti Shift Siang)¶
Fungsi: Upload 3 CSV ekspor backend, otomatis filter / terapkan rumus / deduplikasi, hasilkan XLSX treasure chest + TXT nomor HP.
Langkah operasi: 1. Step 1: Pilih platform 2. Step 2: Upload 3 CSV: - ① Ekspor A · 用户回访 (Kunjungan ulang pengguna, pendaftaran T-1) - ② Ekspor B · 用户统计 (Statistik pengguna, member T-1) - ③ Ekspor C · 用户统计 (Statistik pengguna, member T-2) 3. Step 3 (opsional): Buka untuk melihat/mengubah konfigurasi rumus dan tingkatan 4. Step 4: Klik「一键处理」(Proses sekali klik) 5. Step 5: Download file output
Penjelasan rumus (lihat C.3 Panduan Modifikasi Konfigurasi untuk detail):
- Field input: profit_loss (selisih deposit-penarikan), bukan deposit
- Kalah (selisih deposit-penarikan < 0): Bonus tetap 0.38
- Menang: Cocokkan 9 tingkat bertingkat berdasarkan selisih deposit-penarikan, maksimum 777.77
- Kolom XLSX output: ID Member / Nominal Bonus Treasure Chest / Kelipatan TO (default 1) / Penggandaan deposit (default "开启")
Kebijakan privasi: - Data sensitif (CSV berisi ID member / nomor HP) → Parsing di sisi browser, hanya di memori, bersih saat refresh - Konfigurasi rumus → Sinkronisasi cloud CF KV, aturan bisnis non-sensitif
C.2.7 周拉回 (Tarik Balik Mingguan)¶
Fungsi: Tugas tarik balik yang dipersiapkan setiap Jumat dan dikirimkan pada Sabtu.
Kondisi filter (pembagian kerja): - Sudah difilter di backend (sebelum ekspor): ① Waktu pendaftaran dalam 30 hari ② Terakhir online > 10 hari - Otomatis difilter oleh tool (setelah upload): ③ Jumlah deposit >= 2 (anti-penyalahgunaan dan anti-bot)
Langkah operasi: 1. Atur tanggal dasar (default hari ini), pilih platform 2. Atur nominal pemberian (default 0.88) 3. Upload CSV kunjungan ulang pengguna yang sudah difilter berdasarkan kondisi di backend (mendukung pilih banyak file pecahan) 4. Klik「一键处理」(Proses sekali klik) → Hasilkan XLSX bonus + TXT nomor HP 5. Tambahan: Buka「日期计算器」(Kalkulator tanggal) untuk melihat timestamp filter 30 hari
C.2.8 每日返水 (Rebate Harian)¶
Fungsi: Inspeksi selisih deposit-penarikan 20:00 WIB, eksekusi pemberian rebate untuk platform dengan selisih > 10%.
Rumus: Bonus = Nominal deposit x 0.02 (default 2%)
Langkah operasi: 1. Pilih platform 2. Konfirmasi persentase rebate (default 0.02) 3. Upload CSV statistik pengguna platform hari itu 4. Klik「一键处理」(Proses sekali klik) 5. Tool otomatis: Filter deposit > 0 → Hitung bonus → Hapus baris bernilai 0 → Hasilkan XLSX treasure chest
Catatan penting: - Prasyarat: Hanya dieksekusi untuk platform dengan selisih deposit-penarikan > 10% di laporan harian backend, tool sendiri tidak menilai - Tidak di-deduplikasi dengan §4.3 bonus kunjungan ulang, pemberian independen
C.2.9 交班汇报 (Laporan Serah Terima)¶
Fungsi: Input cepat pesanan yang diproses selama shift, generate laporan serah terima sekali klik dan arsipkan.
Langkah operasi: 1. Isi nama pelapor serah terima (otomatis tersimpan) 2. Pilih platform → Input nomor pesanan → Enter untuk tambah cepat (1 pesanan = 10K) 3. Mode batch: Buka panel lipat → Tempel banyak baris nomor pesanan 4. Klik 「交班汇报」 (Laporan serah terima) → Otomatis salin laporan + arsip cloud + kosongkan daftar saat ini 5. Klik「历史归档」(Arsip riwayat) untuk query catatan serah terima sebelumnya
C.2.10 SMS 测试 (SMS Test)¶
Fungsi: Verifikasi konektivitas SMS API, test satuan dulu baru massal.
Tiga area: 1. Test satuan: Input nomor HP + isi SMS → Kirim test → Lihat hasil 2. Kirim massal TXT: Upload file nomor + teks kustom → Kirim massal (untuk pengiriman ulang/pengiriman manual) 3. Query status pengiriman: Input sendCode untuk query status penerimaan 4. Log pengiriman: 20 catatan pengiriman terakhir, termasuk daftar nomor lengkap dan status per nomor
C.2.11 SMS 监控 (SMS Monitoring)¶
Fungsi: Ringkasan penuh pengiriman SMS hari ini dan monitoring real-time.
Fungsi utama: - Ringkasan hari ini (volume pengiriman / tingkat keberhasilan / biaya) - Area nomor test (verifikasi apakah HP sendiri menerima) - Statistik breakdown per platform - Ranking TOP gagal (tidak termasuk nomor non-TK) - Status Cron polling (antrian persisten, konsumsi otomatis per menit untuk melengkapi status) - Pelengkapan semua status sekali klik / refresh manual
C.2.12 客损拉回 (Tarik Balik Kerugian Pelanggan)¶
Fungsi: Lacak efektivitas tarik balik setelah proses asisten bonus.
Langkah operasi: 1. Pilih tanggal (hari terjadinya kerugian pelanggan) 2. Tiga tampilan: Detail hari itu / Tren 7 hari / Statistik 30 hari 3. Klik「一键复制汇报」(Salin laporan sekali klik) → Generate laporan efektivitas tarik balik untuk ketua tim
Sumber data: Data kerugian pelanggan otomatis diarsipkan ke cloud saat diproses oleh asisten bonus.
C.2.13 FCM Console 助手 (Asisten FCM Console)¶
Fungsi: Persiapkan data Campaign push Firebase hari berikutnya dalam toolbox, kerja sama dengan skrip Tampermonkey untuk auto-fill di Firebase Console.
Langkah operasi: 1. Atur tanggal target (default otomatis: setelah 22:30 WIB otomatis beralih ke besok) 2. Halaman menampilkan semua Campaign yang perlu dibuat (5 titik waktu × N platform) 3. Klik「下载 Tampermonkey 脚本」(Download skrip Tampermonkey) untuk install skrip otomatisasi (lihat C.4 untuk detail) 4. Ke Firebase Console untuk operasi (lihat C.4 untuk detail)
C.3 Panduan Modifikasi Konfigurasi¶
Penting: Semua modifikasi konfigurasi memerlukan izin admin. Klik tombol「管理」(Manajemen) di pojok kanan atas → Masukkan kata sandi admin → Buka kunci.
C.3.1 Manajemen Daftar Platform¶
Lokasi: tools/t1-promo-copy/public/js/data.js → Array DEFAULT_PLATFORMS
Saat ini dikonfigurasi 14 platform (7777W, RP66, RPRR, RP55, YYRR, SL888, 888R, SL999, 99SL, RP99, 9SL, RK55, VC55, FW66).
Field yang dapat dikonfigurasi per platform:
| Field | Arti | Contoh |
|---|---|---|
id |
Identifikasi unik platform | '7777W' |
code |
Kode tukar default (biasanya kosong, di-generate otomatis oleh tool) | '' |
social.type |
Jenis platform sosial | 'Telegram' atau 'Facebook' |
social.color |
Warna brand (hex) | '#FF00FF' |
social.url |
URL link sosial | 'https://t.me/vip_7777w' |
social.label |
Teks tampilan link | 'Link Channel Telegram : ...' |
domain |
Domain platform (untuk teks SMS) | 'dge753.com' |
userCount |
Jumlah bukti sosial (untuk teks social proof) | 18599 |
maxReward |
Hadiah maksimum | '88K' atau '99K' |
pushImage |
Path ikon push | '/api/icon/7777W' |
backendUrl |
Alamat backend | 'https://demo.indback789.com/' |
letterHtml |
Template HTML surat internal | Berisi placeholder {KODE} |
group |
Grup yang dimiliki | 'A' |
smsText1 |
Teks SMS arah belum deposit | Format Leet Speak |
smsText2 |
Teks SMS arah sudah deposit | Format Leet Speak |
smsTextZlh |
Teks SMS tarik balik mingguan | Kosong berarti belum dikonfigurasi |
textColor |
Warna teks (platform khusus seperti 9SL menggunakan hitam) | 'black' |
Cara modifikasi online (direkomendasikan): 1. Klik「管理」(Manajemen) → Masukkan kata sandi untuk buka kunci 2. Edit langsung setiap field platform di panel manajemen 3. Klik「保存所有修改」(Simpan semua perubahan) → Otomatis sinkronisasi ke cloud 4. Rekan lain refresh halaman langsung bisa melihat pembaruan
Cara modifikasi kode (menambah platform baru):
1. Edit tools/t1-promo-copy/public/js/data.js
2. Tambahkan objek platform baru di akhir array DEFAULT_PLATFORMS
3. Deploy: cd tools/t1-promo-copy && npm run deploy
C.3.2 Template Teks Kode Tukar¶
Lokasi: data.js → Array KODE_VARIANTS (15 item)
15 set teks dipetakan ke tanggal bulanan berdasarkan field day (1-15), tanggal 16-30 menggunakan siklus ulang 1-15.
Field yang dapat dikonfigurasi per teks:
| Field | Arti |
|---|---|
day |
Nomor tanggal (1-15) |
styleKey |
Nama kunci gaya (misalnya var_urgent) |
title |
Template judul push (berisi placeholder {KODE}) |
alt_title |
Judul alternatif untuk platform tertentu |
alt_for |
Daftar platform yang menggunakan judul alternatif |
body |
Template isi (berisi placeholder {KODE}, {SOCIAL_PLATFORM}, {SOCIAL_LINK}, {USER_COUNT}, {MAX_REWARD}) |
Mengubah teks: Edit objek yang sesuai dengan day di data.js, pertahankan format placeholder.
C.3.3 Template Promosi Deposit¶
Lokasi: data.js → Konstanta DEPOSIT_PROMO_TEMPLATE
Ini adalah template HTML surat internal kedua, dengan gaya berwarna. Saat mengubah, pertahankan placeholder {MAX_REWARD} dan tag gaya HTML.
C.3.4 Konfigurasi Arah SMS Kunjungan Ulang¶
Lokasi: data.js → Array SMS_DIRECTIONS (3 item)
| ID Arah | Keterangan | Field Teks Terkait |
|---|---|---|
A |
Teks belum deposit | smsText1 |
B |
Teks sudah deposit | smsText2 |
ZLH |
Teks tarik balik mingguan | smsTextZlh |
Mengubah deskripsi arah atau field terkait: Edit array SMS_DIRECTIONS.
Mengubah isi teks SMS platform tertentu: Edit smsText1 / smsText2 / smsTextZlh pada objek platform tersebut.
C.3.5 Konfigurasi Teks Push Aktivitas¶
Lokasi: data.js → Array PUSH_ACTIVITIES (12 item)
Setiap aktivitas berisi:
| Field | Arti |
|---|---|
id |
Identifikasi aktivitas (misalnya vip_salary) |
label |
Label bahasa Mandarin |
title |
Judul push |
firebase |
Teks push Firebase (Android/PWA) |
jpush |
Teks push Jpush (iOS, dengan emoji) |
Mengubah teks aktivitas: Edit field firebase dan jpush pada aktivitas yang sesuai di array PUSH_ACTIVITIES.
C.3.6 Konfigurasi Rumus Bonus Kunjungan Ulang¶
Lokasi: tools/data/t2-reward/formula-config.v3.json
Parameter utama:
| Path Parameter | Nilai Saat Ini | Arti |
|---|---|---|
profiles.default.inputField |
profit_loss |
Field input = selisih deposit-penarikan (bukan nominal deposit) |
profiles.default.loserBonus |
0.38 |
Bonus tetap untuk yang kalah |
profiles.default.loserCondition |
profit_loss < 0 |
Kondisi penentuan kalah |
profiles.default.doubling |
true |
Apakah mengaktifkan tingkatan yang bisa digandakan |
9 tingkat bertingkat untuk pemenang (tingkat bisa digandakan):
| Tingkat | Ambang Selisih Deposit-Penarikan | Bonus |
|---|---|---|
| 1 | >= 44,444,444 | 777.77 |
| 2 | >= 33,333,333 | 577.77 |
| 3 | >= 2,222,222 | 107.77 |
| 4 | >= 1,000,000 | 50.77 |
| 5 | >= 1,000 | 8.80 |
| 6 | >= 500 | 5.50 |
| 7 | >= 200 | 2.80 |
| 8 | >= 50 | 1.80 |
| 9 | >= 10 | 1.08 |
Mengubah rumus bonus:
1. Edit tools/data/t2-reward/formula-config.v3.json
2. Ubah threshold (ambang) atau payout (bonus) di array tiersDoubling
3. Jika perlu mengubah bonus yang kalah, ubah nilai loserBonus
Konfigurasi template output XLSX:
| Path Parameter | Arti |
|---|---|
rewardTemplate.defaults.wagerMultiplier |
Kelipatan TO, default 1 |
rewardTemplate.defaults.rechargeDoubling |
Penggandaan deposit, default "开启" |
rewardTemplate.filterBonusZero |
Apakah filter baris bonus bernilai 0, default true |
rewardTemplate.platformOverrides |
Konfigurasi override platform tertentu (cadangan) |
C.3.7 Konfigurasi Bonus Tetap SMS¶
Lokasi: tools/data/t3-sms/sms-bonus-config.v1.json
| Platform | Bonus Tetap | Catatan |
|---|---|---|
| 7777W | 0.2 | Sudah dikonfirmasi |
| RP66 | 0.2 | Sudah dikonfirmasi |
| RP55 | 0.2 | Sudah dikonfirmasi |
| YYRR | 0.1 | Dokumen asli ambigu, sementara ditetapkan 0.1 |
| Platform lain | null | Belum dikonfirmasi, default menggunakan 0.1 |
C.3.8 Konfigurasi Tingkatan Bonus Deposit Pertama Member Baru¶
Lokasi: Konstanta BONUS_TIERS di dalam index.html (sekitar baris 3115)
Mengubah aturan tingkatan: Edit min (deposit minimum), pct (persentase bonus), to (kelipatan TO) pada setiap objek di array BONUS_TIERS.
C.3.9 Deploy agar Berlaku¶
Setelah semua modifikasi file kode, perlu deploy agar seluruh tim bisa melihat pembaruan:
cd tools/t1-promo-copy
npm run deploy
Deploy menggunakan Cloudflare Wrangler, konfigurasi di wrangler.toml:
- Nama proyek: igaming-t1
- Direktori output: public/
- KV binding: T1_DATA (penyimpanan data berbagi multi-perangkat)
Modifikasi online (melalui panel manajemen mengubah informasi platform) tidak perlu deploy, langsung tersinkronisasi ke KV saat disimpan.
C.4 Skrip Otomatisasi Push Firebase¶
C.4.1 Ringkasan¶
3F Firebase Console Helper adalah skrip pengguna Tampermonkey (versi saat ini v5.7.11), setelah diinstall otomatis menyisipkan overlay bantuan di halaman berikut:
- Firebase Console (
console.firebase.google.com): Auto-fill Campaign push - Backend platform (
*.indback789.com/*.indback666.com): Bantuan push Jpush + audit agen
C.4.2 Langkah Instalasi¶
- Install ekstensi browser Tampermonkey: https://www.tampermonkey.net/
- Penting: Setelah install masuk ke pengaturan Tampermonkey → Ubah Site access menjadi 「On all sites」 (jika tidak, skrip tidak akan berjalan otomatis)
- Dapatkan skrip (pilih salah satu):
- Di Tab「FCM」toolbox klik「下载 Tampermonkey 脚本」(Download skrip Tampermonkey)
- Langsung akses https://igaming-t1.pages.dev/3f-fcm-console-helper.user.js
- Tampermonkey menampilkan konfirmasi instalasi → Klik「安装」(Install)
- Skrip auto-update:
@updateURLdan@downloadURLsudah dikonfigurasi ke alamat toolbox
C.4.3 Alur Penggunaan Firebase Console¶
Skrip menampilkan badge merah/hijau (bisa digeser) di pojok kanan atas halaman Firebase Console, dan overlay operasi di sisi kanan halaman.
Alur operasi yang direkomendasikan: 1. Di Firebase Console Duplicate Campaign kemarin (mewarisi Target + gambar) 2. Masuk ke halaman edit 3. Di overlay kanan cari batch yang sesuai → Klik tombol 「🔥 填入」 (Isi) 4. Skrip otomatis mengisi field judul, isi, dll. 5. Ubah tanggal secara manual (jadwalkan pengiriman ke tanggal target) 6. Klik Publish → Kembali ke overlay klik 「✅ 已发」 (Sudah dikirim)
Mode tanggal (tiga tombol di bagian atas overlay): - ⏱ 自动 (Otomatis): Setelah 22:30 WIB otomatis beralih ke besok - 📅 今天 (Hari ini): Paksa menggunakan data hari ini - ➡️ 明天 (Besok): Paksa menggunakan data besok
C.4.4 Fungsi Backend Platform¶
Di halaman backend platform, skrip otomatis mengenali platform mana saat ini (melalui pemetaan hostname), menyediakan: - Halaman push Jpush: Bantuan mengisi konten push - Halaman audit agen: Bantuan deteksi tabrakan IP (default nonaktif, perlu diaktifkan manual)
Mengaktifkan fungsi audit agen (eksekusi di F12 Console):
localStorage.setItem('fcm_3f_agent_enabled', '1'); location.reload();
Menonaktifkan:
localStorage.removeItem('fcm_3f_agent_enabled'); location.reload();
C.4.5 Catatan Penting¶
- Badge dan overlay keduanya bisa digeser, posisi tersimpan otomatis
- Jika tidak terlihat badge/overlay, periksa pengaturan Site access Tampermonkey
- Skrip menggunakan DOM lock untuk mencegah injeksi ganda
- Mendukung navigasi halaman SPA (interval deteksi perubahan lingkungan secara berkala)
C.5 Pertanyaan yang Sering Diajukan¶
Q1: Halaman kosong setelah membuka toolbox?¶
- Periksa apakah jaringan bisa mengakses Cloudflare (beberapa wilayah mungkin perlu proxy)
- Hapus cache browser lalu coba lagi
- Konfirmasi alamat akses adalah https://igaming-t1.pages.dev/
Q2: Tombol generate kode tukar berwarna abu-abu dan tidak bisa diklik?¶
- Kode tukar sudah pernah di-generate hari itu, ada kunci waktu
- Tunggu setelah 22:00 waktu Indonesia (waktu pergantian shift) untuk terbuka
- Atau gunakan tombol「修改」(Ubah) untuk input manual kode yang sudah diatur di backend
Q3: Setelah upload CSV muncul pesan error format?¶
- Konfirmasi bahwa itu adalah CSV asli yang didownload dari fungsi「导出」(Ekspor) backend
- Nama file CSV harus diawali dengan nama platform (misalnya
SL888-用户统计xxx.csv) - Konfirmasi encoding CSV adalah UTF-8
- Jika file ekspor pecahan beberapa file, Tab 周拉回 mendukung pilih banyak
Q4: Setelah salin surat internal dan tempel ke backend tidak ada warna?¶
- Gunakan tombol「复制（带格式）」(Salin dengan format) (bukan tombol「源码」)
- Pastikan editor backend dalam mode rich text (bukan mode kode)
- Jika masih tidak berhasil, gunakan tombol「源码」→ Backend beralih ke mode kode → Tempel
Q5: Saldo pengiriman SMS 0?¶
- Hubungi Bob untuk top-up akun AboSend
- Di Tab「SMS 测试」lihat kartu saldo untuk mengetahui saldo saat ini
Q6: Setelah install skrip Tampermonkey tidak terlihat badge?¶
- Konfirmasi Site access Tampermonkey diatur ke 「On all sites」
- Di halaman target tekan F12 buka console, cari log
[3F-Helper] - Jika ada
重复注入检测 · 跳过artinya skrip di-load ganda, refresh halaman saja - Periksa apakah halaman adalah Firebase Console atau backend platform (skrip hanya bekerja di dua jenis halaman ini)
Q7: Sudah mengubah data.js tapi tim tidak melihat pembaruan?¶
- Setelah modifikasi file kode perlu deploy:
cd tools/t1-promo-copy && npm run deploy - Modifikasi online informasi platform melalui panel manajemen tidak perlu deploy, tersinkronisasi saat disimpan
Q8: Hasil proses asisten data tidak cocok dengan data backend?¶
- Konfirmasi menggunakan jenis CSV yang benar (用户回访 vs 用户统计)
- Konfirmasi tingkatan dan nilai bonus dalam konfigurasi rumus sesuai dengan aturan bisnis terbaru
- Field input adalah
profit_loss(selisih deposit-penarikan), bukandeposit(nominal deposit) - Jika ragu, di Step 3 buka panel konfigurasi rumus untuk memeriksa parameter saat ini
Q9: Apakah akan bentrok jika beberapa rekan beroperasi bersamaan?¶
- Kode tukar: Sinkronisasi cloud, yang terakhir menyimpan yang berlaku. Disarankan satu grup menunjuk satu orang untuk generate kode
- Modifikasi konfigurasi: Sama, yang terakhir disimpan menimpa sebelumnya
- Proses CSV: Komputasi lokal murni, tidak akan bentrok
- Laporan serah terima: Diarsipkan berdasarkan nama pelapor, tidak bentrok
Q10: Bagaimana cara backup/restore data?¶
- Di panel manajemen ada tombol「导出 v3 备份」(Ekspor backup v3), download backup JSON
- 「迁移 v3 → v4」(Migrasi v3 → v4) untuk migrasi data saat upgrade versi
- 「LS 用量诊断」(Diagnostik penggunaan LS) untuk melihat distribusi penggunaan localStorage
📝 Sumber: Pembelajaran & diskusi