07 · Panduan Kerja Supervisor¶

Berlaku untuk: Supervisor Operasional Sumber: Catatan pembelajaran + Tabel persiapan pembangunan situs baru Disusun oleh: Bob ｜ Tanggal: 2026-04-26 Status: Draf awal, terus diperbarui

Daftar Isi¶

I. Posisi Jabatan Supervisor
1.1 Lingkup Manajemen
1.2 Perbandingan Fokus Pekerjaan
II. Pekerjaan Manajemen Harian
2.1 Posisi Kerja Supervisor
2.2 Manajemen Personel
- 2.2.1 Konfigurasi Personel per Shift
- 2.2.2 Mekanisme Koordinasi dengan Spesialis Manajemen CS
2.3 Penanganan Masalah Platform
2.4 Pemantauan Efek Promosi
2.5 Penjadwalan dan Kepegawaian
2.6 Manajemen Pengeluaran Operasional Harian
2.7 Manajemen Pengujian Remote
2.8 Laporan Operasi Grup
2.9 Konfirmasi Distribusi Grup Pihak Ketiga Pembayaran
2.10 Pengelolaan Skrip CS dan Pelatihan
2.11 Materi UI dan Naskah
III. Alur Kerja Pembangunan Situs Baru
3.1 Ikhtisar Pekerjaan Pembangunan
3.2 Kategori Domain (9 item)
- 3.2.4 Buku Panduan Penanganan Pemblokiran Domain
3.3 Kategori Konfigurasi (11 item)
- 3.3.1 Alur Pendaftaran dan Negosiasi Harga JPush
- 3.3.2 Konfigurasi Nominal & Level Saluran Pembayaran
3.4 Kategori Desain Gambar (7 item)
3.5 Kategori Akun (4 item)
3.6 Kategori Pengujian (4 item)
3.7 Bagan Alir Pembangunan (termasuk Hubungan Paralel)
3.8 Ikhtisar Pembagian Tugas Pembangunan
IV. Pemantauan dan Penyesuaian Efek Promosi
4.1 Pemantauan Promosi Situs Baru
4.2 Pengujian Efek Pull-back Mingguan
V. Sistem Back-office HQ (houqin · Sedang Dicoba Secara Pribadi)
VI. Daftar yang Perlu Dikonfirmasi

I. Posisi Jabatan Supervisor¶

Pekerjaan Supervisor lebih condong ke manajemen personel, bukan operasi eksekusi konkret. Pekerjaan harian utamanya adalah menyelesaikan berbagai masalah yang muncul dalam operasi platform—lebih banyak masalah personel dan bisnis konkret, bukan masalah sistemik platform (masalah sistemik umumnya sudah diselesaikan di awal pembangunan situs).

1.1 Lingkup Manajemen¶

                    ┌──────────┐
                    │  Manajer │
                    └────┬─────┘
                         │
            ┌────────────┼────────────┐
            │                        │
      ┌─────▼─────┐           ┌─────▼──────┐
      │ Supervisor │           │ Supervisor │
      │ (Operasi) │           │   Audit    │
      └─────┬─────┘           └─────┬──────┘
            │                       │
     ┌──────┼──────┐                ▼
     │             │          Tim Audit Remote
┌────▼─────┐ ┌─────▼──────────┐
│  Wakil   │ │ Spesialis Mana-│
│Supervisor│ │ jemen CS       │
│ (Jaga)   │ │ (lapangan, CS) │
└────┬─────┘ └─────┬──────────┘
     │             │
     ▼             ▼
  Tim Jaga    Tim CS Remote

Supervisor dan Supervisor Audit memiliki hubungan paralel, masing-masing bertanggung jawab pada arah berbeda (operasi vs. risiko), bukan hubungan atasan-bawahan. Keduanya melapor kepada Manajer.

Jalur Eskalasi Masalah: Masalah personel remote → Penanggung jawab lapangan menangani lebih dulu → Tidak bisa diselesaikan/perlu keputusan → Diserahkan ke Supervisor/Supervisor Audit → Tetap tidak bisa → Diserahkan ke Manajer untuk keputusan

1.2 Perbandingan Fokus Pekerjaan¶

Dimensi	Wakil Supervisor	Supervisor Audit	Supervisor
Sifat pekerjaan	Operasi eksekusi	Audit risiko	Manajemen personel + Penyelesaian masalah
Fokus harian	Push/follow-up/audit penarikan	Pemeriksaan arbitrase/QC	Koordinasi tim/penyelesaian masalah/pemantauan efek/pengeluaran operasional
Tugas tetap	5x push/inspeksi selisih deposit-tarik	Audit agen/pemeriksaan anomali	Pembangunan situs baru (bertahap) + Pemantauan promosi + Pembayaran harian
Otoritas keputusan	Eksekusi sesuai standar	Penentuan arbitrase	Penyesuaian alur/perubahan parameter/penataan personel/pengeluaran dana

📝 Sumber: Diskusi pembelajaran

II. Pekerjaan Manajemen Harian¶

Pekerjaan harian Supervisor tidak seperti Wakil Supervisor yang memiliki jadwal ritmik tetap, lebih banyak bersifat responsif dan pemantauan:

2.1 Posisi Kerja Supervisor¶

Supervisor sendiri terutama bertanggung jawab pada pekerjaan bersifat keputusan dan audit, sementara pekerjaan eksekusi konkret dilakukan melalui pelatihan bawahan:

Yang Dilakukan Supervisor	Yang Dilakukan Bawahan
Keputusan dan audit	Operasi eksekusi konkret
Melatih Wakil Supervisor dan personel lain	Eksekusi sesuai alur standar
Menangani masalah personel lapangan	Masalah personel remote ditangani penanggung jawab lapangan dulu
Menangani masalah eskalasi yang tidak bisa diselesaikan	Masalah harian ditangani sendiri
Yang tidak bisa diselesaikan diserahkan ke Manajer	—

2.2 Manajemen Personel¶

Tim Bawahan: - Wakil Supervisor—Tim eksekusi jaga - Spesialis Manajemen CS—Lapangan, dirinya sendiri juga adalah CS, sekaligus mengelola tim CS Remote - ⚠️ Supervisor Audit tidak diatur oleh Supervisor—Keduanya berhubungan paralel, masing-masing melapor ke Manajer

2.2.1 Konfigurasi Personel per Shift¶

Setiap shift 6 orang di lapangan (1 orang cuti pada dasarnya tidak mengganggu operasional), dibagi menjadi 3 grup berdasarkan fungsi:

Posisi	Jumlah	Tanggung Jawab Utama	Panduan Kerja
Wakil Supervisor	2	Push/follow-up/audit penarikan/inspeksi selisih deposit-tarik/manajemen saluran pembayaran pihak ketiga	03-Panduan Onboarding Wakil Supervisor
Koreksi Data Member	2	Reset password login member, reset password penarikan (PIN), penggantian nomor rekening bank, pembukaan kunci akun, dan operasi perubahan data lainnya	03-Panduan Onboarding Wakil Supervisor · 5. Reset Password
Spesialis Manajemen CS	2	① Penanganan deposit yang tidak masuk ② Penanganan kartu macet penarikan ③ Manajemen harian tim CS Remote (jadwal/QC/pemantauan/pelatihan)	04-Panduan Spesialis Manajemen CS

  Konfigurasi 6 Orang per Shift di bawah Supervisor

</div>

</div>

</div>

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-03">

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-03">

</div>

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-03">

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-04">

  ┌──────────────────────────────────────────────────────┐
  │              Supervisor (Manajemen)                   │
  │     Keputusan/Audit/Pelatihan/Koordinasi/Pengeluaran  │
  └───────────────┬────────────────────────────────────-─┘
                  │
     ┌────────────┼────────────────────┐
     │            │                    │
  ┌──▼─────┐ ┌───▼─────┐  ┌──────────▼──────────┐
  │ Wakil  │ │ Koreksi │  │ Order Deposit-Tarik │
  │ Super- │ │ Data    │  │ + Manajemen Remote  │
  │ visor  │ │ Member  │  │       ×2            │
  │  ×2    │ │  ×2     │  └──────────┬──────────┘
  └──┬─────┘ └───┬─────┘             │
     │           │                   │
     ▼           ▼                   ├─→ Cek deposit gagal
  Push/follow  Reset password        ├─→ Kartu macet tarik
  Audit tarik  Reset PIN             └─→ Manajemen CS Remote
  Inspeksi     Ganti rekening bank       (jadwal/QC/pantau)
  Manajemen    Buka kunci akun                 │
  saluran                                       ▼
                                       Tim CS Remote (WFH)

Arsitektur Tim CS Remote (di bawah Spesialis Manajemen CS):

Asisten Remote ×10 (5 grup masing-masing 2 orang): Setiap orang mengelola 10 CS Remote, bertanggung jawab atas QC tim, pelatihan pemula, umpan balik masalah
CS Remote ×100 (5 grup masing-masing 20 orang), cakupan 24 jam, dibagi shift pagi/malam (waktu Jakarta WIB):
Versi A (1 grup 20 orang): Shift pagi 10:00-22:00 / Shift malam 22:00-10:00
Versi B (4 grup 80 orang): Shift pagi 12:00-00:00 / Shift malam 00:00-12:00
Versi B mengatur lebih banyak personel karena malam hari 19:00-00:00 adalah puncak aktivitas pengguna

Detail lihat → 04-Panduan Spesialis Manajemen CS

📝 Sumber: Diskusi pembelajaran

2.2.2 Mekanisme Koordinasi dengan Spesialis Manajemen CS¶

Mekanisme koordinasi antara Spesialis Manajemen CS (posisi yang bertanggung jawab atas manajemen CS Remote) dan Supervisor:

❓ Berikut adalah placeholder kerangka, akan dikonfirmasi ke Supervisor untuk konten konkret

Dimensi	Konten	Status
Pelaporan harian	❓ Frekuensi pelaporan, isi pelaporan, saluran pelaporan akan dikonfirmasi	Akan dipelajari
Eskalasi masalah	Masalah CS Remote → Spesialis Manajemen CS tangani dulu → Tidak bisa diselesaikan → Diserahkan ke Supervisor	Sudah dikonfirmasi
Koordinasi penjadwalan	❓ Penjadwalan CS Remote disusun Spesialis Manajemen CS, perlu persetujuan Supervisor atau tidak akan dikonfirmasi	Akan dipelajari
Hasil QC	❓ Bagaimana data QC diringkas ke Supervisor, bagaimana penanganan anomali akan dikonfirmasi	Akan dipelajari
Manajemen kepegawaian	❓ Peran Supervisor dalam alur perekrutan/wawancara/penilaian/promosi CS Remote akan dikonfirmasi	Akan dipelajari
Koordinasi pelatihan	❓ Siapa yang bertanggung jawab atas pelatihan CS Remote baru, materi pelatihan apa yang digunakan akan dikonfirmasi	Akan dipelajari

Panduan kerja detail Spesialis Manajemen CS Remote, lihat → 04-Panduan Spesialis Manajemen CS Remote

Tingkat Penanganan Masalah: - Masalah personel remote → Spesialis Manajemen CS (lapangan) menangani dulu - Penanggung jawab lapangan tidak bisa menangani atau perlu audit Supervisor → Diserahkan ke Supervisor - Yang tidak bisa diselesaikan Supervisor → Diserahkan ke Manajer untuk audit dan keputusan

Tanggung Jawab Pelatihan: - Melatih Wakil Supervisor menguasai alur standar eksekusi jaga - Melatih personel lain melakukan pekerjaan eksekusi konkret - Supervisor tidak melakukan eksekusi konkret, melalui pelatihan agar bawahan yang melakukan

2.3 Penanganan Masalah Platform¶

Berbagai masalah yang muncul dalam operasi platform sehari-hari
Catatan: Umumnya adalah masalah personel dan bisnis konkret, masalah sistemik sudah diselesaikan di awal pembangunan situs

2.4 Pemantauan Efek Promosi¶

Berbagai promosi yang ditetapkan saat situs baru dimulai, perlu pemantauan efek terus-menerus
Promosi pengujian seperti pull-back mingguan, berdasarkan data efek diputuskan apakah perlu menyesuaikan parameter
Detail lihat IV. Pemantauan dan Penyesuaian Efek Promosi

2.5 Penjadwalan dan Kepegawaian¶

Manajemen penjadwalan: Bertanggung jawab atas jadwal personel lapangan, personel UI, personel laporan remote, dan permintaan cuti
Pengaturan gaji akhir bulan: Setiap akhir bulan mengatur biaya rekomendasi internal dan biaya lembur grup A+C, diserahkan ke departemen HR untuk diaudit, kemudian dibayarkan oleh Keuangan

📝 Sumber: Diskusi pembelajaran

2.6 Manajemen Pengeluaran Operasional Harian¶

Supervisor bertanggung jawab atas pembayaran pengeluaran operasional harian, terutama menggunakan USDT melalui multi-sig wallet. Setiap pengeluaran dilaporkan secara real-time ke grup keuangan.

Jenis Pengeluaran Umum:

Jenis Pengeluaran	Keterangan
Biaya SMS harian	Biaya saluran SMS follow-up/pull-back
Gaji karyawan resign	Penyelesaian gaji karyawan yang mengundurkan diri
Reimburse pengeluaran kerja karyawan	Reimburse biaya yang timbul dari pekerjaan harian
Biaya paket layanan CS	Biaya penggunaan agen platform CS seperti Salesmartly
Pengeluaran operasional lain	Biaya operasional harian lainnya

Alur Pembayaran Multi-sig Wallet:

  Manajer mendepositkan sejumlah dana ke multi-sig wallet
        │
        ▼
  ┌──────────────────────────────┐
  │ Supervisor inisiasi penarikan │
  │ (bobot tanda tangan utama     │
  │  ada di Supervisor)           │
  └──────────┬───────────────────┘
             │
             ▼
  ┌──────────────────────────────┐
  │ Wakil Supervisor (yang punya  │
  │ otoritas) menandatangani      │
  │ (setelah double-sign, dana    │
  │  dikeluarkan)                 │
  └──────────┬───────────────────┘
             │
             ▼
  ┌──────────────────────────────┐
  │ Saldo wallet menipis          │
  │ → Supervisor minta tambahan   │
  │   ke Manajer                  │
  └──────────────────────────────┘

Mekanisme Keamanan: Multi-sig wallet membutuhkan dua tanda tangan (inisiasi Supervisor + konfirmasi Wakil Supervisor) untuk dikeluarkan, satu orang tidak bisa beroperasi sendiri, untuk mencegah penyalahgunaan dana.

📝 Sumber: Diskusi pembelajaran

2.7 Manajemen Pengujian Remote¶

Pemantauan grup pengujian remote dan pengujian game/situs pada dasarnya semua adalah Supervisor mengatur personel pengujian remote untuk melakukan pengujian sesuai persyaratan, manajemen terpadu.

2.7.1 Tujuan dan Prinsip Pengujian¶

Mengapa Perlu Pengujian: Platform menghadapi pengguna nyata pasar Indonesia, kelainan fungsi apa pun (pembayaran tidak lancar, game tidak terbuka, halaman tidak dapat diakses) akan langsung menyebabkan kehilangan pengguna dan kerugian dana. Pengujian remote melalui simulasi operasi pengguna nyata, menemukan dan menyelesaikan masalah sebelum mempengaruhi pengguna.

Tujuan Inti Pengujian:

Tujuan	Keterangan
Menjaga pengalaman pengguna	Memastikan situs/game/pembayaran end-to-end normal, deposit, game, penarikan pengguna tidak terhambat
Verifikasi ketersediaan saluran pembayaran	Saluran pembayaran pihak ketiga sering berubah, perlu pengujian rutin untuk konfirmasi saluran deposit dan penarikan lancar
Verifikasi antarmuka vendor game	API vendor game mungkin terjadi gangguan atau perubahan, ditemukan tepat waktu untuk menghindari komplain pengguna
Verifikasi launching situs baru	Setelah situs baru selesai dibangun, harus melalui pengujian lengkap baru bisa dilaunching resmi (lihat III. Pembangunan Situs Baru · 3.6 Kategori Pengujian)
Pemantauan ketersediaan domain	Domain umpan/Domain PWA/Domain bisnis bisa diblokir kapan saja, perlu verifikasi akses terus-menerus

2.7.2 Jenis dan Konten Pengujian¶

Jenis Pengujian	Konten Pengujian	Pemicu	Catatan
Pengujian saluran pembayaran	Deposit (penagihan) + Penarikan (pembayaran) alur lengkap	Saluran baru online, perpindahan saluran, inspeksi harian	Membutuhkan callback order, lihat Wakil Supervisor 4.4 Penanganan Callback Order
Pengujian vendor game	Apakah game vendor tertentu bisa dibuka, taruhan, settlement secara normal	Game baru online, perubahan antarmuka vendor, komplain pengguna	❓ Frekuensi pengujian dan kriteria penilaian konkret akan dikonfirmasi ke Supervisor
Pengujian akses situs	Apakah berbagai domain (domain bisnis/PWA/umpan/APK) terbuka normal	Inspeksi harian, setelah perubahan domain, setelah pemblokiran pulih	Lihat 3.2.1 Detail Sistem Domain
Pemeriksaan konten promosi	Apakah aturan promosi, gambar, tautan, alur klaim sudah benar	Promosi baru online, setelah penyesuaian parameter promosi	—
Simulasi data callback	Melalui bot saluran pihak ketiga `/testpay nomor_order` simulasi callback deposit	Saat pengujian saluran pembayaran	❓ Skenario lebih banyak akan dikonfirmasi

2.7.3 Tanggung Jawab Manajemen Supervisor¶

Supervisor sendiri tidak melakukan operasi pengujian konkret, melainkan bertanggung jawab atas:

  Supervisor mengatur tugas pengujian
        │
        ▼
  Personel pengujian remote eksekusi sesuai persyaratan
  (deposit/penarikan/game/akses situs dll)
        │
        ▼
  Hasil pengujian umpan balik ke grup pengujian remote
        │
        ▼
  ┌─────────────────────────────┐
  │ Supervisor memantau grup    │
  │ pengujian                    │
  │ · Lihat hasil pengujian      │
  │ · Identifikasi masalah       │
  │   anomali                    │
  │   Umum: Saluran pembayaran   │
  │         tidak lancar         │
  │         Situs/game tidak     │
  │         bisa dibuka          │
  │         Konten promosi salah │
  └──────────┬──────────────────┘
             │ Temukan masalah
             ▼
  ┌─────────────────────────────┐
  │ Koordinasi penanganan       │
  │ · Masalah pembayaran →       │
  │   Hubungi merchant Pihak     │
  │   Ketiga                     │
  │ · Domain diblokir → Ganti    │
  │   domain di backend          │
  │ · Game anomali → Hubungi     │
  │   vendor game                │
  │ · Konfigurasi salah → Atur   │
  │   perbaikan                  │
  └─────────────────────────────┘

2.7.4 Pemikiran Investigasi Masalah¶

Saat ditemukan anomali pengujian, investigasi dengan pemikiran berikut:

Gejala Anomali	Arah Investigasi	Dokumen Referensi
Deposit gagal	① Apakah saluran terbuka ② Apakah saldo saluran cukup ③ Apakah konfigurasi nominal/level cocok ④ Apakah merchant Pihak Ketiga anomali	Manajemen Saluran Pembayaran Pihak Ketiga
Penarikan gagal	① Apakah saluran pembayaran normal ② Apakah timeout tanpa callback ③ Apakah merchant menolak	Penarikan Dana
Situs tidak bisa dibuka	① Apakah domain diblokir ② Apakah resolusi DNS efektif ③ Apakah proxy CF normal ④ Apakah akselerasi jalur dikonfigurasi	Fungsi Tipe Domain
Game tidak bisa dibuka	① Apakah antarmuka vendor game normal ② Apakah switch game terbuka ③ Apakah kompatibilitas perangkat/browser tertentu	❓ Akan ditambahkan dokumen terkait manajemen game
Promosi anomali	① Apakah konfigurasi promosi benar ② Apakah parameter waktu/kondisi diset benar ③ Apakah gambar/tautan berhasil diunggah	—

📝 Sumber: Pengaturan materi (berdasarkan diskusi pembelajaran + Panduan Onboarding Wakil Supervisor + Kategori Pengujian Pembangunan Situs Baru), selanjutnya perlu dikonfirmasi ke Supervisor untuk detail pengaturan pengujian konkret dan ditambahkan/dikoreksi

2.8 Laporan Operasi Grup¶

Tidak terbatas pada "sebelum pulang kerja"—isi laporan begitu mendapat data yang perlu diisi. Data biaya transaksi, jumlah customer loss pull-back, dan sebagainya kapan tersedia, saat itu pula isi laporan.

2.8.1 Tanggung Jawab Pengisian Laporan¶

Item Data yang Perlu Diisi/Dikonfirmasi Supervisor (❓ Format laporan dan field lengkap konkret akan dikonfirmasi):

Item Data	Sumber	Fokus Perhatian
Biaya transaksi	Settlement merchant Pihak Ketiga pembayaran	Apakah jumlah masuk akal, apakah anomali tinggi/rendah dibanding rata-rata historis
Jumlah customer loss pull-back	Laporan tugas batch harian Wakil Supervisor	Tren efek pull-back, apakah perlu menyesuaikan strategi pull-back
Data selisih deposit-tarik	Laporan harian backend setiap platform	Apakah rasio dalam kisaran normal (lihat Wakil Supervisor 3.5 Inspeksi Selisih Deposit-Tarik)
Indikator operasional lain	❓ Akan dikonfirmasi	❓ Indikator konkret apa yang dilihat, data apa yang dinilai akan dikonfirmasi ke Supervisor selanjutnya

2.8.2 Tanggung Jawab Pemeriksaan Laporan¶

Supervisor tidak hanya mengisi data sendiri, juga perlu memeriksa kualitas data dari personel pengisi laporan:

  Personel pengisi laporan submit data
        │
        ▼
  ┌─────────────────────────────────┐
  │ Poin Pemeriksaan Supervisor      │
  │                                 │
  │ ① Apakah data diisi dengan benar │
  │    · Apakah ada yang terlewat,   │
  │      salah isi                   │
  │    · Apakah format nilai benar   │
  │                                 │
  │ ② Deteksi anomali data           │
  │    · Apakah rasio selisih        │
  │      deposit-tarik menyimpang    │
  │      dari rata-rata historis     │
  │    · Apakah biaya transaksi      │
  │      tiba-tiba naik/turun        │
  │    · Apakah volume deposit/      │
  │      penarikan ada fluktuasi     │
  │      anomali                     │
  │                                 │
  │ ③ Apakah formula/kalkulasi       │
  │    salah diubah                  │
  │    · Apakah formula Google Sheet │
  │      utuh                        │
  │    · Apakah data ringkasan       │
  │      konsisten dengan detail     │
  └──────────┬──────────────────────┘
             │ Temukan anomali
             ▼
  ┌─────────────────────────────────┐
  │ Alur Investigasi                 │
  │ · Anomali selisih deposit-tarik  │
  │   → Periksa data platform        │
  │   spesifik, apakah ada penarikan │
  │   besar/deposit anomali          │
  │ · Anomali biaya transaksi →      │
  │   Periksa perubahan tarif        │
  │   saluran atau jumlah transaksi  │
  │   anomali                        │
  │ · Data tidak cocok → Investigasi │
  │   apakah ada yang terlewat       │
  │   atau input duplikat            │
  └─────────────────────────────────┘

2.8.3 Masalah Sistem Laporan Saat Ini¶

Saat ini semua laporan operasional diisi manual oleh personel pengisi melalui Google Sheet, terdapat masalah berikut:

#	Masalah	Risiko
1	Tidak ada isolasi data	Personel pengisi bisa melihat seluruh data tabel, kurang isolasi otoritas
2	Risiko kesalahan operasi	Personel pengisi mungkin salah mengubah formula atau data orang lain, mempengaruhi kalkulasi ringkasan akhir
3	Kurang visualisasi	Data semua angka murni, tidak ada tampilan tren grafik, biaya pembelajaran analisis data tinggi untuk Supervisor baru
4	Sulit investigasi anomali	Saat volume data besar, pemeriksaan baris demi baris secara manual tidak efisien, sulit cepat menemukan data anomali

2.8.4 Sistem Dashboard Data (Sedang Dikembangkan)¶

Untuk menyelesaikan masalah di atas, saat ini sedang dirancang dan dikembangkan satu set sistem dashboard data operasional, dibagi menjadi dua sisi:

① Sisi Input Data (untuk personel pengisi): - Antarmuka input khusus, personel pengisi hanya melihat field yang perlu diisi sendiri - Isolasi data: Personel pengisi tidak bisa melihat hasil analisis data lengkap - Pemeriksaan anomali otomatis: Saat input langsung memberikan peringatan anomali real-time (seperti nominal jelas menyimpang dari kisaran normal) - Mengurangi kesalahan operasi: Input berbentuk form, tidak menyentuh formula dasar

② Sisi Dashboard Manajemen (untuk Supervisor/manajemen): - Kompatibel dengan format data murni Google Sheet asli (transisi mulus) - Tampilan visualisasi data: Berbagai indikator operasional dalam bentuk grafik, mendukung perbandingan tren - Filter kustom: Filter fleksibel berdasarkan platform/periode/tipe indikator dengan tampilan visualisasi - Analisis AI (akan diintegrasikan kemudian): Memberikan analisis singkat tren data dasar dan peringatan anomali

Prasyarat penyempurnaan sistem: Perlu mendapatkan semua laporan Google Sheet yang sedang digunakan, memahami data spesifik apa yang diisi personel pengisi setiap hari, bagaimana formula dirancang, baru bisa benar-benar menyempurnakan desain sistem.

❓ Akan dikonfirmasi: Daftar field laporan lengkap, desain formula, kaliber data setiap platform

📝 Sumber: Pengaturan materi + Diskusi pembelajaran, selanjutnya perlu mendapatkan template laporan aktual untuk konfirmasi dan penambahan lebih lanjut

2.9 Konfirmasi Distribusi Grup Pihak Ketiga Pembayaran¶

Melakukan konfirmasi distribusi di grup Pihak Ketiga Pembayaran ❓ Konten dan alur konfirmasi konkret akan dikonfirmasi

📝 Sumber: Diskusi pembelajaran

2.10 Pengelolaan Skrip CS dan Pelatihan¶

Supervisor bertanggung jawab mengatur skrip respon terpadu hotline CS, memastikan semua CS (lapangan + remote) menggunakan respon standar terpadu saat menghadapi pengguna.

Sistem Dokumen Skrip (sudah diatur dan diarsipkan ke direktori 10-Pusat CS):

Dokumen	Konten	Berlaku untuk
01-Pustaka Skrip CS	30+ kategori, 200+ skrip respon standar (Bahasa Indonesia), termasuk nomor shortcut	Seluruh CS
02-SOP Alur Kerja CS Remote	16 disiplin kerja + decision tree lengkap deposit/penarikan/operasi akun	CS Remote
03-Standar Manajemen CS Remote	10 langkah alur kerja CS Remote + standar WFH + FAQ	CS Remote

Tanggung Jawab Manajemen Supervisor: - Pembaruan skrip: Memperbarui pustaka skrip tepat waktu sesuai perubahan bisnis (promosi baru online, penyesuaian aturan, platform baru) - Pelatihan: Saat CS baru bergabung mengatur pembelajaran tiga dokumen di atas, lulus penilaian baru bertugas - QC: Memeriksa secara acak kualitas respon CS, yang tidak sesuai standar dilakukan koreksi dan pelatihan ulang - Hubungan KPI: Kualitas respon (kepatuhan skrip, kecepatan respon, tingkat penyelesaian) dimasukkan ke penilaian KPI CS

📝 Sumber: Diskusi pembelajaran + Pustaka skrip.xlsx

2.11 Materi UI dan Naskah¶

Excel tampilan UI memiliki persyaratan ukuran berbeda dalam gaya layout
Naskah promosi aktivitas ditulis sendiri oleh Supervisor (bukan menyalin dari template)
Semua ikon besar/kecil dalam konfigurasi operasional backend menjadi tanggung jawab Supervisor
Spesifikasi ukuran detail lihat 12-Indeks Tampilan UI

📝 Sumber: Diskusi pembelajaran

III. Alur Kerja Pembangunan Situs Baru¶

Ini adalah pekerjaan tetap bertahap terpenting Supervisor. Setelah pembangunan selesai tidak diulang lagi, namun setiap kali membuka situs baru harus dijalankan lengkap.

3.1 Ikhtisar Pekerjaan Pembangunan¶

Pembangunan situs baru total 37 item pekerjaan, dibagi menjadi 5 kategori besar:

Kategori	Jumlah Pekerjaan	Keterangan
Domain	9	Pembelian domain, pengikatan, resolusi, akselerasi
Konfigurasi	11	Push/pembayaran/game/CS/promosi/Firebase dan konfigurasi backend lain
Desain Gambar	7	ICON/LOGO/Banner/gambar promosi/gambar CS/halaman download dan materi visual lain
Akun	4	Pembuatan dan konfigurasi akun CS/audit/media mandiri
Pengujian	4	Pengujian menyeluruh game/deposit-penarikan/URL/konten promosi

3.2 Kategori Domain (9 item)¶

#	搭建内容	Konten Pembangunan	Penanggung Jawab	Keterangan
1	购买主域名，确定模版，开后台	Beli domain utama, tentukan template, buka backend	Martin	Diputuskan oleh manajemen (Manajer/Bos), Supervisor mendukung eksekusi
2	通知 SEO 做排名	Beri tahu SEO untuk optimasi peringkat	Martin	Setelah domain ditentukan, beri tahu tim SEO sedini mungkin
3	联系技术人员购买配套域名	Hubungi teknisi untuk membeli domain pendukung	Martin	Domain pendukung untuk fungsi tambahan
4	联系技术人员购买炮灰域名	Hubungi teknisi untuk membeli domain "umpan" (decoy)	Martin	Domain Umpan untuk anti-blokir
5	配套域名绑定	Pengikatan domain pendukung	HB
6	PWA 域名绑定	Pengikatan domain PWA	HB	Instalasi PWA membutuhkan domain independen
7	炮灰域名绑定	Pengikatan domain "umpan" (decoy)	HB
8	炮灰域名解析	Pengaturan DNS domain "umpan" (decoy)	HB	Pengaturan resolusi DNS
9	防封域名 + APK 域名线路加速	Domain anti-blokir + percepatan jalur domain APK	HB	Akselerasi jalur memastikan kecepatan download APK

📘 Sumber: Tabel Persiapan Pembangunan Situs Baru

3.2.1 Detail Sistem Domain¶

Konten berikut membantu Supervisor memahami secara mendalam logika desain sistem domain, memudahkan menjelaskan "mengapa demikian" kepada Wakil Supervisor dan personel eksekusi lain.

Backend Feifan Baowang membagi domain menjadi tiga modul manajemen besar:

Modul	Path Backend	Peran Esensial	Untuk Siapa
Domain Situs	Manajemen Domain → Domain Situs	Halaman pendaratan bisnis nyata	Semua pengguna akhir
Domain Anti-blokir PWA	Manajemen Domain → Domain Anti-blokir PWA	Pintu masuk pengganti App desktop	Pengguna yang menginstal PWA
Domain Pengalihan (Domain Umpan)	Manajemen Domain → Domain Pengalihan	Springboard sekali pakai untuk menahan tembakan	Pengguna baru dari iklan/SMS

📘 Sumber: 09-Fungsi Tipe Domain

Lima Tipe Label Domain Situs—bukan hanya klasifikasi, setiap tipe memiliki peran berbeda dalam bisnis:

Tipe	Peran Satu Kalimat	Mengapa Perlu Independen
Umum	Pintu masuk fallback serbaguna (homepage/navigasi/transit pengalihan)	Skenario umum yang tidak membutuhkan perilaku sistem khusus
Berbagi Agen	Tautan eksklusif untuk fission mandiri agen	Sistem otomatis menandai sumber promosi, backend agen langsung memanggil, tidak saling mencemari atribusi dengan promosi resmi
Tautan Promosi	Promosi inisiatif resmi (SMS/push/iklan)	Membedakan "uang perusahaan menarik" vs "agen mempromosikan secara mandiri", memudahkan perhitungan ROI terpisah
Domain APK	Saluran jalur internal APP (3 jalur cadangan setiap situs)	Terekspos = diserang = seluruh APP situs lumpuh; perlu pemrosesan teknis sekunder, dilarang keras diekspos
Domain Deteksi	Probe kesehatan operasi (`/api/check`)	Bisa mendiagnosis status server tanpa membuka situs utama, tidak mengganggu trafik bisnis

📘 Sumber: 09-Fungsi Tipe Domain

Perbandingan Detail Tiga Modul Besar:

Dimensi	Domain Situs	Domain Anti-blokir PWA	Domain Pengalihan (Umpan)
Dampak pemblokiran	Tingkat bencana—Seluruh situs tidak dapat diakses	Sedang—Ganti domain segera pulih, pengguna tidak perlu install ulang	Rendah—Ganti umpan baru terus tayang
Biaya domain	Bernilai tinggi, dipegang jangka panjang	Sedang, dapat diganti	Murah, jangka pendek, barang habis pakai
Mekanisme teknis	Aktivasi NS + Pertahanan CF	Aktivasi NS + Terkait domain situs	Aktivasi NS + Resolusi subdomain + Pengalihan 302
Passthrough parameter	Tidak terlibat	Tidak terlibat	Mendukung (parameter atribusi utm/click_id dll)

3.2.2 Jalur Akses Pengguna Lengkap¶

Memahami bagaimana pengguna berbeda mencapai platform melalui domain berbeda.

┌─────────────── Jalur Akuisisi Pengguna Baru ───────────────┐
│                                                            │
│  Iklan/SMS/Promosi sosmed                                  │
│       │                                                    │
│       ▼                                                    │
│  Domain Umpan dd.xyz.cc  ← Berdiri di depan, tanggung      │
│       │                    risiko pemblokiran              │
│       │ Pengalihan 302 (passthrough parameter              │
│       │  ?utm_source=xx)                                   │
│       ▼                                                    │
│  Domain Bisnis bc666a.top  ← Tipe=Tautan Promosi/Umum     │
│       │                                                    │
│       ▼                                                    │
│  Pengguna registrasi/deposit/install PWA                  │
│                                                            │
├─────────────── Jalur Kunjungan Pengguna Lama ──────────────┤
│                                                            │
│  Ikon PWA desktop ponsel                                  │
│       │                                                    │
│       ▼                                                    │
│  Domain Anti-blokir PWA pwa.abc.com                       │
│  ← Lapis domain independen, dapat hot-replace saat blokir │
│       │ Terkait                                           │
│       ▼                                                    │
│  Domain Bisnis bc666a.top  ← Pengguna beralih tanpa sadar │
│                                                            │
├─────────────── Jalur Berbagi Agen ─────────────────────────┤
│                                                            │
│  Backend Agen → Salin tautan domain berbagi agen          │
│       │                                                    │
│       ▼                                                    │
│  agent-share.top (tipe=Berbagi Agen)                      │
│  → Otomatis bawa kode undangan agen                       │
│       │                                                    │
│       ▼                                                    │
│  Pengguna registrasi, atribusi ke agen tersebut           │
│                                                            │
├─────────────── Jalur Pengguna APK ─────────────────────────┤
│                                                            │
│  Kode internal APP Android                                │
│       │                                                    │
│       ▼                                                    │
│  Domain APK ×3 (hardcoded di kode)                        │
│  ← Dilarang diekspos, 3 jalur cadangan                    │
│       │                                                    │
│       ▼                                                    │
│  APP normal memuat data bisnis                            │
└────────────────────────────────────────────────────────────┘

3.2.3 Arsitektur Anti-blokir Tiga Lapis Bawang¶

Filosofi Desain: Struktur tiga lapis bawang—Umpan di lapisan terluar menanggung pukulan, PWA di tengah menjadi pintu masuk elastis, domain bisnis di inti tidak pernah langsung diekspos. Setiap lapisan diblokir hanya perlu mengganti lapisan tersebut, tidak mempengaruhi lapisan dalam.

           ┌─── Lapis Terluar: Domain Umpan ───┐
           │ Barang habis pakai, blokir ganti  │
           │  ┌─── Lapis Tengah: PWA ───┐      │
           │  │ Pintu elastis, hot      │      │
           │  │ replace                 │      │
           │  │  ┌── Lapis Inti ──┐     │      │
           │  │  │ Domain Bisnis  │     │      │
           │  │  │ Tidak pernah   │     │      │
           │  │  │ terekspos      │     │      │
           │  │  └────────────────┘     │      │
           │  └─────────────────────────┘      │
           └───────────────────────────────────┘

Urutan Risiko Pemblokiran: Umpan (tertinggi) > PWA (menengah) > Domain Bisnis (terendah)

Respon Darurat Setelah Pemblokiran:

Lapis Diblokir	Dampak	Waktu Respon	Operasi
Umpan diblokir	Tautan promosi pengguna baru gagal	5 menit	Backend ganti umpan baru + sinkronisasi resolusi
PWA diblokir	PWA pengguna lama buka layar putih	10 menit	Backend ganti domain PWA baru + terkait domain bisnis asli, pengguna otomatis pulih
Domain bisnis diblokir	Seluruh situs tidak dapat diakses	Tingkat bencana	Migrasi seluruh situs (jarang terjadi karena tidak pernah langsung diekspos)
Domain APK diblokir	APP lumpuh	Perlu repackage rilis ulang	Karena itu dilarang diekspos

Cerita Skenario untuk Memahami:

Skenario 1: Umpan Diblokir—SMS investasi pakai dd.xyz.cc, suatu hari diblokir operator. Backend ganti umpan baru ee.abc.cc mengarah ke domain bisnis yang sama, di grup update template tautan, 5 menit pulih investasi. Domain asli zero impact, pengguna lama benar-benar tidak sadar.

Skenario 2: PWA Diblokir—Ikon PWA desktop pengguna lama buka layar putih. Backend ganti Domain Anti-blokir PWA jadi yang baru, tetap terkait dengan domain bisnis yang sama. Pengguna lain kali buka PWA otomatis ditarik ke jalur baru, tidak perlu uninstall install ulang—cangkang rusak ganti cangkang, inti tidak berubah.

3.2.4 Buku Panduan Penanganan Pemblokiran Domain¶

📘 Sumber: Alur Penanganan Pemblokiran Domain Resmi Situs v2.docx (diperbarui 2026-05-02)

Berikut adalah langkah operasi konkret saat tiga jenis domain diblokir.

A. Penanganan Pemblokiran Domain Resmi Situs¶

Skenario: Domain utama situs diblokir (seperti 7777w77.com diblokir)

Langkah Operasi:

Temukan domain resmi diblokir
      │
      ▼
Backend → "Domain Situs" → Cari domain yang diblokir (seperti 7777w77.com)
      │
      ▼
① Matikan switch "Deteksi Pemblokiran Domain"
   Prinsip: Sudah dipastikan diblokir, tidak perlu sistem
            terus mengingatkan
      │
      ▼
② Periksa apakah "Akselerasi Domain" terbuka
   → Jika terbuka, harus dimatikan secara bersamaan
   Prinsip: Akselerasi Domain hanya 15 slot,
            domain yang diblokir menempati slot itu boros,
            harus menyisakan slot untuk domain yang membutuhkan
      │
      ▼
③ Tandai tanggal pemblokiran di kolom catatan
   Format: "SEO khusus 3.10 diblokir"
      │
      ▼
④ ⚠️ Periksa tipe domain!
   Jika "Domain Agen" diblokir
   → Harus **segera** ubah tipe menjadi "Umum"
      │
      ▼
⑤ Status **tidak perlu dimatikan**
   Prinsip: Pelanggan yang masih bisa membuka tetap dibiarkan
            buka, mematikan status akan menyebabkan pelanggan
            yang sudah mengakses juga tidak bisa mengakses
      │
      ▼
⑥ Jika perlu menambah domain baru
   → Hubungi @tom via Signal untuk menambahkan

⚠️ Tiga Prinsip Kunci: 1. Matikan Akselerasi Domain—15 slot sangat berharga, domain yang diblokir harus melepaskan slotnya 2. Domain Agen yang diblokir harus segera ubah ke tipe Umum—jika tidak bisa mempengaruhi sistem agen 3. Status jangan dimatikan—pelanggan yang masih bisa buka biarkan terus buka, hindari salah mengenai pengguna yang masih dapat akses

B. Penanganan Pemblokiran Domain PWA¶

Skenario: Domain Anti-blokir PWA diblokir (seperti 7777w.gum719.com diblokir telkom)

Langkah Operasi:

Temukan domain PWA diblokir
      │
      ▼
  ① Backend → "Domain Anti-blokir PWA" → Cari domain yang diblokir
     → Matikan "Deteksi Pemblokiran Domain"
     → Catat informasi pemblokiran, seperti
       "Konversi H5 (1220 diblokir telkom)"
      │
      ▼
  ② Hubungi @tom via Signal:
     · Beli domain acak baru (seperti werewurh.com)
     · Atau pilih satu dari domain cadangan PWA yang sudah dibeli
      │
      ▼
  ③ Setelah dapat domain baru, tambahkan prefix platform
     Contoh: 7777w.werewurh.com
      │
      ▼
  ④ Operasi backend:
     · Bind domain baru dulu (cara pengikatan domain)
     · Tambah Domain PWA → Isi domain baru
     · Pilih domain "Anti-blokir Mengarah ke"
     · Konfirmasi tunggu NS1, NS2 muncul
      │
      ▼
  ⑤ Setelah NS muncul → Hubungi @tom via Signal untuk resolusi
      │
      ▼
  ⑥ Setelah resolusi aktif:
     · Buka "Deteksi Pemblokiran Domain"
     · Tambahkan Domain PWA baru ke "JPush"
      │
      ▼
  ⑦ Ganti Domain Umpan yang sebelumnya terikat (lihat sub-alur B.1)
      │
      ▼
  ⑧ Buka "Pop-up Penyelamatan" pada domain PWA yang diblokir
     (lihat sub-alur B.2)

B.1 Sub-alur Pengikatan Ulang Domain Umpan¶

Backend → "Domain Pengalihan Investasi"
      │
      ▼
  Pilih Domain Umpan yang terikat pada Domain PWA yang diblokir
  (mungkin beberapa)
      │
      ▼
  Klik tombol "Resolusi"
      │
      ▼
  Hapus dua record asli
      │
      ▼
  Tambah record domain baru:
  · Subdomain: Input `@`
  · Tautan pengalihan: `https://` + Domain PWA baru
  (Contoh: https://7777w.werewurh.com)
      │
      ▼
  Klik "Sinkronisasi"
      │
      ▼
  ✅ Selesai: Pelanggan PWA yang men-download dari domain lama
     **beralih tanpa sadar** ke domain baru

B.2 Sub-alur Pengaturan Pop-up Penyelamatan (untuk pelanggan lama)¶

⚠️ Masalah Inti: Pelanggan lama menggunakan PWA menambah bookmark desktop, setelah Domain PWA asli diblokir, bookmark desktop akan layar putih tidak bisa main game. Setelah backend menyelesaikan penggantian domain, pelanggan baru natural ke domain baru, tetapi pelanggan lama membutuhkan Pop-up Penyelamatan untuk mengingatkan update.

Backend → Cari konfigurasi **Domain PWA lama yang diblokir**
      │
      ▼
  Buka switch "Pop-up Penyelamatan"
      │
      ▼
  Set pop-up sebagai "Pop-up Paksa"
      │
      ▼
  Di kolom input target pop-up
  isi **Domain PWA baru yang diikat**
  (Contoh: 7777w.werewurh.com)
      │
      ▼
  Salin naskah penyelamatan standar dari B.2.1 di bawah dan paste
      │
      ▼
  Simpan konfigurasi
      │
      ▼
  ✅ Saat pelanggan lama buka bookmark desktop PWA lama
     → Muncul Pop-up Penyelamatan
     → Klik "Update"
     → Otomatis dialihkan ke Domain PWA baru
     → Tambah ulang bookmark desktop lalu lanjut main game

B.2.1 Template Naskah Penyelamatan¶

Naskah penyelamatan standar (langsung salin-paste, tidak perlu modifikasi apa pun):

Unduh aplikasi terbaru!
Klik tombol unduh, lalu tekan tombol di kanan atas untuk membuka halaman unduhan utama menggunakan Google Chrome, dan unduh aplikasi terbaru!

Terjemahan Mandarin sebagai referensi (hanya untuk pemahaman — versi Indonesia yang dipakai di produksi):

下载最新应用！点击下载按钮，然后按右上角的按钮，使用 Google Chrome 打开主下载页面，下载最新应用！

📌 Catatan penggunaan: Semua platform menggunakan naskah yang sama — tidak perlu mengganti nama platform atau domain. Tujuan naskah adalah memandu pelanggan lama untuk membuka halaman unduhan utama via Chrome dan mengunduh ulang atau menambah bookmark desktop baru

✅ Kelompok Pelanggan yang Tidak Terdampak: Pelanggan yang men-download APK native atau paket vest melalui Domain PWA, tidak bergantung pada bookmark desktop PWA, jadi Pop-up Penyelamatan tidak berlaku bagi mereka—tetapi mereka juga tidak butuh penyelamatan, karena APK sudah ada di lokal.

B.3 Tabel Cepat Poin Operasi Pemblokiran Domain PWA¶

Langkah	Operasi	Lokasi
Matikan deteksi+catat	Matikan deteksi pemblokiran domain, catat tanggal dan alasan	Backend → Domain Anti-blokir PWA
Dapat domain baru	Signal @tom beli domain acak atau pilih dari cadangan	Signal
Tambah prefix bind	Domain baru tambah prefix platform lalu bind di backend	Backend → Domain Anti-blokir PWA
Tunggu NS + resolusi	Tunggu NS1/NS2 muncul lalu hubungi @tom untuk resolusi	Signal
Konfigurasi setelah aktif	Buka deteksi pemblokiran + tambah JPush	Backend
Update arah Umpan	Domain Pengalihan Investasi → Resolusi → Hapus record lama → Tambah record baru (@ + https://PWA baru) → Sinkronisasi	Backend → Domain Pengalihan Investasi
Pop-up Penyelamatan	Domain PWA lama buka Pop-up Penyelamatan, mengarah ke Domain PWA baru	Backend → Konfigurasi Domain PWA lama

C. Penanganan Pemblokiran Domain Umpan¶

Skenario: Domain Umpan untuk pengalihan investasi diblokir

Langkah Operasi:

Temukan Domain Umpan diblokir
      │
      ▼
  ① Hubungi @tom via Signal
     Tanyakan apakah bisa lakukan pengalihan 301
     (manfaatkan domain yang belum diblokir untuk pengalihan)
      │
      ▼
  ② Beri tahu **Departemen Investasi**:
     Domain tersebut sudah diblokir, perlu mengganti
     tautan promosi
      │
      ▼
  ③ ⚠️ **Jangan hapus Domain Umpan yang diblokir di backend**
     (simpan record untuk pelacakan)
      │
      ▼
  ④ Berikan **Domain Umpan baru**
     terus diikat ke Domain PWA asli
      │
      ▼
  ⑤ Berikan Domain Umpan baru ke departemen investasi
     untuk lanjut investasi

📝 Keterangan Status: Pemblokiran Domain Umpan saat ini belum pernah terjadi, di atas adalah cara penanganan yang diasumsikan (berdasarkan kemampuan teknis platform).

⚠️ Disiplin Pencatatan Penting: Penggunaan semua domain perlu dicatat dengan jelas dalam tabel, memudahkan ditelusuri saat lupa kemudian (Umpan mana terikat PWA mana, PWA mana terkait domain bisnis mana, dll).

D. Catatan Manajemen Domain Umum¶

Bagian ini adalah disiplin manajemen global di atas penanganan tiga jenis pemblokiran, menghindari pemborosan dana dan kekacauan data dari respon pasif.

#	Catatan	Keterangan
1	Sinkronkan domain yang diblokir ke @tom	Beri tahu tom secepat mungkin, daftarkan ke tabel record pemblokiran terpadu
2	Waktu cache vs perpanjangan domain	Periode cache Domain PWA sekitar 300 hari. Jika domain dibeli 1 tahun tetapi diblokir di hari ke-300, sisa 65 hari sebelum kedaluwarsa tetapi cache masih 300 hari → kasus ini walaupun diblokir tetap harus perpanjang setahun, jika tidak dalam periode cache pengguna lama akan gagal lagi karena domain kedaluwarsa
3	Domain Umpan beli 1 tahun	Domain Umpan umumnya tidak terpakai 2 tahun, tidak boleh digunakan ulang (domain yang pernah diblokir berisiko tinggi jika digunakan ulang), tidak diperpanjang saat kedaluwarsa, beli baru lebih hemat
4	Domain dalam situs beli 2 tahun	Tipe berikut wajib beli 2 tahun: Domain APK, Domain PWA, Domain Agen, Domain Frontend, Domain Pintu Masuk Situs Navigasi, Domain Anti-blokir Mengarah ke (domain ini tidak boleh sering diganti, perlu stabilitas jangka panjang)

Tabel Keputusan Perpanjangan Domain¶

Tipe Domain	Tahun Beli Default	Strategi Perpanjangan Setelah Diblokir	Alasan
Domain APK	2 tahun	Perpanjang 2 tahun	Embedded di kode APP, ganti domain harus repackage rilis ulang
Domain PWA	2 tahun	Perpanjang 1 tahun (lihat periode cache)	Setelah diblokir pelanggan lama lewat Pop-up Penyelamatan migrasi, pelanggan baru lewat domain baru
Domain Agen	2 tahun	Perpanjang 1 tahun	Setelah diblokir ubah tipe ke "Umum" terus pakai
Domain Frontend	2 tahun	Perpanjang 1 tahun	Domain inti bisnis, penting
Pintu Masuk Situs Navigasi	2 tahun	Perpanjang 1 tahun	Jalur panduan pengguna, stabil jangka panjang
Domain Anti-blokir Mengarah ke	2 tahun	Perpanjang 1 tahun	Domain target Anti-blokir PWA
Domain Umpan	1 tahun	Tidak diperpanjang	Barang habis pakai sekali, diblokir buang

Tabel Cepat Penanganan Pemblokiran Domain¶

Tipe Domain	Langkah Pertama	Dapat Pengganti	Konfigurasi Backend	Langkah Khusus	Selanjutnya
Domain Resmi Situs	Matikan deteksi pemblokiran + Matikan Akselerasi Domain + catat tanggal	Hubungi @tom via Signal tambah domain baru	Tipe Agen ubah jadi Umum	Status tidak perlu dimatikan	—
Domain Anti-blokir PWA	Matikan deteksi pemblokiran + catat tanggal	Hubungi @tom via Signal beli domain acak atau pakai cadangan	Tambah prefix bind → tunggu NS → resolusi → JPush	Update arah Umpan + Pop-up Penyelamatan	Buka deteksi pemblokiran
Domain Umpan	Hubungi @tom via Signal lihat apakah bisa pengalihan 301	Sediakan Domain Umpan baru	Jangan hapus domain yang diblokir	Beri tahu departemen investasi ganti tautan	Catat ke tabel

Skenario 3: Passthrough Parameter Atribusi—Investasi iklan dd.xyz.cc?utm_source=fb&click_id=123, setelah pengalihan 302 menjadi bc666a.top?utm_source=fb&click_id=123, jalur atribusi tidak terputus. Umpan menahan tembakan sekaligus, data ROI dikembalikan utuh.

📝 Sumber: Alur Penanganan Pemblokiran Domain Resmi Situs v2.docx + Diskusi pembelajaran 📘 Sumber: 09-Fungsi Tipe Domain 📘 Sumber: 10-Domain Umpan Pengalihan Investasi

3.2.5 Prinsip Resolusi Domain DNS¶

Supervisor perlu memahami prinsip dasar resolusi domain agar bisa menginvestigasi masalah domain tidak lancar, resolusi tidak efektif, dll.

Esensi Resolusi Domain: Menerjemahkan domain yang dimengerti manusia (www.example.com) menjadi alamat IP yang dimengerti mesin (93.184.216.34).

Proses Resolusi:

Pengguna input www.example.com di browser
        │
        ▼
[1] Periksa cache DNS lokal
        │ Tidak ada cache
        ▼
[2] Tanya server DNS lokal (disediakan operator/ISP)
        │ Tidak ada record
        ▼
[3] Tanya server DNS root (13 grup global)
        │ Kembalikan: alamat DNS top-level .com
        ▼
[4] Tanya server DNS top-level .com
        │ Kembalikan: record NS dari example.com
        │ (yaitu "siapa yang mengelola resolusi domain ini")
        ▼
[5] Tanya server DNS otoritatif (ditunjuk oleh record NS)
        │ Kembalikan: record A → 93.184.216.34
        ▼
[6] Browser dapat IP → bangun koneksi → muat halaman

Perbandingan Tiga Tipe Record DNS Inti:

Tipe Record	Fungsi	Analogi	Contoh
Record A	Domain → Alamat IP	Stasiun akhir	`example.com → 93.184.216.34`
CNAME	Domain → Domain lain	Stasiun transit	`www.example.com → example.com`
Record NS	Menentukan siapa yang mengelola resolusi	Pusat dispatching	`example.com NS → ns1.cloudflare.com`

Cara Mengingat Sederhana: Record A adalah stasiun akhir (kasih IP), CNAME adalah stasiun transit (mengarah ke domain lain), NS menentukan siapa yang men-dispatch.

3.2.6 Hosting Cloudflare (Modifikasi NS)¶

Mengapa Hosting Domain ke Cloudflare (CF): - Sertifikat SSL gratis (HTTPS) - Pertahanan DDoS - Akselerasi CDN (300+ node global) - Sembunyikan IP asli server

Langkah Operasi:

  Alur lengkap hosting domain ke Cloudflare
        │
        ▼
  ┌────────────────────────────────┐
  │ (1) Daftar akun Cloudflare      │
  │     dan login                   │
  │     https://www.cloudflare.com  │
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (2) Klik Add a Site             │
  │     Input domain Anda → pilih   │
  │     Free plan                   │
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (3) CF otomatis scan record    │
  │     DNS yang ada                │
  │     Periksa manual apakah utuh  │
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (4) CF berikan dua alamat NS:  │
  │     ns1.cloudflare.com          │
  │     ns2.cloudflare.com          │
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (5) Login backend registrar    │
  │     domain                      │
  │     Cari pengaturan Name Servers│
  │     Hapus NS asli → isi NS dari │
  │     CF                          │
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (6) Kembali ke CF klik Check    │
  │     Nameservers                 │
  │     Tunggu efektif (beberapa    │
  │     menit~24 jam)               │
  │     Muncul centang hijau =      │
  │     hosting berhasil            │
  └────────────────────────────────┘

Pengikatan domain backend Feifan Baowang juga alur serupa: Setelah tambah domain sistem generate NS1/NS2 → ke backend registrar domain ubah NS → 3-5 menit aktif.

📘 Sumber: 09-Fungsi Tipe Domain

3.2.7 Prinsip Akselerasi CDN¶

Masalah: Pengguna di Indonesia, server di negara lain, latensi koneksi langsung tinggi. Solusi: CDN (Content Delivery Network) men-deploy node cache global, pengguna mengakses node terdekat.

Akses tradisional (tanpa CDN):
  Pengguna(Indonesia) ─── Jaringan lintas negara ───→
    Server asal(negara lain)   Latensi tinggi❌

</div>

</div>

</div>

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-03">

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-03">

</div>

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-03">

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-04">

Akselerasi CDN (dengan CF):
  Pengguna(Indonesia) ──→ Node CF Jakarta ──→ Server asal(negara lain)
                              │
                        Hit cache langsung kembalikan ✅
                        Tidak perlu setiap kali balik ke asal

Mode CF Proxy (awan oranye vs awan abu-abu):

	🟠 Awan Oranye (Proxied)	⚪ Awan Abu-abu (DNS-only)
Trafik melewati CF	Ya	Tidak (langsung ke asal)
Sembunyikan IP asal	✅ Ya	❌ Tidak (IP terekspos)
Akselerasi cache CDN	✅ Ada	❌ Tidak ada
Pertahanan DDoS	✅ Ada	❌ Tidak ada
Skenario	Trafik web (direkomendasikan)	Email/FTP, non-HTTP

Saran: Semua domain yang menghadap pengguna buka Awan Oranye (Proxied), dapat akselerasi+pertahanan+sembunyikan IP tiga efek sekaligus.

3.2.8 Detail Operasi Domain Umpan¶

Path Backend: Manajemen Domain → Domain Pengalihan

Alur Operasi:

  Tambah Domain Umpan
        │
        ▼
  ┌──────────────────────────┐
  │ (1) Tambah domain utama   │
  │     pengalihan            │
  │     Input Domain Umpan    │
  └──────────┬───────────────┘
             │
             ▼
  ┌──────────────────────────┐
  │ (2) Aktifkan NS          │
  │     Ke registrar domain  │
  │     ubah NS mengarah ke  │
  │     backend              │
  └──────────┬───────────────┘
             │
             ▼
  ┌──────────────────────────┐
  │ (3) Klik "Resolusi"      │
  │     (tombol hijau)       │
  │     Konfigurasi mapping  │
  │     subdomain:           │
  │     subdomain → URL      │
  │     target               │
  │     (mendukung passthrough│
  │     parameter)           │
  └──────────┬───────────────┘
             │
             ▼
  ┌──────────────────────────┐
  │ (4) Klik "Sinkronisasi"  │
  │     (tombol oranye)      │
  │     Distribusikan        │
  │     konfigurasi ke node  │
  │     CDN                  │
  └──────────────────────────┘

Contoh Passthrough Parameter: dd.umpan.cc?utm=abc → 302 alihkan ke → domain-asli.com?utm=abc Parameter pelacakan promosi tidak hilang.

📘 Sumber: 10-Domain Umpan Pengalihan Investasi

3.3 Kategori Konfigurasi (11 item)¶

#	搭建内容	Konten Pembangunan	Penanggung Jawab	Keterangan
10	极光推送开通、后台绑定 API	Aktifkan Jiguang push & ikat API di backend	Martin	Saluran push JPush
11	极光推送 PWA 配置	Konfigurasi push Jiguang (JPush) untuk PWA	Martin	Push sisi PWA
12	三方通道对接	Integrasi saluran pihak ketiga	Martin	Integrasi saluran Pihak Ketiga Pembayaran
13	支付通道金额及层级配置	Konfigurasi nominal & level saluran pembayaran	HB	Saluran pembayaran dan limit untuk pengguna level berbeda
14	游戏排序开关 + 热门游戏图标	Sakelar urutan game + ikon game populer	nuoya	Urutan tampilan game frontend
15	客服线后台集成、自动化流程、客服接线配置	Integrasi backend layanan pelanggan, alur otomatisasi, konfigurasi penerimaan CS	nuoya	Sistem CS seperti Salesmartly
16	官网 iOS 马甲包	Paket kamuflase iOS untuk situs resmi	Martin	Paket instalasi sisi iOS
17	PDD 活动检查、PDD 手机号上传	Pemeriksaan aktivitas PDD, unggah nomor ponsel PDD	Martin	Konfigurasi promosi Pinduoduo
18	智能 APK 模版配置	Konfigurasi template APK cerdas	Martin	Template paket instalasi sisi Android
19	后台所有文案配置	Konfigurasi semua teks/copy di backend	nuoya	Termasuk naskah promosi, naskah peringatan, dll
20	开通新 Firebase	Aktifkan Firebase baru	yuhai	Saluran push FCM
21	站点配置里的平台站点名称、描述、icon、logo 上传	Konfigurasi situs: nama, deskripsi, ikon, logo	nuoya	Informasi dasar platform

📘 Sumber: Tabel Persiapan Pembangunan Situs Baru

3.3.1 Alur Pendaftaran dan Negosiasi Harga JPush/EngageLab¶

📘 Sumber: Catatan kerja Supervisor

JPush adalah saluran push pesan sisi PWA, saat pembangunan situs baru perlu didaftarkan dan menyelesaikan negosiasi harga.

Langkah 1: Daftar Akun

Buka situs resmi Jiguang: https://www.engagelab.com/
Gunakan email + password untuk daftar (⚠️ Jangan langsung pakai "daftar satu klik" email Google, harus pakai cara email+password)
Setelah pendaftaran selesai login

Langkah 2: Buat Aplikasi

Setelah login buat aplikasi baru
Format nama aplikasi: Umumnya singkatan pasar + Tech/Perusahaan
Pilih Layanan Pesan → WebPush → Buat aplikasi
Pengaturan informasi aplikasi:
Nama: Domain utama situs (contoh YYBB)
Pilih server: Singapura

Langkah 3: Bind Backend

Isi Application Key yang digenerate Jiguang ke backend operasional:

Backend Operasional → Pengaturan Promosi PWA Jiguang → Isi Application Key

Langkah 4: Hubungi Bisnis Jiguang untuk Negosiasi Harga

Hubungi bisnis Jiguang: Signal @winna8989
Sediakan materi:
Application ID yang digenerate Jiguang
Application Key yang digenerate Jiguang
Permintaan: Negosiasi harga JPush
Skrip: Beri tahu bahwa ini paket jaringan, direkomendasikan Martin, negosiasi harga sama dengan paket Martin
Tunggu bisnis menyelesaikan negosiasi harga

Langkah 5: Upgrade Paket

Setelah negosiasi harga selesai, di backend Jiguang generate paket dan selesaikan upgrade.

Diagram Alur Lengkap:

  Daftar engagelab.com (email+password)
        │
        ▼
  Buat aplikasi → pilih WebPush → server pilih Singapura
        │
        ▼
  Dapat Application ID + Application Key
        │
        ├──→ Isi ke backend operasional "Pengaturan Promosi PWA Jiguang"
        │
        └──→ Signal @winna8989 kirim ID+Key
             → Minta negosiasi harga (paket rekomendasi Martin)
                    │
                    ▼
             Tunggu negosiasi harga selesai → Generate paket upgrade

3.3.2 Konfigurasi Nominal & Level Saluran Pembayaran (Edit Info Top-Up Pihak Ketiga)¶

📘 Sumber: Catatan kerja Supervisor + screenshot backend platform

Path Operasi: Backend → Manajemen Keuangan → Konfigurasi Top-Up Pihak Ketiga → pilih saluran pembayaran → klik "Edit"

Posisi Fungsi: Setiap metode pembayaran di setiap saluran pihak ketiga harus dikonfigurasi terpisah — menentukan level user mana yang bisa melihatnya, nominal min/maks top-up, biaya, aturan bonus, dan preset nominal cepat. Saat setup situs baru, ini harus dilakukan untuk setiap metode pembayaran (DANA / OVO / GoPay / QRIS / Kartu Bank dll).

Detail Field Antarmuka Edit¶

Field	Arti	Aturan / Contoh
Pihak Ketiga	Penyedia pembayaran pihak ketiga (dropdown)	mis. `CoverPay(Transfer)`
Metode Pembayaran	Saluran pembayaran spesifik di bawah pihak ketiga (dropdown)	mis. `DANA` / `OVO` / `GoPay` / `QRIS`
Tarif Cash-flow	Persentase biaya yang dikenakan pihak ketiga	`1.1` artinya 1.1% / isi 1 untuk 1%, 0 jika tidak ada
Biaya Tetap Per-transaksi	Biaya tetap per transaksi (IDRK)	`0` jika tidak ada / isi 0 jika tidak ada
Rentang Nominal	Min ~ maks single-deposit user (IDRK)	mis. `10 - 10000` (yaitu 10K~10M IDR) Satuan IDRK, 1 IDRK = 1000 IDR
Rasio Bonus	Persentase bonus top-up	`0` artinya tanpa bonus / isi 1 untuk 1%, maks 20, isi 0 jika tanpa bonus
Multiplier Turnover Bonus	Multiplier turnover yang dibutuhkan untuk nominal bonus	`1` x / min 1x (mencegah memberi uang gratis)
Level Member yang Terlihat	Level user mana yang bisa melihat metode pembayaran ini	Multi-select tag (lihat penjelasan level di bawah)
Urutan	Urutan tampilan di frontend	Angka kecil di depan (ascending)
Catatan	Catatan internal (tidak ditampilkan ke user)	Biasanya isi nama metode pembayaran (mis. `DANA`)
Status	Aktif / Nonaktif	Aktif = terlihat user, Nonaktif = tersembunyi
Nama Tampilan Frontend	Label yang dilihat user	mis. `DANA` / `10K = Rp10,000.00` / `CP` (multi-tag bisa ditumpuk)

Level Member yang Terlihat (Inti Isolasi Hak Akses)¶

Tag level member yang didukung backend:

Tag Level	Arti	Penggunaan Tipikal
Pilih Semua	Semua level terlihat saat dicentang	❓ Akan dikonfirmasi ke Supervisor
Default	Level default (member reguler)	❓ Akan dikonfirmasi ke Supervisor
Pelanggan Retensi 30 Hari	Member terdaftar ≥ 30 hari dengan retensi	❓ Akan dikonfirmasi ke Supervisor
Pelanggan Retensi 15 Hari	Member terdaftar 15 ~ 30 hari	❓ Akan dikonfirmasi ke Supervisor
Pelanggan Retensi 7 Hari	Member terdaftar 7 ~ 15 hari	❓ Akan dikonfirmasi ke Supervisor
User Baru 1	Sub-tier pertama user baru terdaftar	❓ Akan dikonfirmasi ke Supervisor
User Baru	User baru terdaftar	❓ Akan dikonfirmasi ke Supervisor
Pengamatan Arbitrase / BH	Member yang sebelumnya dicurigai arbitrase	❓ Akan dikonfirmasi ke Supervisor
Verifikasi Tahap Kedua / Data	Tier setelah reset password untuk verifikasi keamanan	Penarikan butuh review manual (lihat 03-Panduan Kerja Wakil Supervisor §5.2.3)

Strategi konfigurasi:

❓ Akan dilengkapi setelah konfirmasi ke Supervisor.

Daftar Nominal Cepat¶

Bagian bawah antarmuka memiliki "Daftar Nominal Cepat" — preset tier top-up yang dilihat user di frontend.

Field	Arti	Contoh
Nominal	Nilai nominal backend (satuan IDRK)	`20` / `30` / `50` / `100` / `300` / `500` / `1000` / `5000` / `10000`
Nama Tampilan Frontend	Label nominal yang dilihat user	`20K` / `30K` / `50K` / ... / `10000K`
Aksi	Hapus tier ini / Tambah tier baru	—

Konfigurasi tier tipikal: 20 / 30 / 50 / 100 / 300 / 500 / 1000 / 5000 / 10000 (9 tier), mencakup rentang nominal kecil hingga besar.

📌 Prinsip desain tier: - Onboarding nominal kecil (20~100): Threshold rendah untuk user baru - Mainstream nominal menengah (300~1000): Rentang umum untuk user aktif - VIP nominal besar (5000+): Untuk user nilai tinggi — jangan melebihi cap "Rentang Nominal" saluran - Harus mencakup kelipatan integer (mis. 50 / 100 / 500), sesuai kebiasaan user

Validasi Setelah Konfigurasi¶

Simpan konfigurasi
      │
      ▼
  Tes frontend (login dengan akun tes pada tier yang sesuai)
      │
      ▼
  ① Apakah metode pembayaran ini terlihat di halaman top-up tier ini?
  ② Apakah tier nominal cepat ditampilkan dengan benar?
  ③ Apakah nama tampilan (mis. "DANA / 10K = Rp10,000.00 / CP") sesuai ekspektasi?
      │
      ▼
  Lakukan top-up tes nominal kecil (mis. 20K)
      │
      ▼
  ✅ Verifikasi: Top-up sukses → frontend masuk → backend "Catatan Deposit" bisa dicari

Kesalahan Konfigurasi Umum (Audit Penting)¶

Jenis Kesalahan	Gejala	Konsekuensi
Rentang nominal salah	Min lebih besar dari tier cepat terendah (mis. range 50-10000, tapi cepat ada 20K)	User klik 20K dan melihat error "nominal di bawah minimum"
Rasio bonus salah	Mengisi 5% sebagai 5 (sebenarnya 5%) / mengisi 1% sebagai 0.01 (sebenarnya tanpa bonus)	Platform rugi besar, atau user tidak dapat manfaat
Multiplier turnover bonus diisi 0	User tidak butuh turnover untuk bonus	Uang gratis — user langsung tarik, platform rugi
Pilih semua tier salah	Tier BH / Data juga punya saluran nominal besar terbuka	User berisiko bisa mengeksploitasi saluran nominal besar untuk arbitrase
Status tidak diaktifkan	Lupa aktifkan setelah konfigurasi	User sama sekali tidak bisa melihat saluran ini di frontend

📝 Sumber: Catatan kerja Supervisor + analisis antarmuka backend

3.4 Kategori Desain Gambar (7 item)¶

Semua spesifikasi ukuran, batasan ukuran, template naskah gambar lihat detail di 12 · Indeks Tampilan UI & Pustaka Naskah Promosi, sebelum mendesain pastikan konfirmasi spesifikasi mengacu ke dokumen tersebut.

#	搭建内容	Penanggung Jawab	Referensi Ukuran/Spesifikasi	Keterangan
22	ICON、LOGO 设计	nuoya	ICON 196×196 ≤512KB / LOGO 240×60 ≤200KB	Mengajukan kebutuhan ke tim desain, spesifikasi detail §2.1
23	活动横幅上传	nuoya	656×176 ≤500KB	Spesifikasi+template naskah §2.2 + §3.1~3.14
24	活动内页上传	nuoya	Setiap promosi ukuran berbeda (540×240 ~ 540×900)	Spesifikasi banner internal tiap promosi §2.6
25	Banner 图片上传	nuoya	Besar 656×220 / Kecil 336×100 / Pusat Pribadi 656×160	Spesifikasi lengkap Banner §2.3
26	客服线图标、浮标上传	nuoya	Gambar bulat 1:1 (tanpa batasan ukuran)	Konfigurasi CS §2.4
27	下载页/APK/弹窗/分享图/PWA 启动页	nuoya	Halaman launching 736×1308 ≤2MB / Gambar share 1280×670 / Pop-up 320×250, dll	Materi saluran promosi §2.7 + Share §2.5
28	导航页配置	nuoya	750×250 (5 gambar bergiliran)	§2.7

📘 Sumber: Tabel Persiapan Pembangunan Situs Baru 📘 Sumber: 12-Indeks Tampilan UI (Spesifikasi ukuran lengkap + template dwibahasa naskah promosi aktivitas)

3.5 Kategori Akun (4 item)¶

#	搭建内容	Konten Pembangunan	Penanggung Jawab	Keterangan
29	客服组长后台配置、客服/远程客服后台配置	Konfigurasi backend ketua tim CS, backend CS / CS jarak jauh	❓ Akan ditentukan	Akun tim CS
30	稽核出款后台配置	Konfigurasi backend audit penarikan	❓ Akan ditentukan	Akun tim audit + operasi penarikan
31	自媒体频道创建、刷粉	Buat kanal media mandiri, tambah followers	nuoya	Pembangunan saluran Telegram/sosmed
32	客服线坐席配置	Konfigurasi agen layanan pelanggan	nuoya	Alokasi agen Salesmartly

📘 Sumber: Tabel Persiapan Pembangunan Situs Baru

3.6 Kategori Pengujian (4 item)¶

#	搭建内容	Konten Pembangunan	Penanggung Jawab	Keterangan
33	游戏测试	Pengujian game	nuoya	Konfirmasi game bisa terbuka dan berjalan normal
34	真实存取款测试	Uji deposit & penarikan nyata	yuhai	Menguji alur deposit dan penarikan lengkap
35	网址测试	Uji URL/website	nuoya	Semua domain bisa diakses normal
36	各个活动内容检查	Pemeriksaan konten tiap aktivitas	nuoya	Apakah aturan, gambar, tautan setiap promosi benar

📘 Sumber: Tabel Persiapan Pembangunan Situs Baru

3.7 Bagan Alir Pembangunan (termasuk Hubungan Paralel)¶

Berikut adalah urutan eksekusi aktual, banyak pekerjaan dapat dilakukan paralel untuk mempersingkat siklus total.

═══════════════════════════════════════════════════════
  Urutan Eksekusi Aktual Pembangunan Situs Baru (37 item)
═══════════════════════════════════════════════════════

</div>

</div>

</div>

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-03">

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-03">

</div>

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-03">

</div>

<div markdown="1" class="fresh" data-ts="2026-05-03">

<div markdown="1" class="fresh" data-ts="2026-05-04">

  Manajemen putuskan: Beli domain utama + tentukan
    template + buka backend
        │
        ▼
  Setelah domain dikonfirmasi, tiga jalur berikut
    dimulai bersamaan (paralel):
        │
  ┌─────┼──────────────────────────────┐
  │     │                              │
  ▼     ▼                              ▼
Jalur A  Jalur B                       Jalur C
Domain+  Materi                        Media mandiri+
Konfig   desain                        Akun
  │       │                            │
  ▼       ▼                            ▼
Beri     Beri tahu tim                 Ajukan akun media
tahu     UI desainer                   mandiri:
SEO      siapkan semua                 · Akun Telegram
  │      materi                        · Akun Facebook
  ▼      (ICON/LOGO/                   · Akun WhatsApp
Beli     Banner/                        │
domain   Banner promosi/               ▼
penduk-  Halaman internal/             Buat kanal/grup:
ung +    Ikon CS/Halaman               · Kanal Telegram
Umpan    download dll)                 · Kanal WhatsApp
  │           │                          │
  ▼           │ (selama menunggu        ▼
Pengika-     │ materi)                  Konfigurasi bot
tan dom-     │                          Telegram
ain (pen-    │                          (melalui
dukung+      │                          MiniApp,
PWA+         │                          selanjutnya
Umpan)       │                          integrasi alur
  │           │                          otomatisasi
  ▼           │                          di Salesmartly)
Resolusi      │                          │
DNS+akse-     │                          ▼
lerasi        │                       Input akun media
jalur         │                       mandiri ke
  │           │                       konfigurasi
  ▼           │                       platform
Konfigurasi   │                          │
backend       │                          │
(JPush/Pihak  │                          │
Ketiga/       │                          │
Pembayaran/   │                          │
Game/         │                          │
Firebase/     │                          │
Naskah dll)   │                          │
  │           │                          │
  └─────┬─────┘                          │
        │ Setelah materi siap            │
        ▼                                │
  Upload semua materi                    │
  (Banner/gambar promosi/                │
   ikon CS/halaman download dll)         │
        │                                │
        └──────────┬─────────────────────┘
                   │ Setelah semua selesai
                   ▼
        ═══════════════════════
          Tahap Pengujian (4 item)
        ═══════════════════════
                   │
                   ├─ Pengujian game
                   ├─ Pengujian deposit-penarikan nyata
                   ├─ Pengujian URL
                   └─ Pemeriksaan konten setiap promosi
                   │
                   ▼
              Situs Baru Online 🚀

📝 Sumber: Diskusi pembelajaran

Titik Paralel Kunci: Setelah domain dikonfirmasi, tidak perlu menunggu semua pengikatan domain selesai baru memulai pekerjaan lain. Memberi tahu UI buat materi, mengajukan akun media mandiri, membuat kanal Telegram dan bot, semua ini bisa dilakukan bersamaan, memanfaatkan waktu menunggu sepenuhnya.

Integrasi Bot Telegram + Salesmartly: Setelah bot dikonfigurasi melalui MiniApp, di platform manajemen CS Salesmartly konfigurasi alur otomatisasi. Operasi terkait dapat mengacu ke 03-Panduan Onboarding Wakil Supervisor · 4.12.2 Konfigurasi Alur Otomatisasi CS Salesmartly.

3.8 Ikhtisar Pembagian Tugas Pembangunan¶

Data pembagian tugas berikut berasal dari 22-Tabel Persiapan Pembangunan Situs Baru, penanggung jawab spesifik sudah ditandai di setiap tabel.

Penanggung Jawab	Jumlah Tugas	Lingkup Tanggung Jawab Utama
Martin	8 item	Pengadaan domain (utama+pendukung+umpan), beri tahu SEO, konfigurasi JPush, integrasi saluran Pihak Ketiga, paket kamuflase iOS, promosi PDD, template APK
HB	5 item	Pengikatan/resolusi domain (pendukung+PWA+umpan), akselerasi jalur, konfigurasi nominal & level saluran pembayaran
nuoya	16 item	Konfigurasi game, pembuatan dan upload semua materi (ICON/LOGO/Banner/gambar promosi/ikon CS/halaman download/halaman navigasi), konfigurasi CS, naskah backend, konfigurasi situs, kanal media mandiri, pengujian (game+URL+pemeriksaan promosi)
yuhai	2 item	Aktivasi Firebase, pengujian deposit-penarikan nyata
❓ Akan ditentukan	2 item	Konfigurasi backend ketua tim CS/CS Remote, konfigurasi backend audit penarikan

Keterangan Pemeriksaan:

Tabel persiapan asli adalah 34 item, setelah diatur dalam Panduan Kerja Supervisor menjadi 37 item (karena kategori domain dipisah lebih detail, ditambahkan "beri tahu SEO untuk peringkat" dan "konfigurasi situs"). Perbandingan perbedaan dua dokumen:

Dimensi	Tabel Persiapan Asli (22-Pembangunan Situs Baru)	Panduan Kerja Supervisor (Bab III ini)
Kategori Domain	8 item	9 item (tambah "beri tahu SEO")
Kategori Konfigurasi	11 item	11 item (sama)
Kategori Desain Gambar	7 item	7 item (sama, ditambah spesifikasi ukuran)
Kategori Akun	4 item	4 item (sama)
Kategori Pengujian	4 item	4 item (sama)
Penanggung jawab	✅ Ada	✅ Sudah disinkronkan
Penjelasan prinsip	Tidak ada	✅ Ada (sistem domain/DNS/CDN/arsitektur anti-blokir, dll)
Bagan alir paralel	Tidak ada	✅ Ada (Bagian 3.7)

📘 Sumber: 22-Persiapan Pembangunan Situs Baru

IV. Pemantauan dan Penyesuaian Efek Promosi¶

4.1 Pemantauan Promosi Situs Baru¶

Berbagai promosi yang ditetapkan saat situs baru dimulai, perlu pemantauan efek terus-menerus, tidak boleh setelah set lalu dibiarkan.

Fokus Pemantauan: - Tingkat partisipasi dan tingkat klaim setiap promosi - Dampak promosi terhadap rasio selisih deposit-tarik - Efek retensi pengguna - Apakah muncul anomali arbitrase

4.2 Pengujian Efek Pull-back Mingguan¶

Saat melakukan promosi pengujian seperti pull-back mingguan, perlu: - Terus melacak data efek pull-back - Berdasarkan data putuskan apakah perlu menyesuaikan parameter (seperti nominal pull-back, kondisi filter dll) - Efek tidak baik harus segera menyesuaikan strategi, jangan terus mengeluarkan biaya pada skema pull-back yang tidak efektif

📝 Sumber: Diskusi pembelajaran

V. Sistem Back-office HQ (houqin · Sedang Dicoba Secara Pribadi)¶

Saya sedang mencoba mengembangkan satu set sistem Back-office HQ, berharap dapat mengelola secara terpadu penjadwalan, katering, pemotongan biaya makan, dan urusan back-office lainnya, di masa depan mungkin akan diperluas ke modul absensi, alat tulis kantor, asrama, bus jemputan dll. Bagian ini memperkenalkan konten yang dapat dirujuk dari sudut pandang Supervisor.

5.1 Posisi Proyek¶

Item	Konten
Kode Proyek	houqin (back-office)
Repository Kode	`~/Coding/HRsystem/`
Tech Stack	Go + Gin + PostgreSQL + Redis (backend) / Vue 3 + TS + Naive UI (frontend) / Deploy Docker Compose
i18n	Bahasa Mandarin sebagai base, mendukung zh / en / id (Bahasa Indonesia) / ru
Mata Uang Settlement	Semua biaya makan, gaji, tagihan menggunakan USDT sebagai mata uang dasar (mendukung konversi nilai tukar real-time CNY/AMD/IDR/RUB/USD)

5.2 Masalah yang Ingin Diselesaikan¶

Berharap dapat menggantikan cara manajemen back-office yang saat ini tersebar di banyak Excel + grup WeChat: - Penjadwalan CS tersebar di WFH SHIFT.xlsx (15 Sheet) - QC dan gaji tersebar di Inspector Chat-CR_质检.xlsx (24 Sheet) - Profil pribadi di 远程个人信息_DATA WFH.xlsx (8 Sheet) - Biaya makan bergantung pada statistik manual + notifikasi grup WeChat

📌 Proposisi Nilai Inti: Memindahkan aliran informasi lintas shift dari Excel + grup WeChat ke dalam sistem, agar karyawan, Supervisor, HR, koki masing-masing menjalankan peran dengan zero error.

5.3 Cakupan Tahap Pertama (Phase 1)¶

Modul	Status	Keterangan
Modul Penjadwalan	✅ Sudah dirancang	Shift pagi / shift malam / cuti / tukar shift, termasuk alur persetujuan tukar shift/cuti
Modul Katering	✅ Sudah dirancang	Koki kelola menu + karyawan pilih satu dari tiga (makan/tidak makan/dibungkus) + sinkronisasi tukar shift
Modul Billing	✅ Sudah dirancang	Penetapan harga makanan + record konsumsi + tagihan bulanan + ekspor pemotongan gaji
Inti Platform	✅ Sudah dirancang	Auth / RBAC / Organisasi / Audit / Event Bus / Notifikasi / Multi-zona waktu / i18n
❌ Permintaan alat tulis kantor	Phase 2	Schema dan event channel sudah disiapkan
❌ Absensi clock-in	Phase 2	Sementara pakai DAKA cloud desktop
❌ Asrama / bus jemputan / seragam	Phase 2/3	—
❌ API gaji pemotongan otomatis	Phase 2	Phase 1 ekspor Excel integrasi manual

5.4 Peran Pengguna (sesuai dengan sistem manajemen panduan ini)¶

Peran Sistem HQ	Posisi yang Sesuai dalam Panduan ini	Sisi
Karyawan (Employee)	CS Remote + CS Lapangan + Wakil Supervisor dan posisi eksekusi lainnya	Telegram Mini App (utama) + Web H5 (pendukung)
Supervisor (Team Lead)	Pembaca target panduan ini—mengelola kelompok 8-15 orang	Halaman manajemen Web + Telegram Mini App
HR / Administrasi	Departemen HR + posisi Administrasi	Backend manajemen Web (PC utama)
Koki (Cook)	Personel dapur	Sisi sederhana (kelompok lebih tua)

5.5 Tindakan Inti Supervisor di Sistem HQ¶

Konfirmasi batch pesanan makan grup—Bisa dikerjakan batch sambil duduk di kantor siang hari
Pertukaran shift sementara—Saat karyawan cuti gantikan untuk menyesuaikan shift
Mengubah menu makan karyawan—Misalnya menu makan karyawan yang cuti hari itu
Lihat ringkasan penjadwalan dan absensi grup

5.6 Progress Pengembangan¶

Milestone	Waktu	Status
W0	Desain selesai (2026-04-22 ~ 2026-04-23)	✅
W1	Infrastruktur + Auth + RBAC + Org schema	🔄
W2	Audit + Event Bus + CRUD organisasi	⏳
W3	Modul katering I	⏳
W4	Katering II + penjadwalan	⏳
W5	Billing + FX + Web frontend I	⏳
W6	Web II + MiniApp	⏳
W7	Notifikasi + observabilitas + regresi keamanan	⏳
W8	Rollout abu-abu	⏳

5.7 Indeks Dokumen Internal Proyek¶

Perencanaan produk detail, keputusan teknis, rencana pengembangan lihat di direktori ~/Coding/HRsystem/: - README.md — Quick start - CLAUDE.md — Pintu masuk standar proyek (wajib baca untuk pengembangan) - docs/10-prd.md — PRD kebutuhan produk (v1.2) - docs/11-dev-plan.md — Rencana pengembangan - docs/04-p0-fixes.md — Standar perbaikan P0 - docs/adr/ — Record keputusan arsitektur (14 ADR)

📝 Sumber: README proyek houqin + PRD v1.2

VI. Daftar yang Perlu Dikonfirmasi ❓¶

No.	Hal yang Perlu Dikonfirmasi	Sumber
1	Daftar lengkap posisi yang dikelola Supervisor (selain Wakil Supervisor dan Manajemen CS apa lagi?)	Bagian 1.1
~~2~~	~~Urutan eksekusi pembangunan situs baru dan hubungan dependensi~~	✅ Sudah diselesaikan di Bagian 3.7
~~3~~	~~Pembagian operasi langsung Supervisor vs alokasi ke bawahan dalam pembangunan situs baru~~	✅ Sudah diintegrasikan pembagian penanggung jawab di Bagian 3.8
4	Indikator konkret dan sumber data pemantauan efek promosi	Bagian 4.1
5	Standar keputusan penyesuaian parameter pull-back mingguan (efek di bawah berapa baru disesuaikan?)	Bagian 4.2
6	Apa saja tipe khas "kasus sulit" yang ditangani Supervisor sehari-hari?	Bagian 2.1
7	Mekanisme pelaporan dan eskalasi antara Supervisor dan Manajer	Bab II
8	Konten konkret, frekuensi, dan kriteria penilaian pengujian vendor game tertentu	Bagian 2.7
9	Skenario lebih banyak dan cara operasi simulasi data callback	Bagian 2.7
10	Daftar field lengkap Laporan Operasi Grup, desain formula, kisaran wajar biaya transaksi	Bagian 2.8
11	Konten dan alur konfirmasi distribusi grup Pihak Ketiga Pembayaran konkret	Bagian 2.9
~~12~~	~~Lokasi penyimpanan dokumen skrip CS, frekuensi pembaruan, alur audit~~	✅ Sudah diatur di direktori 10-Pusat CS
13	Template laporan Google Sheet yang sedang digunakan saat ini (perlu didapatkan untuk menyempurnakan desain sistem dashboard data)	Bagian 2.8
14	Penanggung jawab konfigurasi backend CS/audit dalam Kategori Akun pembangunan situs baru	Bagian 3.5

Referensi Silang¶

03-Panduan Onboarding Wakil Supervisor — Alur kerja lengkap posisi Wakil Supervisor yang dikelola Supervisor
06-Panduan Kerja Supervisor Audit — Alur kerja tim audit yang dikelola Supervisor
04-Panduan Penilaian Perilaku Arbitrase Agen — Standar penilaian detail audit arbitrase
22-Persiapan Pembangunan Situs Baru — Data dasar Checklist pembangunan asli (sumber pembagian penanggung jawab)
09-Fungsi Tipe Domain — Referensi detail sistem domain
12-Indeks Tampilan UI — Spesifikasi ukuran materi dan template naskah promosi
10-Pusat CS — Pustaka skrip CS + SOP alur kerja + Standar manajemen CS Remote + Panduan Spesialis Manajemen CS Remote
04-Panduan Spesialis Manajemen CS Remote · §18 Desain Isolasi Otoritas Backend — Perbedaan otoritas backend CS Remote vs posisi manajemen lapangan dan logika keamanan