Target Pembaca: Spesialis Manajemen CS (di kantor, bertanggung jawab atas manajemen tim CS Remote serta penanganan order deposit dan withdrawal) Sumber Konten: SOP Manajemen CS Remote.docx + Diskusi Pembelajaran Penyusun: Bob ｜ Tanggal: 2026-04-30 Status: Draf awal, terus dilengkapi
Daftar Isi¶
Bagian 1 · Bisnis Inti & Penanganan Pesanan¶
Bagian 2 · Manajemen Harian Tim Remote¶
Bagian 3 · Operasional Sistem & Tools¶
Bagian 4 · Keamanan & Manajemen Personil¶
Bagian 5 · Daftar Kemampuan & Referensi Pembelajaran¶
Bagian 1 · Bisnis Inti & Penanganan Pesanan¶
I. Posisi Kerja dan Struktur Tim¶
CS Management Specialist adalah posisi manajemen lapangan yang langsung di bawah Group Leader, dengan 2 spesialis per shift, terutama bertanggung jawab atas operasional harian tim remote customer service dan penanganan pesanan abnormal. Posisi ini mencakup delapan tanggung jawab utama:
- Penanganan Pesanan Deposit/Withdrawal: Investigasi deposit yang gagal masuk, penanganan withdrawal yang macet, dan manajemen Transaction ID
- Monitoring Anomali Channel: Memantau notifikasi grup payment provider pihak ketiga dan menyampaikan ke jalur CS secara tepat waktu
- Pencarian Member ID: Mengidentifikasi akun member berdasarkan informasi wallet/rekening bank untuk feedback CS, membantu pemulihan akun
- Manajemen Penjadwalan Remote CS: Memelihara jadwal 100 orang, menangani fill/absen, menjaga stabilitas shift
- QC & Manajemen Performance: Statistik QC, penyesuaian skor, perhitungan gaji bulanan, evaluasi remote assistant
- Koordinasi Pelatihan Karyawan Baru: Berkolaborasi dengan remote assistant untuk menyelesaikan pelatihan pra-kerja CS baru
- Operasional Cloud Desktop & Keamanan: Monitoring status, distribusi Google OTP, setup Beeftext, investigasi keamanan akun
- Manajemen Personil & Administratif: Wawancara rekrutmen, evaluasi promosi internal, serah terima pengunduran diri, publikasi media sosial, seleksi remote tester
Posisi dalam sistem manajemen Supervisor:
┌──────────────┐
│ Supervisor │
└──────┬───────┘
│
┌──────────────────┼──────────────────────┐
│ │ │
┌─────▼──────┐ ┌──────▼───────┐ ┌──────────▼──────────┐
│ Wakil │ │ Spesialis │ │ Spesialis Manajemen │
│ Supervisor │ │ Koreksi Data │ │ CS │
│ ×2 │ │ Member ×2 │ │ ×2 │
└─────────────┘ └──────────────┘ └──────────┬──────────┘
│
┌───────┴────────┐
│ 5 Grup │
│ 20 orang/grup │
│ 2 asisten/grup │
└───────┬────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ...
│ Asisten │ │ Asisten │ (×5 grup, total 10 asisten)
│ Remote A │ │ Remote B │
│ Kelola 10 │ │ Kelola 10 │
└──────┬──────┘ └──────┬──────┘
│ │
CS Remote ×10 CS Remote ×10
Skala Tim: Total CS Remote 100 orang, dibagi menjadi 5 grup, masing-masing grup 20 orang + 2 asisten, total 10 Asisten Remote.
Semua waktu menggunakan Waktu Indonesia Barat (WIB, UTC+7).
CS Remote menerapkan cakupan 24 jam penuh, dengan dua versi shift:
| Versi | Shift Siang | Shift Malam | Jumlah Grup | Jumlah Orang |
|---|---|---|---|---|
| Versi A | 10:00 - 22:00 | 22:00 - 10:00 | 1 grup | 20 orang |
| Versi B | 12:00 - 00:00 | 00:00 - 12:00 | 4 grup | 80 orang |
Setiap grup 20 orang dibagi menjadi shift siang dan shift malam (masing-masing sekitar 10 orang), memastikan layanan 24 jam tanpa terputus.
Mengapa Versi B memiliki lebih banyak orang: Pukul 19:00-00:00 adalah jam puncak aktivitas pengguna, shift siang Versi B (12:00-00:00) mencakup penuh periode puncak, sehingga membutuhkan lebih banyak tenaga.
Waktu(WIB) 00 02 04 06 08 10 12 14 16 18 20 22 00
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-06">
Versi A ░░░░░░░░░░░░░░░░░░░░██████████████████████████████░░
(1 grup) ← Malam A 22:00-10:00 →← Siang A 10:00-22:00 →
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-06">
Versi B ██████████████████████████░░░░░░░░░░░░░░░░░░░░░░████
(4 grup) ← Malam B 00:00-12:00 → ← Siang B 12:00-00:00 →
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-06">
████ = Shift Siang ░░░░ = Shift Malam
Periode Tumpang Tindih Shift (paling banyak orang online bersamaan): - 12:00-22:00: Siang A + Siang B online bersama (tumpang tindih 10 jam) - 22:00-00:00: Malam A + Siang B online bersama (tumpang tindih 2 jam, buffer serah terima) - 00:00-10:00: Malam A + Malam B online bersama
Setiap Asisten Remote bertanggung jawab mengelola 10 CS Remote di timnya sendiri (setiap grup memiliki 2 asisten yang masing-masing mengelola 10 orang), tanggung jawab utama: - Pengawasan Harian: Memeriksa kualitas kerja anggota tim, penggunaan template chat, eksekusi SOP - Investigasi Kinerja: Menyelidiki data anggota tim seperti waktu respons, durasi penanganan sesi, jumlah chat - Umpan Balik Masalah: Melaporkan masalah dan anomali dalam tim kepada Spesialis Manajemen CS - Pelatihan Karyawan Baru: Bertanggung jawab atas pelatihan CS Remote baru (lihat Bab IX) - Manajemen Disiplin: Menangani masalah seperti ketidakhadiran mendadak, sikap kerja anggota tim
Member menemukan deposit tidak masuk
│
▼
┌─────────────────────────────────────┐
│ (1) CS Remote menerima │
│ · Sesuai SOP minta member │
│ memberikan bukti deposit │
│ · Screenshot harus menampilkan: │
│ nominal, status, waktu, tanggal, │
│ nomor referensi │
│ · Verifikasi tahap pertama: │
│ apakah informasi lengkap │
└──────────┬──────────────────────────┘
│ Verifikasi lulus, kirim ke grup
▼
┌─────────────────────────────────────┐
│ (2) Verifikasi Tahap Kedua oleh │
│ Spesialis Manajemen CS │
│ · Cari order deposit ini di backend │
│ · Cocokkan info screenshot dengan │
│ catatan backend: │
│ ① Apakah waktu transaksi sesuai │
│ ② Apakah metode deposit cocok │
│ (mis. backend tampil DANA, │
│ screenshot juga harus DANA) │
│ ③ Apakah nominal sama │
└──────────┬──────────────────────────┘
│
┌────┴────┐
│ │
Cocok ✅ Tidak Cocok ❌
│ │
▼ ▼
┌──────────┐ ┌──────────────────────┐
│ (3) Kirim│ │ Sampaikan ke CS Remote│
│ ke grup │ │ minta member kirim │
│ pihak 3 │ │ ulang bukti deposit │
│ untuk │ │ yang benar │
│ verifikasi│ └──────────────────────┘
└────┬─────┘
│
▼
┌─────────────────────────────────────┐
│ (4) Tindak lanjut sesuai feedback │
│ pihak ketiga │
│ · Pihak 3 konfirmasi masuk → │
│ beritahu CS untuk informasikan │
│ ke member sudah diproses │
│ · Pihak 3 konfirmasi tidak diterima│
│ → beritahu CS untuk informasikan │
│ member dan bantu selesaikan │
└─────────────────────────────────────┘
2.2 Poin-Poin Verifikasi Tahap Kedua¶
2.2.1 Pencocokan Informasi (4 item lulus semua → kirim ke Grup Channel Pembayaran Pihak Ketiga)¶
| Item Verifikasi | Normal | Anomali |
|---|---|---|
| Urutan Waktu Transaksi | Waktu pembayaran di screenshot ≥ waktu pembuatan order di backend | Urutan salah (bayar dulu baru submit order) → Tolak |
| Metode Deposit | Channel di screenshot = channel di backend (mis. sama-sama DANA) | Tidak sesuai → Kembalikan untuk diperiksa |
| Nominal | Nominal screenshot = nominal order di backend | Tidak sesuai → Kembalikan untuk diperiksa |
| Kelengkapan Screenshot | Status sukses, ada nomor referensi | Blur / terpotong / kurang info → Kembalikan untuk diperiksa |
4 item lulus semua → kirim ke Grup Channel Pembayaran Pihak Ketiga untuk verifikasi (sesuai §2.1 langkah 3-4). Diterima atau tidaknya dana berdasarkan balasan dari Grup Channel Pembayaran Pihak Ketiga.
⚠️ Logika Inti Constraint Urutan: Member harus terlebih dahulu submit form deposit di platform, sistem baru akan menghasilkan Kode Pembayaran (QR Code) atau akun tujuan transfer. Jika waktu pembayaran di screenshot lebih awal dari waktu pembuatan order di backend — artinya member bayar dulu baru submit form — dana tersebut tidak akan masuk ke akun penerima yang ditentukan platform. Constraint ini tidak terkait dengan zona waktu, harus dipenuhi di semua zona waktu.
2.2.2 Tentang "Selisih Waktu" — Informasi Referensi, Bukan Kriteria Penilaian Keras¶
Indonesia memiliki 3 zona waktu, screenshot bukti pembayaran menampilkan waktu lokal HP user — WITA (Bali / Sulawesi) lebih cepat 1 jam dari WIB di backend, WIT (Papua) lebih cepat 2 jam. Sekadar "besarnya selisih waktu" tidak dapat dijadikan dasar penilaian compliance.
Selisih waktu hanya sebagai referensi pendukung:
| Selisih Waktu = Waktu Screenshot − Waktu Order Backend | Inferensi |
|---|---|
| < 0 menit (urutan salah) | Tolak (tidak terkait zona waktu) |
| 0 - 40 menit | User WIB pembayaran normal dengan delay |
| 60 - 100 menit | Kemungkinan user WITA (Bali / Sulawesi) |
| 120 - 160 menit | Kemungkinan user WIT (Papua / Maluku) |
Tabel Cepat Provinsi Indonesia → Zona Waktu¶
| Zona Waktu | UTC | Provinsi / Kota Utama |
|---|---|---|
| WIB | +7 | Jakarta, Jawa Barat/Tengah/Timur, Banten, seluruh Sumatera, Kalimantan Barat/Tengah |
| WITA | +8 | Bali, seluruh Sulawesi, Nusa Tenggara, Kalimantan Selatan/Timur |
| WIT | +9 | Maluku, Maluku Utara, Papua, Papua Barat |
Perubahan Penting: Aturan lama "constraint keras 40 menit" telah dibatalkan — di lintas zona waktu akan salah menilai user Bali / Sulawesi / Papua, dan penilaian compliance sebenarnya bergantung pada verifikasi otoritatif Grup Channel Pembayaran Pihak Ketiga, bukan pada selisih waktu. Spesialis Manajemen CS tidak perlu mengidentifikasi zona waktu user, selisih waktu hanya untuk dilihat sekilas sebagai referensi.
📝 Sumber: Diskusi Pembelajaran + Riset Lintas Zona Waktu (spec: docs/superpowers/specs/2026-05-06-deposit-timezone-rule.md)
Member tanyakan masalah withdrawal
│
▼
┌─────────────────────────────────────┐
│ (1) CS Remote menerima dan │
│ mengumpulkan info │
│ · Nama platform │
│ · Member ID │
│ · Nomor order withdrawal │
│ · Deskripsi masalah spesifik │
│ → Kirim ke grup │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ (2) Spesialis Manajemen CS cek │
│ order di backend │
│ · Cari order withdrawal di backend │
│ · Lihat status order │
└──────────┬──────────────────────────┘
│
┌────┴──────────┐
│ │
Sukses ✅ Diproses/Anomali ⚠️
│ │
▼ ▼
┌──────────────┐ ┌──────────────────────┐
│ (3a) Cek bukti│ │ (3b) Sampaikan ke CS │
│ pembayaran di │ │ Remote sesuai status │
│ grup pihak 3 │ │ backend │
│ (kirim no │ │ · Diproses → tunggu │
│ order ke bot, │ │ · Gagal → cek alasan │
│ otomatis │ │ · Ditolak → cek │
│ balas) │ │ alasan │
└──────┬────────┘ └──────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ (4) Memproses bukti pembayaran │
│ ⚠️ Wajib masking Transaction ID │
│ (jangan tampilkan info pihak 3 ke │
│ user, hindari user komplain yang │
│ menyeret pihak 3) │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ (5) Kirim bukti yang sudah di-mask │
│ ke CS Remote │
│ Beritahu member withdrawal │
│ berhasil │
└─────────────────────────────────────┘
Mengapa harus di-masking: Transaction ID dalam bukti withdrawal (nomor seri transaksi pembayaran pihak ketiga) jika dilihat user, user dapat: - Menggunakan ID untuk melacak nama merchant pihak ketiga, lalu: - Langsung menghubungi pihak ketiga untuk komplain/klaim, melewati CS kami - Meninggalkan catatan komplain di platform pihak ketiga, mempengaruhi hubungan kerja sama kami dengan pihak ketiga - Menggunakan info pihak ketiga untuk penipuan lain
Dua Metode Penanganan (pilih salah satu):
| Metode | Tools | Operasi |
|---|---|---|
| Metode A: Masking Blur | Snapaste atau tools screenshot serupa | Screenshot bukti lengkap → gunakan fitur mosaic/blur untuk menutupi baris Transaction ID → simpan gambar, kirim ke grup |
| Metode B: Screenshot Selektif | Tools screenshot apa saja (bawaan sistem juga bisa) | Saat screenshot langsung pilih bagian tanpa Transaction ID, hanya tampilkan info penting "Transaksi Sukses + Nominal + Waktu" |
Info Penting yang Wajib Dipertahankan dalam Screenshot: - ✅ Status transaksi (Berhasil / Sukses / Success) - ✅ Nominal withdrawal - ✅ Waktu dan tanggal withdrawal - ✅ Beberapa digit terakhir akun penerima (agar member dapat mengenali akunnya sendiri) - ❌ Transaction ID / Reference Number (wajib ditutup atau dipotong) - ❌ Setiap identitas yang dapat melacak balik identitas merchant pihak ketiga
⚠️ Prinsip Inti: Metode B (screenshot selektif) lebih aman daripada Metode A (masking blur) — informasi yang langsung tidak ditampilkan tidak akan pernah dapat dipulihkan atau ditebak dengan brute force, berbeda dengan gambar yang di-masking.
📝 Sumber: Diskusi Pembelajaran
Skenario: Member bind akun DANA yang salah (mis. hanya 1 digit angka salah), tetapi akun yang salah itu kebetulan ada, dan withdrawal sukses sampai ke akun yang salah tersebut.
Prinsip Penanganan: - Pihak ketiga sudah memotong dana dan dana sudah keluar ke akun yang salah → platform tidak bertanggung jawab - Termasuk kesalahan binding member sendiri - CS perlu menjelaskan situasi ke member, dan bantu member memperbaiki binding ke akun yang benar, untuk menghindari kesalahan berulang
⚠️ Poin Kunci: Dalam kasus ini dana sudah keluar, tidak bisa ditarik kembali. Hanya bisa membantu member memperbaiki akun untuk mencegah kesalahan berikutnya.
📝 Sumber: Diskusi Pembelajaran
Spesialis Manajemen CS perlu terus memperhatikan notifikasi dari grup-grup berikut: - Grup Pembayaran/Penerimaan Pihak Ketiga — pemeliharaan bank, fluktuasi channel, anomali channel - Grup Kerja — notifikasi internal perusahaan
Grup pihak 3/grup kerja publish notifikasi
(mis: BRI maintenance, deposit mungkin telat masuk)
│
▼
┌─────────────────────────────────────┐
│ Spesialis Manajemen CS menentukan │
│ cakupan dampak │
│ · Bank/dompet mana yang terdampak? │
│ · Berdampak pada deposit atau │
│ withdrawal? │
│ · Perkiraan durasi dampak? │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Segera kirim notifikasi di grup CS │
│ utama │
│ · Jelaskan bank/dompet yang │
│ terdampak │
│ · Jelaskan jenis dampak (deposit │
│ tertunda/withdrawal dihentikan) │
│ · Jelaskan perkiraan waktu pulih │
│ (jika ada) │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Setelah CS Remote menerima │
│ notifikasi │
│ · Jika ada user yang menanyakan │
│ masalah ini │
│ · Dapat langsung memberitahu alasan │
│ · Meningkatkan efisiensi komunikasi, │
│ mengurangi eskalasi │
└─────────────────────────────────────┘
📝 Sumber: Diskusi Pembelajaran
Pencarian Member ID memiliki dua metode, prioritaskan metode pertama (dompet/akun bank), jika metode pertama tidak dapat memastikan baru gunakan metode kedua (investigasi IP) sebagai pendukung.
CS Remote minta member memberikan info
(Nama dompet/bank + nomor akun)
│
▼
CS Remote kirim ke grup
(Nama platform + jenis dompet/bank + nomor akun)
│
▼
┌─────────────────────────────────────┐
│ Spesialis Manajemen CS cari di │
│ backend │
│ · Backend → Manajemen Member │
│ → Pencarian Kartu Bank / │
│ Pencarian Dompet │
│ · Input nomor akun untuk pencarian │
└──────────┬──────────────────────────┘
│
┌────┴────┐
│ │
Hit 1 hasil Hit banyak hasil
│ │
▼ ▼
Sampaikan ID Lihat 5.3 Penanganan
ke CS Multi-Akun
Skenario yang Berlaku: Member tidak dapat memberikan info kartu bank/dompet yang di-bind, atau metode 1 tidak berhasil mengidentifikasi.
⚠️ Batasan Ketersediaan IP: Tidak semua riwayat chat mengandung alamat IP.
| Sumber Channel | IP Terlihat? |
|---|---|
| Akses Langsung Website (LiveChat) | ✅ Terlihat |
| Chat CS dari Telegram | ❌ Tidak Terlihat |
| Chat CS dari Messenger (Facebook) | ❌ Tidak Terlihat |
Jika member menghubungi CS via Telegram atau Messenger, riwayat chat di backend Salesmartly tidak mengandung alamat IP, dalam hal ini metode 2 tidak dapat digunakan, perlu langsung tanyakan ID member atau gunakan metode 1 (pencarian dompet/kartu bank).
Langkah-Langkah Pencarian:
Di backend CS (Salesmartly)
cari halaman percakapan member ini dengan CS
│
▼
Cek panel info pelanggan di sebelah kanan
apakah menampilkan IP
(Sumber Telegram/Messenger tidak ada IP)
│
┌─────┴─────┐
│ │
Ada IP Tidak ada IP
│ │
▼ ▼
Lanjut Ganti metode 1
langkah atau langsung tanyakan
berikut ID ke member
│
▼
Lihat IP login member dan nama platform
│
▼
┌─────────────────────────────────────┐
│ Masuk backend game │
│ · Manajemen Member → Halaman │
│ Investigasi IP │
│ · Input IP login member untuk │
│ pencarian │
└──────────┬──────────────────────────┘
│
┌────┴────────────┐
│ │
Hit 1 hasil Hit banyak hasil ⚠️
│ │
▼ ▼
Sampaikan ID Lihat "Penanganan
ke CS Multi-Hasil IP" di bawah
- Path Backend:
Backend → Manajemen Member → Investigasi IP - Cara Pencarian: Satu kotak input IP + tombol "Query", masukkan IP yang dicari lalu klik query
- Tampilan List 9 Kolom (urut waktu terbaru):
| Kolom | Arti |
|---|---|
| Waktu Login | Timestamp login pada IP tersebut (UTC+7) |
| Member ID | Biru dapat diklik, masuk ke arsip member — ini adalah field kunci yang harus disampaikan ke CS |
| Login IP | IP login saat ini |
| Lokasi IP | Mis. United States / Japan Osaka |
| Info Browser | Mis. Chrome 141.0 / Safari 18.1 |
| Sistem Operasi | Mis. Mac 15.6 |
| Tipe Perangkat | Mis. desktop / mobile |
| Brand HP | Mis. Apple |
| Model HP | (Sebagian mungkin kosong) |
Penanganan Multi-Hasil IP:
Sangat umum sebuah IP mendeteksi banyak Member ID (WiFi bersama, IP dinamis operator, dll), saat itu:
- Beralih ke Metode 1: Minta member memberikan akun bank/dompet yang di-bind, gunakan akun untuk mencocokkan secara presisi mengeliminasi ID lain
- Padukan dengan device fingerprint: Perhatikan perangkat login (sistem operasi/browser/model HP) apakah konsisten — multi-akun di perangkat yang sama lebih mencurigakan daripada multi-akun di IP yang sama
- Jika tetap tidak dapat dipastikan: Sampaikan beberapa kandidat ID dan situasinya ke Supervisor, biarkan Supervisor memutuskan langkah selanjutnya
⚠️ Multi Member ID di IP yang Sama = Sinyal Risiko Tinggi: Selain membantu member menemukan ID, perlu juga mengevaluasi apakah ada situasi satu orang banyak akun (lihat 5.4).
📌 Peringatan IP Berbagi di Indonesia: Operator seperti Telkomsel/Indosat/XL sebagian segmen IP-nya adalah Shared NAT, yang dapat menyebabkan beberapa user nyata berbagi satu IP publik. Hanya saat IP + Perangkat + Pola Perilaku ketiganya cocok baru dapat dinyatakan sebagai satu orang banyak akun (lihat 13-02 §V Hal yang Perlu Diperhatikan).
Skenario: User dengan satu nomor HP yang sama mendaftarkan DANA, OVO, GoPay dan jenis dompet elektronik lainnya, masing-masing di-bind ke akun member yang berbeda.
- Aturan sistem: Akun yang sama dengan jenis yang sama hanya dapat di-bind ke satu akun member (mis. satu nomor DANA hanya dapat di-bind ke satu member)
- Tetapi dompet jenis berbeda meskipun nomor HP-nya sama, dapat di-bind ke akun member yang berbeda
Cara Penanganan: 1. Berdasarkan jenis dompet (DANA/OVO/GoPay) yang diberikan CS Remote di grup, tentukan Member ID yang sesuai 2. Sampaikan ID yang benar ke CS Remote
⚠️ Peringatan Multi-Akun: Dompet berbeda dengan nomor HP yang sama di-bind ke member berbeda, sangat dicurigai sebagai satu orang banyak akun. Aturan sistem melarang satu user mendaftarkan banyak akun game. Jika menemukan situasi seperti ini, harus ditandai dan dilaporkan ke Supervisor, biarkan Supervisor/Audit memutuskan apakah perlu penanganan lebih lanjut.
Skenario: Melalui investigasi IP ditemukan banyak akun member berbeda di IP yang sama.
Logika Pertimbangan:
| Kemungkinan Alasan | Tingkat Risiko | Cara Penanganan |
|---|---|---|
| WiFi bersama keluarga/kantor, daftar oleh orang berbeda | Rendah | Gunakan metode 1 dengan akun untuk eliminasi, tangani normal |
| Perangkat sama ganti IP di waktu berbeda (IP dinamis) | Rendah | Sama seperti di atas |
| Satu orang daftar banyak akun (multi-akun) | ⚠️ Tinggi | Tandai dan laporkan ke Supervisor, biarkan Audit memutuskan |
⚠️ Standar Pelaporan: Jika beberapa Member ID di IP yang sama memiliki situasi berikut, harus segera dilaporkan ke Supervisor: - Perilaku deposit/withdrawal sangat mirip (waktu, nominal, channel berdekatan) - Akun dompet/bank yang di-bind tumpang tindih atau berkaitan - Berpartisipasi di event yang sama dan semuanya menerima hadiah - Info perangkat sangat konsisten (sistem operasi sama + versi browser sama + model HP sama)
Lihat: 04-Panduan Penilaian Perilaku Arbitrase Agen + 13-02 Panduan Penggunaan Investigasi IP
Saran Penilaian (berdasarkan dokumen Investigasi IP platform): 1. Hanya "multi-akun di IP yang sama" — bisa jadi WiFi/NAT bersama, tidak dapat dinyatakan sendiri 2. Hanya "multi-akun di perangkat yang sama" — anomali yang jelas, tingkat kecurigaan tinggi 3. IP + Perangkat + Pola Perilaku ketiganya cocok — pada dasarnya dapat dinyatakan sebagai satu orang banyak akun, segera laporkan
Alur Eskalasi Bertingkat:
Spesialis Manajemen CS menemukan kecurigaan
(Investigasi IP hit multi-akun + perilaku mencurigakan)
│
▼
┌─────────────────────────────────────┐
│ (1) Tingkat Pertama: Laporkan ke │
│ Wakil Supervisor │
│ · Sediakan: IP / beberapa Member │
│ ID / info perangkat / deskripsi │
│ perilaku mencurigakan │
│ · Wakil Supervisor verifikasi │
│ lebih lanjut │
└──────────┬──────────────────────────┘
│
┌────┴────┐
│ │
Tidak ada Ada
masalah masalah
│ │
▼ ▼
Tutup tiket ┌─────────────────────────────────────┐
│ (2) Tingkat Kedua: Wakil Supervisor │
│ investigasi mendalam │
│ · Fokus investigasi karakteristik │
│ arbitrase multi-akun (deposit/ │
│ rolling/penerimaan event) │
│ · Evaluasi tingkat keparahan │
│ masalah │
└──────────┬──────────────────────────┘
│
┌─────┴─────┐
│ │
Kasus Kasus
umum serius
│ │
▼ ▼
┌──────────┐ ┌──────────────────┐
│ Masuk │ │ (3) Tingkat │
│ proses │ │ Ketiga: notifikasi│
│ peringatan│ │ ke Supervisor │
│ arbitrase│ │ · Supervisor │
│ (lihat 04│ │ memutuskan │
│ Panduan │ │ rencana │
│ Arbitrase)│ │ penanganan │
│ │ │ · Mis: freeze │
│ │ │ akun / potong │
│ │ │ saldo / blacklist│
└──────────┘ └──────────────────┘
📌 Prinsip Kunci: Spesialis Manajemen CS tidak langsung mengambil keputusan penanganan akun — saat menemukan kecurigaan, hanya bertanggung jawab mengumpulkan info + melaporkan, penanganan diputuskan oleh Wakil Supervisor (kasus umum) atau Supervisor (kasus serius). Ini sejalan dengan prinsip "rem tanpa gas" pada isolasi akses backend §12.
📝 Sumber: Diskusi Pembelajaran + 13-02 Panduan Penggunaan Investigasi IP + 04-Panduan Penilaian Perilaku Arbitrase Agen
Spesialis Manajemen CS bertanggung jawab sesuai rencana operasional, publish konten media sosial gambar dan teks di channel yang ditentukan secara terjadwal:
| Jenis Konten | Penjelasan |
|---|---|
| Post Terjadwal Kode Penukaran | Sesuai jadwal publish gambar dan teks dengan kode penukaran, agar member dapat segera klaim |
| Konten Promosi Event | Selaras dengan ritme event platform, publish gambar dan teks promosi terkait |
| Notifikasi Operasional Lainnya | Update aturan platform, notifikasi maintenance, dan konten yang perlu dipublikasikan |
| Poin | Penjelasan |
|---|---|
| Channel Publikasi | Grup/channel media sosial Facebook, Telegram, WhatsApp, dll |
| Waktu Publikasi | Waktu Indonesia (WIB) 19:00 dan 00:00, 2 kali publish terjadwal setiap hari |
| Material Gambar | Dibuat oleh Tim UI/Desain sesuai kebutuhan. Contoh: setelah Wakil Supervisor setting kode penukaran, serahkan ke tim UI untuk buat gambar promosi sesuai kode penukaran |
| Konten Teks | Umumnya Wakil Supervisor sudah menyiapkan teks, publisher copy berdasarkan itu lalu lakukan optimasi emoji yang sesuai, usahakan setiap kali publish ada perubahan dan terasa baru |
| Pembedaan Multi-Platform | Saat mengelola banyak platform, sebelum publish wajib konfirmasi channel sesuai dengan nama platform, hindari konten salah kirim platform |
| Konfirmasi Publikasi | Setelah publish konfirmasi konten tampil normal, jika ada anomali segera beritahu Supervisor |
Alur Kolaborasi Material:
Wakil Supervisor setting kode penukaran/parameter event
│
▼
Wakil Supervisor siapkan teks + beritahu tim UI
│
├──→ Tim UI buat gambar promosi sesuai kode penukaran
│
└──→ Teks dikirim ke Spesialis Manajemen CS
│
▼
Spesialis Manajemen CS:
· Copy teks
· Optimasi sesuai (tambah emoji, sesuaikan ungkapan)
· Publish terjadwal di 19:00 dan 00:00 ke setiap channel
📘 Sumber: SOP Manajemen CS Remote.docx (Persyaratan Kompetensi Item ke-6) + Konfirmasi Diskusi Pembelajaran
Spesialis Manajemen CS bertanggung jawab atas penjadwalan semua CS Remote (100 orang): - Menyusun Tabel Jadwal Kerja, memastikan setiap shift memiliki cukup orang - Menangani pengajuan tukar libur/cuti — tentukan apakah disetujui berdasarkan kondisi jadwal, setelah disetujui sampaikan ke Supervisor - Menangani ketidakhadiran mendadak — seperti karyawan listrik mati, kondisi darurat, dll.
Tools Saat Ini: File Google Sheet WFH SHIFT(远程排班表）.xlsx (total 15 Sheet)
Struktur Tabel Inti:
| Sheet | Kegunaan |
|---|---|
| AST SPV | Tabel jadwal bulanan supervisor (37 kolom) |
| SHIFT CR1 ~ CR7 | Jadwal karyawan untuk 7 grup shift (masing-masing 42 kolom) |
| KPI (Kinerja) | Standar penilaian kinerja dan aturan pengurangan poin |
| Teks CS (Template Chat) | Library template chat CS (sudah dimigrasi ke 01-Library Template Chat CS) |
| WFH (Catatan Remote) | Standar CS Remote (sudah dimigrasi ke 03-Standar Manajemen CS Remote) |
Field Inti Tabel SHIFT CR*:
- Jam Kerja (jenis shift): PAGI / SHIFT / MALAM
- Kolom jam kerja (mis. 10:00-22:00): jelaskan jam kerja setiap shift
- Kolom tanggal (1-31 setiap bulan): status jadwal harian (Pagi / Siang / Malam / OFF / IZIN / Libur Tahunan)
- Kolom nama karyawan: identifikasi anggota setiap grup shift
⚠️ Acuan Waktu: Semua waktu menggunakan Waktu Indonesia Barat (WIB, UTC+7), header tabel akan menulis
Jam kerja sesuai dengan waktu lokal atau Waktu Indonesia Barat.
Asisten Remote melaporkan: ada karyawan
yang tidak bisa bekerja karena situasi darurat
(mis: listrik mati, urusan keluarga darurat, dll)
│
▼
┌─────────────────────────────────────┐
│ Spesialis Manajemen CS menangani │
│ · Catat alasan ketidakhadiran │
│ · Hitung durasi tidak masuk │
│ · Koordinasi orang lain untuk │
│ menggantikan shift │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Penggantian shift di kemudian hari │
│ · Waktu yang tidak masuk harus │
│ diganti dengan lembur │
│ · Atur penggantian shift di jadwal │
│ selanjutnya │
└─────────────────────────────────────┘
| # | Masalah | Dampak |
|---|---|---|
| 1 | Kurangnya Isolasi Data | Tabel Jadwal + Tabel Quality Check + Arsip Pribadi tersebar di 3 Excel, info karyawan redundan dan perlu disinkronkan manual |
| 2 | Biaya Sinkronisasi Manual Tinggi | Setelah perubahan jadwal, perlu update tabel quality check dan tabel gaji secara manual, mudah terlewat |
| 3 | Tidak Ada Validasi Otomatis | Tidak otomatis mengecek "shift duplikat/konflik jadwal/karyawan dijadwalkan dua shift" |
| 4 | Tidak Ada Analisis Tren | Data bulanan terkumpul tetapi tidak ada dashboard visualisasi (tren/perbandingan) |
| 5 | Perhitungan Gaji Manual | Hari Kerja × Gaji Harian + Bonus Kinerja, semua dihitung manual |
Saya pribadi sedang mencoba mengembangkan proyek houqin (Backend Tengah), berharap dapat menyatukan menggantikan manajemen jadwal/quality check/gaji yang saat ini tersebar di Google Sheet.
Modul yang Diharapkan Terintegrasi (Phase 1 awal): - Manajemen Jadwal (Pagi/Malam/Libur/Tukar Shift) - Catering + Billing (penetapan harga makan + catatan konsumsi + ekspor potongan gaji) - Inti Platform: Auth / RBAC / Organisasi / Audit / Multi-timezone / i18n (Mandarin/Inggris/Indonesia/Rusia) - Settlement Mata Uang: Semua biaya makan/gaji/billing menggunakan USDT sebagai mata uang dasar
7.5.1 Daftar Kebutuhan Pengembangan dari Sudut Pandang Spesialis Manajemen CS (Sudah Tercatat)¶
Kebutuhan fitur yang terkumpul selama belajar bersama di lapangan, akan diserahkan ke tim pengembang houqin:
| Sumber Bagian | Kebutuhan | Prioritas |
|---|---|---|
| §11.1.4 | Filter satu klik untuk akun Cloud Desktop yang sedang idle (menghindari pengecekan manual satu per satu) | P1 |
| §15.5 | Penerimaan pengajuan resign satu klik (karyawan submit mandiri → notifikasi otomatis ke spesialis) | P0 |
| §15.5 | Template Formulir Resign tertanam (template "Formulir Resign-Posisi Remote (Kontrak)" tertanam di sistem) | P0 |
| §15.5 | Generator password kuat otomatis (saat reset password Cloud Desktop/Salesmartly) | P1 |
| §15.5 | Identifikasi otomatis akun bersama (sistem menampilkan karyawan aktif lain yang memakai akun sama) | P1 |
| §15.5 | Distribusi password multi-channel (otomatis pilih channel Signal sesuai jenis akun: Pribadi/Kerja) | P1 |
| §15.5 | Notifikasi grup otomatis (setelah diterima, otomatis posting notifikasi resign di grup kerja) | P0 |
📌 Detail rencana produk dan progress pengembangan lihat Panduan Kerja Supervisor → 07-Panduan Kerja Supervisor · Sistem HQ Backend Tengah. Dokumen ini hanya menyimpan antarmuka penggunaan yang relevan untuk Spesialis Manajemen CS, untuk menghindari duplikasi info antar dokumen.
📝 Sumber: Diskusi Pembelajaran + Analisis File Google Sheet CS Remote Grup A + Dokumen proyek houqin
Quality Check dilakukan melalui backend manajemen CS Salesmartly (panduan penggunaan detail lihat 06-Panduan Penggunaan Backend Salesmartly), terutama memperhatikan indikator berikut:
| Indikator | Penjelasan |
|---|---|
| Waktu Respons Pertama | Waktu CS pertama kali membalas setelah user memulai sesi |
| Rata-rata Durasi Penanganan Sesi | Waktu rata-rata dari sesi mulai hingga sesi selesai |
| Jumlah Chat Hari Ini | Total user yang ditangani hari ini |
| Standar Penggunaan Template Chat | Apakah menggunakan template chat standar (lihat 01-Library Template Chat CS) |
| Eksekusi SOP | Apakah menangani masalah sesuai prosedur standar (lihat 02-SOP Alur Kerja CS Remote) |
| Sikap Layanan | Apakah sikap dalam melayani member sopan dan baik |
| Rating Positif/Negatif Member | Feedback rating member setelah sesi berakhir |
Dimensi Penilaian (Total 100 poin) — Berdasarkan analisis tabel nyata Inspector Chat-CR_质检.xlsx:
| # | Item Penilaian | Maksimal | Cara Hitung |
|---|---|---|---|
| 1 | Skor Quality Check | 20 | Setiap kesalahan kurang 3 poin (penanganan salah) / Setiap kesalahan kurang 2 poin (singkatan, tata bahasa) / Mulai dari 20 |
| 2 | Masalah Kerja | 5 | Masalah sikap kerja setiap kesalahan kurang 5 poin (lalai, dingin, lempar tanggung jawab, tidak sopan) |
| 3 | Skor Jumlah Chat | 10 | Berdasarkan formula estimasi jumlah chat (semakin banyak chat semakin tinggi skor) |
| 4 | Skor Waktu Respons Pertama | 30 | Semakin cepat respons semakin tinggi skor (bobot terbesar) |
| 5 | Skor Rata-rata Waktu Respons | 30 | Rata-rata waktu respons sepanjang sesi |
| 6 | Tambah/Kurang Skor Rating Positif Member | ±10 | Terkait dengan tingkat rating positif |
| 7 | Pengurangan Rating Negatif | Nilai negatif | Langsung kurang poin |
| Total Skor | 100+ | — | = Jumlah dari semua item di atas |
Sistem Grade (berdasarkan reverse-engineering data historis + istilah catatan aktual):
| Grade | Arti | Catatan Bahasa Indonesia | Estimasi Rentang Skor |
|---|---|---|---|
| Cukup Bagus | Luar Biasa (Excellent) | Cukup Bagus | ≥ 72.5 poin |
| Cukup | Baik (Layak) | Cukup | 62.5 ~ 72.5 poin |
| Semangat | Standar (Biasa, masih perlu usaha) | Semangat | 12 ~ 44 poin |
| No KPI | Tidak Lulus / Resign | No KPI | < 0 poin |
⚠️ Penjelasan Sampel: Rentang skor di tabel di atas berdasarkan reverse-engineering statistik dari 8 sampel historis, kepercayaan menengah. Grade Standar S/A/B/C/D/E (yang disebut di Sheet catatan) rentang skor presisinya masih perlu dikonfirmasi dengan lebih banyak data bulanan.
📊 Logika Skor Negatif Anomali Quality Check: - Rentang Normal: Skor quality check 0 ~ 20 (maksimal 20) - Pelanggaran Ringan: -10 ~ 0 (mis. akumulasi beberapa kesalahan kecil) - Pelanggaran Berat: ≤ -90 poin — skenario tipikal: karyawan resign bulan berjalan/pelanggaran berat dipotong ~92 poin sekaligus (terverifikasi sampel aktual)
📊 Formula Estimasi Jumlah Chat (regresi linear R²=0.989, kepercayaan tinggi):
- Titik Nol: Jumlah chat sekitar 2171 (tidak dipotong tidak ditambah) - Skor Negatif: Di bawah 2171 → potong linear (mis. 1759 chat sesuai -2.88 poin) - Batas Bawah: -10 poin (karyawan dengan jumlah chat sangat sedikit atau 0) - Maksimal 10: Tercapai saat jumlah chat sekitar 4400+ chatSkor Jumlah Chat = Jumlah Chat × 0.004456 - 9.67
⚠️ Larangan Singkatan (Item Pengurangan Quality Check): - Dilarang menggunakan
yg(yang),tdk(tidak),kmi(kami) dan singkatan lisan lainnya - Hindari penggunaan berlebihan kata "kami", gunakan ekspresi yang lebih sopan
Alur Penilaian:
┌─────────────────────────────────────┐
│ Asisten Remote (×10, 2 orang/grup) │
│ · Setiap orang memeriksa 10 orang │
│ yang dia kelola │
│ · Cek penggunaan template chat, │
│ eksekusi SOP, sikap │
│ · Catat masalah dan kinerja spesifik │
│ → Sampaikan ke Spesialis Manajemen CS│
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Spesialis Manajemen CS │
│ · Rangkum feedback 10 asisten │
│ · Padukan dengan indikator data │
│ Salesmartly │
│ · Terapkan 7 formula penilaian → │
│ hitung total skor │
│ · Tetapkan grade S/A/B/C/D/E │
│ · Isi Tabel Gaji & Kinerja yang │
│ diberikan Supervisor │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Rangkuman Akhir Bulan │
│ · Hari Kerja × Gaji Harian = │
│ Gaji Pokok │
│ · Total Skor → Bonus Kinerja yang │
│ Layak │
│ · Total Gaji → kirim via alamat │
│ Wallet │
└─────────────────────────────────────┘
Tabel Gaji & Kinerja yang Digunakan Saat Ini: Inspector Chat-CR_质检.xlsx (24 Sheet)
Field Inti (17 item):
| No | Nama Field | Kegunaan |
|---|---|---|
| 1 | Nama Karyawan | Sinergi dengan tabel jadwal/arsip pribadi |
| 2 | Shift | Pagi / Siang / Malam |
| 3 | Skor Quality Check (20 poin) | Lihat §8.2 |
| 4 | Masalah Kerja (5 poin) | Penilaian sikap kerja |
| 5 | Rating Positif Member | Tingkat rating positif (mis. 5.26%) |
| 6 | Tambah/Kurang Rating Positif (10 poin) | Konversi tingkat rating positif menjadi skor |
| 7 | Pengurangan Rating Negatif | Pengurangan negatif |
| 8 | Jumlah Chat | Total chat bulan ini |
| 9 | Estimasi Jumlah Chat | Formula konversi jumlah chat |
| 10 | Skor Jumlah Chat (10 poin) | Maksimal 10 |
| 11 | Skor Waktu Respons Pertama (30 poin) | Bobot tertinggi |
| 12 | Skor Rata-rata Waktu Respons (30 poin) | Bobot setara |
| 13 | Total Skor | Jumlah semua item |
| 14 | Bonus Kinerja yang Layak | Bonus terkait dengan total skor |
| 15 | Hari Kerja | Hari Kerja bulan ini (basis gaji) |
| 16 | Penilaian | S/A/B/C/D/E |
| 17 | Catatan | Penjelasan khusus |
Organisasi Sheet:
- Pisah berdasarkan shift: CR 01, CR 02... setiap grup shift Sheet terpisah
- Tampilan berpasangan: Sebagian Sheet menampilkan "Karyawan A - Karyawan B" berpasangan (mencerminkan hubungan partner shift)
- Iterasi bulanan: Generate versi baru per bulan (mis. APRIL)
❓ Akan dikonfirmasi ke Supervisor: - Rentang skor spesifik dan nominal bonus kinerja untuk grade S/A/B/C/D/E - Formula presisi estimasi jumlah chat (di statistik user beberapa karyawan muncul nilai negatif seperti -2.88, apakah normal) - Logika perhitungan skor negatif anomali (seperti skor quality check -92) (apakah ada item pengurangan khusus)
Spesialis Manajemen CS perlu menilai kinerja 10 Asisten Remote bawahannya, dimensi penilaian:
| Dimensi | Hal yang Dinilai |
|---|---|
| Ketepatan Waktu Respons | Apakah dapat segera membalas dan menangani setelah feedback masalah |
| Kemampuan Menangani Masalah | Saat CS bawahan ada masalah, apakah asisten dapat segera berkomunikasi dan mendorong perbaikan |
| Efektivitas Manajemen Tim | Apakah kualitas kerja tim secara keseluruhan meningkat |
| Tren Frekuensi Masalah | Apakah frekuensi masalah harian semakin berkurang |
| Hasil Pelatihan | Apakah karyawan baru setelah pelatihan dapat lancar kerja mandiri |
WFH SHIFT (Tabel Jadwal Kerja)
│ Nama Karyawan + Hari Kerja
▼
Inspector Chat-CR_质检 (Tabel Penilaian Kinerja + Tabel Perhitungan Gaji)
│ Dimensi Penilaian (Sheet Nilai): Quality Check/Masalah Kerja/Waktu Respons → Total Skor → S/A/B/C/D/E
│ Perhitungan Gaji Bulanan (Sheet INSPECTOR APRIL): Gaji Pokok + Hari Kerja Aktual + Rasio Jumlah Chat → Total Gaji
▼
远程个人信息_DATA WFH (Arsip Pribadi)
│ Alamat Wallet + Status Karyawan Tetap
▼
Pembayaran Gaji (Transfer USDT ke alamat Wallet)
Lokasi Sheet perhitungan gaji: Inspector Chat-CR_质检.xlsx → Sheet INSPECTOR / INSPECTOR APRIL (iterasi per bulan)
Daftar Field Lengkap (Indonesia-Mandarin, total 32 kolom):
| Nama Kolom (Indonesia) | Mandarin | Arti |
|---|---|---|
| Nama Kerja | 小名 | Nama kerja karyawan |
| CS | 客服昵称 | Nama tampilan di LiveChat |
| Jam Kerja | 上班时间 | Periode shift |
| Tanggal Kerja | 入职时间 | Tanggal masuk kerja |
| Total | Total | Total jumlah chat bulanan |
| 1 ~ 30 | 每日列 | Jumlah chat harian (data 30 hari) |
| GAJI POKOK | 基础工资 | Gaji dasar tetap (USDT, mis. 360 / 400) |
| Total hari kerja | 上班天数 | Hari kerja yang dijadwalkan bulan ini (mis. 29 hari) |
| OFF | 休假 | Jumlah hari libur mingguan |
| IZIN | 请假 | Jumlah hari cuti |
| Hari Kerja | 实际上班 | = Total hari kerja - OFF - IZIN |
| GAJI | 实际工资 | = Gaji Pokok × (Hari Kerja / Total hari kerja) |
| LC | 单量 | Jumlah chat LiveChat |
| Jumlah Chat | 应当接线量 | Target jumlah chat bulanan (mis. 10150) |
| KPI | 绩效最高 | Bonus kinerja maksimal (USDT, mis. 320 / 340) |
| kerajinan | 全勤 | Bonus full attendance (USDT) |
| KPI/Hari | 每日绩效 | = KPI / Total hari kerja |
| Total KPI | 上班天数绩效 | = KPI/Hari × Total hari kerja |
| Jumlah Chat(%) | 接线量比例 | = LC aktual / Jumlah Chat target |
| KPI STAFF | 应得绩效 | = Total KPI × Jumlah Chat(%) |
| Extra KPI | 绩效得分 | Item tambahan poin |
| Potong KPI | 应得工资 | Item potongan kinerja (mis. case tertentu potong 20) |
| Total KPI | 绩效总分 | = KPI STAFF + Extra KPI - Potong KPI |
| Total Gaji | 应得工资 / 总工资 | = GAJI + Total KPI |
| Remark | 备注 | Penjelasan khusus |
Formula Perhitungan Inti:
Hari Kerja = Total hari kerja - OFF - IZIN
GAJI (Gaji Aktual) = GAJI POKOK × (Hari Kerja / Total hari kerja)
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-06">
KPI/Hari = KPI / Total hari kerja
Total KPI (per hari kerja) = KPI/Hari × Total hari kerja ≈ KPI
Jumlah Chat(%) = LC aktual / Jumlah Chat target
KPI STAFF (Bonus yang Layak) = Total KPI × Jumlah Chat(%)
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-06">
Total KPI (Skor Akhir) = KPI STAFF + Extra KPI - Potong KPI
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-04">
</div>
<div markdown="1" class="fresh" data-ts="2026-05-04">
<div markdown="1" class="fresh" data-ts="2026-05-06">
【Total Gaji = GAJI + Total KPI】 ← Gaji bulanan akhir (USDT)
Sampel Nyata (sudah disensor):
| Karyawan | Gaji Pokok | Hari Kerja/Total | Gaji Aktual | KPI Max | Rasio Chat | KPI yang Layak | Potongan | Total Gaji |
|---|---|---|---|---|---|---|---|---|
| A | 400 | 27/29 | 386.67 | 340 | 0.75 | 246.32 | 0 | 632.99 |
| B | 400 | 27/29 | 386.67 | 340 | 0.63 | 205.52 | 0 | 592.19 |
| C | 360 | 27/29 | 348.00 | 320 | 0.61 | 188.89 | 0 | 536.89 |
| D | 400 | 29/29 | 386.67 | 340 | 0.56 | 185.12 | 20 | 551.79 |
Distribusi Gaji (sampel 126 orang): - Terendah: 0 (kasus khusus seperti cuti sebulan penuh/belum masuk kerja) - Median: ~543 USDT - Rata-rata: ~479 USDT - Tertinggi: ~657 USDT
✅ Otomasi Perhitungan Gaji: Sheet perhitungan gaji sudah ada dan menggunakan formula Excel untuk perhitungan otomatis, tidak ada tahap yang hilang. Tujuan Sistem Manajemen HQ bukan "menutupi yang hilang", tetapi mengintegrasikan data jadwal/quality check/gaji yang tersebar di 3 Excel ke satu sistem terpadu, menghindari sinkronisasi manual, menyediakan dashboard visualisasi, mendukung isolasi akses.
📝 Sumber: Diskusi Pembelajaran + Analisis File Google Sheet CS Remote Grup A (WFH SHIFT / Inspector Chat-CR_质检 INSPECTOR APRIL Sheet / 远程个人信息_DATA WFH)
CS Remote baru masuk
│
▼
┌─────────────────────────────────────┐
│ Spesialis Manajemen CS menugaskan │
│ ke Asisten Remote yang sesuai │
│ Asisten Remote bertanggung jawab │
│ pelatihan one-on-one │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Asisten Remote melakukan pelatihan │
│ · Belajar template chat → 01 │
│ · Alur kerja → 02 SOP │
│ · Standar WFH → 03 Standar │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Asisten Remote feedback progres │
│ pelatihan │
│ · Bisa kerja mandiri → │
│ sesuaikan jadwal │
│ · Perlu lanjut pelatihan → │
│ perpanjang masa pelatihan │
│ · Tidak cocok untuk posisi → │
│ sampaikan ke spesialis manajemen │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Spesialis Manajemen CS lakukan │
│ penyesuaian sesuai feedback │
│ · Bisa mandiri → jadwal resmi │
│ · Perlu perpanjangan → atur lebih │
│ banyak waktu pelatihan │
│ · Tidak cocok → pertimbangkan ganti │
│ posisi atau hentikan │
│ · Jika perlu, atur asisten lain │
│ melatih ulang │
└─────────────────────────────────────┘
| Dokumen | Kegunaan |
|---|---|
| 01-Library Template Chat CS | Belajar template balasan standar, kuasai bahasa untuk berbagai skenario |
| 02-SOP Alur Kerja CS Remote | Belajar pohon keputusan lengkap untuk operasi deposit/withdrawal/akun |
| 03-Standar Manajemen CS Remote | Belajar 10 langkah harian WFH + 15 standar + FAQ |
📝 Sumber: Diskusi Pembelajaran
Logika Dasar: Personel Pengujian Remote diseleksi dari CS Remote, dikelola oleh Spesialis Manajemen CS, mengemban tiga jenis pekerjaan pengujian — domain, deposit, dan game — sebagai "pos terdepan" pemantauan risiko platform.
Sumber: Diseleksi dari CS Remote aktif.
Persyaratan Perangkat / Sumber Daya:
| Item | Persyaratan |
|---|---|
| Perangkat HP | Memiliki HP Android dan iPhone iOS sekaligus (dua sistem) |
| Kartu SIM | Memiliki kartu SIM Tiga Operator Besar Indonesia sekaligus (seperti TK dll. tiga operator) |
| Kemampuan Office | Mahir menggunakan Google Spreadsheet (untuk pelaporan hasil) |
| Dasar Bisnis | Wajib sudah pernah bertugas sebagai CS Remote selama beberapa waktu, paham bisnis platform |
⚠️ HP dua sistem + kartu SIM Tiga Operator Besar adalah syarat keras — pengujian perlu mencakup berbagai perangkat dan lingkungan jaringan.
10.2 Tinjauan Tiga Jenis Pekerjaan Pengujian¶
| Jenis Pengujian | Frekuensi | Tools | Tujuan Utama |
|---|---|---|---|
| Pengujian Domain | Setiap 1 jam sekali | URL Tes API + HP Tiga Operator Besar | Mendeteksi ketersediaan domain platform, menemukan domain yang diblokir lebih awal |
| Pengujian Deposit | Setiap 2 jam sekali | Akun pengujian + Halaman Deposit setiap platform | Mendeteksi ketersediaan metode pembayaran pihak ketiga |
| Pengujian Game | Dipicu oleh notifikasi Supervisor | HP Android / iOS | Memverifikasi fungsi game tertentu, teks UI, performa |
Domain Dibagi Dua Jenis: - Domain Utama (domain bisnis): ⚠️ Paling penting — sekali bermasalah harus lapor langsung ke grup pengujian secara real-time - Domain Promosi / Domain Umpan: Diblokir adalah perilaku yang diharapkan, ganti sesuai alur
Alur Pengujian Setiap Jam:
Mulai pengujian jam ini
│
▼
┌─────────────────────────────────────┐
│ ① Tes batch dengan kartu TK │
│ (Operator 1) │
│ · Buka batch URL Tes API setiap │
│ platform di HP │
│ (satu tab per platform sekaligus)│
│ · Tunggu hasil terkumpul │
└────────────┬────────────────────────┘
│
┌──────┴──────┐
│ │
Semua hijau ✅ Ada merah ❌
│ │
▼ ▼
Ganti operator ┌─────────────────────────────┐
2/3 ulangi │ ② Buka domain bermasalah │
│ │ secara terpisah untuk tes │
▼ │ · Akses pertama ditemukan │
Kumpulkan │ masalah │
hasil tiga │ · Bersihkan cache browser /│
operator │ pakai mode incognito tes │
│ ulang, hilangkan │
│ gangguan cache │
└────────────┬────────────────┘
│
┌──────┴──────┐
│ │
Akses pulih Tetap tidak bisa
│ │
▼ ▼
Tes selesai ┌─────────────────────┐
│ ③ Konfirmasi anomali│
│ domain │
│ · Update Google │
│ Spreadsheet │
│ · Domain Utama → │
│ lapor langsung │
│ ke grup pengujian│
└─────────────────────┘
│
▼
Ganti Operator 2 → ulangi ①②③
│
▼
Ganti Operator 3 → ulangi ①②③
│
▼
Kumpulkan hasil tes Tiga Operator Besar ke Google Spreadsheet
Poin Optimasi Efisiensi Pengujian:
| Poin Optimasi | Cara | Manfaat |
|---|---|---|
| Paralel Batch | Satu SIM operator buka banyak tab sekaligus, tes banyak platform sekaligus | Waktu tes puluhan platform dari serial → paralel |
| Hilangkan Cache | Saat pertama bermasalah, bersihkan cache/incognito tes ulang, hindari laporan palsu | Kurangi false positive, hindari laporan tidak perlu |
| Tiga Operator Wajib Dites | Cakupan TK / IM3 / XL dll. → bedakan "blokir seluruh jaringan" vs "blokir satu operator" | Lokalisasi presisi sumber blokir (operator memblokir vs DNS pollution dll.) |
| Domain Utama Prioritas Lapor Real-time | Anomali Domain Utama → tidak menunggu rangkuman, langsung lapor ke grup pengujian | Domain Utama level bencana, setiap menit kehilangan user |
📌 Dokumen Terkait: Alur penanganan blokir domain lihat 07-Panduan Kerja Supervisor · §3.2.4 Manual Operasi Penanganan Blokir Domain
10.4.1 Persiapan Sekali (Registrasi Akun)¶
Personel pengujian onboarding
│
▼
Daftarkan satu akun pengujian di setiap platform (pekerjaan sekali)
│
▼
Kirim semua info akun pengujian platform ke Spesialis Manajemen CS
│
▼
┌─────────────────────────────────┐
│ Spesialis Manajemen CS menandai │
│ di backend │
│ · Setiap akun pengujian │
│ ditandai sebagai "Akun │
│ Transfer Tes Remote" di │
│ backend │
│ · Selanjutnya dapat memantau │
│ aktivitas tes akun ini di │
│ backend │
└─────────────────────────────────┘
10.4.2 Alur Patroli Setiap 2 Jam¶
Mulai patroli ronde ini
│
▼
┌─────────────────────────────────┐
│ Masuk setiap platform (pakai │
│ akun pengujian platform terkait)│
│ │ │
│ ▼ │
│ Masuk halaman deposit │
│ │ │
│ ▼ │
│ Tes semua metode pembayaran │
│ pihak ketiga di platform ini │
│ · Klik masuk setiap metode │
│ (DANA/OVO/QRIS/Kartu Bank/ │
│ GoPay dll.) │
│ · Periksa apakah muncul │
│ normal: │
│ - QR Code penerima ✅ │
│ - Akun bank penerima ✅ │
│ · Gejala anomali: │
│ - Error │
│ - QR Code tidak tampil │
│ - Loading gagal │
└──────────┬──────────────────────┘
│
▼
Update hasil setiap platform × setiap metode pembayaran
ke Google Spreadsheet
⚠️ Penting: Saat pengujian tidak perlu deposit nyata — cukup tes sampai tahap "muncul QR Code/akun penerima", membuktikan backend metode pembayaran tersebut normal.
📌 Mekanisme Pemeriksaan Acak: Spesialis Manajemen CS dapat login menggunakan akun tester untuk pemeriksaan acak — selama tester benar-benar memulai aksi pengujian deposit (meskipun tidak membayar), backend seharusnya memiliki catatan order deposit terkait. Jika pemeriksaan acak menemukan tidak ada catatan order deposit untuk akun pengujian pada periode tertentu, berarti tester tersebut tidak melaksanakan pengujian sesuai aturan, dan ini dapat dijadikan dasar pengurangan kinerja.
10.4.3 Mekanisme Pengawasan Akun Pengujian¶
| Dimensi | Penjelasan |
|---|---|
| Penandaan Akun | Backend ditandai sebagai "Akun Transfer Tes Remote", dibedakan dari member nyata |
| Pengawasan Perilaku | Spesialis Manajemen CS dapat melihat aktivitas akun pengujian di backend (jumlah deposit/jumlah gagal dll.), mengawasi apakah personel pengujian bekerja sesuai aturan |
| Pemeriksaan Login | Login menggunakan akun tester ke platform dan cek silang dengan "jumlah order deposit yang seharusnya" — setiap patroli 2 jam × jumlah platform × jumlah metode pembayaran = jumlah order yang seharusnya. Lebih sedikit = pengujian terlewat |
| Disiplin Penggunaan | Akun pengujian tidak boleh dipakai untuk deposit nyata atau game pribadi |
10.5.1 Cara Pemicu¶
Dipicu oleh notifikasi Supervisor — contoh: "Tolong tes game baru/anomali tertentu di platform tertentu".
10.5.2 Perangkat Pengujian¶
Sesuai notifikasi: - HP Android → tes pengalaman game di sisi Android - iPhone iOS → tes pengalaman game di sisi iOS
10.5.3 Item Pengecekan Standar¶
| # | Item Pengecekan | Standar Lulus | Gejala Anomali |
|---|---|---|---|
| 1 | Tingkat Sukses Masuk Game | Game terbuka normal, tidak error | Layar hitam/putih/crash/tidak respons |
| 2 | Latency dan Lag | Operasi lancar, tidak ada delay yang nyata | Respon lambat, gambar lag, animasi drop frame |
| 3 | Interaksi Tombol | Semua tombol game (taruhan/batal/konfirmasi dll.) berfungsi normal | Tombol tidak respons, klik tidak efektif, salah trigger aksi lain |
| 4 | Bahasa UI | Bahasa Indonesia sepenuhnya (tanpa sisa Mandarin/Inggris) | Tombol/popup/error message lokal muncul Mandarin/Inggris |
| 5 | Ikon / Elemen UI | Tampilan lengkap, tidak salah posisi | Gambar gagal load, elemen UI salah posisi |
| 6 | SFX / Animasi | Diputar normal | SFX hilang, animasi anomali |
❓ Perlu dilengkapi: Item pengujian game yang lebih rinci dapat mengacu pada [11-Manual Platform/19-Manajemen Game], akan dilengkapi setelah dokumen game spesifik tersedia.
10.5.4 Mekanisme Pelaporan¶
Selesai tes → susun hasil (screenshot + deskripsi teks)
│
▼
Lapor ke grup kerja → @ Supervisor
│
▼
Supervisor putuskan tindakan lanjutan (hubungi vendor game/atur konfigurasi/jeda game dll.)
| Dimensi | Penjelasan |
|---|---|
| Pengujian Domain Setiap Jam | Dalam window waktu ± tertentu pada setiap jam bulat wajib selesai lapor |
| Pengujian Deposit Setiap 2 Jam | Lapor pada jam genap, mencakup periode utama setiap hari |
| Pelacakan Aktivitas Akun Pengujian | Melalui penandaan backend + monitoring perilaku |
| Penilaian Kualitas | Tes terlewat/lapor terlambat/laporan keliru akan memengaruhi kinerja (dapat dimasukkan ke §8 Manajemen Quality Check dan Kinerja) |
📝 Sumber: Pembelajaran lapangan
Spesialis Manajemen CS bertanggung jawab atas operasi harian lingkungan Cloud Desktop CS Remote, mencakup lima jenis pekerjaan: pemantauan status karyawan, distribusi OTP, restart mandiri / teknis, peminjaman akun sementara, dan konfigurasi alat input cepat Beeftext.
Lihat status online CS Remote real-time via management end cloud desktop:
| Item Cek | Status Normal | Penanganan Anomali |
|---|---|---|
| Apakah online tepat waktu | Setelah shift mulai semua karyawan sudah login | Hubungi Asisten Remote terkait untuk konfirmasi situasi |
| Apakah ada offline anomali | Tetap online selama jam kerja | Periksa alasan — apakah sudah dilaporkan, apakah benar |
| Aktivitas kerja | Terus menerima chat, tidak ada periode panjang tanpa operasi | Ingatkan asisten untuk mendorong, jika perlu catat dan laporkan |
Ini adalah aksi inti dari perspektif admin cloud desktop, sangat berbeda dari perspektif karyawan menggunakan cloud desktop sendiri (05 §7).
Cara Pemeriksaan: Spesialis Manajemen CS dapat secara acak membuka cloud desktop karyawan mana saja (CR01~CR50+) di management end, dan melihat alur kerja karyawan tersebut secara real-time.
Fokus Pemeriksaan:
| Dimensi Pemeriksaan | Poin Observasi | Penanganan Anomali |
|---|---|---|
| Apakah Alur Operasi Sesuai Standar | Apakah menangani masalah sesuai 02-SOP Alur Kerja CS Remote (seperti cek ID dulu, ikuti pohon keputusan SOP) | Tidak standar → beritahu Asisten Remote terkait untuk lanjut pelatihan |
| Efisiensi Kerja | Durasi penanganan satu sesi, jumlah chat paralel, interval idle | Terlalu lambat/cepat anomali → komunikasi untuk pahami alasan |
| Penggunaan Template Chat | Apakah menggunakan template chat standar 01-Library Template Chat CS, apakah sembarangan pakai singkatan (yg/tdk/kmi) | Singkatan atau template tidak standar → ingatkan + kurang KPI |
| Operasi Backend | Apakah operasi dalam batas akses, apakah ada perilaku query anomali (seperti sering query member yang sama) | Anomali → segera lapor Supervisor (lihat §14.3 Tanggung Jawab Investigasi) |
| Identifikasi Kesalahan | Apakah balasan ke member ada salah (seperti ID salah ketik di backend, info salah terkirim) | Segera ingatkan karyawan untuk memperbaiki, hindari eskalasi |
Saran Ritme Pemeriksaan: - Periode puncak (19:00-00:00) setiap jam Pemeriksaan Acak 5-10 mesin - Periode normal setiap 2 jam pemeriksaan 3-5 mesin - Fokus perhatian pada karyawan baru (masa pelatihan) dan karyawan dengan skor quality check rendah belakangan
❓ Perlu konfirmasi: Nama platform spesifik sistem manajemen cloud desktop dan antarmuka management end, akan dilengkapi setelah konfirmasi ke Supervisor training.
Mekanisme Restart Dua Tingkat:
CS Remote melaporkan masalah pada Cloud Desktop
│
▼
┌─────────────────────────────────┐
│ Tingkat 1: Restart Mandiri │
│ Spesialis Manajemen CS via │
│ backend Cloud Desktop │
│ · Lakukan operasi restart │
│ untuk akun tersebut │
└──────────┬──────────────────────┘
│
┌────┴────┐
│ │
Pulih Masih bermasalah
│ │
▼ ▼
Kerja ┌─────────────────────────────────┐
pulih │ Tingkat 2: Lapor ke Grup Teknis │
│ CR │
│ · Jelaskan masalah spesifik di │
│ Grup Teknis CR │
│ · Ditangani oleh teknisi │
│ operator Cloud Desktop │
│ · Teknisi melakukan restart │
│ yang lebih dalam │
│ (perkiraan: lapis host / │
│ lapis fisik) │
└─────────────────────────────────┘
Mengapa Restart Mandiri Tidak Selalu Bisa Menyelesaikan (perkiraan):
| Tingkat Restart | Pelaksana | Cakupan Pengaruh | Masalah yang Bisa Diselesaikan |
|---|---|---|---|
| Restart Mandiri Backend | Spesialis Manajemen CS | Soft restart pada lapis OS Virtual Machine Cloud Desktop | OS lag, proses aplikasi hang, pemakaian memori berlebih |
| Restart Grup Teknis CR | Teknisi operator Cloud Desktop | Restart lapis host / lapis fisik + network stack + driver | Koneksi jaringan VM putus, masalah resource host, anomali driver, error virtual disk, dan kegagalan dalam lain |
⚠️ Perbedaan teknis di atas merupakan perkiraan — Spesialis Manajemen CS hanya perlu tahu alur dua tingkat "Mandiri → Tidak Selesai → Eskalasi ke Grup Teknis CR". Implementasi teknis spesifik ❓ menunggu konfirmasi Grup Teknis CR.
Format Laporan ke Grup Teknis CR (saran):
Akun Cloud Desktop: [Nomor CR]
Gejala Kerusakan: [Deskripsi spesifik, misal: layar hitam, jaringan putus, aplikasi crash, operasi tertentu hang, dll.]
Operasi yang Sudah Dicoba: [Sudah Restart Mandiri N kali tetap tidak efektif]
Tingkat Urgensi: [Periode puncak = mendesak / Periode normal = biasa]
Skenario: Saat Cloud Desktop seorang CS Remote mengalami kerusakan, setelah dilaporkan ke Grup Teknis CR dan teknisi mengatakan butuh waktu untuk menangani, dapat dicari akun Cloud Desktop yang tidak digunakan dari shift saat ini untuk dipinjamkan sementara ke CS tersebut, agar tidak menunda pekerjaan.
Konfirmasi CS yang bermasalah perlu menunggu penanganan teknis
│
▼
┌─────────────────────────────────┐
│ Cari akun Cloud Desktop yang │
│ idle pada shift saat ini │
│ · Akun yang belum dijadwalkan │
│ pada shift saat ini │
│ · Akun karyawan in-shift yang │
│ sementara belum login │
│ · Akun karyawan libur/cuti │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ Kirim info akun idle ke CS │
│ yang bermasalah │
│ (Signal Kerja) │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ CS yang bermasalah login akun │
│ pinjaman dan lanjutkan kerja │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ Setelah teknisi selesai │
│ menangani akun asli, beritahu │
│ CS untuk kembali ke akun sendiri│
└─────────────────────────────────┘
📌 Kebutuhan Fitur Sistem HQ (sudah dicatat): Sistem karyawan perlu fitur baru "Filter satu klik untuk akun Cloud Desktop yang sedang idle", menghindari kerumitan pengecekan manual satu per satu. Detail lihat §7.5 Sistem HQ Backend Tengah.
📝 Sumber: Pembelajaran lapangan
Saat CS Remote login cloud desktop, sistem mungkin akan mengirim One-Time Password (OTP) ke HP/email yang di-bind. Saat karyawan tidak dapat menerima kode verifikasi sendiri, Spesialis Manajemen CS membantu menerima dan meneruskan.
Alur Penanganan:
Karyawan feedback: tidak bisa login,
tidak terima kode verifikasi
│
▼
Spesialis Manajemen CS terima kode
(dari management end atau perangkat
bersama perusahaan)
│
▼
Segera teruskan ke karyawan via grup/chat pribadi
│
▼
Karyawan konfirmasi login sukses → catat selesai
❓ Perlu konfirmasi: Sumber spesifik kode verifikasi (terima di management end/SMS/perangkat khusus) dan channel forwarding, akan dilengkapi setelah konfirmasi ke Supervisor training.
| Jenis Masalah | Cara Penanganan |
|---|---|
| Karyawan login gagal | Konfirmasi akun benar → bantu teruskan kode verifikasi → jika tetap tidak terselesaikan lapor Supervisor |
| Cloud desktop koneksi terputus | Arahkan karyawan koneksi ulang → jika timeout tidak pulih, eskalasi ke Supervisor |
| Akses akun anomali | Catat masalah dan sampaikan ke Supervisor, tunggu perbaikan akses |
| Konflik akun digunakan banyak orang | Minta karyawan keluar dari akun orang lain lalu login ulang ke akun sendiri (lihat 03-Standar Manajemen CS Remote §1.3) |
📘 Sumber: SOP Manajemen CS Remote.docx (Persyaratan Kompetensi Item ke-8)
Logika Dasar: Cloud Desktop yang dipakai CS Remote semuanya bersistem Windows, alat input cepat pendampingnya adalah Beeftext (alat open source gratis). Beeftext memungkinkan CS mengonfigurasi penggantian otomatis kode pendek → teks panjang (misalnya mengetik ;w1 otomatis berkembang menjadi salam pembuka lengkap).
11.4.1 Alur Konfigurasi Standar Sebelum Bertugas¶
Karyawan baru onboarding / Reinstall lingkungan
│
▼
┌─────────────────────────────────┐
│ ① Install Beeftext │
│ · Download installer dari │
│ beeftext.org │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ ② Konfigurasi input cepat sesuai│
│ library template chat │
│ · Mengacu pada nomor di │
│ [01-Library Template Chat CS]│
│ (w1/t1/d1/wd1/gs1...) │
│ · Buat aturan kode pendek → │
│ teks panjang di Beeftext │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ ③ Export file konfigurasi JSON │
│ · Halaman utama Beeftext → │
│ Export │
│ · Simpan sebagai file `.json` │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ ④ Upload ke Google Drive tim │
│ · Saran penamaan file: │
│ `beeftext-[nama]-[tgl].json` │
│ · Update setiap kali library │
│ template chat berubah │
└─────────────────────────────────┘
11.4.2 Alur Pemulihan Kerusakan (Pemulihan Cepat Setelah Cloud Desktop Direinstall)¶
Cloud Desktop bermasalah perlu reinstall / Beeftext reinstall
│
▼
Install ulang Beeftext
│
▼
┌─────────────────────────────────┐
│ Download file backup JSON │
│ karyawan dari Google Drive tim │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ Halaman utama Beeftext → Import │
│ Pilih file JSON yang baru saja │
│ didownload │
└──────────┬──────────────────────┘
│
▼
✅ Semua input cepat langsung pulih, hemat waktu konfigurasi ulang
11.4.3 Tanggung Jawab Manajemen Spesialis Manajemen CS¶
| Dimensi | Tanggung Jawab |
|---|---|
| Pengecekan Onboarding | Setelah karyawan baru selesai konfigurasi, periksa apakah JSON sudah di-upload ke Google Drive tim |
| Sinkronisasi Update Template | Saat library template chat di-update, ingatkan karyawan aktif untuk meng-update konfigurasi Beeftext + ekspor backup ulang |
| Pemeliharaan Drive | Bersihkan file backup karyawan yang sudah resign secara berkala |
| Penyampaian Pelatihan | Pada sesi pelatihan karyawan baru, pastikan karyawan menguasai konfigurasi Beeftext dan operasi ekspor |
📝 Sumber: Pembelajaran lapangan
11.5 Manajemen Pendaftaran Akun Signal¶
Logika Dasar: Software utama untuk komunikasi internal tim adalah Signal. CS Remote lokal Indonesia kesulitan mendaftar Signal karena keterbatasan KYC dan lain-lain, sehingga Spesialis Manajemen CS yang mendaftarkan atas nama mereka melalui Cloud Desktop karyawan, dengan menggunakan nomor HP internasional dari platform hero-sms.com untuk menerima Kode Verifikasi.
11.5.1 Skenario Pemicu¶
| Skenario | Penanganan |
|---|---|
| Karyawan baru bergabung | Pendaftaran akun Signal pertama kali untuk karyawan baru |
| Masalah akun karyawan lama | Pendaftaran ulang (nomor HP tidak aktif / akun terblokir / pindah perangkat tidak bisa pulih, dll.) |
11.5.2 Alur Operasi (End-to-End)¶
⚠️ Prinsip Pemisahan Lingkungan Operasi: hero-sms.com adalah kredensial manajemen yang sensitif, hanya boleh login di Komputer Admin Sendiri — sama sekali tidak boleh login atau mengoperasikan hero-sms.com di Remote Desktop karyawan (Cloud Desktop), untuk menghindari karyawan melihat akun platform, saldo, area inbox, dan informasi sensitif lainnya. Di Cloud Desktop karyawan hanya melakukan langkah "konfigurasi Signal untuk karyawan tersebut" saja.
Lingkungan Operasi
【Komputer Admin Sendiri】
[1] Buka hero-sms.com, login akun manajemen
├─ Cek saldo
├─ Saldo cukup → pilih nomor + minta penerimaan Kode Verifikasi Signal
└─ Saldo tidak cukup → eskalasi ke Group Leader untuk top-up, tunggu top-up selesai baru lanjutkan
│
▼
[2] Salin nomor HP yang dipilih; biarkan jendela area inbox hero-sms.com terbuka untuk digunakan
│
▼
─────────────────────────────────────────────────
【Remote Desktop Karyawan (Cloud Desktop CR0X)】
[3] Login Cloud Desktop karyawan
│
▼
[4] Di Cloud Desktop buka aplikasi Signal, mulai pendaftaran
├─ Terima Terms & Privacy
├─ Masukkan nomor HP internasional lengkap dari langkah [2]
│ - Wajib menyertakan Kode Negara (mis. +62 Indonesia / +7 Rusia / +1 Amerika)
│ - Hilangkan angka 0 di depan
│ - Kode Negara mengikuti negara asal nomor saat pemilihan di hero-sms.com
└─ Submit Signal → SMS Kode Verifikasi akan dikirim ke hero-sms.com (diterima di Komputer Admin Sendiri)
│
▼
─────────────────────────────────────────────────
【Komputer Admin Sendiri】
[5] Terima Kode Verifikasi di area inbox hero-sms.com → salin
└─ Jika SMS tidak masuk: kembali ke Cloud Desktop karyawan, klik "Call me" di Signal untuk beralih ke Verifikasi Suara
(panggilan suara juga akan diterima di hero-sms)
│
▼
─────────────────────────────────────────────────
【Remote Desktop Karyawan (Cloud Desktop CR0X)】
[6] Kembali ke Signal di Cloud Desktop, masukkan Kode Verifikasi untuk menyelesaikan pendaftaran
│
▼
[7] Atur Profil
├─ Nama Depan / First Name (**wajib diisi**, bisa pakai ID Karyawan atau identitas posisi, mis. "CS-A12")
├─ Nama Belakang / Last Name (opsional)
└─ Foto Profil (opsional)
│
▼
[8] Atur Signal PIN (**wajib dibuat**)
├─ 4-20 digit angka atau alfanumerik
├─ Digunakan untuk perpindahan perangkat / pemulihan akun
└─ ⚠️ PIN **dicatat di Komputer Admin Sendiri** dalam buku/manajer kata sandi, jangan ditulis di Cloud Desktop
│
▼
[9] Tarik ke Grup Kerja yang sesuai
└─ Tarik ke grup sesuai posisi karyawan dan kebutuhan pasar (pasar berbeda menggunakan grup berbeda, sesuai konfigurasi aktual saat itu)
│
▼
[10] Logout dari Cloud Desktop karyawan + beritahu karyawan bahwa Signal sudah siap
│
▼
─────────────────────────────────────────────────
【Komputer Admin Sendiri】
[11] Pemeliharaan Berkelanjutan: cek saldo hero-sms.com secara berkala
└─ Saldo rendah → eskalasi ke Group Leader untuk top-up
11.5.3 Manajemen Akun Platform hero-sms.com¶
| Item | Konten |
|---|---|
| Tanggung Jawab Platform | Menyediakan nomor HP internasional untuk menerima Kode Verifikasi Signal + auto-debit periodik untuk perpanjangan nomor HP (Tetap Aktif) |
| Hak Penggunaan Akun | Spesialis Manajemen CS login dan menggunakan secara langsung, tidak perlu pengajuan ke atas |
| Lingkungan Login | ⚠️ Hanya login di Komputer Admin Sendiri — sama sekali tidak boleh login hero-sms.com di Cloud Desktop karyawan (isolasi kredensial sensitif) |
| Top-up | Saldo tidak cukup → Spesialis Manajemen CS eskalasi ke Group Leader, Group Leader mengatur top-up |
| Tetap Aktif Nomor HP | Platform auto-debit untuk perpanjangan — saldo tidak cukup akan menyebabkan nomor HP tidak aktif → akun Signal karyawan tersebut akan terputus |
11.5.4 Catatan Penting¶
- ⚠️ Pemisahan Lingkungan (paling penting): hero-sms.com hanya login di Komputer Admin Sendiri, Cloud Desktop karyawan hanya melakukan operasi pendaftaran Signal. Antara keduanya hanya nomor HP + Kode Verifikasi yang ditransfer satu arah — jangan buka halaman hero-sms.com di Cloud Desktop karyawan, jangan login akun hero-sms.com di Cloud Desktop.
- PIN juga hanya disimpan di Komputer Admin Sendiri: gunakan password manager untuk mencatat Signal PIN setiap karyawan, jangan tulis ke file / catatan apapun di Cloud Desktop — bahkan karyawan sendiri tidak boleh tahu PIN-nya
- Nomor HP harus Tetap Aktif: hero-sms.com auto-debit untuk perpanjangan nomor HP secara periodik; jika saldo habis, nomor HP tidak aktif → akun Signal karyawan tersebut akan terputus (tidak bisa menerima verifikasi perangkat baru, mungkin akan dihapus dari jaringan Signal)
- Jangan menganggap nomor HP yang didaftarkan di hero-sms.com sebagai nomor HP asli karyawan: ini hanya nomor virtual untuk menerima Kode Verifikasi Signal, jangan digunakan untuk alur bisnis lain
- Kode Negara mengikuti negara asal nomor: Signal melihat Kode Negara dari nomor HP, tidak terkait dengan lokasi sebenarnya karyawan — Kode Negara saat pendaftaran mengikuti negara nomor yang dipilih di hero-sms.com
11.5.5 Menunggu Konfirmasi dari Group Leader ❓¶
- Frekuensi monitoring saldo hero-sms.com (sekali per hari / minggu / bulan?)
- Threshold peringatan saldo (saldo berapa baru eskalasi ke Group Leader untuk top-up?)
📝 Sumber: Diskusi Pembelajaran Shadowing Langsung + Riset dokumen pendaftaran resmi Signal (Signal Support · Register a phone number / Signal PIN)
Logika Dasar: Lingkungan kerja fisik CS Remote tidak terkontrol (jaringan rumah, tanpa monitoring, mungkin ada keluarga/teman serumah yang melihat, perangkat mungkin dipakai pribadi), bahkan untuk fungsi bisnis yang sama, posisi remote harus memiliki akses "lebih sedikit" dari posisi di kantor. Ini bukan ketidakpercayaan, tetapi melindungi CS Remote secara alami terbebas dari rantai kecurigaan saat terjadi insiden dana.
Backend platform memiliki 4 modul besar, perbandingan akses CS Remote dengan posisi manajemen CS sebagai berikut:
| Modul | CS Remote Bisa Lihat | Spesialis Manajemen CS Bisa Lihat | Penjelasan Perbedaan |
|---|---|---|---|
| Manajemen Member (13-Member dan Risk Control) | ✅ 14 sub-halaman | ✅ 14 sub-halaman (setara) | Akses setara, kebutuhan bisnis query data member |
| Manajemen Keuangan (14-Keuangan dan Pembayaran) | ⚠️ 3 sub-halaman | ✅ 6 sub-halaman (lebih 3) | Isolasi Hak Akses Inti — lihat §12.2 |
| Catatan Event (17-Catatan Event) | ✅ 18 sub-halaman | ✅ 18 sub-halaman (setara) | Akses setara, kebutuhan bisnis konsultasi event |
| Tools Marketing (16-Tools Marketing) | ⚠️ 2 sub-halaman | ✅ 3 sub-halaman (lebih 1) | Kontrol akses pembuatan kode penukaran — lihat §12.3 |
| Halaman | CS Remote | Spesialis Manajemen | Fungsi Inti | Data Sensitif yang Termasuk |
|---|---|---|---|---|
| 02-Deposit Pihak 3 Belum Masuk | ✅ | ✅ | Order deposit dompet elektronik pihak ketiga (DANA/OVO/dll) yang menunggu konfirmasi | Member ID, nomor order, nominal deposit, channel pihak 3, metode pembayaran, waktu pengajuan |
| 04-Catatan Deposit | ✅ | ✅ | Arsip semua order deposit, dapat batalkan konfirmasi salah dalam 30 menit | Termasuk akun dompet/nomor kartu bank lengkap member (akun yang dipakai user untuk bayar), nomor order, channel deposit, channel promosi, nominal |
| 07-Lock Withdrawal | ✅ | ✅ | Pool review pertama order withdrawal, dapat lock/unlock | Member ID, nomor order, jenis withdrawal (BANK/DANA), nominal withdrawal, biaya admin, jumlah deposit/withdrawal, pengunci |
| 03-Deposit Bank Belum Masuk | ❌ | ✅ | Deposit kartu bank lokal Indonesia (BCA/BRI/BNI) yang menunggu konfirmasi | Nomor kartu bank transfer member + nomor kartu penerimaan platform + info matching nomor order di berita |
| 05-Pembayaran Withdrawal | ❌ | ✅ | Layer eksekusi order yang sudah di-lock, pembayaran tunggal/penolakan batch | Nomor kartu bank/akun dompet binding withdrawal member, pemilihan channel pembayaran, hak penolakan |
| 06-Catatan Withdrawal | ❌ | ✅ | Arsip semua withdrawal + konfirmasi cadangan "pihak 3 sudah bayar" | Akun withdrawal member, biaya admin, biaya transaksi, channel pihak 3 detail, audit operator, alasan penolakan |
| Halaman | CS Remote | Spesialis Manajemen | Fungsi Inti | Data Sensitif |
|---|---|---|---|---|
| 04-Pesan Internal-Semua User | ✅ | ✅ | Kirim pesan sistem ke semua member | Rendah: hanya konten teks |
| 05-Pesan Internal-User Tertentu | ✅ | ✅ | Kirim pesan sistem ke member tertentu (seperti notifikasi kompensasi withdrawal tertahan) | Rendah: hanya konten teks |
| 01-Kode Penukaran | ❌ | ✅ | Generate kode penukaran yang dapat diklaim untuk hadiah + setting kelipatan turnover | Sangat Tinggi: hak generate bonus dari nol |
| Dimensi | Konten |
|---|---|
| Jalur Ancaman | ① Lihat akun binding withdrawal lengkap member → bawa akun + nomor order ke grup pihak 3 menyamar member untuk meraup dana (samar member komplain withdrawal gagal minta pihak 3 bayar lagi) ② Field operator + flow pembayaran lengkap → kerja sama internal-eksternal mengontrol urutan pembayaran / sengaja menunda withdrawal member tertentu ③ Screenshot keluar untuk profiling rantai pencucian uang atau penipuan komplain |
| Titik Hambat | Hambat "info akun sisi pembayaran + hak operasi" — posisi remote hanya tersisa "Lock Withdrawal" yaitu operasi searah hanya bisa intercept, tidak bisa loloskan, tidak bisa melihat akun pembayaran spesifik |
| Alasan Bisnis | Hak keputusan pembayaran milik posisi keuangan + posisi manajemen CS, pekerjaan CS Remote hanya perlu "menemukan mencurigakan → lock → eskalasi", tidak perlu lihat detail pembayaran dan akun member |
| Dimensi | Konten |
|---|---|
| Jalur Ancaman | ① Halaman ini berisi nomor kartu bank transfer member + nomor kartu penerimaan platform + nomor order di berita → bawa nomor order ke grup pihak 3 menyamar keuangan memalsukan bukti pembayaran untuk meraup dana ② Nomor kartu penerimaan platform bocor → black market phishing menyamar CS untuk terima pembayaran ③ Info nomor kartu dijual ke black market credential stuffing untuk deposit palsu/pencucian uang |
| Titik Hambat | Hambat exposure "infrastruktur penerimaan platform + nomor kartu bank user". Deposit Pihak 3 Belum Masuk hanya menampilkan hasil callback gateway pihak 3, tidak menampilkan field nomor kartu bank spesifik |
| Alasan Bisnis | Deposit kartu bank umumnya channel VIP nominal besar, ditangani oleh personel khusus posisi di kantor + posisi keuangan untuk mencocokkan bukti |
| Dimensi | Konten |
|---|---|
| Jalur Ancaman | Kode penukaran = hak generate bonus dari nol — generate kode untuk akun sendiri/keluarga/komplotan → tukar uang sungguhan → mencuri dana platform tanpa biaya |
| Titik Hambat | Putuskan total rantai "posisi remote → hak penciptaan dana". Pesan internal hanya bisa menyampaikan informasi, tidak dapat menghasilkan dana |
| Alasan Bisnis | Memberi benefit termasuk aksi keputusan posisi marketing + posisi manajemen, harus melalui jejak persetujuan |
Filosofi desain: Beri "rem" ke posisi remote, jangan beri "gas" — bisa intercept withdrawal mencurigakan, tetapi tidak bisa loloskan dana apapun.
| Halaman | Kebutuhan Bisnis | Mengapa Aman |
|---|---|---|
| Deposit Pihak 3 Belum Masuk | Tangani komplain user deposit tidak masuk | Data adalah callback gateway pihak 3 yang sudah desensitisasi, tidak ada nomor kartu bank platform |
| Catatan Deposit | Cocokkan komplain deposit historis | Hanya read-only historis, tidak ada hak operasi, tidak ada keputusan pembayaran |
| Lock Withdrawal | Temukan kecurigaan risk control segera bekukan | Aksi risk control searah (intercept > loloskan), biaya kesalahan adalah penundaan bukan kerugian dana |
Karena isolasi hak akses, banyak titik bisnis CS Remote harus feedback di grup, dieksekusi oleh posisi di kantor:
| Skenario Bisnis | CS Remote Bisa Lakukan | Harus Dieksekusi Posisi di Kantor |
|---|---|---|
| Investigasi deposit tidak masuk | Kumpulkan bukti member, verifikasi awal | Spesialis Manajemen CS cek di "03-Deposit Bank Belum Masuk"/"05-Pembayaran Withdrawal" |
| Penanganan withdrawal tertahan | Kumpulkan info member, lock withdrawal mencurigakan | Spesialis Manajemen CS eksekusi penolakan di "05-Pembayaran Withdrawal" + verifikasi grup pihak 3 |
| Reset password/PIN | Terima permintaan member + feedback di grup | Wakil Supervisor eksekusi reset + tarik ke level Verifikasi Tahap Kedua |
| Perubahan kartu bank/dompet | Kumpulkan bukti + feedback di grup | Posisi Koreksi Data Member di kantor eksekusi perubahan |
| Kirim hadiah kode penukaran | Feedback kebutuhan di grup | Spesialis Manajemen CS/Wakil Supervisor generate kode penukaran |
Isolasi hak akses hanya garis pertahanan pertama, Spesialis Manajemen CS perlu juga menerapkan pertahanan berlapis:
| Pertahanan | Langkah | Penanggung Jawab |
|---|---|---|
| Audit Operasi | Perhatikan log operasi backend, secara berkala Pemeriksaan Acak perilaku query/export CS Remote | Spesialis Manajemen CS |
| Peringatan Anomali | Jumlah query member harian anomali, terus-menerus buka data member yang sama, operasi di luar jam kerja → lapor Supervisor | Spesialis Manajemen CS |
| Lingkungan Jaringan | CS Remote harus pakai cloud desktop (CR) yang dialokasikan perusahaan, dilarang komputer pribadi | Lihat detail §11 Manajemen Cloud Desktop |
| Perlindungan Screenshot | CS Remote dilarang screenshot konten backend untuk dikirim keluar (denda $50/kali) | Lihat detail §14.4 Langkah Pencegahan |
| Desensitisasi Data Member | Screenshot ke member harus mask semua PII (nomor HP/nomor kartu/akun pihak 3) | Lihat detail 05-Pelatihan Onboarding §3.3 |
📚 Poin Pelatihan: Buat CS Remote memahami "Dibatasi bukan karena tidak dipercaya, tetapi melindungi Anda agar tidak menanggung kesalahan" — saat terjadi insiden dana, orang yang tidak punya akses secara alami terbebas dari rantai kecurigaan.
📝 Sumber: Diskusi Pembelajaran + Manual Platform 14-Keuangan dan Pembayaran + 16-Tools Marketing
STK (Serah Terima Kerja) adalah dokumen serah terima yang harus diverifikasi setiap shift, mencatat status kerja shift sebelumnya, anomali channel, hal-hal yang perlu ditindaklanjuti, dan info penting lainnya.
CS Remote setiap hari masuk kerja langkah ke-4 yaitu "Cek Dokumen STK dan tanda tangan" (lihat 03-Standar Manajemen CS Remote §1.4).
CS Remote bertanggung jawab cek dan tanda tangan, Spesialis Manajemen CS perlu verifikasi tambahan hal berikut:
| Item Verifikasi | Penjelasan |
|---|---|
| Kelengkapan Konten | Apakah notifikasi anomali channel, order yang perlu ditangani, hal khusus shift sebelumnya semua sudah dicatat |
| Update Terbaru Platform | Apakah penyesuaian event, update aturan, channel naik/turun sudah disinkronkan ditulis |
| Status Tanda Tangan CS | Konfirmasi semua CS Remote yang bertugas sudah baca dan selesai tanda tangan konfirmasi |
| Hal yang Perlu Ditindaklanjuti | Apakah masalah yang tersisa dari shift sebelumnya memiliki PIC dan arah penanganan yang jelas |
Waktu Verifikasi: Selesaikan verifikasi sesegera mungkin setelah shift dimulai, jika ditemukan ada yang terlewat atau hal anomali segera hubungi shift sebelumnya untuk melengkapi.
❓ Perlu konfirmasi: Format spesifik dokumen STK (file/pesan grup/formulir), lokasi arsip, cara tanda tangan, akan dilengkapi setelah konfirmasi ke Supervisor training.
CS Remote memiliki akses untuk melihat info member dan membantu mengubah password, terdapat risiko keamanan berikut:
Modus Pencurian: Beberapa CS memanfaatkan kesempatan membantu member reset password login atau password withdrawal, login ke akun member → mengubah kartu bank/dompet yang di-bind ke milik mereka → ajukan withdrawal → mencuri dana member.
Wakil Supervisor sudah menerapkan mekanisme keamanan "Verifikasi Tahap Kedua/Level Data" dalam alur reset password: - Setelah reset password, member otomatis masuk ke level Verifikasi Tahap Kedua - Pada level ini withdrawal tidak melalui pembayaran otomatis, harus review manual - Saat Wakil Supervisor melakukan review akan mengecek apakah akun withdrawal adalah data lama (normal) atau data baru (mencurigakan)
Alur Verifikasi Review Withdrawal:
Member ajukan withdrawal
│
▼
┌─────────────────────────────────────┐
│ Wakil Supervisor cocokkan info │
│ withdrawal │
│ · Apakah nama akun penerima sama │
│ dengan info pendaftaran member? │
│ · Apakah akun withdrawal sama dengan │
│ yang di-bind sebelumnya? │
└──────────┬──────────────────────────┘
│
┌────┴────┐
│ │
Sama ✅ Tidak Sama ❌
│ │
▼ ▼
Withdrawal ┌──────────────────────────┐
Normal │ (1) Pertama tutup hak │
│ withdrawal │
│ (2) Minta member │
│ verifikasi identitas │
│ konfirmasi apakah │
│ ybs ganti akun sendiri│
└──────────┬───────────────┘
│
┌────┴────┐
│ │
Mencurigakan🔴 Asli 🟢
│ │
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ Minta verifikasi │ │ Tidak perlu video │
│ video │ │ · Setelah konfirmasi │
│ · Gunakan HP lain │ │ pulihkan withdrawal│
│ rekam video │ │ · Withdrawal normal │
│ · Tampilkan info 2 │ └──────────────────────┘
│ akun dompet berbeda │
│ · Jika sudah pakai 2 │
│ HP, harus pakai HP │
│ ke-3 (pastikan tidak│
│ PS palsu) │
└──────────────────────┘
⚠️ Aturan Verifikasi Video: - Tujuannya mencegah pemalsuan screenshot — minta member rekam video dengan HP lain, sambil menampilkan halaman info akun dari dua dompet elektronik berbeda - Jika member sudah menggunakan 2 HP (satu menampilkan dompet A, satu menampilkan dompet B), maka harus menggunakan HP ke-3 untuk merekam video, memastikan keaslian gambar - Jika dapat dibuktikan screenshot asli (yaitu memang ybs sendiri yang ganti akun), tidak perlu verifikasi video HP ketiga, langsung konfirmasi dan pulihkan withdrawal
Verifikasi Tahap Kedua oleh Wakil Supervisor adalah pertahanan setelah kejadian, Spesialis Manajemen CS perlu melakukan investigasi sebelum dan saat kejadian:
Temukan sinyal mencurigakan (salah satu trigger)
· Member komplain akun dicuri/dana anomali
· Wakil Supervisor menolak withdrawal
mencurigakan dan beri feedback
· Quality check menemukan operasi anomali CS
│
▼
┌─────────────────────────────────────┐
│ (1) Lokalisasi CS yang terlibat │
│ · Cari riwayat sesi member ini di │
│ backend Salesmartly │
│ · Konfirmasi CS mana yang menangani│
│ permintaan reset password/ │
│ perubahan data │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ (2) Investigasi riwayat chat │
│ · Apakah CS eksekusi reset password │
│ sesuai SOP │
│ · Apakah meminta member memberikan │
│ bukti identitas │
│ · Apakah ada operasi anomali │
│ (seperti aktif mengarahkan member │
│ untuk mengubah info binding) │
└──────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ (3) Verifikasi catatan operasi │
│ backend │
│ · Cek timeline perubahan data │
│ akun member │
│ · Apakah interval waktu Reset │
│ Password → Perubahan Binding → │
│ Withdrawal anomali singkat │
│ · Apakah dompet/kartu bank baru │
│ yang di-bind terkait dengan CS │
│ tersebut atau akun mencurigakan │
│ lainnya │
└──────────┬──────────────────────────┘
│
┌────┴────┐
│ │
Konfirmasi Bukan
Pencurian Tersangka
│ │
▼ ▼
┌──────────┐ ┌──────────────┐
│ (4a) │ │ (4b) │
│ Lapor ke │ │ Catat hasil │
│ Supervisor│ │ investigasi │
│ Tangani │ │ Arsip untuk │
│ sesuai │ │ referensi │
│ aturan │ └──────────────┘
│ · Skors │
│ · Bekukan │
│ · Tarik │
└──────────┘
| Level Pencegahan | Langkah | Penanggung Jawab |
|---|---|---|
| Level Aturan | Dalam pelatihan jelaskan: ubah data member tanpa izin = denda $50/kali, mencuri akun = skors + tindakan | Asisten Remote (pelatihan) |
| Level Alur | Semua reset password harus dengan konfirmasi leader, CS Remote tidak berwenang eksekusi mandiri | Spesialis Manajemen CS |
| Level Teknis | Setelah reset password otomatis masuk level Verifikasi Tahap Kedua, withdrawal harus review manual | Wakil Supervisor (review) |
| Level Monitoring | Pemeriksaan Acak berkala riwayat sesi terkait reset password, investigasi pola anomali | Spesialis Manajemen CS |
| Level Pelacakan | Semua operasi perubahan data ada log backend, dapat dilacak ke operator dan waktu spesifik | Supervisor |
⚠️ Prinsip Kunci: CS Remote hanya dapat mengumpulkan info dari member dan menyampaikan ke grup, semua operasi reset password dan perubahan data harus dieksekusi oleh personel di kantor yang memiliki akses (Spesialis Manajemen CS/Wakil Supervisor). CS Remote sendiri tidak memiliki akses langsung untuk mengubah data member.
📝 Sumber: Diskusi Pembelajaran
Spesialis Manajemen CS mengemban pekerjaan penambahan personel tim CS Remote: - Rekrutmen Eksternal: Sesuai kekurangan tim saat ini (resign/ekspansi), atur wawancara kandidat - Promosi Internal: Identifikasi CS Remote terbaik, rekomendasikan promosi menjadi Asisten Remote, mendukung pembangunan jenjang
Identifikasi kebutuhan rekrutmen (kekurangan tim)
│
▼
Dapatkan CV/kontak kandidat
(Sumber: rujukan Supervisor/rekomendasi internal)
│
▼
Atur waktu wawancara, lakukan wawancara
(sesuai checklist pertanyaan standar di bawah)
│
▼
Evaluasi kandidat, beri skor komprehensif
│
▼
Lulus → laporkan ke Supervisor, atur pelatihan
onboarding (lihat detail Bab IX)
Tidak lulus → catat alasan, lanjut rekrutmen
Berikut adalah 10 pertanyaan screening standar untuk wawancara CS Remote, ditanyakan satu per satu sesuai urutan:
| # | Pertanyaan | Tujuan Penilaian |
|---|---|---|
| 1 | Please introduce yourself. (Silakan perkenalkan diri Anda) | Kemampuan ekspresi, kelancaran komunikasi |
| 2 | Where are you currently located? (Saat ini di mana?) | Konfirmasi lokasi geografis, evaluasi lingkungan jaringan |
| 3 | What is your current living situation? (own house / rented / dormitory) (Kondisi tempat tinggal: milik sendiri/sewa/asrama) | Stabilitas lingkungan kerja |
| · How is your internet connection? Any stability issues? (Bagaimana koneksi internet? Stabil?) | Kondisi dasar kerja remote | |
| · What device do you use for work (laptop/PC)? What are the specifications? (Perangkat dan spesifikasi kerja?) | Apakah perangkat memenuhi syarat | |
| · Typing test (please complete): https://10fastfingers.com/typing-test/indonesian (Tes kecepatan mengetik) | Kecepatan mengetik langsung mempengaruhi efisiensi CS | |
| · Are you familiar with AutoText or keyboard shortcuts? (Apakah familiar dengan input cepat?) | Potensi efisiensi kerja | |
| 4 | Does your area experience frequent power outages? (Apakah daerahmu sering mati listrik?) | Risiko kontinuitas kerja remote |
| 5 | What is your work experience? Have you worked as a Customer Service (CS) before? (Pengalaman kerja? Pernah jadi CS?) | Kesesuaian pengalaman |
| 6 | Please explain your understanding of the Customer Service role. (Apa pemahaman Anda tentang pekerjaan CS?) | Pemahaman posisi, kesadaran layanan |
| 7 | Explanation of salary, leave policy, and KPI structure. (Penjelasan gaji, kebijakan cuti, dan struktur KPI) | Konfirmasi kandidat menerima syarat |
| 8 | Work setup explanation: (Penjelasan cara kerja) | Konfirmasi kandidat memahami bentuk pekerjaan |
| · Work From Home (WFH) (Kerja jarak jauh) | — | |
| · Using cloud desktop / remote tools (similar to TeamViewer) (Gunakan cloud desktop/tools remote) | — | |
| 9 | Are you able to handle 250+ live chat inquiries per day? (Bisa handle 250+ live chat per hari?) | Daya tahan beban kerja |
| 10 | How much RAM does your laptop/PC have? (RAM laptop/PC seberapa besar?) | Persyaratan minimum cloud desktop |
⚠️ Tes mengetik di pertanyaan 3 adalah item screening wajib — CS Remote perlu mengetik cepat untuk membalas member, kandidat dengan kecepatan mengetik lambat tidak cocok untuk posisi ini.
⚠️ Volume 250+ chat di pertanyaan 9 — Ini adalah beban kerja harian yang sebenarnya, harus konfirmasi kandidat dapat menerima multitasking intensitas tinggi.
| Dimensi Penilaian | Hal yang Dinilai |
|---|---|
| Kualitas Kerja | Template chat standar, eksekusi SOP akurat, tingkat kesalahan rendah |
| Tanggung Jawab | Kehadiran stabil, aktif menemukan dan feedback masalah |
| Kemampuan Komunikasi | Komunikasi dengan member dan tim lancar, tahu batas |
| Kemampuan Belajar | Cepat menguasai aturan baru dan perubahan alur |
| Kerjasama Tim | Mau membantu karyawan baru, menggerakkan suasana tim |
Saran promosi perlu dilaporkan ke Supervisor untuk persetujuan, setelah disetujui atur pelatihan asisten baru dan serah terima tanggung jawab.
Lihat: Persyaratan Kompetensi Wajib Item ke-10 — "Mampu mengidentifikasi CS Remote terbaik dan promosikan menjadi Asisten Remote, mendukung pembangunan jenjang tim".
❓ Perlu konfirmasi: Alur persetujuan promosi spesifik dan formulir yang dibutuhkan, akan dilengkapi setelah konfirmasi ke Supervisor training.
Hal administrasi seperti karyawan resign, perubahan personel perlu diisi di template aplikasi administrasi sesuai aturan, untuk memastikan alur sesuai standar.
Lihat: Persyaratan Kompetensi Wajib Item ke-9 — "Memahami formulir resign, formulir clearance, dan template aplikasi, memastikan alur administrasi sesuai standar".
❓ Perlu konfirmasi: Lokasi spesifik template formulir dan cara pengisian, akan dilengkapi setelah konfirmasi ke Supervisor training.
📘 Sumber: SOP Manajemen CS Remote.docx (Persyaratan Kompetensi Item ke-9, 10)
Logika Dasar: Resign CS Remote melibatkan perubahan password pada beberapa sistem akun, koordinasi akun bersama, dan isolasi informasi sensitif, harus dijalankan sesuai alur standar untuk mencegah karyawan yang resign mempertahankan akses lanjutan apa pun.
15.5.1 Alur Resign Lengkap¶
CS Remote mengajukan permohonan resign
(jelaskan situasi, tentukan tanggal resign)
│
▼
┌─────────────────────────────────┐
│ ① Spesialis Manajemen CS isi │
│ Formulir Resign │
│ · Template: Formulir Resign- │
│ Posisi Remote (Kontrak) │
│ · Template diminta dari │
│ Supervisor │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ ② Formulir Resign dikirim ke │
│ Supervisor untuk disetujui │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ ③ Notifikasi tim di grup kerja │
│ · Umumkan karyawan tersebut │
│ sudah resign │
│ · Ingatkan: tidak diperbolehkan│
│ membagikan info akun atau │
│ info sensitif lain │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ ④ Penanganan tiga akun backend │
│ (lihat 17.5.2) │
│ · Backend Cloud Desktop: │
│ ubah password │
│ · Backend Salesmartly: │
│ ubah password │
│ · Backend Platform: tidak │
│ ubah password (lihat alasan) │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ ⑤ Notifikasi karyawan aktif │
│ pemakai akun yang sama │
│ (sesuai jenis akun, channel │
│ Signal berbeda) │
└─────────────────────────────────┘
15.5.2 Penanganan Diferensiasi Tiga Akun Backend (Inti)¶
| Sistem Akun | Apakah Ubah Password | Channel Notifikasi Karyawan Aktif Akun Sama | Alasan |
|---|---|---|---|
| Backend Cloud Desktop | ✅ Wajib ubah | Signal Pribadi (HP/perangkat rumah) | Setelah ganti password, karyawan tersebut sementara tidak bisa login Cloud Desktop, Signal Kerja terpasang di dalam Cloud Desktop, sehingga tidak bisa diberitahu via Signal Kerja — wajib pakai Signal Pribadi karyawan |
| Backend Salesmartly | ✅ Wajib ubah | Signal Kerja (di dalam Cloud Desktop) | Signal Kerja dapat dipakai untuk login normal, channel biasa cukup untuk notifikasi |
| Backend Platform | ❌ Tidak ubah | — | Pengaman ganda: ① Dibatasi hanya bisa login melalui IP Cloud Desktop; ② Setiap akun punya Google Authenticator yang disimpan oleh Spesialis Manajemen CS. Karyawan resign yang punya password sendiri pun tidak bisa login |
⚠️ Poin Kunci: Signal Pribadi vs Signal Kerja - Signal Pribadi: Signal yang terpasang di HP/perangkat pribadi karyawan (untuk notifikasi terkait Cloud Desktop) - Signal Kerja: Signal yang terpasang di dalam Cloud Desktop (untuk komunikasi kerja sehari-hari, termasuk notifikasi Salesmartly) - Mengubah password Cloud Desktop akan menyebabkan Signal Kerja sementara tidak tersedia → harus pakai Signal Pribadi untuk notifikasi
15.5.3 Mengapa Backend Platform Tidak Ubah Password (Pengaman Ganda)¶
| Lapisan Pengaman | Mekanisme | Efek Pertahanan |
|---|---|---|
| Lapisan 1: Pembatasan IP | Backend Platform dibatasi hanya bisa login melalui IP Cloud Desktop | Karyawan resign yang login dari IP rumah/eksternal manapun akan ditolak |
| Lapisan 2: Google Authenticator | Setiap akun dikonfigurasi dengan Google Authenticator sebagai verifikasi dua langkah; kode disimpan oleh Spesialis Manajemen CS, tidak diberikan ke karyawan | Bahkan jika password bocor, tanpa kode tetap tidak bisa login |
Kesimpulan: Karyawan yang resign tidak ada cara untuk menerobos dua lapisan pengaman ini — sehingga Backend Platform tidak perlu ubah password, untuk menghindari pekerjaan notifikasi karyawan aktif akun sama yang tidak perlu.
15.5.4 Matriks Penanganan Akun Bersama¶
Setelah ubah password (Cloud Desktop / Salesmartly)
│
▼
┌─────────────────────────────────┐
│ Query: karyawan aktif lain mana │
│ yang masih memakai akun ini? │
│ · Akun Cloud Desktop biasanya │
│ dipakai banyak orang │
│ · Akun Salesmartly juga sering │
│ dipakai bersama │
└──────────┬──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ Pilih channel notifikasi sesuai │
│ jenis akun │
│ │
│ Password Cloud Desktop │
│ → kirim via Signal Pribadi │
│ Password Salesmartly │
│ → kirim via Signal Kerja │
└─────────────────────────────────┘
Selain Backend Cloud Desktop dan Backend Salesmartly yang perlu ubah password manual ke platform spesifik, seluruh alur resign dapat diintegrasikan ke Sistem HQ Backend Tengah (§5 houqin):
| Fitur | Deskripsi | Prioritas |
|---|---|---|
| Pengajuan resign satu klik | Karyawan submit pengajuan resign mandiri → notifikasi otomatis ke Spesialis Manajemen CS | P0 |
| Penerimaan satu klik | Spesialis terima dengan satu klik → otomatis generate Formulir Resign (template "Formulir Resign-Posisi Remote (Kontrak)" tertanam) | P0 |
| Notifikasi grup otomatis | Setelah diterima otomatis posting notifikasi resign di grup kerja | P0 |
| Generator password kuat otomatis | Sistem otomatis generate password kuat baru untuk Cloud Desktop/Salesmartly | P1 |
| Identifikasi akun bersama otomatis | Sistem otomatis identifikasi karyawan aktif pemakai akun sama, daftar pihak yang perlu diberitahu | P1 |
| Distribusi password multi-channel | Otomatis pilih channel Signal sesuai jenis akun (Pribadi/Kerja) | P1 |
📝 Action Item: Setelah disusun, kebutuhan di atas diserahkan ke tim pengembang Sistem HQ (proyek houqin).
📝 Sumber: Pembelajaran lapangan
Konten berikut berasal dari dokumen resmi "SOP Manajemen CS Remote".
| No | Item SOP | Standar/Persyaratan | Penjelasan Penting |
|---|---|---|---|
| 1 | Memahami alur dasar CS | Harus memahami semua alur dasar lini CS | Termasuk cara menerima chat, alur balasan, template chat dan model operasi dasar |
| 2 | Memiliki pemikiran logis dan objektif | Mampu mandiri dan objektif membangun serta mengoptimalkan logika template chat | Membantu meningkatkan kualitas layanan, efisiensi komunikasi, dan akurasi penilaian |
| 3 | Menguasai fungsi backend CS | Harus terampil menggunakan berbagai fungsi backend | Termasuk media sosial, FB Messenger, Bot Telegram, laporan, buat user baru, modifikasi alur otomatis dan investigasi, dll |
| 4 | Menyusun jadwal CS Remote | Mampu mandiri menyusun shift CS Remote | Penjadwalan harus rasional, jelas, dapat dieksekusi, dan memastikan kesinambungan layanan |
| 5 | Statistik jumlah lini CS | Mampu menghitung dan menguasai jumlah lini CS | Memudahkan manajemen sumber daya dan kontrol operasional |
| 6 | Membagikan gambar dan teks media sosial | Mampu membagikan konten yang sesuai sesuai kebutuhan | Seperti post terjadwal kode penukaran, dll |
| 7 | Memahami logika order deposit/withdrawal yang hilang | Memahami logika bisnis terkait dan cara penanganan | Memudahkan membantu menangani masalah anomali bisnis |
| 8 | Menguasai operasi cloud desktop | Harus terampil menggunakan cloud desktop | Termasuk login, monitoring, investigasi masalah, dan penggunaan harian |
| 9 | Menguasai template aplikasi administrasi | Memahami formulir resign, formulir clearance, dan template aplikasi | Memastikan alur administrasi sesuai standar |
| 10 | Menemukan dan membina karyawan terbaik | Mampu mengidentifikasi CS Remote terbaik dan promosikan menjadi Asisten Remote | Mendukung pembangunan jenjang tim |
| 11 | Monitoring Anomali Channel | Memantau notifikasi grup pihak ketiga, memahami risiko channel | Notifikasi tepat waktu kepada lini CS tentang risiko channel |
| 12 | Keterampilan Pencarian Member ID | Menguasai 4 metode pencarian, identifikasi risiko multi-akun | Mengidentifikasi risiko multi-akun dan melaporkan |
| 13 | Manajemen Remote Tester | Memahami seleksi tester, kategori test, agregasi hasil | Mengawasi absensi tester dan agregasi hasil |
📘 Sumber: SOP Manajemen CS Remote.docx
| No | Konten Pekerjaan Harian | Standar Eksekusi | Tujuan Kerja |
|---|---|---|---|
| 1 | Membagikan gambar dan teks media sosial | Sesuai rencana operasional, publish konten seperti post kode penukaran terjadwal, perhatikan pembedaan nama platform multi (lihat detail Bab VI) | Memastikan promosi operasional sinkron |
| 2 | Wawancara kandidat | Atur wawancara sesuai kekurangan tim, evaluasi kandidat sesuai standar (lihat detail Bab XV) | Mendukung penambahan personel dan pembangunan jenjang |
| 3 | Investigasi kualitas dan kuantitas lini CS | Cek jumlah CS online dan indikator kualitas layanan via backend Salesmartly, konfirmasi tenaga kerja setiap shift terisi | Memastikan lini CS stabil normal |
| 4 | Investigasi dan tangani masalah cloud desktop | Segera tangani anomali cloud desktop yang dilaporkan karyawan seperti login gagal, koneksi terputus (lihat detail Bab XI) | Menjamin kestabilan lingkungan kerja remote |
| 5 | Memperhatikan dan mendistribusikan kode verifikasi cloud desktop | Kode verifikasi (OTP) yang diterima karyawan saat login cloud desktop jika tidak dapat diambil sendiri, akan diterima oleh spesialis manajemen lalu diteruskan (lihat detail Bab XI) | Menghindari karyawan tidak dapat login karena masalah kode verifikasi |
| 6 | Menghitung dan mencatat jumlah quality check | Setiap hari hitung jumlah catatan quality check yang dikirim Asisten Remote, gabungkan ke data Salesmartly (lihat detail Bab VIII) | Sebagai dasar manajemen kualitas dan rangkuman bulanan |
| 7 | Tangani masalah order deposit/withdrawal | Tangani anomali yang dilaporkan CS Remote seperti deposit tidak masuk, withdrawal tertahan (lihat detail Bab II, Bab III) | Memastikan anomali order tertutup tepat waktu |
| 8 | Gunakan cloud desktop untuk monitor status karyawan | Lihat status online CS Remote real-time via management end cloud desktop, jika ada anomali offline segera hubungi (lihat detail Bab XI) | Mengawasi disiplin dan efisiensi kerja |
| 9 | Verifikasi Dokumen Serah Terima Kerja (STK) | Cek kelengkapan konten dokumen STK, konfirmasi semua CS yang bertugas sudah baca dan tanda tangan (lihat detail Bab XIII) | Mencegah info terlewat dan diskontinuitas kerja |
| 10 | Perhatikan keaktifan Asisten Remote | Terus amati kecepatan respons dan kualitas feedback masalah dari 5 Asisten Remote (lihat detail Bab VIII §8.3) | Memastikan posisi pendukung berperan dalam manajemen |
| 11 | Mengatur, memeriksa, menyusun jadwal kerja | Terus pertahankan tabel jadwal 100 orang, tangani permintaan tukar libur/ketidakhadiran/penggantian shift (lihat detail Bab VII) | Menjaga ketertiban shift |
| 12 | Memonitor notifikasi grup pembayaran/penerimaan pihak ketiga dan grup kerja | Terus perhatikan anomali channel grup pihak 3, notifikasi pemeliharaan bank, segera teruskan ke grup CS utama (lihat detail Bab IV) | Memastikan CS Remote memahami dinamika channel, mengurangi komplain member |
| 13 | Menangani permintaan pencarian Member ID | Berdasarkan akun dompet/bank yang dilaporkan CS Remote, cari di backend dan sampaikan Member ID yang sesuai, perhatikan peringatan multi-akun (lihat detail Bab V) | Membantu member cepat menemukan akun |
| 14 | Rangkum feedback asisten dan isi Tabel Gaji & Kinerja | Kumpulkan feedback quality check harian dan tambah/kurang poin dari 5 Asisten Remote, padukan dengan data Salesmartly, isi Tabel Gaji & Kinerja yang diberikan Supervisor (lihat detail Bab VIII §8.2) | Sebagai akumulasi data harian untuk penilaian gaji bulanan |
| 15 | Investigasi anomali akun & deteksi multi-akun | Berdasarkan feedback QC dan laporan member, lakukan audit IP dan investigasi akun terkait | Mencegah pencurian akun dan arbitrase |
| 16 | Manajemen harian remote tester | Mengawasi penyelesaian test domain, deposit, dan game oleh tester | Memastikan mekanisme peringatan dini risiko platform |
| 17 | Publikasi operasional media sosial | Publikasikan kode redeem, promosi, update di FB/Instagram/TikTok sesuai rencana | Memastikan sinkronisasi publisitas pemasaran |
📘 Sumber: SOP Manajemen CS Remote.docx
| No | Konten Pekerjaan Bulanan | Standar Eksekusi | Tujuan Kerja |
|---|---|---|---|
| 1 | Rangkuman tambah/kurang skor kinerja bulanan CS Remote | Rangkum catatan tambah/kurang skor 100 CS Remote sepanjang bulan, atur per grup lalu submit ke Supervisor (lihat detail Bab VIII) | Sebagai dasar perhitungan gaji bulanan |
| 2 | Rangkuman jumlah quality check bulanan | Rangkum data quality check Salesmartly sebulan penuh, analisis tren kualitas tiap grup (lihat detail Bab VIII) | Sebagai dasar analisis kualitas dan manajemen bulanan |
| 3 | Distribusi slip gaji | Tepat waktu rapikan data gaji bulan ini, distribusikan slip gaji ke setiap CS Remote via channel yang ditentukan | Memastikan alur gaji standar dan transparan |
| 4 | Penilaian kinerja bulanan Asisten Remote | Sesuai 5 dimensi di Bab VIII §8.3 nilai kinerja 5 Asisten Remote bulan ini, hasil submit ke Supervisor | Mendukung pembangunan jenjang dan manajemen insentif |
| 5 | Rangkuman administrasi bulanan | Rapikan perubahan personel bulan ini (masuk baru/resign/promosi jadi asisten), arsipkan catatan cuti, proses formulir aplikasi administrasi (lihat detail Bab XV) | Memastikan alur administrasi HR sesuai dan diarsipkan |
| 6 | Ringkasan administratif perubahan personil | Kompilasi file dan kontrak karyawan baru, pengunduran diri, dan promosi bulan ini | Memastikan kelengkapan arsip HR dan kepatuhan kontrak |
| 7 | Ringkasan bulanan remote tester | Agregasi beban kerja test, masalah risiko teridentifikasi, penilaian bulanan | Sebagai dasar perhitungan kinerja posisi tester |
📘 Sumber: SOP Manajemen CS Remote.docx
| No | Hal Penting | Penjelasan |
|---|---|---|
| 1 | Kemampuan Memahami Seluruh Alur | Posisi manajemen harus benar-benar memahami operasi CS, bukan hanya pengawasan permukaan |
| 2 | Kemampuan Backend dan Cloud Desktop | Ini adalah dasar kemampuan paling inti dalam manajemen CS Remote |
| 3 | Manajemen Jadwal dan Quality Check | Langsung menentukan kestabilan tim dan kualitas layanan |
| 4 | Tanggung Jawab Pembinaan Talenta | Manajemen perlu mengemban tanggung jawab menemukan, membina, mempromosikan karyawan terbaik |
| 5 | Standar Dokumen dan Administrasi | Semua formulir, serah terima, catatan, data gaji harus dikelola dengan ketat |
📘 Sumber: SOP Manajemen CS Remote.docx
Setelah cross-validasi dengan dokumen lain + analisis tabel nyata + riset tools, dari 10 topik yang awalnya perlu dipelajari, 9 sudah ter-cover, hanya tersisa 1 yang perlu lanjut konfirmasi ke Supervisor training.
| No | Topik | Dokumen yang Cover | Lokasi Referensi |
|---|---|---|---|
| ~~1~~ | ~~Path operasi spesifik dan antarmuka query backend order deposit~~ | 05-Panduan Pelatihan Pre-job CS Remote | §6.4 Deposit Tidak Masuk (termasuk path lengkap CRM → Financial Management → Deposit records → input ID → Query + tabel verifikasi bukti) |
| ~~2~~ | ~~Tools dan operasi masking Transaction ID~~ | Dokumen ini | §3.2 Tools dan Metode Masking Transaction ID (Snapaste masking vs screenshot selektif) |
| ~~3~~ | ~~Alur spesifik verifikasi grup pihak 3 (cara query merchant berbeda)~~ | 02-SOP Alur Kerja CS Remote + 03-Panduan Onboarding Wakil Supervisor | 02 §kondisi 2 "Menunggu Pembayaran" sesuai nama Merchant ke grup Telegram terkait untuk verifikasi (seperti grup cover pay); 03 §4.10 alur investigasi merchant 30 menit tidak ada callback withdrawal |
| ~~4~~ | ~~Operasi spesifik backend quality check Salesmartly dan view indikator~~ | 06-Panduan Penggunaan Backend Salesmartly | Cover ganda perspektif CS + perspektif admin (antarmuka, KPI, Pemeriksaan Acak quality check, export laporan) |
| ~~5~~ | ~~Format spesifik dan tools jadwal CS Remote~~ | Dokumen ini + 05 §8 | §7.2 Tools Jadwal Kerja dan Format Tabel (struktur nyata WFH SHIFT.xlsx) + §7.5 Sistem Manajemen HQ |
| ~~6~~ | ~~Format spesifik dan cara pengisian Tabel Gaji & Kinerja~~ | Dokumen ini | §8.3 Format Tabel Gaji & Kinerja (17 field+formula perhitungan / dari analisis nyata Inspector Chat-CR_质检.xlsx) |
| ~~7~~ | ~~Operasi cloud desktop (CR) + perspektif monitoring admin~~ | 05-Panduan Pelatihan Pre-job CS Remote + Dokumen ini | 05 §7 perspektif CS (CR/OTP/DAKA) + Dokumen ini §11.1.2 Pemeriksaan Acak Cloud Desktop |
| ~~8~~ | ~~Alur wawancara dan standar penilaian~~ | Dokumen ini | §15.2 Alur Wawancara Eksternal + §15.2.1 Checklist Pertanyaan Standar Wawancara |
| ~~10~~ | ~~Alur penanganan standar setelah deteksi multi-akun~~ | 05 + 03-Panduan Onboarding Wakil Supervisor + 04-Panduan Penilaian Perilaku Arbitrase Agen + 06-Panduan Kerja Supervisor Audit | 05 §6.8 alur investigasi IP saldo hilang; 03 §4.1 deteksi multi-akun review withdrawal; 04 standar penilaian arbitrase; 06 perspektif Supervisor Audit |
| No | Topik | Bagian yang Sudah Ter-cover | Yang Masih Perlu Ditambahkan |
|---|---|---|---|
| 9 | Mekanisme komunikasi dan pelaporan harian dengan Supervisor | 05 §1.1 Empat Grup Kerja (IDR-MD-Bahas Kerja / IDR-MD-Utama CS / Cek DP/WD / STK/WFH) | Frekuensi pelaporan spesifik, template konten pelaporan, jalur eskalasi antara Spesialis Manajemen CS ↔ Supervisor |
| No | Topik | Catatan |
|---|---|---|
| ~~7.2 tambahan~~ | ~~Rentang skor grade~~ | ✅ Sudah di-reverse-engineer dari data historis (Cukup Bagus≥72.5 / Cukup 62.5~72.5 / Semangat 12~44 / No KPI<0), lihat §8.2 |
| ~~7.3 tambahan~~ | ~~Formula estimasi jumlah chat~~ | ✅ Sudah di-reverse-engineer: Skor = Jumlah Chat × 0.004456 - 9.67 (R²=0.989) |
| ~~7.3 tambahan~~ | ~~Logika perhitungan skor negatif anomali~~ | ✅ Sudah dikonfirmasi: resign bulan berjalan/pelanggaran berat dipotong ~92 poin sekaligus |
| ~~Sistem HQ~~ | ~~Dokumen kebutuhan Sistem Manajemen HQ~~ | ✅ Sudah masuk pengembangan (codename proyek houqin, detail lihat 07-Panduan Kerja Supervisor) |
| 14 tambahan | Nama platform spesifik dan antarmuka management end sistem manajemen cloud desktop | Di §11 masih ditandai ❓ |
Prinsip Sinergi Antar-Dokumen: Hindari duplikasi konten — dokumen ini (perspektif Spesialis Manajemen CS) hanya menjelaskan keputusan manajemen dan standar penilaian, sedangkan langkah operasi spesifik diprioritaskan di 05-Panduan Pelatihan Pre-job CS Remote. Jika ditemukan dua dokumen menjelaskan operasi yang sama dengan tidak konsisten, ikuti 05 (paling dekat dengan operasi lini depan).
- 01-Library Template Chat CS — Template balasan standar CS (wajib baca pelatihan)
- 02-SOP Alur Kerja CS Remote — Pohon keputusan SOP detail operasi deposit/withdrawal/akun
- 03-Standar Manajemen CS Remote — Alur harian WFH CS Remote + 15 standar + FAQ
- 07-Panduan Kerja Supervisor — Ringkasan manajemen Supervisor untuk Spesialis Manajemen CS
- 03-Panduan Onboarding Wakil Supervisor — Referensi alur operasi Wakil Supervisor terkait deposit/withdrawal
- 04-Panduan Penilaian Perilaku Arbitrase Agen — Standar penilaian perilaku multi-akun/arbitrase
- 14-Keuangan dan Pembayaran — Penjelasan detail fungsi 6 sub-halaman manajemen keuangan (referensi perbedaan akses)
- 16-Tools Marketing — Penjelasan detail fungsi 3 sub-halaman tools marketing (referensi perbedaan akses)
- 13-Member dan Risk Control — 14 sub-halaman manajemen member (CS Remote dan posisi manajemen akses setara)
📘 Sumber: SOP Manajemen CS Remote.docx + Diskusi Pembelajaran + Manual Platform (14/16/13)