07 · Supervisor Work Guide

Applicable to: Operations Supervisor Source: Learning notes + New site setup preparation worksheet Compiled by: Bob ｜ Date: 2026-04-26 Status: Draft, continuously updated

---

Table of Contents

• 1. Role Positioning
• 1.1 Management Scope
• 1.2 Work Focus Comparison
• 2. Daily Management Work
• 2.1 Supervisor Work Positioning
• 2.2 Personnel Management
  • 2.2.1 Shift Personnel Configuration
  • 2.2.2 Coordination Mechanism with CS Management Specialist
• 2.3 Platform Issue Handling
• 2.4 Campaign Effect Monitoring
• 2.5 Scheduling & HR
• 2.6 Daily Operating Expense Management
• 2.7 Remote Testing Management
• 2.8 Group Operations Report
• 2.9 Payment Gateway Third-Party Group Dispatch Confirmation
• 2.10 CS Script Compilation & Training
• 2.11 UI Asset Copy
• 3. New Site Setup Workflow
• 3.1 Setup Work Overview
• 3.2 Domain Category (9 items)
  • 3.2.4 Domain Ban Handling Operation Manual
• 3.3 Configuration Category (11 items)
  • 3.3.1 JPush Registration & Pricing Adjustment Process
  • 3.3.2 Payment Channel Amount & Tier Configuration
• 3.4 Design Category (7 items)
• 3.5 Account Category (4 items)
• 3.6 Testing Category (4 items)
• 3.7 Setup Workflow Overview Diagram (with Parallel Relationships)
• 3.8 Setup Task Assignment Overview
• 4. Campaign Effect Monitoring & Adjustment
• 4.1 New Site Campaign Monitoring
• 4.2 Weekly Win-back Effect Testing
• 5. HQ Logistics Platform (houqin · Personal Attempt)
• 6. Pending Confirmation Checklist

---

1. Role Positioning

The Supervisor's work leans toward personnel management rather than specific execution operations. Daily work mainly involves resolving various issues that arise in platform operations — more often personnel and specific business issues rather than systematic platform issues (which are usually resolved during the initial site setup phase).

1.1 Management Scope

                    ┌──────────┐
                    │ Manager   │
                    └────┬─────┘
                         │
            ┌────────────┼────────────┐
            │                        │
      ┌─────▼─────┐           ┌─────▼──────┐
      │ Supervisor │           │   Audit    │
      │(Operations)│           │ Supervisor │
      │           │           │(Risk Ctrl) │
      └─────┬─────┘           └─────┬──────┘
            │                       │
     ┌──────┼──────┐                ▼
     │             │          Remote Audit Team
┌────▼────┐  ┌─────▼──────────┐
│ Deputy  │  │ CS Management  │
│Supervisor│  │  Specialist    │
│(On-duty)│  │(On-site, also  │
│         │  │ serves as CS)  │
└────┬────┘  └─────┬──────────┘
     │             │
     ▼             ▼
On-duty Team  Remote CS Team

The Supervisor and Audit Supervisor have a parallel relationship, each responsible for different directions (operations vs. risk control), not a hierarchical relationship. Both report to the Manager.

Issue escalation chain: Remote personnel issues → On-site supervisor handles first → Cannot resolve / requires decision → Submit to Supervisor / Audit Supervisor → Still unresolvable → Submit to Manager for review and decision

1.2 Work Focus Comparison

Dimension	Deputy Supervisor	Audit Supervisor	Supervisor
Work Nature	Execution operations	Risk control review	Personnel management + Issue resolution
Daily Focus	Push/Win-back/Withdrawal review	Arbitrage detection / QA	Team coordination / Difficult case handling / Effect monitoring / Operating expenses
Fixed Tasks	5 push campaigns / Deposit-withdrawal balance check	Agent review / Anomaly detection	New site setup (phased) + Campaign monitoring + Daily payments
Decision Authority	Execute by standard	Arbitrage determination	Process adjustment / Parameter modification / Personnel allocation / Fund disbursement

📝 Source: Learning discussion

---

2. Daily Management Work

The Supervisor's daily work is not as structured with a fixed cadence as the Deputy Supervisor's; it is more reactive and monitoring-oriented:

2.1 Supervisor Work Positioning

The Supervisor is mainly responsible for decision-making and review work. Specific execution work is accomplished through training subordinates:

What the Supervisor does	What subordinates do
Decision-making and review	Specific execution operations
Train Deputy Supervisor and other personnel	Execute by standard processes
Handle on-site personnel issues	Remote personnel issues are first handled by on-site supervisors
Handle escalated issues that cannot be resolved	Daily issues handled independently
Submit unresolvable issues to Manager	—

2.2 Personnel Management

Subordinate teams: - Deputy Supervisor — On-duty execution team - CS Management Specialist — On-site, also serves as CS, manages remote CS team - ⚠️ Audit Supervisor is NOT under Supervisor's management — They are parallel, each reports to the Manager

2.2.1 Shift Personnel Configuration

Each shift has 6 on-site personnel (1 person on leave does not significantly affect operations), divided into 3 functional groups:

Position	Headcount	Main Responsibilities	Work Guide
Deputy Supervisor	2	Push / Win-back / Withdrawal review / Deposit-withdrawal balance check / Payment gateway management and other on-duty execution work	03-Deputy Supervisor Onboarding Guide
Member Data Correction	2	Member login password reset, withdrawal password (PIN) reset, bank card change, account unlock, etc.	03-Deputy Supervisor Onboarding · §5 Password Reset
CS Management Specialist	2	① Deposit not credited investigation ② Withdrawal stuck order investigation ③ Daily management of remote CS team (scheduling/QA/monitoring/training)	04-CS Management Specialist Work Guide

  Each shift's 6-person configuration under Supervisor

</div>

</div>

</div>

</div>

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

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

</div>

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

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

</div>

</div>

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

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

</div>

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

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

  ┌──────────────────────────────────────────────────────┐
  │              Supervisor (Management Layer)            │
  │   Decision / Review / Training / Coordination /       │
  │            Operating Expenses                          │
  └───────────────┬────────────────────────────────────-─┘
                  │
     ┌────────────┼────────────────────┐
     │            │                    │
  ┌──▼──┐    ┌───▼────┐    ┌─────────▼──────────┐
  │Deputy│   │Member  │    │Deposit/Withdraw    │
  │Super.│   │Data    │    │Orders + Remote     │
  │ ×2   │   │Correct.│    │Management ×2       │
  │      │   │ ×2     │    │                    │
  └──┬──┘    └───┬────┘    └─────────┬──────────┘
     │           │                   │
     ▼           ▼                   ├─→ Deposit not credited
  Push/Win-back  Password reset     ├─→ Withdrawal stuck order
  Withdraw rev.  PIN reset          └─→ Remote CS management
  Dep-Wd check   Bank card change           (Schedule/QA/Monitor)
  Channel mgmt.  Account unlock                    │
                                                  ▼
                                       Remote CS Team (WFH)

Remote CS Team Structure (managed by CS Management Specialist):

• Remote Assistant ×10 (5 groups × 2 each): Each manages 10 remote CS agents, responsible for team QA, new hire training, issue feedback
• Remote CS Agent ×100 (5 groups × 20 each), 24-hour full coverage, divided into day/night shifts (Indonesia Jakarta time WIB):
• Version A (1 group of 20): Day 10:00-22:00 / Night 22:00-10:00
• Version B (4 groups of 80): Day 12:00-00:00 / Night 00:00-12:00
• Version B has more staff because 19:00-00:00 is the peak active period for users

See → 04-CS Management Specialist Work Guide

📝 Source: Learning discussion

2.2.2 Coordination Mechanism with CS Management Specialist

❓ The following is a placeholder framework, pending confirmation with the Supervisor for specific content

Coordination mechanism between CS Management Specialist (the role responsible for managing remote CS) and the Supervisor:

Dimension	Content	Status
Daily reporting	❓ Reporting frequency, content, channel pending confirmation	To be learned
Issue escalation	Remote CS issues → CS Management Specialist handles first → Cannot resolve → Submit to Supervisor	Confirmed
Schedule coordination	❓ Remote CS schedules made by CS Management Specialist; whether Supervisor approval is required pending confirmation	To be learned
QA results	❓ How QA data is summarized to Supervisor, how anomalies are handled pending confirmation	To be learned
HR management	❓ Supervisor's role in remote CS recruitment / interview / appraisal / promotion pending confirmation	To be learned
Training coordination	❓ Who is responsible for new remote CS training, what materials are used pending confirmation	To be learned

For detailed CS Management Specialist work guide, see → 04-CS Management Specialist Work Guide

Issue Handling Hierarchy: - Remote staff issues → CS Management Specialist (on-site) handles first - If on-site supervisor cannot resolve or requires Supervisor's decision → Submit to Supervisor - If Supervisor cannot resolve → Submit to Manager for review and decision

Training Responsibilities: - Train Deputy Supervisor to master standard on-duty execution processes - Train other personnel for specific execution work - Supervisor does not perform specific execution; trains subordinates to do it

2.3 Platform Issue Handling

• Various issues that arise in daily platform operations
• Note: Generally personnel and specific business issues; systematic issues are resolved during the initial site setup phase

2.4 Campaign Effect Monitoring

• Various campaigns set up at the beginning of the new site need continuous effect monitoring
• Test campaigns such as weekly win-back; based on effect data, decide whether parameters need adjustment
• See 4. Campaign Effect Monitoring & Adjustment

2.5 Scheduling & HR

• Schedule management: Responsible for scheduling and leave requests for on-site staff, UI staff, and remote report staff
• End-of-month salary compilation: At the end of each month, compile A+C group referral fees and overtime pay, submit to HR for review, then disbursed by Finance

📝 Source: Learning discussion

2.6 Daily Operating Expense Management

The Supervisor is responsible for daily operating expense payments, mainly via USDT through a multi-signature wallet. Each expenditure is reported in real-time to the Finance group.

Common expense types:

Expense Type	Description
Daily SMS fees	SMS win-back / callback channel fees
Departed employee salary	Salary settlement for departed employees
Employee work expense reimbursement	Reimbursement for daily work-related expenses
CS line subscription fees	Seat usage fees for Salesmartly and other CS platforms
Other operating expenses	Other daily operating-related expenses

Multi-signature wallet payment flow:

  Manager deposits a certain amount into multi-sig wallet
        │
        ▼
  ┌──────────────────────────────┐
  │ Supervisor initiates payout   │
  │ (Main signature weight        │
  │  on Supervisor)               │
  └──────────┬───────────────────┘
             │
             ▼
  ┌──────────────────────────────┐
  │ Authorized Deputy Supervisor  │
  │ co-signs (Dual-signature      │
  │ confirmation releases funds)  │
  └──────────┬───────────────────┘
             │
             ▼
  ┌──────────────────────────────┐
  │ When wallet balance drops to  │
  │ a certain level → Supervisor  │
  │ requests refill from Manager  │
  └──────────────────────────────┘

Security mechanism: The multi-sig wallet requires two signatures (Supervisor initiates + Deputy Supervisor confirms) for funds to be released. A single person cannot operate independently, preventing fund misappropriation.

📝 Source: Learning discussion

2.7 Remote Testing Management

Remote testing group monitoring and game/website testing are essentially the Supervisor arranging remote test personnel to perform tests as required, under unified management.

2.7.1 Testing Purpose & Principle

Why test: The platform serves real users in the Indonesian market. Any functional anomaly (payment failure, games not opening, page inaccessible) directly leads to user churn and financial loss. Remote testing simulates real user operations to discover and fix issues before they affect users.

Core testing purposes:

Purpose	Description
Ensure user experience	Ensure the entire website / game / payment chain works normally; users can deposit, play, and withdraw without obstacles
Verify payment channel availability	Payment gateway channels change frequently; periodic testing is required to confirm deposit and withdrawal channels are unobstructed
Verify game vendor interface	Game vendor APIs may fail or change; timely discovery avoids user complaints
New site launch acceptance	After new site setup, complete testing must pass before official launch (see §3.6 Testing Category)
Domain availability monitoring	Decoy domains / PWA domains / business domains may be banned at any time; continuous verification of access is required

2.7.2 Testing Types & Content

Test Type	Test Content	Trigger Timing	Notes
Payment channel test	Deposit (collection) + Withdrawal (payout) full flow	New channel launch, channel switch, daily inspection	Order callback support required, see Deputy Supervisor §4.4 Order Callback Handling
Game vendor test	Whether specified vendor's games can open, bet, settle normally	New game launch, vendor interface change, user complaint	❓ Specific test frequency and criteria pending confirmation with Supervisor
Website access test	Whether all domain types (business / PWA / decoy / APK) open normally	Daily inspection, after domain change, after ban recovery	See §3.2.1 Domain System Details
Campaign content check	Whether campaign rules, images, links, claim flow are correct	New campaign launch, after parameter adjustment	—
Simulated callback data	Use third-party channel bot /testpay <order_no> to simulate deposit callback	During payment channel testing	❓ More scenarios pending confirmation

2.7.3 Supervisor's Management Responsibilities

The Supervisor does not personally perform specific test operations, but is responsible for:

  Supervisor assigns test tasks
        │
        ▼
  Remote test personnel execute as required
  (Deposit / Withdrawal / Game / Website access, etc.)
        │
        ▼
  Test results reported back to remote test group
        │
        ▼
  ┌─────────────────────────────┐
  │ Supervisor monitors test    │
  │ group:                      │
  │ · Review test results       │
  │ · Identify anomalies        │
  │   Common: Payment channel   │
  │           down              │
  │           Site/game down    │
  │           Campaign error    │
  └──────────┬──────────────────┘
             │ Issue found
             ▼
  ┌─────────────────────────────┐
  │ Coordinate relevant         │
  │ personnel to handle:        │
  │ · Payment issue → Contact   │
  │   third-party merchant      │
  │ · Domain banned → Backend   │
  │   change domain             │
  │ · Game anomaly → Contact    │
  │   game vendor               │
  │ · Config error → Arrange    │
  │   correction                │
  └─────────────────────────────┘

2.7.4 Issue Investigation Approach

When a test anomaly is found, investigate as follows:

Anomaly	Investigation Direction	Reference
Deposit failure	① Is the channel enabled ② Is channel balance sufficient ③ Do amount/level configurations match ④ Is the third-party merchant abnormal	Payment Gateway Channel Management
Withdrawal failure	① Is the payout channel normal ② Has it timed out without callback ③ Has merchant rejected	Withdrawal Payout
Website not opening	① Is the domain banned ② Is DNS resolution working ③ Is CF proxy normal ④ Is line acceleration configured	Domain Type Functions
Game not opening	① Is the game vendor interface normal ② Is the game switch enabled ③ Are there device/browser compatibility issues	❓ Game management documentation to be added
Campaign anomaly	① Are campaign settings correct ② Are time/condition parameters set right ③ Are images/links uploaded successfully	—

📝 Source: Document compilation (based on learning discussion + Deputy Supervisor onboarding guide + new site setup testing category); follow-up confirmation with Supervisor and refinement needed.

2.8 Group Operations Report

Not limited to "before end of shift" — fill in the report as soon as the data is in hand. Whenever processing fee data, customer-loss win-back numbers, etc. become available, fill them in.

2.8.1 Report Filing Responsibilities

Data items the Supervisor must fill / confirm (❓ specific report format and complete fields pending confirmation):

Data Item	Source	Focus
Processing fee	Payment gateway third-party merchant settlement	Whether the amount is reasonable; abnormally high/low compared with historical average
Customer-loss win-back count	Daily batch task report from Deputy Supervisor	Win-back effect trend, whether strategy adjustment is needed
Deposit-withdrawal balance data	Daily report from each platform backend	Whether the ratio is within normal range (see Deputy Supervisor §3.5 Deposit-Withdrawal Balance Inspection)
Other operating metrics	❓ Pending confirmation	❓ Specific metrics and judgments pending confirmation with Supervisor

2.8.2 Report Review Responsibilities

The Supervisor not only fills in data personally but also needs to review the data quality of report fillers:

  Report fillers submit data
        │
        ▼
  ┌─────────────────────────────────┐
  │ Supervisor review checklist     │
  │                                 │
  │ ① Is data filled correctly      │
  │    · Any missing/wrong entries  │
  │    · Is numerical format correct│
  │                                 │
  │ ② Anomaly detection             │
  │    · Is dep-wd ratio deviating  │
  │      from historical average    │
  │    · Are processing fees        │
  │      suddenly higher/lower      │
  │    · Are deposit/withdraw       │
  │      volumes fluctuating abn.   │
  │                                 │
  │ ③ Are formulas/calculations     │
  │   accidentally modified         │
  │    · Are Google Sheet formulas  │
  │      intact                     │
  │    · Do summary data and detail │
  │      records match              │
  └──────────┬──────────────────────┘
             │ Anomaly found
             ▼
  ┌─────────────────────────────────┐
  │ Investigation flow              │
  │ · Dep-wd anomaly → Check        │
  │   specific platform data        │
  │   for large withdraw/abnormal   │
  │   deposit                       │
  │ · Fee anomaly → Check channel   │
  │   rate change or transaction    │
  │   count anomaly                 │
  │ · Data mismatch → Investigate   │
  │   missing or duplicate entries  │
  └─────────────────────────────────┘

2.8.3 Issues with the Current Reporting System

Currently all operations reports are manually filled by report personnel via Google Sheet, which has the following issues:

#	Issue	Risk
1	Lack of data isolation	Report fillers can see all data in the entire sheet; lacks permission isolation
2	Mis-operation risk	Report fillers may accidentally modify formulas or others' data, affecting final summary calculation
3	Lack of visualization	Data is all raw numbers without chart trends; new Supervisors face high learning cost analyzing data
4	Difficult anomaly investigation	With large data volume, manual row-by-row inspection is inefficient; hard to quickly identify anomalies

2.8.4 Data Dashboard System (In Development)

To address the above issues, a set of operations data dashboard system is currently being designed and developed, divided into two ends:

① Data Entry End (for report fillers): - Dedicated entry interface; fillers only see fields they need to fill - Data isolation: fillers cannot see complete data analysis results - Automatic anomaly detection: real-time alerts during entry (e.g., amount obviously deviating from normal range) - Reduce mis-operations: form-based entry, no contact with underlying formulas

② Management Dashboard End (for Supervisor / management): - Compatible with original Google Sheet pure data format (smooth transition) - Visualized data display: charted operations metrics with trend comparison support - Custom filtering: flexible filtering and visualization by platform / time period / metric type - AI analysis (later integration): brief analysis of base data trends and anomaly alerts

Prerequisite for system completion: Need to obtain all currently used Google Sheet reports, understand which data daily fillers fill in and how formulas are designed, in order to truly refine the system design.

❓ Pending confirmation: Complete report field list, formula design, data definition for each platform

📝 Source: Document compilation + learning discussion; further confirmation and supplementation needed after obtaining actual report templates

2.9 Payment Gateway Third-Party Group Dispatch Confirmation

• Perform dispatch confirmation in the payment gateway third-party group ❓ Specific content and process pending confirmation

📝 Source: Learning discussion

2.10 CS Script Compilation & Training

The Supervisor is responsible for compiling unified scripts for CS hotline replies, ensuring all CS (on-site + remote) use unified standard responses when facing users.

Script system documents (compiled and archived to 10-Customer Service Center directory):

Document	Content	Audience
01-CS Script Library	30+ categories, 200+ standard reply scripts (Indonesian), with shortcut codes	All CS
02-Remote CS Workflow SOP	16 work disciplines + complete decision trees for deposit/withdrawal/account operations	Remote CS
03-Remote CS Management Standards	Remote CS 10-step workflow + WFH standards + FAQ	Remote CS

Supervisor's management responsibilities: - Script update: Timely update script library based on business changes (new campaign launches, rule adjustments, new platforms) - Training: Arrange new CS to study the above three documents upon onboarding; on duty after passing assessment - QA: Spot-check CS reply quality; correct and retrain those not meeting standards - KPI link: Reply quality (script compliance, response speed, resolution rate) included in CS KPI assessment

📝 Source: Learning discussion + Script library.xlsx

2.11 UI Asset Copy

• The UI display image Excel has different size requirements for various layouts
• Campaign promotion copy is written by the Supervisor personally (not copied from a template)
• All large and small icons in the backend operations configuration are the Supervisor's responsibility
• For size specifications, see 12-UI Display Image Index

📝 Source: Learning discussion

---

3. New Site Setup Workflow

This is the Supervisor's most important phased fixed work. After setup is complete, it is not repeated, but must be fully executed for each new site.

3.1 Setup Work Overview

New site setup totals 37 items, divided into 5 categories:

Category	Number of Items	Description
Domain	9	Domain purchase, binding, resolution, acceleration
Configuration	11	Push / Payment / Game / CS / Campaign / Firebase backend configuration
Design	7	ICON / LOGO / Banner / Campaign image / CS image / Download page visual assets
Account	4	CS / Audit / Self-media account creation and configuration
Testing	4	Comprehensive testing of games / deposit-withdrawal / URLs / campaign content

3.2 Domain Category (9 items)

#	Setup Item	Konten Pembangunan	Owner	Description
1	Purchase main domain, determine template, open backend	Beli domain utama, tentukan template, buka backend	Martin	Decided by management (Manager / Boss); Supervisor coordinates execution
2	Notify SEO for ranking	Beri tahu SEO untuk optimasi peringkat	Martin	Notify SEO team as early as possible after domain confirmation
3	Contact technicians to purchase supporting domains	Hubungi teknisi untuk membeli domain pendukung	Martin	Supporting domains for auxiliary functions
4	Contact technicians to purchase decoy domains	Hubungi teknisi untuk membeli domain "umpan" (decoy)	Martin	Decoy domains for anti-block
5	Bind supporting domains	Pengikatan domain pendukung	HB
6	Bind PWA domain	Pengikatan domain PWA	HB	PWA installation requires independent domain
7	Bind decoy domain	Pengikatan domain "umpan" (decoy)	HB
8	Decoy domain DNS resolution	Pengaturan DNS domain "umpan" (decoy)	HB	DNS resolution settings
9	Anti-block domain + APK domain line acceleration	Domain anti-blokir + percepatan jalur domain APK	HB	Line acceleration ensures APK download speed

📘 Source: New Site Setup Preparation Worksheet

3.2.1 Domain System Details

The following helps the Supervisor deeply understand the design logic of the domain system, making it easier to explain "why we do it this way" to Deputy Supervisor and other executors.

The backend has three major domain management modules:

Module	Backend Path	Essential Role	Audience
Website Domain	Domain Management → Website Domain	Real business landing page	All end users
PWA Anti-block Domain	Domain Management → PWA Anti-block Domain	Stand-in entry for desktop App	PWA installation users
Redirect Domain (Decoy Domain)	Domain Management → Redirect Domain	One-time bullet-blocking springboard	New users from ad/SMS reach

📘 Source: 09-Domain Type Functions

Five type tags for website domains — not just classification; each plays a different role in business:

Type	Role in One Sentence	Why Independent
Normal	Universal fallback entry (homepage / navigation / redirect transit)	General scenarios that don't need special system behavior
Agent Sharing	Exclusive link for agent-driven viral spread	System auto-tags promotion source; agent backend directly references; doesn't pollute attribution with official promotion
Promotion Link	Official active reach (SMS / push / ads)	Distinguishes "company-paid acquisition" vs "agent-organic spread"; convenient for separate ROI accounting
APK Domain	Internal line channel for App (3 per site for redundancy)	Exposure = attack = full-site APP failure; requires technical secondary processing; strictly forbidden to expose externally
Detection Domain	Ops health probe (/api/check)	Diagnose server status without opening main site; doesn't interfere with business traffic

📘 Source: 09-Domain Type Functions

Detailed comparison of three modules:

Dimension	Website Domain	PWA Anti-block Domain	Redirect Domain (Decoy)
Ban impact	Catastrophic — Full site inaccessible	Medium — Switch domain to recover, no reinstall needed	Low — Switch to another decoy and continue
Domain cost	High value, long-term holding	Medium, replaceable	Cheap, short-term, consumable
Technical mechanism	NS activation + CF defense	NS activation + linked website domain	NS activation + subdomain resolution + 302 redirect
Parameter passthrough	Not involved	Not involved	Supported (utm / click_id and other attribution parameters)

3.2.2 Complete User Access Path

Understand how different users reach the platform via different domains.

┌───────────── New User Acquisition Path ─────────────┐
│                                                      │
│  Ads / SMS / Social media promotion                  │
│       │                                              │
│       ▼                                              │
│  Decoy domain dd.xyz.cc   ← Frontline, takes ban risk│
│       │  302 redirect (parameter passthrough         │
│       │  ?utm_source=xx)                             │
│       ▼                                              │
│  Business domain bc666a.top                          │
│       │   ← Type=Promotion Link / Normal             │
│       ▼                                              │
│  User register / deposit / install PWA               │
│                                                      │
├───────────── Returning User Path ───────────────────┤
│                                                      │
│  Mobile desktop PWA icon                             │
│       │                                              │
│       ▼                                              │
│  PWA anti-block domain pwa.abc.com                   │
│       │   ← Independent domain layer; banned can     │
│       │     hot-swap                                  │
│       ▼                                              │
│  Business domain bc666a.top                          │
│       │   ← User unaware of switch                   │
│                                                      │
├───────────── Agent Sharing Path ─────────────────────┤
│                                                      │
│  Agent backend → Copy agent share domain link        │
│       │                                              │
│       ▼                                              │
│  agent-share.top (Type=Agent Sharing)                │
│       │   → Auto carries agent invitation code       │
│       ▼                                              │
│  User registers; attributed to that agent            │
│                                                      │
├───────────── APK User Path ──────────────────────────┤
│                                                      │
│  Android APP internal code                           │
│       │                                              │
│       ▼                                              │
│  APK domain ×3 (hardcoded)                           │
│       │   ← Strictly forbidden to expose; 3 for      │
│       │     redundancy                               │
│       ▼                                              │
│  APP loads business data normally                    │
└──────────────────────────────────────────────────────┘

3.2.3 Three-Layer Onion Anti-Block Architecture

Design philosophy: Three-layer onion structure — decoy at outermost layer takes the hits, PWA in the middle as elastic entry, business domain at the core never directly exposed. Each layer banned only requires replacing that layer, not affecting inner layers.

           ┌─── Outermost: Decoy domain ──┐
           │ Bullet-blocking consumable;   │
           │ replace when banned           │
           │  ┌─── Middle: PWA ──────────┐ │
           │  │ Elastic entry, hot-swap  │ │
           │  │  ┌── Core ──────────┐    │ │
           │  │  │ Business domain  │    │ │
           │  │  │ Never exposed    │    │ │
           │  │  └──────────────────┘    │ │
           │  └──────────────────────────┘ │
           └───────────────────────────────┘

Ban risk ranking: Decoy (highest) > PWA (medium) > Business domain (lowest)

Emergency response after ban:

Banned Layer	Impact	Response Time	Operation
Decoy banned	New user promotion link invalid	5 minutes	Backend switch new decoy + sync resolution
PWA banned	Old user PWA opens to white screen	10 minutes	Backend switch new PWA domain + link to original business domain; users auto-recover
Business domain banned	Full site inaccessible	Catastrophic	Full site migration (rarely happens because never directly exposed)
APK domain banned	APP failure	Requires repackage and release	That's why exposure is strictly forbidden

Scenario stories to aid understanding:

Scenario 1: Decoy banned — SMS campaign uses dd.xyz.cc, one day banned by carrier. Backend switches to a new decoy ee.abc.cc pointing to the same business domain; updates link template in the group; resumes campaign in 5 minutes. Real domain zero impact, old users completely unaware.

Scenario 2: PWA banned — Old user's desktop PWA icon opens to white screen. Backend swaps PWA anti-block domain with a new one, still linked to the same business domain. Next time user opens PWA, auto-redirects to new line, no need to uninstall and reinstall — shell broken, swap shell; core unchanged.

3.2.4 Domain Ban Handling Operation Manual

📘 Source: Website Official Domain Ban Handling Process v2.docx (updated 2026-05-02)

The following are specific operation steps for the three types of domain ban scenarios.

A. Website Official Domain Ban Handling

Scenario: Website main domain banned (e.g., 7777w77.com banned)

Operation steps:

Discover official domain banned
      │
      ▼
Backend → "Website Domain" → Find banned domain (e.g., 7777w77.com)
      │
      ▼
① Turn off "Domain Ban Detection" switch
   Reason: Already confirmed banned;
   no need for system to keep alerting
      │
      ▼
② Synchronously check whether "Domain Acceleration" is enabled
   → If enabled, must turn off synchronously
   Reason: Domain acceleration only has 15 quotas;
           banned domain occupying a quota is wasteful;
           keep quota for domains that need it
      │
      ▼
③ Mark block date in remarks column
   Format: "SEO dedicated, blocked 3.10"
      │
      ▼
④ ⚠️ Check the domain type!
   If a "Agent Domain" is banned
   → Must **immediately** change type to "Normal"
      │
      ▼
⑤ Status **does NOT need to be turned off**
   Reason: Customers who can still open it should be allowed to;
           turning off status would also block users still able to access
      │
      ▼
⑥ If a new domain needs to be added
   → Contact domain admin @tom via Signal to add

⚠️ Three key principles: 1. Turn off domain acceleration — 15 quotas are precious; banned domain must release them 2. Banned agent domain must immediately change type to Normal — otherwise may affect agent system 3. Do NOT turn off status — customers who can still open it should keep using it; avoid harming users still able to access

---

B. PWA Domain Ban Handling

Scenario: PWA anti-block domain banned (e.g., 7777w.gum719.com blocked by Telkom)

Operation steps:

Discover PWA domain banned
      │
      ▼
  ① Backend → "PWA Anti-block Domain" → Find banned domain
     → Turn off "Domain Ban Detection"
     → Note block info, e.g., "H5 conversion (1220 blocked by Telkom)"
      │
      ▼
  ② Contact @tom via Signal:
     · Purchase new random-string domain (e.g., werewurh.com)
     · Or pick one from already-purchased PWA backup domains
      │
      ▼
  ③ After getting new domain, add platform prefix
     E.g.: 7777w.werewurh.com
      │
      ▼
  ④ Backend operations:
     · First bind new domain (domain binding flow)
     · Add PWA domain → Fill in new domain
     · Select "Anti-block Target" domain
     · Confirm and wait for NS1, NS2 to display
      │
      ▼
  ⑤ Once NS displays → Contact @tom via Signal for resolution
      │
      ▼
  ⑥ After resolution active:
     · Turn on "Domain Ban Detection"
     · Add new PWA domain to "JPush"
      │
      ▼
  ⑦ Replace originally bound decoy domain (see B.1 sub-flow)
      │
      ▼
  ⑧ Enable "Rescue Popup" on banned PWA domain (see B.2 sub-flow)

B.1 Decoy Domain Re-binding Sub-flow

Backend → "Campaign Redirect Domain"
      │
      ▼
  Select decoy domain bound to banned PWA domain (may be multiple)
      │
      ▼
  Click "Resolve" button
      │
      ▼
  Delete two original records
      │
      ▼
  Add new domain record:
  · Subdomain: enter `@`
  · Redirect link: `https://` + new PWA domain
  (E.g.: https://7777w.werewurh.com)
      │
      ▼
  Click "Sync"
      │
      ▼
  ✅ Done: PWA customers downloaded under old domain
     **seamlessly switch** to new domain

B.2 Rescue Popup Setup Sub-flow (for old customers)

⚠️ Core problem: Old customers used PWA to add a desktop bookmark; once the original PWA domain is banned, the desktop bookmark shows white screen, cannot play. After backend completes domain switch, new customers naturally land on the new domain, but old customers need a rescue popup reminder to update.

Backend → Find the **banned old PWA domain** configuration item
      │
      ▼
  Enable "Rescue Popup" switch
      │
      ▼
  Set popup as "Forced Popup"
      │
      ▼
  In the popup target input field
  Enter the **newly bound PWA domain**
  (E.g.: 7777w.werewurh.com)
      │
      ▼
  Copy the standard rescue copy from B.2.1 below and paste
      │
      ▼
  Save configuration
      │
      ▼
  ✅ When old customers open old PWA desktop bookmark
     → Rescue popup appears
     → Click "Update"
     → Auto-redirect to new PWA domain
     → Re-add desktop bookmark and continue playing

B.2.1 Rescue Copy Template

Standard rescue copy (copy and paste directly, no modification needed):

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

English translation for reference (informational only — always use the Indonesian version in production):

Download the latest app! Click the download button, then press the button in the top-right to open the main download page in Google Chrome, and download the latest app!

📌 Usage notes: All platforms use this same copy — no need to replace platform name or domain. The copy's purpose is to guide returning customers to open the main download page in Chrome and re-download or re-add a fresh desktop bookmark

✅ Customer groups not affected: Customers who downloaded the native APK or repackaged app via the PWA domain do not depend on the PWA desktop bookmark, so the rescue popup does not apply to them — but they also don't need rescue, because the APK is already on their device.

B.3 PWA Domain Ban Operation Quick Reference

Step	Operation	Location
Turn off detection + remark	Turn off domain ban detection, mark date and reason	Backend → PWA Anti-block Domain
Get new domain	Signal @tom to buy random-string domain or pick from backup	Signal
Prefix bind	Add platform prefix to new domain, then bind in backend	Backend → PWA Anti-block Domain
Wait for NS + resolution	Wait for NS1/NS2 to show, then contact @tom for resolution	Signal
Post-activation config	Turn on ban detection + add to JPush	Backend
Update decoy pointing	Campaign redirect domain → Resolve → Delete old → Add new (@ + https://newPWA) → Sync	Backend → Campaign Redirect Domain
Rescue popup	Enable rescue popup on old PWA domain, pointing to new PWA domain	Backend → Old PWA domain config

---

C. Decoy Domain Ban Handling

Scenario: Decoy domain used for campaign redirect is banned

Operation steps:

Discover decoy domain banned
      │
      ▼
  ① Contact @tom via Signal
     Ask whether 301 redirect is feasible
     (using an unbanned domain to redirect)
      │
      ▼
  ② Notify the **Marketing/Distribution Department**:
     This domain has been banned;
     promotion link needs replacement
      │
      ▼
  ③ ⚠️ **Do NOT delete the banned decoy domain in the backend**
     (keep record for traceability)
      │
      ▼
  ④ Provide a **new decoy domain**
     Continue binding to the original PWA domain
      │
      ▼
  ⑤ Provide the new decoy domain to Marketing
     to continue promotion

📝 Status note: Decoy domain ban has not yet occurred; the above is a preset handling approach (derived from platform technical capabilities).

⚠️ Important record-keeping discipline: All domain usage paths must be clearly registered in the table, for easy lookup later when forgetting (which decoy is bound to which PWA, which PWA is linked to which business domains, etc.).

---

D. General Domain Management Notes

This section covers global management discipline above the three ban handling scenarios, to avoid waste and data confusion from passive responses.

#	Note	Description
1	Sync banned domains to @tom	Notify tom immediately; register to unified ban record table
2	Cache time vs domain renewal	PWA domain cache cycle is approximately 300 days. If a domain is purchased for 1 year but banned on day 300, with 65 days remaining but cache still active for 300 days → in this case, even a banned domain must be renewed for one year, otherwise old users will be impacted again when the domain expires within the cache period
3	Decoy domain buy 1 year	Decoy domains generally don't last 2 years; cannot be reused (banned domains have high reuse risk); don't renew at expiry, buy new ones is more economical
4	Internal site domains buy 2 years	The following types must be bought for 2 years: APK domain, PWA domain, agent domain, frontend domain, navigation site entry domain, anti-block target domain (these domains cannot be frequently changed; require long-term stability)

Domain Renewal Decision Table

Domain Type	Default Purchase Period	Renewal Strategy After Ban	Reason
APK domain	2 years	Renew 2 years	Hardcoded in APP code; switching requires repackaging and release
PWA domain	2 years	Renew 1 year (depends on cache cycle)	After ban, old customers migrate via rescue popup; new customers go to new domain
Agent domain	2 years	Renew 1 year	After ban, change type to "Normal" and continue using
Frontend domain	2 years	Renew 1 year	Core business domain; important
Navigation entry	2 years	Renew 1 year	User guidance chain; long-term stable
Anti-block target domain	2 years	Renew 1 year	Target domain for PWA anti-block
Decoy domain	1 year	Do NOT renew	One-time consumable; discard upon ban

---

Domain Ban Handling Quick Reference

Domain Type	First Step	Get Replacement	Backend Config	Special Step	Follow-up
Website Official Domain	Turn off ban detection + Turn off domain acceleration + remark date	Contact @tom via Signal to add new domain	Change agent type to Normal	Status no need to turn off	—
PWA Anti-block Domain	Turn off ban detection + remark date	Contact @tom via Signal to buy random-string domain or use backup	Prefix bind → Wait for NS → Resolve → JPush	Update decoy pointing + Rescue popup	Turn on ban detection
Decoy Domain	Contact @tom via Signal to check 301 feasibility	Provide new decoy domain	Do NOT delete banned domain	Notify Marketing to change link	Register in table

Scenario 3: Parameter passthrough attribution — Ad campaign dd.xyz.cc?utm_source=fb&click_id=123; after 302 redirect becomes bc666a.top?utm_source=fb&click_id=123; attribution chain unbroken. While decoy takes the hit, ROI data is fully relayed.

📝 Source: Website Official Domain Ban Handling Process v2.docx + learning discussion 📘 Source: 09-Domain Type Functions 📘 Source: 10-Campaign Redirect Decoy Domain

3.2.5 DNS Domain Resolution Principle

The Supervisor needs to understand basic DNS principles to investigate issues like domains not working or resolution not taking effect.

The essence of domain resolution: Translates a human-readable domain (www.example.com) into a machine-readable IP address (93.184.216.34).

Resolution process:

User enters www.example.com in browser
        │
        ▼
[1] Check local DNS cache
        │ No cache
        ▼
[2] Query local DNS server (provided by ISP)
        │ No record
        ▼
[3] Query root DNS server (13 groups globally)
        │ Returns: TLD DNS address for .com
        ▼
[4] Query .com TLD DNS server
        │ Returns: NS records for example.com
        │ (i.e., "who manages this domain's resolution")
        ▼
[5] Query authoritative DNS server (specified by NS record)
        │ Returns: A record → 93.184.216.34
        ▼
[6] Browser obtains IP → Establishes connection → Loads page

Comparison of three core DNS records:

Record Type	Purpose	Analogy	Example
A record	Domain → IP address	Terminal	example.com → 93.184.216.34
CNAME	Domain → Another domain	Transit	www.example.com → example.com
NS record	Specifies who manages resolution	Dispatch center	example.com NS → ns1.cloudflare.com

Simple memo: A record is the terminal (gives IP), CNAME is transit (points to another domain), NS decides who dispatches.

3.2.6 Cloudflare Hosting (NS Modification)

Why host domain on Cloudflare (CF): - Free SSL certificate (HTTPS) - DDoS protection - CDN acceleration (300+ nodes globally) - Hide origin server real IP

Operation steps:

  Complete process to host domain on Cloudflare
        │
        ▼
  ┌────────────────────────────────┐
  │ (1) Register Cloudflare account│
  │     and log in                 │
  │     https://www.cloudflare.com │
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (2) Click Add a Site           │
  │     Enter your domain → Select │
  │     Free plan                  │
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (3) CF auto-scans existing DNS │
  │     records                    │
  │     Manually verify completeness│
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (4) CF provides two NS         │
  │     addresses:                 │
  │     ns1.cloudflare.com         │
  │     ns2.cloudflare.com         │
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (5) Log in to domain registrar │
  │     backend                    │
  │     Find Name Servers settings │
  │     Delete original NS → Enter │
  │     CF's NS                    │
  └──────────┬─────────────────────┘
             │
             ▼
  ┌────────────────────────────────┐
  │ (6) Back to CF, click Check    │
  │     Nameservers                │
  │     Wait for activation        │
  │     (minutes ~ 24 hours)       │
  │     Green check = hosting OK   │
  └────────────────────────────────┘

The platform backend domain binding follows a similar process: after adding a domain, the system generates NS1/NS2 → go to domain registrar backend to change NS → activates in 3-5 minutes.

📘 Source: 09-Domain Type Functions

3.2.7 CDN Acceleration Principle

Problem: Users in Indonesia, server in another country; direct connection has high latency. Solution: CDN (Content Delivery Network) deploys cache nodes globally; users access the nearest node.

Traditional access (no CDN):
  User (Indonesia) ─── Cross-border network ───→ Origin (other country)
                                                            High latency ❌

</div>

</div>

</div>

</div>

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

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

</div>

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

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

</div>

</div>

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

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

</div>

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

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

CDN acceleration (with CF):
  User (Indonesia) ──→ CF Jakarta node ──→ Origin (other country)
                            │
                  Cache hit returns directly ✅
                  No need to reach origin every time

CF Proxy mode (Orange cloud vs Gray cloud):

	🟠 Orange Cloud (Proxied)	⚪ Gray Cloud (DNS-only)
Traffic through CF	Yes	No (direct to origin)
Hide origin IP	✅ Yes	❌ No (IP exposed)
CDN cache acceleration	✅ Yes	❌ No
DDoS protection	✅ Yes	❌ No
Use case	Web traffic (recommended)	Email/FTP and other non-HTTP

Recommendation: All user-facing domains should enable Orange Cloud (Proxied) to gain acceleration + protection + IP hiding triple benefits.

3.2.8 Decoy Domain Operation Details

Backend path: Domain Management → Redirect Domain

Operation flow:

  Add decoy domain
        │
        ▼
  ┌──────────────────────────┐
  │ (1) Add redirect main    │
  │     domain               │
  │     Enter decoy domain   │
  └──────────┬───────────────┘
             │
             ▼
  ┌──────────────────────────┐
  │ (2) Activate NS          │
  │     Go to registrar to   │
  │     change NS pointing   │
  │     to backend           │
  └──────────┬───────────────┘
             │
             ▼
  ┌──────────────────────────┐
  │ (3) Click "Resolve"      │
  │     (green button)       │
  │     Configure subdomain  │
  │     mapping:             │
  │     subdomain → target URL│
  │     (supports parameter  │
  │      passthrough)        │
  └──────────┬───────────────┘
             │
             ▼
  ┌──────────────────────────┐
  │ (4) Click "Sync"         │
  │     (orange button)      │
  │     Push config to CDN   │
  │     nodes                │
  └──────────────────────────┘

Parameter passthrough example: dd.decoy.cc?utm=abc → 302 redirect to → realdomain.com?utm=abc Promotion tracking parameters are not lost.

📘 Source: 10-Campaign Redirect Decoy Domain

---

3.3 Configuration Category (11 items)

#	Setup Item	Konten Pembangunan	Owner	Description
10	JPush activation, backend API binding	Aktifkan Jiguang push & ikat API di backend	Martin	JPush channel
11	JPush PWA configuration	Konfigurasi push Jiguang (JPush) untuk PWA	Martin	PWA push
12	Third-party channel integration	Integrasi saluran pihak ketiga	Martin	Payment gateway integration
13	Payment channel amount & level configuration	Konfigurasi nominal & level saluran pembayaran	HB	Payment channel and limits for different user levels
14	Game ordering switch + popular game icons	Sakelar urutan game + ikon game populer	nuoya	Frontend game display order
15	CS line backend integration, automation flow, CS routing config	Integrasi backend layanan pelanggan, alur otomatisasi, konfigurasi penerimaan CS	nuoya	Salesmartly and other CS systems
16	Official site iOS repackaged app	Paket kamuflase iOS untuk situs resmi	Martin	iOS install package
17	PDD campaign check, PDD phone number upload	Pemeriksaan aktivitas PDD, unggah nomor ponsel PDD	Martin	Pinduoduo campaign config
18	Smart APK template configuration	Konfigurasi template APK cerdas	Martin	Android install package template
19	All backend copy configuration	Konfigurasi semua teks/copy di backend	nuoya	Includes campaign copy, prompt copy, etc.
20	Activate new Firebase	Aktifkan Firebase baru	yuhai	FCM push channel
21	Site config: platform site name, description, icon, logo upload	Konfigurasi situs: nama, deskripsi, ikon, logo	nuoya	Platform basic info

📘 Source: New Site Setup Preparation Worksheet

3.3.1 JPush (JPush/EngageLab) Registration & Pricing Adjustment Process

📘 Source: Supervisor work notes

JPush is the message push channel for the PWA end. New site setup requires registration and pricing adjustment.

Step 1: Register Account

1. Open JPush official site: https://www.engagelab.com/
2. Use email + password registration (⚠️ do NOT use Google email "one-click registration"; must use email + password)
3. Log in after registration

Step 2: Create Application

1. Create new application after login
2. Application name format: typically market abbreviation + "Tech" / company
3. Select Message Service → WebPush → Create application
4. Application info settings:
5. Name: site main domain (e.g., YYBB)
6. Server selection: Singapore

Step 3: Bind Backend

Fill the Application Key generated by JPush into the operations backend:

Operations Backend → PWA JPush Promotion Settings → Enter Application Key

Step 4: Contact JPush Sales for Pricing Adjustment

1. Contact JPush sales: Signal @winna8989
2. Provide info:
3. Application ID generated by JPush
4. Application Key generated by JPush
5. Request: JPush pricing adjustment
6. Script: Inform that we are an iGaming platform, recommended by Martin, request pricing matching Martin's package
7. Wait for sales to complete pricing adjustment

Step 5: Upgrade Package

After pricing adjustment is done, generate package and complete upgrade in JPush backend.

Complete flow chart:

  Register engagelab.com (email + password)
        │
        ▼
  Create App → Select WebPush → Server: Singapore
        │
        ▼
  Get App ID + App Key
        │
        ├──→ Enter into operations backend
        │     "PWA JPush Promotion Settings"
        │
        └──→ Signal @winna8989, send ID + Key
             → Request pricing adjustment
               (Martin's recommended package)
                    │
                    ▼
             Wait for adjustment → Generate package upgrade

---

3.3.2 Payment Channel Amount & Tier Configuration (Edit Third-party Deposit Info)

📘 Source: Supervisor work notes + platform backend screenshots

Operation path: Backend → Financial Management → Third-party Deposit Configuration → select a payment channel → click "Edit"

Function positioning: Each payment method under each third-party channel must be configured individually — determines which tier of users can see it, min/max deposit amount, fees, bonus rules, and quick amount presets. During new site setup, this must be done for every payment method (DANA / OVO / GoPay / QRIS / Bank Card etc.).

Edit Interface Field Details

Field	Meaning	Rule / Example
Third-party	Third-party payment provider (dropdown)	e.g., CoverPay(Transfer)
Payment Method	Specific payment channel under the third-party (dropdown)	e.g., DANA / OVO / GoPay / QRIS
Cash-flow Fee Rate	Fee percentage charged by third-party	1.1 means 1.1% / fill 1 for 1%, 0 if none
Per-transaction Fixed Fee	Fixed fee per transaction (IDRK)	0 for no fixed fee / fill 0 if none
Amount Range	User single-deposit min ~ max (IDRK)	e.g., 10 - 10000 (i.e., 10K~10M IDR) Unit IDRK, 1 IDRK = 1000 IDR
Bonus Ratio	Deposit bonus percentage	0 means no bonus / fill 1 for 1%, max 20, fill 0 if no bonus
Bonus Turnover Multiplier	Turnover multiplier required for the bonus amount	1 x / min 1x (prevents giving away free money)
Visible Member Tiers	Which user tiers can see this payment method	Multi-select tags (see tier description below)
Sort	Display order on frontend	Smaller number shows first (ascending)
Remark	Internal note (not shown to users)	Usually fill payment method name (e.g., DANA)
Status	Enabled / Disabled	Enabled = visible to users, Disabled = hidden
Frontend Display Name	Label shown to users	e.g., DANA / 10K = Rp10,000.00 / CP (multiple tags can stack)

Visible Member Tiers (Core Permission Isolation)

Member tier tags supported by backend:

Tier Tag	Meaning	Typical Use
Select All	All tiers visible when checked	❓ To be confirmed with Supervisor
Default	Default tier (regular members)	❓ To be confirmed with Supervisor
30-day Retained Customers	Members registered ≥ 30 days with retention	❓ To be confirmed with Supervisor
15-day Retained Customers	Members registered 15 ~ 30 days	❓ To be confirmed with Supervisor
7-day Retained Customers	Members registered 7 ~ 15 days	❓ To be confirmed with Supervisor
New User 1	First sub-tier of new registered users	❓ To be confirmed with Supervisor
New User	Newly registered users	❓ To be confirmed with Supervisor
Arbitrage Watch / BH	Members previously suspected of arbitrage	❓ To be confirmed with Supervisor
Secondary Verification / Data	Tier entered after password reset for security verification	Withdrawals require manual review (see 03-Deputy Supervisor Work Guide §5.2.3)

Configuration strategy:

❓ To be supplemented after confirming with Supervisor.

Quick Amount List

The bottom of the interface has a "Quick Amount List" — preset deposit tiers users see on the frontend.

Field	Meaning	Example
Amount	Backend amount value (unit IDRK)	20 / 30 / 50 / 100 / 300 / 500 / 1000 / 5000 / 10000
Frontend Display Name	Amount label users see	20K / 30K / 50K / ... / 10000K
Action	Delete this tier / Add new tier	—

Typical tier configuration: 20 / 30 / 50 / 100 / 300 / 500 / 1000 / 5000 / 10000 (9 tiers), covering small to large amount range.

📌 Tier design principles: - Small amount onboarding (20~100): Low threshold for new users - Mid-amount mainstream (300~1000): Common range for active users - High-amount VIP (5000+): For high-value users — do not exceed the channel's "Amount Range" cap - Must include integer multiples (e.g., 50 / 100 / 500), matches user habits

Validation After Configuration

Save configuration
      │
      ▼
  Frontend test (login with a test account of the corresponding tier)
      │
      ▼
  ① Is this payment method visible on the deposit page for this tier?
  ② Are quick amount tiers correctly displayed?
  ③ Is the display name (e.g., "DANA / 10K = Rp10,000.00 / CP") as expected?
      │
      ▼
  Initiate a small test deposit (e.g., 20K)
      │
      ▼
  ✅ Verify: Deposit success → frontend credited → backend "Deposit Records" queryable

Common Configuration Mistakes (Key Audit Points)

Mistake Type	Symptom	Consequence
Wrong amount range	Min greater than the lowest quick tier (e.g., range 50-10000, but quick has 20K)	User clicks 20K and sees "amount below minimum" error
Wrong bonus ratio	Filled 5% as 5 (actual 5%) / filled 1% as 0.01 (actual no bonus)	Either platform loses heavily, or users get no benefit
Bonus turnover multiplier set to 0	Users don't need turnover for the bonus	Free money — users withdraw immediately, platform loses
Wrong tier select-all	BH / Data tiers also have high-amount channels open	Risky users may exploit high-amount channels for arbitrage
Status not enabled	Forgot to enable after configuration	Users completely cannot see this channel on frontend

📝 Source: Supervisor work notes + backend interface analysis

---

3.4 Design Category (7 items)

All image size specifications, file size limits, and copy templates are detailed in 12 · UI Display Image Index & Campaign Promotion Copy Library. Always check this document for specifications before designing.

#	Setup Item	Owner	Size / Spec Reference	Description
22	ICON, LOGO design	nuoya	ICON 196×196 ≤512KB / LOGO 240×60 ≤200KB	Submit requirements to design team, Spec details §2.1
23	Campaign banner upload	nuoya	656×176 ≤500KB	Spec + copy templates §2.2 + §3.1~3.14
24	Campaign inner page upload	nuoya	Different sizes per campaign (540×240 ~ 540×900)	Per-campaign banner specs §2.6
25	Banner image upload	nuoya	Large 656×220 / Small 336×100 / Personal Center 656×160	Banner full spec §2.3
26	CS line icon, floating icon upload	nuoya	1:1 round image (no size limit)	CS config §2.4
27	Download page / APK / popup / share image / PWA splash	nuoya	Splash 736×1308 ≤2MB / Share 1280×670 / Popup 320×250 etc.	Promotion channel assets §2.7 + Share §2.5
28	Navigation page configuration	nuoya	750×250 (5 rotating images)	§2.7

📘 Source: New Site Setup Preparation Worksheet 📘 Source: 12-UI Display Image Index (full size specs + bilingual campaign promotion copy templates)

3.5 Account Category (4 items)

#	Setup Item	Konten Pembangunan	Owner	Description
29	CS supervisor backend config, CS / remote CS backend config	Konfigurasi backend ketua tim CS, backend CS / CS jarak jauh	❓ TBD	CS team accounts
30	Audit withdrawal backend config	Konfigurasi backend audit penarikan	❓ TBD	Audit team + withdrawal operation accounts
31	Self-media channel creation, follower boost	Buat kanal media mandiri, tambah followers	nuoya	Telegram / social media channel buildup
32	CS line agent configuration	Konfigurasi agen layanan pelanggan	nuoya	Salesmartly seat allocation

📘 Source: New Site Setup Preparation Worksheet

3.6 Testing Category (4 items)

#	Setup Item	Konten Pembangunan	Owner	Description
33	Game testing	Pengujian game	nuoya	Confirm games can open and run normally
34	Real deposit & withdrawal test	Uji deposit & penarikan nyata	yuhai	Test full deposit and withdrawal flow
35	URL test	Uji URL/website	nuoya	All domains can be accessed normally
36	Each campaign content check	Pemeriksaan konten tiap aktivitas	nuoya	Whether each campaign's rules, images, links are correct

📘 Source: New Site Setup Preparation Worksheet

3.7 Setup Workflow Overview Diagram (with Parallel Relationships)

The following is the actual execution sequence; many tasks can be done in parallel to shorten total cycle time.

═══════════════════════════════════════════════════════
  Actual New Site Setup Execution Sequence (37 items)
═══════════════════════════════════════════════════════

</div>

</div>

</div>

</div>

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

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

</div>

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

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

</div>

</div>

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

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

</div>

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

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

  Management decides: Buy main domain + Determine template + Open backend
        │
        ▼
  After domain confirmation, three lines start in parallel:
        │
  ┌─────┼──────────────────────────────┐
  │     │                              │
  ▼     ▼                              ▼
Line A   Line B                       Line C
Domain+  Design                       Self-media+
Config   Assets                       Accounts
  │       │                            │
  ▼       ▼                            ▼
Notify   Notify design / UI            Apply for self-media
SEO      team to prepare               accounts:
  │      all assets                    · Telegram account
  ▼      (ICON / LOGO /                · Facebook account
Buy      Banner / Campaign             · WhatsApp account
support  banner / Inner page /          │
+ decoy  CS icon /                      ▼
domains  Download page, etc.)          Create channels / groups:
  │           │                        · Telegram channel
  ▼           │                        · WhatsApp channel
Domain        │                          │
binding       │                          ▼
(support+PWA  │                       Configure Telegram bot
+decoy)       │                       (Configure via MiniApp;
  │           │                        later integrate
  ▼           │                        automation flow in
DNS resolve   │                        Salesmartly)
+line         │                          │
acceleration  │                          ▼
  │           │                       Enter self-media accounts
  ▼           │                       into platform config
Backend       │                       items
config        │                          │
(JPush/3rd    │                          │
party/Pay/    │                          │
Game/Firebase │                          │
/Copy etc.)   │                          │
  │           │                          │
  └─────┬─────┘                          │
        │ After assets ready             │
        ▼                                │
  Upload all assets                      │
  (Banner / Campaign img /              │
   CS icon / Download page,             │
   etc.)                                │
        │                                │
        └──────────┬─────────────────────┘
                   │ After all complete
                   ▼
        ═══════════════════════
          Testing Phase (4 items)
        ═══════════════════════
                   │
                   ├─ Game test
                   ├─ Real deposit & withdrawal test
                   ├─ URL test
                   └─ Each campaign content check
                   │
                   ▼
              New Site Launch 🚀

📝 Source: Learning discussion

Key parallel point: After domain confirmation, no need to wait for all domain bindings before starting other work. Notifying designers for assets, applying for self-media accounts, and creating Telegram channels and bots can all be done simultaneously, fully utilizing the waiting time.

Telegram bot + Salesmartly integration: After the bot is configured via MiniApp, configure the automation flow in Salesmartly. For related operations, see 03-Deputy Supervisor Onboarding · §4.12.2 Salesmartly CS Automation Flow Configuration.

3.8 Setup Task Assignment Overview

The following assignment data is from 22-New Site Setup Preparation Worksheet; each table notes specific owners.

Owner	Task Count	Main Responsibility
Martin	8 items	Domain procurement (main + supporting + decoy), notify SEO, JPush config, third-party channel integration, iOS repackaged app, PDD campaign, APK template
HB	5 items	Domain binding / resolution (supporting + PWA + decoy), line acceleration, payment channel amount & level config
nuoya	16 items	Game config, all asset production and upload (ICON / LOGO / Banner / Campaign img / CS icon / Download page / Nav page), CS line config, backend copy, site config, self-media channel, testing (game + URL + campaign check)
yuhai	2 items	Firebase activation, real deposit & withdrawal test
❓ TBD	2 items	CS supervisor / Remote CS backend config, audit withdrawal backend config

Gap analysis explanation:

The original preparation worksheet has 34 items; after the Supervisor work guide compilation, it is 37 items (because the domain category is split more finely, and items like "notify SEO" and "site config" are added). Comparison of differences between the two documents:

Dimension	Original Prep Worksheet (22-New Site Setup)	Supervisor Work Guide (Chapter 3 of this doc)
Domain category	8 items	9 items (added "Notify SEO")
Configuration	11 items	11 items (consistent)
Design	7 items	7 items (consistent; size specs added)
Account	4 items	4 items (consistent)
Testing	4 items	4 items (consistent)
Owner	✅ Yes	✅ Synced
Principle explanation	None	✅ Yes (domain system / DNS / CDN / anti-block architecture, etc.)
Parallel flow chart	None	✅ Yes (§3.7)

📘 Source: 22-New Site Setup Preparation Work

---

4. Campaign Effect Monitoring & Adjustment

4.1 New Site Campaign Monitoring

Various campaigns set up at the beginning of the new site need continuous effect monitoring; cannot just set them up and forget.

Monitoring focus: - Participation rate and claim rate of each campaign - Impact of campaigns on deposit-withdrawal balance ratio - User retention effect - Whether arbitrage anomalies appear

4.2 Weekly Win-back Effect Testing

When running test campaigns like weekly win-back, you need to: - Continuously track win-back effect data - Decide based on data whether to adjust parameters (e.g., win-back amount, filter conditions, etc.) - Adjust strategy in time when effect is poor; do not continue investing in ineffective win-back schemes

📝 Source: Learning discussion

---

5. HQ Logistics Platform (houqin · Personal Attempt)

I am personally attempting to develop a logistics middle platform system, hoping to unify management of scheduling, meal allocation, meal fee deduction and other logistics business; future may extend to attendance, office supplies, dormitory, shuttle bus, etc. This section introduces content that may be of reference from the Supervisor's perspective.

5.1 Project Positioning

Item	Content
Project codename	houqin (logistics)
Code repo	~/Coding/HRsystem/
Tech stack	Go + Gin + PostgreSQL + Redis (backend) / Vue 3 + TS + Naive UI (frontend) / Docker Compose deployment
i18n	Chinese as base; supports zh / en / id (Indonesian) / ru
Settlement currency	All meal fees, salaries, bills based on USDT (supports CNY/AMD/IDR/RUB/USD real-time exchange rate conversion)

5.2 Problems to Solve

Hoping to replace the current logistics management approach scattered across multiple Excel + WeChat groups: - CS scheduling scattered in WFH SHIFT.xlsx (15 sheets) - QA and salary scattered in Inspector Chat-CR_质检.xlsx (24 sheets) - Personal profiles in 远程个人信息_DATA WFH.xlsx (8 sheets) - Meal fees rely on manual statistics + WeChat group notifications

📌 Core value proposition: Move cross-shift information flow from Excel + WeChat groups into the system, allowing employees, supervisors, HR, and cooks to perform their duties with zero errors.

5.3 Phase 1 Scope

Module	Status	Description
Scheduling module	✅ Planned	Day shift / Night shift / Leave / Shift change; with leave/swap approval flow
Meal module	✅ Planned	Cook manages menu + employee three-choice (eat/skip/takeaway) + shift transfer linkage
Billing module	✅ Planned	Meal pricing + consumption record + monthly bill + salary deduction export
Platform core	✅ Planned	Auth / RBAC / Org / Audit / Event bus / Notification / Multi-timezone / i18n
❌ Office supplies request	Phase 2	Schema and event channel reserved
❌ Attendance check-in	Phase 2	Currently uses cloud desktop DAKA
❌ Dormitory / Shuttle / Uniform	Phase 2/3	—
❌ Salary API auto-deduction	Phase 2	Phase 1 exports Excel for manual handling

5.4 User Roles (Mapped to Management System in This Guide)

HQ System Role	Corresponding Position in This Guide	End
Employee	Remote CS + on-site CS + Deputy Supervisor and other execution positions	Telegram Mini App (main) + Web H5 (auxiliary)
Team Lead	This guide's target reader — manages team of 8-15	Web management page + Telegram Mini App
HR / Admin	HR department + admin position	Web management backend (PC main)
Cook	Kitchen staff	Simplified end (older demographic)

5.5 Supervisor's Core Actions in HQ System

• Batch confirm group meal orders — can be processed in batches while sitting in office during the day
• Temporary shift change — adjust shifts when an employee takes leave
• Modify employee meal orders on their behalf — e.g., adjust meal order on the day an employee takes leave
• View group's scheduling and attendance summary

5.6 Development Progress

Milestone	Time	Status
W0	Design completed (2026-04-22 ~ 2026-04-23)	✅
W1	Infrastructure + Auth + RBAC + Org schema	🔄
W2	Audit + Event Bus + Org CRUD	⏳
W3	Meal module I	⏳
W4	Meal II + Scheduling	⏳
W5	Billing + FX + Web frontend I	⏳
W6	Web II + MiniApp	⏳
W7	Notification + Observability + Security regression	⏳
W8	Gradual rollout	⏳

5.7 Project Internal Documentation Index

For detailed product planning, technical decisions, and development plan, see in the ~/Coding/HRsystem/ directory: - README.md — Quick start - CLAUDE.md — Project standards entry (must-read for development) - docs/10-prd.md — Product Requirements Document (v1.2) - docs/11-dev-plan.md — Development plan - docs/04-p0-fixes.md — P0 fix standards - docs/adr/ — Architecture Decision Records (14 ADRs)

📝 Source: houqin project README + PRD v1.2

---

6. Pending Confirmation Checklist ❓

#	Pending Item	Source
1	Complete list of positions managed by Supervisor (besides Deputy Supervisor and CS Management, what else?)	§1.1
~~2~~	~~New site setup execution sequence and dependencies~~	✅ Resolved in §3.7
~~3~~	~~Division between Supervisor's personal operation vs assignment to subordinates in new site setup~~	✅ Integrated owner assignment in §3.8
4	Specific metrics and data sources for campaign effect monitoring	§4.1
5	Decision criteria for weekly win-back parameter adjustment (below what effect to adjust?)	§4.2
6	What are the typical types of "difficult cases" handled by Supervisor daily?	§2.1
7	Reporting and escalation mechanism between Supervisor and Manager	Chapter 2
8	Specific content, frequency, criteria for designated game vendor testing	§2.7
9	More scenarios and operations of simulated callback data	§2.7
10	Complete field list, formula design, processing fee reasonable range for Group Operations Report	§2.8
11	Specific content and process of payment gateway third-party group dispatch confirmation	§2.9
~~12~~	~~Storage location, update frequency, review process for CS script documents~~	✅ Compiled to 10-Customer Service Center directory
13	Currently used Google Sheet report templates (need to obtain to refine data dashboard system design)	§2.8
14	Owner for CS / audit backend configuration in new site setup account category	§3.5

---

Cross-references

• 03-Deputy Supervisor Onboarding Guide — Complete workflow for Deputy Supervisor managed by Supervisor
• 06-Audit Supervisor Work Guide — Workflow for Audit team managed by Supervisor
• 04-Agent Arbitrage Behavior Determination Guide — Detailed criteria for arbitrage review
• 22-New Site Setup Preparation Work — Original setup checklist data source (owner assignment source)
• 09-Domain Type Functions — Domain system details reference
• 12-UI Display Image Index — Asset size specifications and campaign copy templates
• 10-Customer Service Center — CS script library + Workflow SOP + Remote CS management standards + CS Management Specialist work guide
• 04-CS Management Specialist Work Guide · §18 Backend Permission Isolation Design — Backend permission differences between remote CS vs on-site management positions and security logic