03 · Deputy Team Lead Onboarding Guide (Shift Operations Playbook)¶
Target audience: Newly appointed Deputy Team Leads, colleagues needing to align on shift SOPs, future handover recipients Core question: On your first solo shift, you should know exactly what to do at each time slot, how to close the loop on every task, and whom to escalate to when something goes wrong Positioning: An operational Playbook, not a job description (JD). Use alongside 01-团队管理基础 and 02-远程团队协作 Author: Bob ｜ Last updated: 2026-04-12
📚 Companion manuals: 11-平台手册/非凡包网/ — 12 topic docs + 9 subdirectories with 79 sub-manuals (Member & Risk 14 / Finance & Payment 10 / Campaign Config 13 / Marketing Tools 5 / Activity Records 18 / Promotion Channels 11 / Game Mgmt 3 / System Admin 4 / Frontend User 1), total 91 docs
Table of Contents¶
- I. Role Definition & Red Lines
- II. Daily Work Timeline (Indonesia Time UTC+7)
- Responsibility Map · One-Page Overview
- III. Cadence Task Workflows (A-Line)
- 3.1 Push Notification Full Pipeline
- 3.2 Redemption Code Management
- 3.3 Day-Shift Batch Task Suite (SMS + Bonus merged)
- 3.4 Weekly Pull-Back (Friday prep + Saturday send)
- 3.5 Deposit-Withdrawal Spread Inspection + Conditional Rebate
- 3.6 Payment Collection & Disbursement Channel Management
- IV. Reactive Task Workflows (B-Line · Handle on Arrival)
- 4.1 Withdrawal Order Review
- 4.2 Deduction Processing
- 4.3 Member Permission Changes
- 4.4 Order Callback Processing
- 4.5 Wagering Requirement Verification
- 4.6 Bet Restriction Troubleshooting
- 4.7 Event Day RTP Adjustment
- 4.8 Chargeback/Reversal Order Processing
- 4.12 New-Site Onboarding (Assist the Team Lead)
- 4.13 Finance Disbursement Anomaly Order Review
- V. Common Issue Handling
- 5.1 Member Forgot Login Password
- 5.2 Member Forgot Withdrawal Password
- 5.3 Promotional Event Rules — Quick Answers for Complaints
- VI. Collaboration & Communication Standards
- VII. Shift Handover Checklist
- VIII. Automation Recommendations
- IX. Pending Confirmation Checklist
- X. Lessons Learned & Pitfalls
- Appendix A · Quick Reference Card
- Appendix B · Related Document Index
- Appendix C · Deputy Lead Toolbox User Guide
I. Role Definition & Red Lines¶
1.1 Three-in-One Role Profile¶
The Deputy Team Lead is essentially a "Marketing Execution + Risk Control Screening + Coordination Hub" three-in-one role:
┌──────────────────────────────┐
│ Deputy Team Lead (On Shift) │
└──────────────┬───────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
┌───────▼──────────┐ ┌───────▼──────────┐ ┌───────▼──────────┐
│ Marketing Exec │ │ Risk Control │ │ Coordination │
│ ~45% │ │ Screening ~30% │ │ Hub ~25% │
│ Output layer │ │ Decision layer │ │ Process layer │
│ User reach + │ │ Funds / account │ │ Cross-team coord │
│ incentives │ │ second review │ │ + traceability │
└──────────────────┘ └──────────────────┘ └──────────────────┘
Three-in-one responsibility matrix (covers all chapters in this doc):
| Marketing Execution (output layer) | Risk Control Screening (decision layer) | Coordination Hub (process layer) |
|---|---|---|
| Push notifications (Firebase / JPush 5x/day + In-App 1x/day) → 3.1 | Withdrawal order review (incl. agent anti-arbitrage review) → 4.1 | Task claim (anti-duplication, prerequisite for all B-Line actions) → IV |
| Redemption code management (set / rotate) → 3.2 | Deduction execution (Audit finds → CS communicates → user agrees → Deputy executes) → 4.2 | Order callback processing (act per CS / finance / risk notice) → 4.4 |
| SMS user callback (registered-not-deposited + loss pull-back) → 3.3 | Member permission changes (open/close betting / withdrawal / login) → 4.3 | Pay-in/pay-out channel management (1st task on shift + hourly inspection) → 3.6 |
| Batch Treasure Box distribution (yesterday-deposit / day-before-not-yesterday pull-back, daily) → 3.3.4 / 3.3.5 | Wagering check → 4.5 | Deposit success rate monitoring (every 30 min) → 4.9 |
| Weekly pull-back (registered within 30d + inactive 10+d + ≥ 2 deposits, weekly) → 3.4 | Bet restriction investigation → 4.6 | Withdrawal 30-min no-callback handling → 4.10 |
| Dep-Wdl spread conditional rebate (20:00 · 0.02 ratio · supervisor approval) → 3.5 | Password reset (login + withdrawal · social-engineering defense) → 5.1 / 5.2 | Reversal/refund order processing → 4.8 |
| Peak-hour best-deposit channel switch (new users only, open 19:00 / close 03:00) → 3.6 sub-task | User Lock List unlock (paired with password reset + post-arbitrage unlock) → 5.2.2 | Disbursement interface timeout order processing → 4.11 |
| Event-day RTP rate adjustment → 4.7 | Finance disbursement anomaly order review (human-error identification) → 4.13 | New-site onboarding assistance (domain binding + Salesmartly / Telegram bot automation config) → 4.12 |
| — | — | Finance group reporting (mandatory for every fund-related action) + CS group response + handover (10:00 AM / 10:00 PM) |
📝 Source: Study & discussion
1.2 Role Boundaries — What I Am NOT¶
| Role | Not This | Reason |
|---|---|---|
| Campaign Planner | Does not decide redemption code amount/quantity/copy strategy | Redemption codes set by Deputy Lead; amount/quantity parameters follow team rules |
| Finance Auditor | Does not independently initiate deduction decisions | Deductions initiated by Audit Team → CS communicates → User agrees → Deputy Lead executes; report to finance group after completion |
| Frontline CS | Does not directly reply to user inquiries | User issues go through CS team; only handle permission/deduction cases escalated by CS |
📝 Source: Study & discussion
1.3 Three Inviolable Red Lines¶
┌──────────────────────────────────────────────────────────────────┐
│ Three Red Lines │
│ │
│ ① Prevent Duplication │
│ Tasks in the group must be "claimed before executed", │
│ especially member permissions, deductions, order callbacks │
│ Duplicate operations = Financial loss │
│ │
│ ② Prevent Fraud │
│ Agent withdrawals must go through arbitrage review │
│ (per four criteria) │
│ Auto-payout failure → regardless of first withdrawal or not, │
│ must query actual order status and handle accordingly │
│ │
│ ③ Prevent Broken Chains │
│ Every action must leave a trail: back-office notes / │
│ group announcements / spreadsheet entries / finance & CS │
│ notifications, for shift handover and post-mortem review │
└──────────────────────────────────────────────────────────────────┘
📝 Source: Study & discussion
II. Daily Work Timeline (Indonesia Time UTC+7)¶
The Deputy Team Lead's work rhythm consists of two parallel lines:
- A-Line (Cadence Tasks): Execute at fixed time points — 5 pushes + commission + SMS + inspection + rebate
- B-Line (Reactive Tasks): Withdrawals / permissions / deductions / callbacks — handle on arrival
Time(UTC+7) Night Shift Day Shift Action
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
00:00 ████████ ░░░░░░░░ A-Line Push ① (night shift only)
Firebase auto + manual JPush (PWA/bookmark)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📌 Indonesian peak 19:00–03:00, night push critical
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
02:00~10:00 ░░░░░░░░ ░░░░░░░░ B-Line Response Window: Withdrawals/Permissions/
Deductions/Callbacks
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10:00 >> Day shift takes over + handover confirmation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10:00~10:15 ████████ A-Line Payment Channel Mgmt (first task of day shift)
Check CP/ATM balance → configure disbursement →
verify channel order
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10:15~11:00 ████████ A-Line Day-Shift Batch Task Suite (SMS Callback + Bonus, 4 sub-tasks)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
11:00 ████████ A-Line Push ② (Firebase + JPush)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
15:00 ████████ A-Line Push ③ (Firebase + JPush)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
19:00 ████████ A-Line Push ④ (Firebase + JPush + In-App)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
20:00 ████████ A-Line Deposit-Withdrawal Spread Inspection
(all platforms)
+-- >10% platform → notify supervisor
+-- >10% platform → trigger same-day rebate (0.02)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
20:00~20:40 Inspection (<=15min) + Rebate (<=25min)
Must finish before 21:00 push
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
21:00 ████████ A-Line Push ⑤ (last push of day shift, Firebase + JPush)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
22:00 >> Night shift takes over + handover confirmation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Key principle: Firebase is auto-scheduled — set it once and it fires on time; JPush and In-App Messages must be sent manually at the exact time (no pre-scheduling), so always set an alarm 1 hour before each push.
📝 Source: Study & discussion
A-Line Cadence Task Quick Reference¶
| # | Task | Frequency | Time | Details |
|---|---|---|---|---|
| 1 | Push Notification (Firebase + JPush + In-App Msg) | Firebase/JPush 5x/day + In-App 1x/day | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 (In-App only 19:00) | 3.1 |
| 2 | Redemption Code Management | When codes need updating | Deputy Lead sets per platform | 3.2 |
| 3 | Day-Shift Batch Task Suite (SMS Callback + Bonus Distribution, 4 sub-tasks) | 1 batch/day | After day shift starts | 3.3 |
| 4 | Weekly Pull-Back (registered within 30 days + inactive 10+ days + ≥ 2 deposits → 0.88 + SMS) | 1x/week | Prep Fri, send Sat (with 3.3) | 3.4 |
| 5 | Deposit-Withdrawal Spread Inspection + Conditional Rebate | 1x/day | 20:00 | 3.5 |
| 6 | Payment Collection & Disbursement Channel Management | Daily | First task of day shift | 3.6 |
B-Line Reactive Task Quick Reference¶
| Task | Trigger | Details |
|---|---|---|
| Withdrawal Order Review | When order arrives | 4.1 |
| Deduction Processing | When CS reports | 4.2 |
| Member Permission On/Off | When CS reports | 4.3 |
| Order Callback Processing | When pushed in group | 4.4 |
| Deposit Success Rate Monitoring | Every 30 min (scheduled) | 4.9 |
| Withdrawal 30-Min No-Callback | When back-office alerts | 4.10 |
| Disbursement Interface Timeout | When back-office alerts | 4.11 |
Responsibility Map · One-Page Overview¶
Read this map before your first shift — everything the Deputy Lead is responsible for lives here. A-Line / B-Line are just two of four categories. Details expand in later chapters.
Deputy Lead Responsibility Map (4 categories)
│
├─ A-Line · Cadence Tasks (time-boxed, highest priority, non-interruptible)
│ │
│ ├─ 📣 Push & outreach
│ │ ├─ 3.1 Push notifications (Firebase / JPush 5x/day + In-App 1x/day)
│ │ └─ 3.2 Redemption code management (as needed, ad-hoc)
│ │
│ ├─ 👥 User operations
│ │ ├─ 3.3 Day-shift batch suite (1 batch/day · 4 sub-tasks: SMS + bonus)
│ │ └─ 3.4 Weekly pull-back (Fri prep + Sat send)
│ │
│ └─ 💰 Financial operations
│ ├─ 3.5 Dep-Wdl spread inspection + conditional rebate (daily 20:00)
│ ├─ 3.6 Pay-in/pay-out channel management (1st task + hourly inspection)
│ └─ 3.6 sub-task: Peak-hour best-deposit channel switch (open 19:00 / close 03:00)
│
├─ B-Line · Reactive Tasks (event-triggered, 4-step: Claim → Execute → Reply → Report)
│ │
│ ├─ 🚨 Withdrawal decision chain
│ │ ├─ 4.1 Withdrawal order review (highest risk)
│ │ ├─ 4.10 Withdrawal 30-min no-callback
│ │ └─ 4.11 Disbursement interface timeout
│ │
│ ├─ 🔧 Account intervention
│ │ ├─ 4.2 Deduction processing
│ │ ├─ 4.3 Member permission changes
│ │ ├─ 5.1 Member forgot login password
│ │ └─ 5.2 Member forgot withdrawal password
│ │
│ ├─ 🔁 Fund flow
│ │ ├─ 4.4 Order callback processing
│ │ └─ 4.13 Finance disbursement anomaly order review (human-error identification)
│ │
│ └─ 📊 Monitoring / alerts
│ └─ 4.9 Deposit success rate monitoring (every 30 min)
│
├─ 🤝 Collaboration (runs all day + ad-hoc assistance to Team Lead)
│ ├─ Handover (10:00 AM + 10:00 PM, see VII)
│ ├─ Group communication (CS / risk / finance / shift groups, see VI)
│ ├─ Finance group reporting (required for every fund-related action)
│ └─ 4.12 New-site onboarding assistance (domain binding + CS automation + bot config)
│
└─ 📚 Growth (ongoing)
├─ Study the platform manual (Appendix B · index of 91 sub-manuals)
├─ Build your learnings (X · pitfalls & efficiency notes)
└─ Feedback on automation (VIII · tool inventory)
By-frequency master table (all deep links):
| Frequency | Task | Category | See |
|---|---|---|---|
| Daily · 5 fixed slots | Push notifications (Firebase + JPush 5x/day + In-App 1x/day) | A-Line | 3.1 |
| Daily · first task on shift | Pay-in/pay-out channel management | A-Line | 3.6 |
| Daily · hourly | Pay-out merchant balance inspection | A-Line | 3.6 sub-task |
| Daily · after day shift | Day-shift batch suite (SMS + bonus, 4 paths) | A-Line | 3.3 |
| Daily · 20:00 | Dep-Wdl spread inspection + rebate | A-Line | 3.5 |
| Daily · open 19:00 / close 03:00 | Peak-hour best-deposit channel (new users only) | A-Line | 3.6 sub-task |
| Daily · every 30 min | Deposit success rate monitoring | B-Line | 4.9 |
| Daily · event-triggered | Withdrawal review / deduction / permissions / callback / password reset | B-Line | 4.1 / 4.2 / 4.3 / 4.4 / 5.1 / 5.2 |
| Ad-hoc · finance-group-triggered | Finance disbursement anomaly order review (human-error identification) | B-Line | 4.13 |
| Ad-hoc (when new code) | Redemption code management | A-Line | 3.2 |
| Ad-hoc · Team Lead notice | New-site onboarding assistance (domain binding + CS automation + bot config) | Collab | 4.12 |
| Weekly · Fri+Sat | Weekly pull-back (within 30d + 10d inactive + ≥2 deposits) | A-Line | 3.4 |
| Ongoing | Handover / group chat / finance reporting | Collab | VI / VII |
| Ongoing | Study / learnings / automation feedback | Growth | VIII / X / App B |
III. Cadence Task Workflows (A-Line)¶
3.1 Push Notification Full Pipeline (Firebase + JPush + In-App Message)¶
The entire push task is divided into three phases. Execute Phase 1 and Phase 2 (one-time) each time you receive new redemption codes, then repeat Phase 3 daily at the scheduled time points.
The three push channels target different user segments with different frequencies:
| Channel | Target Users | Frequency | Time Points |
|---|---|---|---|
| Firebase (FCM) | APK users (native Android builds) | 5x/day | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 |
| JPush (Aurora Push) | PWA / bookmark users (iOS + Android — anyone who installed our PWA) | 5x/day | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 |
| In-App Message | All logged-in users (Web + App) | 1x/day | 19:00 |
About "JPush": The back-office menu is named "Aurora Push / JPush", but its actual target is PWA / bookmark users (users who added the site to their home screen). Not restricted by OS — iOS and Android users both receive it as long as they installed the PWA. It is an independent channel separate from Firebase (which targets native APK).
Why are time points 00:00 / 11:00 / 15:00 / 19:00 / 21:00? The Indonesian market has its peak activity from 19:00–03:00 (prime evening entertainment hours). These 5 slots cover pre-peak warm-up, daytime continuous reach, and peak-period concentrated reach. Firebase and JPush fire at all 5 slots; In-App only at 19:00. 11:00 is the lunch break for typical office workers — they often check their phones then. 15:00 is when many Indonesian government officials end their workday — also an easy-to-reach window.
┌─────────────────────────────────────────────────────────────────┐
│ Full Pipeline Overview │
│ │
│ Phase 1: Preparation (done once per new code batch) │
│ Deputy Lead sets code → send to UI for image → download → │
│ rename → create code in back-office → update copy library │
│ │
│ Phase 2: Scheduling (before each push, pre-configure the │
│ next time point during idle time) │
│ Configure scheduled tasks in Firebase for each platform │
│ (10+ platforms, one by one; can duplicate old tasks) │
│ │
│ Phase 3: Execution (5 time points daily) │
│ 00:00 → Firebase + JPush │
│ 11:00 → Firebase + JPush │
│ 15:00 → Firebase + JPush │
│ 19:00 → Firebase + JPush + In-App (full combo) │
│ 21:00 → Firebase + JPush │
│ Note: delete old In-App Message before sending new one │
└─────────────────────────────────────────────────────────────────┘
Phase 1 · Preparation: Done Once When Codes Need Updating¶
Deputy Lead decides new code
│
│ (1) Set redemption code (new site: use site name e.g. SL888;
│ thereafter: random 4-digit number)
▼
┌─────────────────────────────────┐
│ (2) Send to UI team for image │ ← Provide code, UI creates
│ creation │ marketing images
└────────┬────────────────────────┘
│
▼
┌───────────────────────────┐
│ (3) Download images locally │
└────────┬──────────────────┘
│
▼
┌────────────────────────────────┐
│ (4) Rename images to "platform │ ← Standardize for next shift
│ name" │ to identify easily
└────────┬───────────────────────┘
│
▼
┌───────────────────────────┐
│ (5) Send to team group │ ← Sync info, avoid duplicate downloads
└────────┬──────────────────┘
│
▼
┌───────────────────────────────────────┐
│ (6) Enter each platform's back-office,│
│ create new redemption code: │
│ · Generation qty: 1 │
│ · Single-code use count: 50,000 │
│ · Target audience: same-day │
│ depositors │
│ · Amount: random between 1-2 │
│ · Wagering Requirement = Amount │
│ · Double-check code is correct │
└────────┬──────────────────────────────┘
│
▼
┌───────────────────────────────────────┐
│ (7) Update Google Sheets "Promo Copy │
│ Library" — replace new code into │
│ the corresponding platform's │
│ copy template │
└───────────────────────────────────────┘
Key Parameters:
| Parameter | Current Value | Notes |
|---|---|---|
| Generation qty (codes per run) | 1 | Only 1 redemption code created per run, same for all platforms |
| Single-code use count | 50,000 | One code can be claimed by up to 50K members |
| Target audience | Same-day depositors | Back-office default filter |
| Amount range | 1 ~ 2 (random) | New platforms start at 2.2, gradually reduce to 1.0, then random between 1-2 |
| Wagering multiplier | 1x (= amount) | Turnover requirement |
| Firebase push frequency | 5x/day (APK / native Android) | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 |
| JPush frequency | 5x/day (PWA/bookmark users — iOS + Android) | 00:00 / 11:00 / 15:00 / 19:00 / 21:00 |
| In-App Message frequency | 1x/day (all logged-in users) | 19:00 |
📝 Source: Study & discussion
🤖 Automation progress: Tampermonkey automation scripts for Firebase and JPush have been developed, greatly reducing mechanical copy-paste work and improving efficiency. Technical design documented at 02-技术体系/16-firebase/. Note: current push time points (on the hour) coincide with FCM global traffic peaks; recommended to shift +3 minutes to avoid congestion.
Phase 2 · Scheduling: Configure Scheduled Tasks in Firebase¶
Important: This is NOT about configuring all 5 time points at once. The actual process is to only configure the next time point, using idle time to set it up in advance. Since there are 10+ platforms each requiring individual configuration, the workload is significant, so each shift handles its own time slots.
After current push is done (or during idle time)
│
▼
┌───────────────────────────────────────────┐
│ For each platform (10+), configure the │
│ next time point one by one: │
│ │
│ Enter this platform's Firebase Console │
│ │ │
│ ▼ │
│ Duplicate the previous scheduled task │
│ (saves time) │
│ │ │
│ ▼ │
│ Edit: │
│ · Title → copy from Google Copy Library │
│ · Content → copy from Google Copy Lib │
│ · Image → matching platform image │
│ (verify!) │
│ · Time → next cadence point │
│ │ │
│ ▼ │
│ Verify: platform ↔ image ↔ copy ↔ │
│ redemption code consistency │
│ │ │
│ └→ Next platform, repeat above │
└───────────────────────────────────────────┘
Shift Assignments:
| Shift | Push Times to Configure | When to Configure |
|---|---|---|
| Night shift | 00:00 push | After taking over, during idle time |
| Day shift | 11:00 / 15:00 / 19:00 / 21:00 | After each push, use idle time to configure the next one |
Common Pitfalls:
| Pitfall | Consequence | Prevention |
|---|---|---|
| Image mismatch | Push for Platform A shows Platform B's image | Cross-check platform name after configuring each one |
| Copy has outdated redemption code | Users get expired codes | Use Google Copy Library as Single Source of Truth |
| Firebase timezone set incorrectly | Push time offset | Set Firebase to Indonesia timezone (UTC+7), no conversion needed |
| Missed configuring a platform | That platform's users get no push | Check off each platform against the master list after completion |
📝 Source: Study & discussion
Phase 3 · Execution: Fire on Schedule¶
Principle: Firebase and JPush fire at all 5 time points (5x/day); In-App Message only fires at 19:00 (1x/day). At 00:00 / 11:00 / 15:00 / 21:00, send Firebase + JPush only. At 19:00, send the full combo (Firebase + JPush + In-App).
Action Table per Time Point (uniform across all slots):
| Time | Firebase (APK/Android) | JPush (PWA/bookmark) | In-App Message (all) | Notes |
|---|---|---|---|---|
| 00:00 | ✅ Auto-triggered | ✅ Send manually | — | Firebase + JPush only (night-shift) |
| 11:00 | ✅ Auto-triggered | ✅ Send manually | — | Firebase + JPush only |
| 15:00 | ✅ Auto-triggered | ✅ Send manually | — | Firebase + JPush only |
| 19:00 | ✅ Auto-triggered | ✅ Send manually | ✅ Send manually | Full combo (Firebase + JPush + In-App) |
| 21:00 | ✅ Auto-triggered | ✅ Send manually | — | Firebase + JPush only (last day-shift push) |
T-60 minutes (set alarm to prepare in advance)
│
│ JPush / In-App Message cannot be pre-scheduled —
│ must be sent manually at exact time
▼
Prepare push:
· Open back-office JPush page (draft ready)
· If 19:00 slot: also open In-App page (HTML pasted)
· Firebase is pre-scheduled in Phase 2 — no manual action
│
▼
T-0: Time! Fire push:
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ ① Firebase │ │ ② JPush │ │ ③ In-App Message │
│ (auto-triggered) │ │ Click "Send" │ │ · Open code │
│ All 5 slots │ │ All 5 slots │ │ editor │
│ (APK/Android) │ │ (PWA/bookmark) │ │ · Paste HTML │
│ │ │ │ │ (overwrite) │
│ │ │ │ │ · Click Send │
│ │ │ │ │ · Delete old msg │
│ │ │ │ │ 19:00 only │
│ │ │ │ │ │
└──────────────────┘ └──────────────────┘ └──────────────────┘
│
▼
T+5: Post in the shift group "Push sent at HH:MM
(Firebase + JPush [+ In-App])" — channels logged for audit
Pitfalls to Avoid:
- Firebase + JPush fire at all 5 slots; In-App only at 19:00 — don't send In-App at 00:00/11:00/15:00/21:00
- JPush & In-App cannot be pre-scheduled, must be sent manually at the exact time — set alarm 1 hour in advance
- Delete the old In-App Message before sending the new one to avoid pile-up
- During handover, explicitly confirm the incoming shift knows the In-App schedule (19:00 only)
📝 Source: Study & discussion
3.2 Redemption Code Management¶
Redemption codes are set by the Deputy Team Lead for each platform. After setting, send to UI team for image creation, then enter the push notification flow.
Naming Rules¶
| Scenario | Naming Method | Example |
|---|---|---|
| New site | Use the site name directly | SL888 |
| Subsequent changes | Random 4-digit number | 3847 |
Complete Flow¶
Deputy Lead sets redemption codes for each platform
(new site uses site name, afterwards use random 4-digit number)
【An auto tool already exists to batch-create and manage codes directly】
│
▼
┌───────────────────────────────┐
│ (1) Create redemption code │
│ in back-office │
│ (see parameters below) │
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────┐
│ (2) Send code to UI team │
│ UI creates push image │
│ for the platform │
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────┐
│ (3) Download received image │
│ + rename by platform name │
│ Send to team group chat │
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────┐
│ (4) Update Google Sheets │
│ "Promo Copy Library" │
│ Replace code in platform │
│ copy template │
└────────┬──────────────────────┘
│
▼
Enter 3.1 Phase 2 (Firebase scheduling)
📝 Source: Study & discussion
Back-Office Creation Parameters¶
| Parameter | Value | Notes |
|---|---|---|
| Generation Quantity | 1 | Only one redemption code is created per run (same for all platforms) |
| Single-code Use Count | 50,000 | The same redemption code can be used by up to 50,000 members (each member uses it once) |
| Target Audience | Same-day depositors | Back-office filter condition, current default |
| Redeemable Amount | 1 ~ 2 (random) | Enter range in back-office. The unit on Indonesian platforms is K — 1 equals 1,000 IDR. |
| Wagering Requirement | = Amount (1x) | Turnover requirement equals the amount itself |
| Validity | 1 day | Codes are usually set during night-shift takeover, around 22:00 onwards, with validity set to the next day 23:59:59 |
Important note: When creating a code, the back-office auto-generates a 4-character code containing letters + digits. However, Indonesian users are not used to alphanumeric codes, so after creation the Deputy Lead must click the "Custom Code" button and change the auto-generated code to the unified code already set above.
New platform strategy: For newly launched platforms, the redeemable amount of the code starts at 2.2, gradually reduces to 1.0, and after stabilization settles into the 1-2 random range.
📝 Source: Study & discussion
Relationship with Push Copy¶
After creating redemption codes, you must synchronize the Google Sheets "Promo Copy Library" with the corresponding platform's copy template to ensure the push text contains the latest code. The Copy Library is the Single Source of Truth — all text for Phase 2 scheduling and Phase 3 execution is copied from here.
🤖 Automation opportunity: Push copy rotation tool — randomly selects one copy per platform, no repeat within 24 hours, ensuring each site's push is different every time. Already built in tools/t1-promo-copy/ — code is there to review and reuse.
3.3 Day-Shift Batch Task Suite (SMS Callback + Bonus Distribution)¶
What to do: After the day shift takes over, run a batch suite — pull data from the back-office → split into 4 filter paths → every path produces a phone-number TXT; 3 of them (sub-tasks 1/3/4) additionally produce a bonus Excel for Treasure Box import, while sub-task 2 (loss pull-back) produces only TXT + a loss headcount report → finally go to the SMS platform to send all messages.
Objective: Reach 4 user segments (registered-not-deposited / loss / yesterday's depositors / day-before-deposited-not-yesterday) through bonus + SMS to drive first-deposit conversion and retention.
When: Once daily, right after the day shift takes over (after Payment Channel Management is complete).
3.3.1 Four Sub-Tasks Overview Matrix¶
| # | Name | Data source | Filter | Amount logic | TXT file name (phones) | XLSX file name (bonus template) | Final SMS text |
|---|---|---|---|---|---|---|---|
| 1 | Registered, not deposited | User Callback page · yesterday's registrants | Deposit=0 + Bets=0 + notes empty | Mon–Fri 0.2 / Sat–Sun 0.3 | MMDD+sms+platform.txt (e.g. 0108smsRPRR.txt) |
yesterday MMDD+registered-not-deposited+platform.xlsx (e.g. 0107注册未充值RPRR.xlsx) |
Not-Deposited Callback |
| 2 | Loss pull-back | Reuse sub-task 1's raw table | Has deposit + 0 bets + notes empty | — (no bonus, only SMS + loss headcount) | MMDD+kslh+platform.txt (e.g. 0108kslhRPRR.txt) |
platform-MMDD loss:XXX (headcount sheet, sent to supervisor after all platforms done) |
Loss Pull-back |
| 3 | Yesterday's depositors pull-back | User Stats page · yesterday | Formula-based; deposit-withdraw diff < 0 gets a flat 0.38; drop bonus = 0 | Team Excel formula (⚠️ from the 5th tier onward "can-double vs no-double" formulas differ; current standard is can-double — swap the formula if that changes) | MMDD+czlh+platform.txt (e.g. 0108czlhRPRR.txt) |
yesterday MMDD+czlh+platform.xlsx (e.g. 0107czlhRPRR.xlsx) |
Loss Pull-back |
| 4 | Deposited day-before-yesterday but not yesterday | User Stats page · day before yesterday | Compare against sub-task 3's "yesterday had deposit" list, remove duplicates; apply the same formula as sub-task 3; drop bonus = 0 | Same formula as sub-task 3 | MMDD+lh+platform.txt (e.g. 0108lhRPRR.txt) |
yesterday MMDD+lh+platform.xlsx (e.g. 0107lhRPRR.xlsx) |
Loss Pull-back |
📝 Source: Study & discussion
File naming rules:
- TXT (phone list) = today's date (send day) + type code + platform
- XLSX (bonus template) = yesterday's date (data source day) + type description + platform
- Type codes: sms (registered-not-deposited) / kslh (loss pull-back) / czlh (yesterday deposit pull-back) / lh (day-before deposited but not yesterday)
3.3.2 Sub-Task 1 · Registered Not Deposited¶
Back-office Marketing Tools → User Callback → filter yesterday's registrants → Export
│
▼
In the exported sheet, filter: Deposit=0 + Bets=0 + notes empty
│
├─ Copy [phone numbers] → new notepad file 0108smsRPRR.txt
│
└─ Copy [user IDs] → paste into "Import Treasure Box" Excel template
│
▼
Amount: Mon–Fri 0.2 / Sat–Sun 0.3
│
▼
Save Excel as 0107注册未充值RPRR.xlsx
│
▼
Back-office Ops Config → Activity Config → Invite Activity row → "Activity Config"
│
▼
Side nav → "Import Treasure Box Config" page
│
▼
[Unclaimed Treasure Box Count] row → "View" → "Import Treasure Box Rewards"
│
▼
Select the file 0107注册未充值RPRR.xlsx → Import complete
Shared template note: The Import Treasure Box Excel template can be downloaded once from the back-office and saved locally. For each run, clear old data and fill in new — reuse the template.
📝 Source: Study & discussion
3.3.3 Sub-Task 2 · Loss Pull-Back¶
Reuse the raw table exported in Sub-Task 1 (no need to export again), just apply a different filter.
In Sub-Task 1's raw table, re-filter:
[Has deposit] + [0 bets] + [Notes empty]
│
├─ Count loss headcount → record in a separate sheet
│ File name: platform-0108loss:XXX (XXX = count)
│ After all platforms done, consolidate and send to supervisor
│
└─ Copy [phone numbers] → new notepad file 0108kslhRPRR.txt
Difference from Sub-Task 1: Loss pull-back does not distribute bonus (no Treasure Box import); only SMS + headcount report to supervisor.
📝 Source: Study & discussion
3.3.4 Sub-Task 3 · Yesterday's Depositors Pull-Back¶
Back-office Marketing Tools → User Stats → export yesterday's member data
│
▼
Paste the "team-maintained bonus formula" (from doc/Google Sheets) into the exported sheet
⚠️ From the 5th tier onward, "can-double vs no-double" formulas differ; current standard is [can-double]
If switching to no-double, swap the formula accordingly
│
▼
Apply formula to all rows → auto-compute bonus per member
│
├─ Filter [deposit-withdraw diff < 0] → flat 0.38 bonus
│ (these are "members who won"; flat refund amount)
│
▼
Clear filters → re-filter [bonus ≠ 0] (drop bonus = 0 rows)
│
▼
Copy [user ID + amount] → paste into Import Treasure Box template
Save as 0107czlhRPRR.xlsx
│
├─ Also copy [phone numbers] → notepad file 0108czlhRPRR.txt
│
▼
Use the same "Ops Config → Activity Config → Invite Activity → Import Treasure Box"
path as 3.3.2 → select 0107czlhRPRR.xlsx → import distribution
Formula location: both "can-double" and "no-double" formulas are baked into the small tool under tools/ — review the code or run the tool directly; no need to paste formulas manually each time.
📝 Source: Study & discussion
3.3.5 Sub-Task 4 · Deposited Day-Before-Yesterday But Not Yesterday¶
Goal: Retrieve members who deposited the day before yesterday but skipped yesterday (churn-warning users). The key is "dedup" — members who deposited on both days were already included in Sub-Task 3; don't send twice. The dedup logic (compare day-before-yesterday vs yesterday lists) is also in the tools/ small tool.
Back-office Marketing Tools → User Stats → export [day-before-yesterday] member data
│
▼
Extract the list of members who deposited the day before yesterday
│
▼
Compare against Sub-Task 3's list of "members who deposited yesterday"
│
▼
Filter overlaps → [remove] duplicates
(Deposited on both days = already sent in Sub-Task 3, don't send again here)
│
▼
Remaining = deposited day-before + no deposit yesterday → target users
│
▼
Apply [same formula as Sub-Task 3] to compute bonus
│
▼
Clear filters → re-filter and drop [bonus = 0] rows
│
▼
Copy [user ID + amount] → paste into Import Treasure Box template
Save as 0107lhRPRR.xlsx
│
├─ Copy [phone numbers] → notepad file 0108lhRPRR.txt
│
▼
Use the same "Import Treasure Box" path as 3.3.2 → import distribution
📝 Source: Study & discussion
3.3.6 SMS Unified Send (After All Sub-Tasks Complete)¶
At this point, the Deputy Lead should have 4 TXT files (sms / kslh / czlh / lh), plus 3 bonus XLSX imports done (sub-tasks 1/3/4), and Sub-Task 2's loss headcount sheet sent to the supervisor.
On hand: 4 TXT + sub-task 2 loss headcount already sent to supervisor
│
▼
┌─────────────────────────────────────────────────┐
│ ① Insert test numbers │
│ Randomly mix a few verifiable test numbers │
│ into each TXT │
│ Source: ask in the CS group / handover from │
│ previous shift (sites usually have a │
│ fixed set already recorded) │
│ Position: mix with real numbers, don't cluster│
│ at the top or bottom of the file │
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ② Total up volume │
│ Sum line counts of all 4 TXT = today's total │
│ (used later for the channel quote) │
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ③ Copy pre-check │
│ Submit both templates (Not-Deposited Callback │
│ + Loss Pull-back) to the SMS channel for │
│ banned-word check → fix copy per feedback │
│ ⚠️ Banned-word list shifts; do this every run│
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ④ Channel quote + supervisor approval │
│ Volume → channel quote → submit to supervisor │
│ Only send after supervisor approves │
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ⑤ Actual send │
│ Use the TXT ↔ text mapping (see table below) │
│ Submit each TXT in the SMS platform │
└──────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ ⑥ Verify test numbers │
│ ├─ All received → channel OK, batch done │
│ └─ Some not received → contact channel now │
│ (outage / low balance / banned-word hit) │
└─────────────────────────────────────────────────┘
Number list ↔ SMS text mapping (for Step ⑤):
| Number list type | Corresponding SMS text |
|---|---|
MMDD+sms+platform (sub-task 1) |
Not-Deposited Callback |
MMDD+kslh+platform (sub-task 2) |
Loss Pull-back |
MMDD+czlh+platform (sub-task 3) |
Loss Pull-back |
MMDD+lh+platform (sub-task 4) |
Loss Pull-back |
Number-list file format: different SMS vendors have different requirements — some want
.txt, some want.xlsx. Provide per the vendor's requirement; keep naming consistent.The actual text content (including per-platform variants and leet-speak anti-filter versions) lives in 09-SMS回访文案库; do not enumerate it in this section.
About the two SMS texts: Copy is split into two main directions — "Not-Deposited Callback" and "Loss Pull-back for deposited users" — mainly to avoid sensitive content in SMS (the two scenarios need different phrasing). Exact copy gets refined from time to time based on carrier banned-word feedback and campaign changes.
📝 Source: Study & discussion
3.3.7 Shared Parameters and Back-Office Path Quick Reference¶
Import Treasure Box template hard parameters (applies to all sub-tasks using Treasure Box import):
| Parameter | Value | Notes |
|---|---|---|
| Wagering multiplier | 1x | Team-defined |
| Deposit doubling | ON | Team-defined (pairs with the "5th-tier can-double" formula) |
If parameters need to change, confirm with the supervisor first — do not self-adjust.
Back-office path quick reference:
| Action | Path |
|---|---|
| Export yesterday's registrants (sub-task 1 base data) | Marketing Tools → User Callback → select yesterday → Export |
| Export yesterday / day-before member data (sub-tasks 3/4 base data) | Marketing Tools → User Stats → select date → Export |
| Download Import Treasure Box template (first-time use) | Ops Config → Activity Config → Invite Activity → Activity Config → side nav → Import Treasure Box Config |
| Import Treasure Box reward (every bonus run) | Above Import Treasure Box Config page → [Unclaimed Treasure Box Count] row → "View" → "Import Treasure Box Rewards" |
3.3.8 What Rewards the Deputy Lead Does NOT Need to Handle¶
The following activities are auto-settled by the system — they do NOT appear in this batch suite:
| Activity | Settlement Time | Claim Window |
|---|---|---|
| VIP Upgrade Reward | Instant on meeting criteria | — |
| VIP Weekly Reward | Monday 04:00 (UTC+7) | 7-day claim window, forfeit on expiry |
| VIP Monthly Reward | 1st of month 04:00 (UTC+7) | 30-day claim window, forfeit on expiry |
| Betting Challenge | Instant on meeting bet target | Per activity config |
| Red-Packet Rain | Triggered after daily deposit, reset at 0:00 next day | Valid only for that run |
This section's "manual batch" specifically covers daily-deposit-driven Treasure Box bonus (sub-tasks 1/3/4) + loss SMS (sub-task 2).
📘 Source: 06-VIP奖励活动配置 + 07-投注闯关活动详解 + 08-红包雨活动功能
3.3.9 Automation Opportunity 🤖¶
Current state: Data-processing automation (formula application, dedup comparison, unified file naming) is already implemented in the tools/ small toolkit. SMS channels have confirmed they do NOT expose an API, so export, Treasure Box import, and SMS platform paste still require manual steps.
Further opportunity: 1. Back-office scheduled job tags qualifying members (registered-not-deposited / loss / yesterday deposited / day-before deposited not yesterday); Deputy Lead then just exports by tag — needs back-office support 2. Automated data pull: needs the back-office to open an API; currently only manual export works
SMS API integration is closed (channel-side confirmed no API) — no longer listed as a candidate.
Full opportunity inventory: 12-自动化路线图/02-自动化机会盘点.
3.4 Weekly Pull-Back (Once Weekly · Friday Prep + Saturday Send)¶
What to do: Once a week, filter for "registered within 30 days, inactive for 10+ days, with at least 2 deposits" silent members — send 0.88 bonus + SMS to win them back.
Objective: Reactivate medium-value members who have deposited before but have been offline recently.
Rhythm: - Friday: Export data → filter → prepare the bonus Excel and phone-number TXT - Saturday: Import Treasure Box to distribute 0.88, send SMS (done together with 3.3 daily batch)
3.4.1 Friday · Filter and Export¶
Back-office path: Marketing Tools → User Callback page
Filter conditions (all three apply together):
| # | Dimension | Condition | Example (processing day = Friday 4/1, day before = Thursday 3/31) |
|---|---|---|---|
| 1 | Registration time | Count back 30 days using the day before processing (Thursday) as the cutoff | Filter members registered between 3/1 00:00 – 4/1 00:00 |
| 2 | Last online time | No login for over 10 days | Last online end time before 3/22 00:00 |
| 3 | Deposit count | Exclude never-deposited + exclude only-1-deposit members | Deposit count ≥ 2 (anti-arbitrage / anti-farming) |
Export the filtered result as a spreadsheet.
3.4.2 Friday · Prepare Two Output Files¶
① Bonus Excel (for Saturday's Treasure Box import)
| Field | Value |
|---|---|
| User ID | Copy from filtered result |
| Bonus amount | 0.88 (current default; may be adjusted or the activity may be paused depending on platform operations / campaign results — follow supervisor notice) |
Save as a new spreadsheet.
② Phone-number TXT (for Saturday's SMS)
| Item | Value |
|---|---|
| Content | Phone numbers from the filtered result |
| Naming format | <site name>+zlh+<date> (zlh = weekly pull-back) |
3.4.3 Saturday · Distribution (Done Together with 3.3)¶
- Import Treasure Box: Same path as 3.3 sub-tasks 3/4 (Ops Config → Activity Config → Invite Activity → Activity Config → side nav → Import Treasure Box Config → "Unclaimed Treasure Box Count" row → "View" → "Import Treasure Box Rewards"); select Friday's prepared bonus Excel → Import
- SMS send: Submit the weekly-pull-back TXT together with 3.3's 4 TXT files to the SMS platform
📝 Source: Study & discussion
3.5 Deposit-Withdrawal Spread Inspection + Conditional Rebate (Daily 20:00)¶
Flow at a glance: At 20:00 every day, scan each platform's daily report for the spread ratio → for any platform > 10%, send the list to the supervisor first → supervisor decides whether to rebate at 0.02 → only after their approval, execute the batch rebate. Must finish by 20:40 to leave time for the 21:00 push.
Key Parameters¶
| Item | Value |
|---|---|
| Inspection time | Daily 20:00 (Indonesia time UTC+7, hard deadline) |
| Inspection path | Each platform's back-office → Report Mgmt → Daily Report → click [Query] to refresh today's data |
| User data source | Each platform back-office → Marketing Tools → User Statistics → export today's user data |
| Threshold | Single platform Dep-Wdl spread ratio > 10% (the back-office daily report's "Spread Ratio" column shows the percentage directly — no manual math) |
| "Platform" definition | One platform = one website; each distinct website counts as its own platform |
| Rebate ratio | 0.02 (fixed) |
| Rebate trigger | Only platforms > 10%, and supervisor approval required before rebating |
| Rebate operation entry | Same path as 3.3's "Import Treasure Box" (Ops Config → Activity Config → Invite Activity → Import Treasure Box Config → Import Treasure Box Rewards) |
| Treasure Box max amount | Check the rebate template's max value first; if it exceeds the current TB config → temporarily raise → after users claim, restore the original max |
| Time window | 20:00 ~ 20:40 (inspection + report supervisor + wait approval + batch rebate, all done) |
📝 Source: Study & discussion
Fundamental Difference from 3.3 Batch Suite¶
| Dimension | 3.3 Batch Suite (sub-tasks 3/4 bonus) | 3.5 Dep-Wdl Spread Rebate |
|---|---|---|
| Data scope | Yesterday / day before (historical) | T0 today |
| Trigger | None (mandatory daily) | Only spread > 10% AND supervisor-approved |
| Calculation | Tiered Dep-Wdl Spread formula | Fixed 0.02 ratio |
| Supervisor approval needed | No (execute directly) | Yes (must wait for supervisor approval) |
| Nature | Dep-Wdl Spread compensation | Conditional retention incentive |
Complete Flow¶
20:00 (Indonesia time · hard deadline · set alarm at 19:50)
│
▼
==============================
Step 1: Per-platform scan
==============================
│
▼
┌────────────────────────────────────┐
│ (1) Log into each platform's │
│ back-office │
│ Report Mgmt → Daily Report │
│ Click [Query] to refresh today │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (2) Look directly at the "Spread │
│ Ratio" column │
│ · > 10% → record the platform │
│ · ≤ 10% → skip, next platform │
│ (back-office shows the % — no │
│ manual math) │
└──────────┬─────────────────────────┘
│
▼
Repeat (1)(2) for each platform until all are scanned
│
▼
==============================
Step 2: Collect + ask supervisor
==============================
│
▼
Any platform above threshold?
│
┌────┴────┐
│ │
No Yes
│ │
▼ ▼
┌──────────┐ ┌─────────────────────────────────┐
│ Post in │ │ (3) Compile the above-threshold │
│ group: │ │ platform list and send to │
│ "20:00 │ │ supervisor — ask whether to │
│ scan │ │ rebate at 0.02 │
│ done, │ └──────────┬──────────────────────┘
│ no │ │
│ issues" │ ▼
│ │ Supervisor decision?
│ → Prep │ │
│ 21:00 │ ┌────┴────┐
│ push │ │ │
│ │ No rebate Approve
│ │ │ │
│ │ ▼ ▼
│ │ ┌──────────┐ ┌─────────────────┐
│ │ │ Skip │ │ Step 3: Batch │
│ │ │ rebate │ │ rebate │
│ │ │ Note in │ └────────┬────────┘
│ │ │ group │ │
│ │ └──────────┘ │
└──────────┘ │
▼
==========================================================
Step 3: Batch rebate (only after supervisor approval)
==========================================================
│
▼
┌────────────────────────────────────┐
│ (4a) Build the rebate Excel template│
│ · Ratio: 0.02 (fixed) │
│ · Scope: that platform's │
│ same-day users matching │
│ back-office rebate rules │
│ · Compute each user's amount │
│ │
│ ⚠️ After computing, **check │
│ the max amount** across all │
│ users in the template │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4b) Check the Treasure Box "max │
│ amount" config │
│ Rebate max > current TB max? │
│ ├─ Yes → temporarily **raise │
│ │ the TB max** to cover │
│ └─ No → straight to (4c) │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4c) Same path as 3.3 sub-tasks 3/4 │
│ Ops Config → Activity Config → │
│ Invite Activity → Activity │
│ Config → side nav → Import │
│ Treasure Box Config → │
│ "Unclaimed Treasure Box Count" │
│ row "View" → "Import Treasure │
│ Box Rewards" │
│ → Select the (4a) rebate file │
│ → Import │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4d) After users claim the boxes, │
│ **restore the original TB max**│
│ (only if you raised it in 4b) │
│ ⚠️ Don't skip this! The raised │
│ max was a temporary patch for │
│ this rebate only — leaving it │
│ raised will affect later │
│ activities' Treasure Box config│
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (5) Group post + shift sheet entry │
│ · Which platform was rebated │
│ · Ratio 0.02 │
│ · Approving supervisor's name │
│ · TB max raised? (restored?) │
└──────────┬─────────────────────────┘
│
▼
Prep 21:00 push ⑤
Business Rationale¶
At 8 PM, decide based on today's spread ratio — > 10% means users are losing more today (withdrawals far below deposits). The 0.02 (2%) platform rebate is a retention incentive: give back a little so users keep playing, trading a small payout for sustained activity and re-deposits.
📝 Source: Study & discussion
Notes:
- 20:00 is a hard Indonesia-time deadline, same timezone as Firebase pushes — no conversion needed
- Always post the scan result in the group, even when there's no breach: "20:00 scan done, no issues"
- Above threshold ≠ automatic rebate — wait for supervisor approval, do NOT decide on your own
- When multiple platforms breach at once, send a single consolidated list to the supervisor (one ask, not many pings)
- Screenshot every "report supervisor / supervisor approval" exchange
- If all platforms are ≤ 10%, skip the rebate step entirely; shift sheet records "no platform triggered"
- Rebate goes through the same "Import Treasure Box" entry as 3.3 — same path, just different template content (rebate amounts)
- ⚠️ Treasure Box max amount may need a temporary raise: if any user's amount in the rebate template exceeds the currently configured TB max, raise it before importing; after users claim, restore the original max immediately so later activities aren't affected
- Eyeball the rebate template before upload (user IDs / amounts / row count) to avoid sending the wrong money
📝 Source: Study & discussion
🤖 Automation opportunity: The scan can be scripted to auto-pull every platform's daily-report "Spread Ratio" column, auto-compile the above-threshold list and @ both Deputy Lead and supervisor in the shift group — Deputy Lead just forwards the ask. Rebate template generation can share the same toolchain as 3.3 sub-tasks 3/4 (tools/ already implements the formula application). The "raise then restore" Treasure Box max action should have an automated reminder so the restore step is never skipped.
3.6 Payment Collection & Disbursement Channel Management (First Task of Day Shift)¶
Priority: The very first task after day shift starts, before SMS callback and commission distribution.
Core objective: Ensure third-party payment channel funds are sufficient, configurations are correct, and success rates meet standards, to guarantee smooth user deposits and withdrawals.
Key Parameters¶
| Item | Value |
|---|---|
| Execution time | Immediately after day shift starts (10:00) + hourly inspection throughout the day |
| Merchant roles | CP/ATM Collection/Disbursement roles are dynamically assigned, NOT fixed |
| Balance reference | Channel balance ≥ 20 million IDR preferred (below this, lower the weight) |
| Core principle | Merchants that collect more also disburse more ("what comes in goes out") |
| Channel order | Collection order = Disbursement order (keep consistent — core rule) |
| Success rate monitoring | Audit Team checks hourly → reports to supervisor → supervisor decides |
Why are CP/ATM roles dynamically assigned?
The same third-party merchant can act as both a collector (receiving user deposits) AND a disburser (paying user withdrawals). Which merchant collects more / disburses more in a given shift is NOT fixed — it's dynamically adjusted based on real-time success rate and balance.
Core principle: merchants that collect more should also disburse more. Rationale:
- ✅ Money collected is quickly paid out via disbursement → smooth fund turnover
- ✅ Avoid single-merchant balance pile-up (collect-only → merchant account piles up unused funds, tying up our quota)
- ✅ Avoid single-merchant balance depletion (disburse-only → balance drains fast, cannot handle large withdrawals)
- ✅ Collection and disbursement orders generally stay aligned → same merchant in the same position on both sides, natural in/out balance
So each inspection requires re-evaluation — not "this merchant is permanently the collector" but "whoever collects more this hour, also disburses more this hour".
📝 Source: Study & discussion
Complete Flow¶
Day shift starts (10:00 · first task)
│
▼
==============================
Step 1: Check Channel Balances
==============================
│
▼
┌────────────────────────────────────┐
│ (1) Query balance via bot commands │
│ in each channel's Telegram │
│ group │
│ Check CP/ATM channel balances │
│ Record each channel's current │
│ balance │
└──────────┬─────────────────────────┘
│
▼
Balance >= 20 million IDR?
│
┌────┴────┐
│ │
Yes No
│ │
▼ ▼
┌──────────┐ ┌─────────────────────────────┐
│ Normal │ │ Flag low-balance channels │
│ → Proceed│ │ → Notify supervisor to top up│
│ to Step 2│ │ → Temporarily adjust │
│ │ │ disbursement weight │
│ │ │ to avoid this channel │
└──────────┘ └──────────┬──────────────────┘
│
▼
==============================
Step 2: Configure Disbursement Strategy
==============================
│
▼
┌────────────────────────────────────┐
│ (2) Review each channel's │
│ collection volume │
│ Confirm which channel │
│ collects the most │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (3) Adjust disbursement config │
│ Principle: Channels with more │
│ collections get priority for │
│ disbursement │
│ Avoid draining a single │
│ channel's funds │
└──────────┬─────────────────────────┘
│
▼
==============================
Step 3: Verify Channel Order
==============================
│
▼
┌────────────────────────────────────┐
│ (4) Compare collection/disbursement│
│ channel configuration order │
│ Both should be roughly aligned │
│ If misaligned → adjust │
└──────────┬─────────────────────────┘
│
▼
==============================
Step 4: Execute Supervisor-Directed Changes (if any)
==============================
│
▼
┌────────────────────────────────────┐
│ (5) Check for supervisor-notified │
│ channel changes │
│ · Enable/disable a channel │
│ · Adjust channel weights │
│ Execute config per instructions│
└──────────┬─────────────────────────┘
│
▼
┌──────────────────┐
│ Done → Proceed to│
│ SMS Callback / │
│ Commission │
└──────────────────┘
─────────────────────────────────────
Continuous Monitoring (throughout the day)
─────────────────────────────────────
┌────────────────────────────────────┐
│ Audit Team checks third-party │
│ channel success rates hourly │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ Reports to supervisor │
└──────────┬─────────────────────────┘
│
▼
Success rate anomaly?
│
┌────┴────┐
│ │
No Yes
│ │
▼ ▼
┌──────────┐ ┌─────────────────────────────┐
│ Continue │ │ Supervisor decides whether │
│ monitoring│ │ to switch channels │
│ │ │ │ │
│ │ │ ▼ │
│ │ │ Notify Deputy Lead / team │
│ │ │ to execute switch │
│ │ │ │ │
│ │ │ ▼ │
│ │ │ Execute channel on/off / │
│ │ │ weight adjustment │
│ │ │ → Confirm effective │
│ │ │ → Post in group │
└──────────┘ └─────────────────────────────┘
Notes:
- This is the highest priority task for day shift — complete before SMS callback and commission distribution
- Channels with balance below 20 million IDR are not disabled — instead, lower their weight so they're queued after higher-balance channels for disbursement. Always prefer channels with larger balances first.
- Channel on/off and weight adjustments must follow supervisor instructions — do not decide independently
- Success rate monitoring is the Audit Team's responsibility; Deputy Lead executes the switching action
- All channel change operations must be screenshot-archived and reported in the group
- Third-party disbursement bank maintenance notices: Third-party disbursement providers sometimes notify that bank disbursement services are temporarily suspended due to Indonesian bank system maintenance or network issues. Upon receiving such notice, temporarily disable the bank disbursement type in the back-office disbursement channels; re-enable once the provider confirms service is restored
📝 Source: Study & discussion
🤖 Automation opportunity: Channel balance queries and success rate monitoring can be built into an automated dashboard that auto-pulls each channel's balance and success rate hourly, with alerts pushed to the group when below threshold. Channel order consistency checks can also be scripted — compare collection/disbursement configs and auto-alert on mismatches.
Sub-Task · Hourly Collection Merchant Balance Inspection¶
Purpose: Ensure disbursement channels always have enough balance to process user withdrawals, preventing balance depletion that would cause withdrawal failures. This is a recurring guard task running throughout the day AFTER the initial 3.6 configuration at shift start.
Why hourly?
- Disbursement balance is consumed in real time (every user withdrawal draws it down), not static
- If the #1-ranked disbursement merchant runs dry, subsequent withdrawals pile up on that single merchant → user complaints, success rate collapses
- Swapping the top slot to "a merchant with higher balance" distributes pressure across all disbursement merchants
- 1-hour cadence is empirical: fast enough to catch problems (no single merchant gets fully drained), not so fast that the Deputy Lead drowns in pointless checks
Hourly Inspection Flow:
Every hour (on the hour, or 5 min before)
│
▼
┌────────────────────────────────────┐
│ (1) Query disbursement balance in │
│ each merchant's Telegram group │
│ via bot command │
│ Record top-3 merchants' balance│
└──────────┬─────────────────────────┘
│
▼
Top-ranked disbursement merchant balance too low?
│
┌────┴────┐
│ │
No Yes
│ │
▼ ▼
┌──────────┐ ┌────────────────────────────────────┐
│ Keep │ │ (2) Adjust collection/disbursement │
│ original │ │ channel order │
│ config, │ │ · Move high-balance merchant │
│ keep │ │ to the front │
│ watching │ │ · Align collection order │
│ │ │ (keep collection = disburse) │
│ │ │ ← core rule │
│ │ └──────────┬─────────────────────────┘
│ │ │
│ │ ▼
│ │ ┌────────────────────────────────────┐
│ │ │ (3) This is a TEMP adjustment → │
│ │ │ set a reminder to revisit │
│ │ │ · Re-inspect in 1-2 hours │
│ │ │ · Adjust back / keep per data │
│ │ │ · Brief note in shift group │
│ │ └──────────┬─────────────────────────┘
│ │ │
│ │ ▼
│ │ Large withdrawal incoming +
│ │ disbursement balance not enough?
│ │ │
│ │ ┌────┴────┐
│ │ │ │
│ │ No Yes
│ │ │ │
│ │ ▼ ▼
│ │ ┌──────────┐ ┌────────────────────────────┐
│ │ │ Continue │ │ (4) NOTIFY TEAM LEAD │
│ │ │ under │ │ immediately to coordinate│
│ │ │ adjusted │ │ · May need emergency │
│ │ │ config │ │ top-up │
│ │ │ │ │ · Or emergency backup │
│ │ │ │ │ merchant activation │
│ │ │ │ │ · Or negotiate merchant │
│ │ │ │ │ advance │
│ │ │ │ │ Deputy Lead does NOT │
│ │ │ │ │ decide alone │
│ │ └──────────┘ └────────────────────────────┘
└──────────┘
│
▼
Log this hour's inspection → wait for next hour
Key Points:
- Core rule: Collection order = Disbursement order (consistent with 3.6 principle — don't break it via temp adjustment)
- Temp adjustments need "revert" action: Whenever you temporarily demote/promote a merchant, set a reminder (phone calendar / Telegram bot) to re-evaluate
- Large withdrawal + insufficient balance = escalation: Deputy Lead does NOT decide alone — notify team lead immediately. This touches fund replenishment / merchant negotiation, outside Deputy Lead's authority
- Log inspections: Brief post in shift group each hour ("XX:00 inspection: rank #1 ATM-A balance XX, normal") — useful for handover and review
- Inspection + shift-start config = continuous pipeline: 10:00 initial config doubles as the first inspection's baseline; then 11:00 / 12:00 / ... roll on the hour
📝 Source: Study & discussion
🤖 Automation opportunity: Hourly inspection can become a scheduled Telegram bot task — auto-query each merchant's balance on the hour, auto-detect if rank-1 is below threshold, auto-@Deputy Lead in the shift group with a suggested adjustment ("switch top slot to merchant XX"), Deputy Lead only needs to confirm execution.
Sub-Task · Peak-Hour Best Deposit Channel On/Off (New Users Only)¶
Goal: During Indonesian peak hours, cost is NOT the priority (slightly higher fees are acceptable) — enable whichever channel currently offers the best deposit experience for new users, trading higher cost for new-user retention during peak hours.
Key parameters:
| Item | Value |
|---|---|
| Open time | Around Indonesia 19:00 ⚠️ Exact time TBC with supervisor / colleagues |
| Close time | Around 03:00 dawn ⚠️ Exact time TBC with supervisor / colleagues |
| Audience | New users only (restrict via group permissions / channel visibility — don't let regular users get routed through this higher-fee channel) |
| Channel choice | Whichever channel currently provides the best deposit experience — the specific channel depends on this site's actual configuration and may change as the platform adjusts |
| Frequency | Once daily (open in the evening, close before dawn) |
Operations:
Before peak hour (~Indonesia 19:00 ± TBC)
│
▼
┌────────────────────────────────────┐
│ (1) Back-office → Pay-in channel │
│ config → find the current best │
│ deposit channel used for new │
│ users during peak hours │
│ (follows per-site config) │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (2) Enable the channel │
│ Permission: visible / usable │
│ to NEW users only │
│ (don't let regular users use │
│ it — cost will balloon) │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (3) Brief post in shift group: │
│ "HH:MM enabled <channel name> │
│ (new users only)" │
└──────────┬─────────────────────────┘
│
▼
Peak hour runs
(~19:00 to ~03:00 TBC)
│
▼
Peak hour ends (~03:00 ± TBC)
│
▼
┌────────────────────────────────────┐
│ (4) Disable the peak-hour channel │
│ Brief post: "HH:MM disabled │
│ <channel name>" │
└────────────────────────────────────┘
Notes: - Do NOT keep it on 24h: fee is higher than standard channels — running it all day blows up cost - New users only: when enabling, double-check permission / group config; regular users must stay on the standard channel - Specific channel is not fixed: which channel is currently "optimal" varies with platform configuration. At handover, always confirm which channel is being used for peak hours; different sites may configure differently — don't copy names from another site - Time window TBC: the 19:00 / 03:00 above are current best-guess values — confirm exact open/close times with the supervisor before going live, then update this section with the confirmed values - Leave a trail: screenshot the config before/after + post timestamps in the shift group - If anomalies: if the channel's success rate drops during peak, sync with the supervisor immediately — temporary close or switching to a backup channel may be needed
📝 Source: Study & discussion
🤖 Automation opportunity: If the open/close times are fixed, a Telegram bot scheduled task can auto-enable at 19:00 + auto-disable at 03:00, with the Deputy Lead only receiving notifications. The permission layer ("new users only") + dynamic channel-name config needs back-office support for "open a specific channel by user group".
IV. Reactive Task Workflows (B-Line · Handle on Arrival)¶
B-Line characteristics: No fixed schedule; triggered by messages in CS group, risk control group, or finance group. Handle immediately upon receipt, following the universal "Claim → Execute → Reply → Report" four-step framework.
4.1 Withdrawal Order Review (Highest Risk, Most Complex Decisions)¶
Withdrawal review is the highest-risk, most decision-branching task in the Deputy Lead's daily work. A single misjudgment can result in real financial loss, or let a fraudulent user slip through.
4.1.1 Universal Pre-Steps¶
Receive withdrawal order notification
│
▼
┌───────────────────────────────┐
│ First action: [Lock Order] │ ← Prevent other colleagues
│ (Click "Lock" in back-office) │ from duplicate processing
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────┐
│ Read the order [Notes] field │
└────────┬──────────────────────┘
│
▼
┌───────────────────────────────┐
│ Determine order type │
│ ├─ Notes contain "Agent │ → Go to 4.1.5 Agent Withdrawal
│ │ Withdrawal" │ flow
│ └─ Other → Regular user │ → Go to 4.1.4 Regular User flow
└───────────────────────────────┘
4.1.2 Auto-Payout Four-Layer Switch (Background Knowledge)¶
The system has four layers of switches; all must be ON for auto-payout. If any layer fails, the order is routed to manual review:
┌─────────────────────────────────────────────┐
│ Auto-Payout Four-Layer Switch │
│ │
│ Layer 1: Site master switch ON │
│ │ │
│ ▼ │
│ Layer 2: Third-party disbursement │
│ channel ON │
│ │ │
│ ▼ │
│ Layer 3: Member's tier allows auto-payout │
│ │ │
│ ▼ │
│ Layer 4: Member's individual switch ON │
│ │ │
│ ▼ │
│ All passed → Auto-payout │
│ │
│ Any layer fails → Routed to manual review │
└─────────────────────────────────────────────┘
Forced manual review (regardless of four-layer switches): exceeds auto-payout limit, insufficient first-deposit turnover, contains agent bonus, withdrawal interval too short.
📘 Source: 01-自动出款功能详解
4.1.3 Withdrawal Order Notes Handling Manual (8 Rules)¶
Notes Overview Table¶
| # | Notes Content | Action Summary | Detailed Flow |
|---|---|---|---|
| 1 | Agent Withdrawal | Subordinate behavior pattern detection + account review + P1/P2 penalty | Go to 4.1.5 Agent Withdrawal review flow |
| 2 | User tier does not allow auto-payout | Arbitrage Observation / Confirmed Arbitrage tier users; focus on bonus type + bet pattern + multiples; full investigation flow. Also Secondary Verification / Data tier; verify old vs new WD account | See Note 2 details below |
| 3 | Auto-payout failed | Query actual order status, handle by status | See Note 3 details below + Order Status Table |
| 4 | Exceeds max auto-payout amount | Back-office threshold = 5000; route to manual review (game cheating / bonus abuse / genuine customer check) | See Note 4 details below |
| 5 | 4 withdrawals within 2 minutes | First warning by balance; if game-bug arbitrage → emergency-close auto-payout | See Note 5 details below |
| 6 | Insufficient first-withdrawal turnover | Rule currently OFF, approve directly | See Note 6 details below |
| 7 | Payout channel amount limit | Usually "no channel available" — all merchants fail the cycle; check with merchant whether it's maintenance/fluctuation or unsupported, then have member switch wallets or act on merchant feedback | See Note 7 details below |
| 8 | Disbursement failed | Manual payout also triggers; query status + confirm with third party (similar to Note 3) | See Note 8 details below |
📝 Source: Study & discussion
Note 1: Agent Withdrawal¶
Trigger: The user has claimed any of invitation reward / Pinduoduo reward / Treasure Box bonus, and the first withdrawal after claiming auto-tags as "Agent Withdrawal".
Review goal: Decide whether the agent is a real agent (genuine subordinates + normal gameplay) or an arbitrage agent (sock-puppet accounts farming bonuses).
Handling: Go to 4.1.5 Agent Withdrawal review flow (subordinate behavior pattern detection + P1/P2 penalty).
📝 Source: Study & discussion
Note 2: User Tier Does Not Allow Auto-Payout¶
Trigger: The user's current tier is configured in the back-office as "auto-payout not allowed" — typical tiers include: - "Arbitrage Observation Tier" (previously suspected of arbitrage) or "Confirmed Arbitrage" (already judged as arbitrage) - "Secondary Verification / Data" Tier (password-reset security verification, see 5.2.3)
Review focus (varies by tier type):
Arbitrage Observation Tier: - Which bonus type the user claimed (invitation / Pinduoduo / Treasure Box / other) - Betting pattern (focused on low-risk / high-rebate plays?) - Bet multiples (just barely meeting the turnover before withdrawing?)
Secondary Verification / Data Tier: - Check remarks — whether it says "WD requires secondary confirmation, verify if old withdrawal details" - Verify withdrawal account — is it the old WD account or a new WD account? - Old account → Delete remarks + approve payout + remove from tier - New account → Reject + disable withdrawal + require screen recording verification (see 5.2.3)
Receive Note 2 order
│
▼
Review per 4.1.5 four criteria
│
▼
Account change record investigation
│
├─ Filter deposit records, check amounts and time distribution
│
▼
Bet record investigation
│
├─ Check if betting behavior is normal
│ (time intervals, amounts, game types)
│
▼
Comprehensive judgment
│
├─ Normal member → Approve, release payment
└─ Arbitrage/abnormal behavior detected →
Handle per investigation results (reject/escalate/freeze)
📝 Source: Study & discussion
Note 3: Auto-Payout Failed¶
Receive Note 3 order
│
▼
Take order number to query actual order status
│
▼
Based on returned status, check [Actual Order Status Table]
│
├─ Invalid account/format error → ⚠️ Run Smart Account Error Check first (see below), do NOT mark invalid directly
├─ Account status abnormal → Confirm with third-party first, handle based on actual situation
├─ Risk control blocked → Confirm with third-party: user account issue → mark invalid; channel issue → handle accordingly
├─ Amount exceeded → Confirm with third-party: not user-related → reject for resubmission; user limit → follow Limit Optimization Flow (see below)
├─ System/network failure → ⚠️ Check history first (see Anti-Loop Rejection Mechanism below)
├─ Account info validation error → Confirm with third-party: user issue → mark invalid; other → handle accordingly
└─ Transaction limit → Follow Limit Optimization Flow (see below); other → handle accordingly
⚠️ Anti-Loop Rejection Mechanism (applies to status 5/6/8/9 — system/network failures)
Problem: The failure reason returned by the third-party order-query API is not always accurate, and the explanation from third-party customer service may not reflect the real status either. If you simply keep rejecting and asking the user to resubmit, the user may get stuck in a "withdraw → fail → reject → resubmit → fail again" loop, severely hurting the experience.
Procedure: Before rejecting, check the user's withdrawal history for the day:
About to reject (system/network failure) │ ▼ Check withdrawal records: has this user had other orders rejected today? │ ┌───┴───┐ │ │ No Yes (first) (repeated failure) │ │ ▼ ▼ Normal Check: are the repeated withdrawals using the same wallet/bank account? reject, │ ask to ┌───┴───┐ resubmit │ │ Different Same account rejected multiple times accounts │ │ ▼ ▼ Confirm with third-party staff the specific issue: Normal · Is it a user account info error? reject, · Is it an account limit? ask to · Is it a temporary channel outage? resubmit · Or something else? │ ▼ Handle based on confirmed cause: · Account issue → disable withdrawal + notify CS, ask user to contact CS to change wallet/bank · Channel issue → switch channel, manual payout · Cannot confirm → suspend withdrawal permission + notify CS, ask user to change payout methodCore principle: Same user, same account, rejected 2+ times in the same day → cannot simply reject again; must investigate the cause before taking action.
⚠️ Smart Account Error Check (for status 1/3/7 — "account invalid / account error / info mismatch" failures)
Problem: Third-party returning "recipient info error" doesn't always mean the user's account is actually wrong — especially during batch failures across platforms, it's likely channel fluctuation.
Flow:
Third-party returns "account invalid / account error / info mismatch" │ ▼ Has user successfully withdrawn to this account before? │ ┌───┴───────────────────────┐ │ │ Yes (has success record) No (first time using this account) │ │ ▼ ▼ Likely channel issue Go to user detail page (previously worked, now Check bound wallet/bank card info error = unlikely account │ problem, could be cross- ▼ bank maintenance / What is the withdrawal method? 3rd-party API fluctuation / │ bank card limit etc.) ┌─────┴─────────┐ → Reject for resubmission │ │ Wallet Bank card │ │ ▼ ▼ Phone # vs Is bank card account match? info reasonable? │ (card number ┌───┴───┐ digits/format │ │ normal?) Differs Identical │ by 1-2 or completely ┌───┴───┐ digits different │ │ (likely │ Format Format typo) │ abnormal normal │ ▼ │ │ ▼ Likely ▼ ▼ Mark channel Mark Likely invalid issue invalid channel flow → Reject flow issue for re- → Reject submission for re- submissionAuxiliary signals: - Batch failures across multiple platforms at the same time = almost certainly channel fluctuation - First-time withdrawal user = check binding info carefully, don't mark invalid directly (affects retention) - Previously successful same account = almost certainly channel fluctuation (cross-bank maintenance / 3rd-party API fluctuation / bank card limit etc.), not account info error - Bank card withdrawal returning "account info error" → 3rd-party error reasons are often inaccurate; actual cause may be cross-bank transaction maintenance, bank card limit, or temporary channel failure — do not simply process based on the "account info error" message - Core principle: Do not simply act on the 3rd-party error reason; look at the user's account and historical withdrawal records to make a comprehensive judgment, minimizing withdrawal friction for users
⚠️ Limit Optimization Flow: Different banks and wallets have different daily/monthly limits, and whether the user has completed KYC also affects the limit. When handling limit issues, first check how many withdrawal methods the user has bound before deciding the approach:
Confirmed as limit issue │ ▼ Check number of withdrawal methods bound to user account │ ┌───┴───┐ │ │ Multiple Only one (≥2 bank card/ bank wallet cards/ wallets) │ │ ▼ ▼ Do NOT Follow original flow: disable Disable withdrawal withdrawal permission Just + Add limit date note reject (e.g. DANA LIMIT 4/25) the order + Reject order with note: + Notify CS group "Current Ask user to contact CS XX limit reached, please switch to another method"Core logic: Users with multiple withdrawal methods bound usually understand limits — just tell them to switch to another method and resubmit, no need to disable permissions, no need to contact CS, no need to wait for us to re-enable — eliminates 3 steps, improves user experience. Only users with a single withdrawal method need the full flow of disabling permissions + contacting CS.
⚠️ Banks not supported by the disbursement system: The following banks are not supported by the disbursement system. The system will display "auto-disbursement failed" directly (without mentioning the third party): - BANK JAGO SYARIAH - BANK JAGO UUS - BANK ALADIN SYARIAH - SUPERBANK - BANK MANDIRI TASPEN
📝 Source: Study & discussion
Actual Order Status Table (used for Note 3 — look up status after querying the order):
| # | Order Status | Cause | Backend Operation | Core Principle |
|---|---|---|---|---|
| 1 | Invalid account / Incorrect payee format / Payee account validation error | Account doesn't exist / format error / account-channel mismatch | ⚠️ Run Smart Account Error Check first: previously successful → channel fluctuation, reject for resubmission; first time → check binding info; confirmed user issue → mark invalid + reject | Smart judgment |
| 2 | Payee account status abnormal | Account frozen / not activated / closed | Confirm with third-party first, handle based on actual situation | Must confirm with third-party channel first |
| 3 | Account error or risk control | Account flagged by risk control | Confirm with third-party: user account issue → mark invalid; channel issue → handle accordingly | Must confirm with third-party channel first |
| 4 | Amount exceeded / Daily limit / Monthly limit | Exceeds bank or account limit | Confirm with third-party: not user-related → reject for resubmission; user limit → follow Limit Optimization Flow (multiple withdrawal methods → reject with note to switch method; single withdrawal method → disable permission + notify CS) | Limit optimization |
| 5 | System busy / System error / Request timeout | System processing congestion or fluctuation / may also be user's withdrawal account/wallet issue | ⚠️ Run anti-loop rejection check first (check today's history); first time → reject for resubmission; same account repeated failure → confirm real cause with third party | Anti-loop rejection |
| 6 | Request failed / Transaction failed | — | ⚠️ Run anti-loop rejection check first; first time → reject for resubmission; repeated failure → investigate cause | Anti-loop rejection |
| 7 | Payee account info validation error | Account info doesn't match bank/wallet validation rules (name, account mismatch) | Confirm with third-party: user issue → mark invalid; other → handle accordingly | Must confirm with third-party channel first |
| 8 | Network error | Network fluctuation | ⚠️ Run anti-loop rejection check first; first time → reject for resubmission; repeated failure → investigate cause | Anti-loop rejection |
| 9 | Requests too frequent | — | ⚠️ Run anti-loop rejection check first; first time → reject for resubmission; repeated failure → investigate cause | Anti-loop rejection |
| 10 | Transaction limit | Amount exceeds limit | Follow Limit Optimization Flow: multiple withdrawal methods → reject with note to switch method; single withdrawal method → disable withdrawal permission + add limit date note + notify CS; other → handle accordingly | Limit optimization |
Core handling principles summary: - Status 1 (invalid account): ⚠️ Do NOT mark invalid directly — run Smart Account Error Check first (previously successful same account → channel fluctuation; first time → check binding info) - Status 5/6/8/9 (system/network errors): First time → reject for resubmission; same account repeated failure in the same day → must investigate cause before taking action (see Anti-Loop Rejection Mechanism) - Status 2/3/4/7/10 (need confirmation): Must confirm with third-party channel first before taking action
⚠️ The failure reason from the third-party order-query API is not always accurate, and the third-party CS response may not reflect the real status either. When encountering repeated failures, do not blindly trust the API return value — use comprehensive judgment.
📝 Source: Study & discussion
Notify CS Group After Reject (when asking user to resubmit)¶
Underlying logic: When we reject a withdrawal order and ask the user to resubmit, we must post the rejection to the CS group. This way, when CS later receives a customer inquiry and looks up the user ID, they immediately know why it was rejected and can respond efficiently and accurately, without coming back to the Deputy Supervisor for re-confirmation.
Applicable scenarios (any rejection that asks the user to resubmit must be posted): - Status 4 amount exceeds limit → reject and let user resubmit - Status 5/6/8/9 system/network first-time failure → reject and let user resubmit - Status 10 transaction limit (multi-payout method) → reject and switch method - Channel fluctuation confirmed not user-side → reject and let user resubmit
Standard group message format:
Platform: [platform name]
User ID: [member account]
Reject reason: [brief explanation, with "please ask user to resubmit withdrawal order"]
Examples:
Platform: 7777W
User ID: 6281234567890
Reject reason: Amount exceeds limit (third-party confirmed not user-account issue), please resubmit withdrawal order
Platform: RP55
User ID: 6289876543210
Reject reason: Network fluctuation caused payout failure (first time), please resubmit withdrawal order
⚠️ Cases NOT to post to CS group: The following are final rejections (not asking user to resubmit) — handle per existing remark workflow, no need to post to CS group: - Account invalid (Status 1, confirmed user-side issue) → close permission and run account-error flow - Arbitrage violations (BH BAT / BH RK) → run P1/P2 remark flow, post to corresponding audit group - Single payout method with account limit (Status 10 single-method) → close permission + notify CS for limit-optimization flow
📌 CS-side counterpart action: Once CS receives the rejection notice, they file it into their follow-up list. When the user comes asking "why did my withdrawal fail/get rejected", CS replies directly per the rejection reason: "please resubmit the withdrawal order". For unclear cases, @ Deputy Supervisor for confirmation.
📝 Source: Study & discussion
Note 4: Exceeds Max Auto-Payout Amount¶
Trigger: The back-office currently sets the max auto-payout amount = 5000; anything above auto-routes to manual review.
Review purpose: Route to manual to check whether the user's behavior includes game cheating / bonus abuse / whether it is a genuine customer.
Receive Note 4 order
│
▼
Fund account change investigation
│
├─ Filter deposit records: check today's deposit amounts
│ and time distribution
│ (Large deposits in short time? Abnormal amounts?)
│
▼
Bet record investigation
│
├─ Check time intervals between multiple bets
│ (Bot-like dense betting?)
│
▼
Platform P&L investigation
│
├─ Filter loss records, check bet amounts and win amounts
│ Within normal range?
│ │
│ ├─ Uncertain → Check the game rules on frontend/App,
│ │ compare win probability and payout ratio
│ │
│ └─ Clearly abnormal → Handle per investigation results
│
▼
Comprehensive judgment
│
├─ Confirmed normal user → Approve, manually release payment
└─ Abnormal behavior detected → Handle per results
(reject/escalate/freeze)
📝 Source: Study & discussion
Note 5: 4 Withdrawals Within 2 Minutes¶
Two business rationales (understand these before you know why to block):
- Reduce transaction fees: Splitting one withdrawal into multiple smaller ones incurs multiple fees — prompt the user to withdraw all at once (saves cost for both the platform and the user)
- Block game-bug arbitrage: When a game has a bug (e.g., "loss doesn't deduct principal" letting the user profit infinitely), a single large withdrawal triggers manual review and gets blocked — the user then tries many small withdrawals to bypass the large-withdrawal block. This mechanism catches exactly that low-amount-high-frequency pattern
⚠️ If identified as game-bug arbitrage: this mechanism can also catch it and emergency-close auto-payout.
Receive Note 5 order
│
▼
First time triggering high-frequency withdrawal alert?
│
├─ No (repeat) → Escalate handling per actual situation
│
└─ Yes (first time)
│
▼
Check user's last withdrawal account balance
│
├─ Has balance → Reject this withdrawal
│ Note: "Please withdraw full balance
│ in one transaction"
│
└─ No balance → Approve directly, release payment
(If identified as bug arbitrage → this mechanism can also
catch it and emergency-close auto-payout)
📝 Source: Study & discussion
Note 6: Insufficient First-Withdrawal Turnover¶
Trigger: The back-office originally set "first-withdrawal wagering below 1.5x" to auto-route to manual review.
Original rationale: Users who farmed bonuses on first deposit then withdrew with low wagering needed a human look.
Current status: this rule has been turned OFF. Reason: many new users deposit first then do a small trial withdrawal to test the site's reliability (can I actually withdraw?) — blocking this would kill the first-deposit experience and churn new users.
Current handling: Approve directly, allow withdrawal.
General rule: in other cases, members who have not met the wagering requirement simply cannot initiate a withdrawal — the front-end blocks it outright, so no Deputy Lead judgment is needed. Note 6 is a legacy-platform fallback; new platforms rarely trigger it.
📝 Source: Study & discussion
Note 7: Payout Channel Amount Limit¶
Why this happens: This note usually appears because no channel is available — the system cycles through all merchants, and if a channel (e.g. DANA) is under maintenance or experiencing fluctuations, most likely every merchant fails the cycle and the system categorizes the order as "payout channel amount limit". Note: Different merchants may support the same wallet differently — for example, DANA is configured internally by some merchants but not others.
Handling: 1. Check with the merchant: is the channel under maintenance / fluctuating, or completely unsupported? 2. Act on the merchant's feedback: - Temporary maintenance / fluctuation → let the member wait, or switch to another wallet - Merchant does not support the channel → have the member switch to another available wallet / bank card - Merchant reports anomaly → handle per their specific feedback
📝 Source: Study & discussion
Note 8: Disbursement Failed¶
Trigger: When the Deputy Lead manually uses a payout channel to release the withdrawal and the payout fails, the system auto-tags as "Disbursement Failed".
Common failure causes (similar to Note 3 "Auto-payout failed"): - Merchant API fluctuation - User's wallet info is incorrect - Limits, etc.
Handling:
Still need to query order feedback from the corresponding merchant, then handle per the feedback.
📝 Source: Study & discussion
Key Amount/Duration Hard Rules Quick Reference:
| Hard Rule | Value | Applicable Scenario |
|---|---|---|
| E-wallet monthly limit (Dana/Ovo/Linkaja/Gopay/ShopeePay) | Confirm with third-party channel (not fixed) | Note 3 |
| Payout channel per-transaction limit | Confirm with third-party channel (not fixed) | Note 7 |
| Max auto-payout amount | 5000 (unit per back-office config) | Note 4 |
| High-frequency withdrawal threshold | 4 times within 2 minutes | Note 5 |
| High-frequency first offense (has balance) | Reject, require one-time full withdrawal | Note 5 |
| High-frequency first offense (no balance) | Approve directly | Note 5 |
| First-withdrawal low-turnover threshold (OFF) | 1.5x wagering routes to manual (currently disabled) | Note 6 |
📝 Source: Study & discussion
🤖 Automation opportunity: Among the 8 note rules, Note 6 (approve directly) can be auto-handled by script. Notes 2 and 4 require full investigation flow, suitable for semi-automation (bot auto-pulls account changes/bet data, human makes final judgment). Full rule engine design at 12-自动化路线图/.
4.1.4 Regular User Withdrawal Decision Tree¶
Regular user withdrawal (notes != "Agent Withdrawal")
│
▼
Read order [Notes] field
│
├─ Note 2: "User tier does not allow auto-payout"
│ │
│ ▼
│ Full investigation flow
│ │
│ ├─ 1. Review per 4.1.5 criteria
│ ├─ 2. Account changes: Are deposit amounts/timing normal?
│ └─ 3. Bet records: Normal betting behavior?
│ │
│ ├─ Normal → Approve, release payment
│ └─ Abnormal → Handle per investigation results
│
├─ Note 3: "Auto-payout failed"
│ │
│ ▼
│ Query actual order status (by order number)
│ │
│ └─ Cross-reference [Actual Order Status Table]
│ ├─ Account/format issue → Verify or retry
│ ├─ Account frozen/closed → Switch account or contact user
│ ├─ Risk control blocked → Switch account/reduce freq/amount
│ ├─ Amount exceeded → Split/switch account/KYC upgrade
│ ├─ System/network issue → Retry after delay
│ └─ Transaction failed → Retry or switch payment method
│
├─ Note 4: "Exceeds max auto-payout amount"
│ │
│ ▼
│ Full investigation flow (stricter than Note 2)
│ │
│ ├─ 1. Fund changes: Today's deposit amounts & timing
│ ├─ 2. Bet records: Are time intervals between bets normal?
│ └─ 3. Platform P&L: Bet/win amounts within normal range?
│ │
│ ├─ Confirmed normal → Approve, manually release
│ └─ Abnormal detected → Handle per investigation results
│
├─ Note 5: "4 withdrawals within 2 minutes"
│ │
│ ▼
│ First time triggered?
│ │
│ ├─ First → Check last withdrawal account balance
│ │ │
│ │ ├─ Has balance → Reject, note "withdraw all at once"
│ │ └─ No balance → Approve directly
│ │
│ └─ Repeat → Escalate per actual situation
│
├─ Note 6: "Insufficient first-withdrawal turnover"
│ └─ Approve directly, allow withdrawal
│
├─ Note 7: "Payout channel amount limit"
│ └─ Usually triggered by "no channel available" — the system
│ cycles through all merchants and all fail (e.g. DANA is
│ under maintenance / fluctuating). Check with merchant:
│ maintenance/fluctuation, or unsupported channel?
│ Maintenance → let member wait or switch wallet.
│ Unsupported → have member use another wallet/bank card.
│
├─ Note 8: "Disbursement failed"
│ └─ First query the order status, then confirm the
│ specific failure cause with the third party, and
│ handle based on the cause.
│
└─ Other notes → Refer to notes handling manual, escalate if needed
Key principles: 1. Notes 2 and 4 cannot be approved directly — must complete full investigation (account changes + bets), confirm normal user before approving. 2. Note 3: query actual status first — don't guess the cause from the note alone; query the actual order status by order number, then handle accordingly. 3. Note 8: reject directly — the back-office has already tried all channels; switching again won't help. Ask user to resubmit. But also watch for anti-loop rejection — if the same user and same account has been rejected 2+ times in the same day, investigate the cause. 4. Limit-related rules have no fixed numbers — e-wallet limits and payout channel caps must be confirmed with the respective third-party channel. When handling limits, follow the Limit Optimization Flow: multiple withdrawal methods → reject with note to switch method; single withdrawal method → disable permission + notify CS.
📝 Source: Study & discussion
4.1.5 Agent Withdrawal Review Flow¶
How the "Agent Withdrawal" note is triggered: Once a user has claimed an invitation reward or a Pinduoduo reward, the first withdrawal after claiming automatically carries the "Agent Withdrawal" note, forcing manual review.
Legitimate Agent behavior (allowed): Users who claim invitation rewards are typically agents (have subordinates); they can skip making deposits and skip placing bets entirely, earn commission from subordinates' deposits and wagering, and directly withdraw the reward — as long as the subordinates are independent real users.
What arbitrage actually means: The agent registers a batch of their own sock-puppet accounts as subordinates, then uses those puppets to deposit and wager to farm commission for the main account, then withdraws. Arbitrage is not judged by whether the agent plays games themselves — it's judged by whether the subordinates are independent real users.
Account-change data retention: Account-change records are kept for the most recent 60 days only; records older than 3 months cannot be queried. For users whose reward claim dates are long ago, earlier data may not be available — work with whatever is within the queryable range.
Five Arbitrage Review Criteria (2026-04 Edition)¶
Review general principle: If the member is not maliciously farming Treasure Box, try to retain them. Based on subordinate quality and subordinate activity, flexibly decide on deduction / no deduction, move into / out of Arbitrage Observation tier. Better to err on the side of leniency — do not wrongly penalize; retain the member whenever possible.
📝 Source: Study & discussion
Criterion 1 · P2 Arbitrage Pattern Detection (primary criterion)
Check the agent's subordinate user behavior patterns:
| Check Item | Condition |
|---|---|
| Subordinate deposit amount | 50–60 (back-office units, K IDR) |
| Subordinate wagering volume | ~600 (back-office units, just enough to claim Treasure Box) |
| Percentage of subordinates matching the above pattern | ≥70% |
All three conditions met simultaneously → triggers P2 arbitrage determination.
Small agent special handling: If the agent has ≤3 subordinates and only claimed one invitation reward, may be approved at discretion — let them profit a little so they have motivation to develop more subordinates.
📝 Source: Study & discussion
Criterion 2 · Conditions for Retaining a Normal Member (no deduction, no tier move)
Prerequisite: Does NOT trigger Criterion 1.
| Retention Condition | Description |
|---|---|
| At least one subordinate has | Large deposits, large wagering volume, recently active (had deposits within the past 3–5 days) ❓ Exact threshold for "large" pending supervisor clarification |
| And does not trigger Criterion 1 | Overall does not match the "deposit 50-60 + wagering 600 + ≥70%" arbitrage pattern |
Conditions met → do not move into Arbitrage Observation tier, member retains access to all promotions; delete existing P2 notes, re-annotate as "no deduction, date + handler" (e.g., 不扣款，可以出 4.21 AA).
📝 Source: Study & discussion
Criterion 3 · Moving Out of Arbitrage Observation Tier (restore to normal)
Applicable to: existing customers (previously moved into Arbitrage Observation tier).
| Exit Condition | Description |
|---|---|
| Deposits + withdrawals | ≥40 transactions |
| Recent deposit activity | Still actively depositing recently |
| Subordinate activity | Subordinates have active deposits, and active period exceeds 1 month |
Conditions met → delete all notes, treat as a normal member, resume monitoring.
After restoration, if the member again claims invitation / Pinduoduo rewards and withdraws, still review according to P1 member standards.
📝 Source: Study & discussion
Criterion 4 · Deputy Lead Double Review (re-verification before executing deduction)
Regardless of whether P2 was flagged by the Audit Team or discovered by the Deputy Lead themselves, before actually executing any deduction, the Deputy Lead must re-evaluate against Criteria 1 through 3:
- Meets P2 standard → proceed with deduction flow normally; after deduction, unlock betting/withdrawal permissions (member stays in Arbitrage Observation tier; commission permissions remain open)
- Does NOT meet P2 standard → no deduction; cancel P2 notes; move out of Arbitrage Observation tier; change tier to 7-day retention or 30-day retention based on registration date; annotate as "no deduction, date + handler"
📝 Source: Study & discussion
Supplementary Arbitrage Behavior Assessment Reference (supplements Criterion 1)¶
| # | Behavior Pattern | Assessment |
|---|---|---|
| 1 | After claiming reward, no normal game bets, deposits once → bets for profit → withdraws | Suspected arbitrage |
| 2 | After claiming reward, bets normally with game profits → withdraws (entirely using the bonus for arbitrage) | Suspected arbitrage |
| 3 | More than 5 subordinate members have identical or very similar cumulative deposit and valid wagering data (especially identical deposit amounts) | Suspected arbitrage |
The above 3 patterns serve as supplementary reference for further judgment; the primary criterion remains Criterion 1.
Agent Withdrawal Review Complete Workflow¶
═══════════════════════════════════════════
Agent Withdrawal Review Complete Flow
(2026-04 New Standard)
═══════════════════════════════════════════
See note "Agent Withdrawal"
│
▼
Lock order → Open member info detail page
│
▼
========================================
Step 1: Screen subordinate behavior
patterns per Criterion 1
(primary criterion)
========================================
│
▼
┌───────────────────────────────────────┐
│ Check the agent's subordinates: │
│ · Subordinate deposit amounts and │
│ wagering volumes │
│ · Match "deposit 50-60 + wagering │
│ ~600" pattern? │
│ · Percentage of such subordinates │
│ among all subordinates │
└────────┬──────────────────────────────┘
│
▼
========================================
Step 2: Check Account Change Records
========================================
│
▼
┌───────────────────────────────────────┐
│ Investigate [Account Change Records]: │
│ · Claimed invitation rewards / │
│ Pinduoduo rewards? │
│ · Has legitimate deposits? │
│ · Has legitimate game bets? │
│ · Reference supplementary assessment │
│ criteria (3 behavior patterns) │
└────────┬──────────────────────────────┘
│
▼
========================================
Step 3: Comprehensive Determination
========================================
│
▼
┌─────────────────────────────────────┐
│ Does it trigger Criterion 1? │
│ (≥70% subordinates match │
│ arbitrage pattern) │
└────────┬────────────────────────────┘
│
┌─────┴─────────┐
│ │
Not triggered Triggered
│ │
▼ ▼
Check Criterion 2 Enter P1/P2
(retention handling
conditions)
│
▼
┌──────────────┐
│ Meets │
│ Criterion 2? │
│ (≥1 sub with │
│ large │
│ deposits + │
│ large │
│ wagering + │
│ recently │
│ active) │
└──────┬───────┘
┌───┴───┐
│ │
Yes No
│ │
▼ ▼
Approve Approve
+ no tier (standard
move pass)
+ delete
P2 notes
═══════════════════════════════════════════
Triggered Arbitrage → P1 / P2 Handling
═══════════════════════════════════════════
│
▼
Check member [Notes] field
│
┌─────┴────────────────────────────┐
│ │
Has P1 notes No notes
(previously warned) (first discovery)
│ │
▼ ▼
P1 date is today? ┌──────────────┐
│ │ P1 Warning │
┌──┴──┐ │ · Note "P1 │
│ │ │ warning │
Yes No │ date+handler"│
│ │ │ · Reject │
▼ ▼ │ withdrawal │
┌────┐ Check account │ · User re- │
│Appr│ changes │ submits → │
│ove │ │ │ approve │
│dire│ ┌──┴──┐ │ directly │
│ctly│ │ │ └──────────────┘
│(no │ Corrected Still
│dup │ │ arbitraging
│proc│ ▼ │
│ess)│ Approve Enter P2 ↓
└────┘
≤3 subordinates + only claimed one
invitation reward
→ may approve at discretion
(motivation to develop subordinates)
========================================
P2 Handling Flow
========================================
P2 can be triggered via two paths:
┌─────────────┬──────────────────┐
│ Path A │ Path B │
│ Audit Team │ Deputy Lead │
│ finds │ discovers during │
│ continued │ own review │
│ arbitrage │ │
└──────┬──────┴──────┬───────────┘
│ │
▼ ▼
P2 actions (same regardless of trigger):
┌───────────────────────────────────────┐
│ (1) Disable betting permissions │
│ (2) Disable withdrawal permissions │
│ ⚠️ Commission permissions remain │
│ open │
│ (3) Move into Arbitrage Observation │
│ tier │
│ (4) Note "P2 warning date+handler" │
│ (5) Reject order │
│ (6) Notify CS │
└────────┬──────────────────────────────┘
│
▼
User contacts CS → confirms deduction
→ CS notifies Deputy Lead to execute
│
▼
╔══════════════════════════════════╗
║ Criterion 4 · Deputy Lead ║
║ Double Review ║
║ Re-evaluate against Criteria ║
║ 1 through 3 ║
╚══════════════════════════════════╝
│
┌─────┴─────┐
│ │
Meets P2 Does NOT
standard meet P2
│ │
▼ ▼
Deduction No deduction:
flow · Cancel P2 notes
(see 4.2) · Move out of Arbitrage
· Deduct Observation tier
bonus · Change to 7-day /
· After 30-day retention tier
deduction based on registration
unlock date
betting/ · Note "no deduction,
withdrawal date+handler"
· Stays in
Observation
tier
· Commission
remains open
· Report to
Finance group
📝 Source: Study & discussion
Notes Format Standard¶
| Scenario | Note Template | Example |
|---|---|---|
| P1 Warning | ❓ To be filled | ❓ To be filled |
| P2 Deduct Bonus | ❓ To be filled | ❓ To be filled |
| Double review overturned (does not meet P2) | 不扣款，可以出 {日期} {经手人} |
不扣款，可以出 4.21 AA |
| Removed from Observation tier | Delete all notes, treat as normal member | — |
Normal Agent vs Arbitrage Agent · Decision Formula¶
Look at the subordinates, not at the agent themselves. - The agent themselves is allowed to skip deposits and skip betting — "no deposits, no games" is not an arbitrage signal - Subordinate behavior is normal (does not match "deposit 50-60 + wagering 600 + ≥70%" pattern) → agent claiming reward is legitimate - Subordinate behavior is highly uniform (matches the above pattern ≥70%) → arbitrage suspected
📘 Source: 04-禁止投注问题排查 (lock operation path) 📝 Source: Study & discussion (complete review flow and arbitrage determination criteria)
🤖 Automation opportunity: Subordinate behavior pattern screening + account change record checking is one of the most time-consuming tasks for the Deputy Lead. Scripts can auto-scan subordinate deposit/wagering volume distributions, calculate the percentage matching the arbitrage pattern, and flag abnormal agents. Full API requirements spec at 12-自动化路线图/01-代理提现审核API.md. If these checks can be standardized into a one-click back-office function, the Deputy Lead only needs to confirm results and execute actions; after a trial period this can be fully automated, with the Deputy Lead conducting random spot checks.
4.2 Deduction Processing¶
The Deputy Lead can directly execute deduction operations, but deductions are not self-initiated — the complete chain is: Audit Team discovers issue → closes user's related permissions → CS communicates with user → user agrees to deduction → CS sends message to Deputy Lead → Deputy Lead executes deduction → restores permissions → notifies CS → reports to finance group.
Audit Team discovers issue
(closes user's withdrawal permissions, etc.)
│
▼
CS communicates deduction with user
│
▼
User agrees to deduction?
├─ No → CS reports to Audit Team, escalation process
│
└─ Yes → CS initiates deduction request in group
│
▼
┌───────────────────────┐
│ (1) Claim in group │
└────────┬──────────────┘
│
▼
┌───────────────────────────────────────────┐
│ (2) Check user's [Account Change Records] │
│ Verify amounts to deduct: │
│ · Invitation rewards │
│ · Pinduoduo rewards │
│ · Profits generated from above rewards │
│ Deduction principle: Keep only the │
│ user's own deposited funds, or the │
│ balance before receiving rewards │
└────────┬──────────────────────────────────┘
│
▼
======================================================
(2.5) Cross-Verification (mandatory — confirm
Audit Team's judgment is accurate)
======================================================
┌───────────────────────────────────────────┐
│ · Follow the agent withdrawal review flow │
│ (see 4.1.5) to verify Audit Team's │
│ judgment is accurate │
│ │
│ · Confirmed problematic → proceed with │
│ deduction │
│ · Disagreement found → report back to │
│ Audit Team, suspend deduction │
└────────┬──────────────────────────────────┘
│
▼
┌───────────────────────┐
│ (3) Execute deduction │
│ in back-office │
│ Path: Member Mgmt →│
│ Member List → Click│
│ UID → Account Data │
│ → Modify Balance │
└────────┬──────────────┘
│
▼
┌───────────────────────────────┐
│ (4) Restore user's disabled │
│ permissions │
│ (withdrawal/betting etc., │
│ per Audit Team's request) │
└────────┬──────────────────────┘
│
▼
┌───────────────────────┐
│ (5) Notify CS in group │
│ "Deducted + perms │
│ restored" │
└────────┬──────────────┘
│
▼
┌───────────────────────┐
│ (6) Report to finance │ ← Mandatory report
│ group │
│ Include: Platform / │
│ User ID / Deduction │
│ amount / Reason │
└───────────────────────┘
Finance group report template: no standalone template file — just copy the format of a recent report from a colleague in the group (the 4 key fields from the flow above: Platform / User ID / Deduction amount / Reason).
Deduction Amount Calculation Principles:
| To Deduct | To Keep |
|---|---|
| Invitation reward amount | User's own deposited funds |
| Pinduoduo reward amount | Account balance before receiving rewards |
| Profits generated from above rewards | — |
Core logic: All reward-related money (including profits) must be deducted; all of the user's own money must be kept. Must check account change records line by line — do not take a blunt approach based on current balance.
📝 Source: Study & discussion
⚠️ Deduction ≠ Deposit Reversal (Two Completely Different Actions)¶
| Dimension | Deduction (this section) | Deposit Reversal |
|---|---|---|
| Trigger reason | User violation / deficit / risk control deduction | A just-confirmed deposit order was a mistake |
| Time limit | No time limit, can operate anytime | Within 30 minutes after order confirmation (button disappears after) |
| Operation path | Member Mgmt → Member List → Click UID → Account Data → Modify Balance | Finance Mgmt → Deposit Records → Deposit Reversal |
| Target | Member's existing balance | That specific deposit order (balance deducted + order cancelled + turnover rolled back) |
| Who triggers | CS feedback | Finance/admin discovers mistaken confirmation — self-rescue |
| Finance reporting | ✅ Required | ✅ Required for large or frequent reversals |
Decision mnemonic: - CS says "this user has a violation, need to deduct" → Use Deduction - Admin/Finance says "I just confirmed a deposit by mistake, hurry and reverse" → Use Deposit Reversal (30-minute countdown!)
📘 Source: 05-充值订单收回款项 + 13-会员与风控/01-会员列表
Two Types of "Add/Deduct" — Must Distinguish¶
| Type | Counts Toward Deposit Stats | Use Case |
|---|---|---|
| Manual Add/Deduct | ✅ Counts as deposit | Deposit top-up, financial adjustment |
| Bonus Add/Deduct | ❌ Does NOT count as deposit | Event compensation, missed bonus (daily operations use this) |
Operation path: Member Mgmt → Member List → Click UID → Account Data → Modify Balance (select type in popup).
Additional notes:
- All manual add/deduct operations are auto-logged, including pre-operation balance / post-operation balance / operator / reason notes
- Deputy Lead must fill in notes (with ticket/complaint number) — this is your audit protection
- Per-transaction/daily limits are configured in System Management → Admin Accounts; exceeding limits results in automatic rejection
📘 Source: 13-会员与风控/01-会员列表 + 17-活动记录/10-彩金加减款记录
4.3 Member Permission Changes¶
CS initiates request in group
│
▼
┌──────────────────────────────┐
│ Claim in group │
│ Method: Reply OK or ✅ check │
└────────┬─────────────────────┘
│
▼
┌───────────────────────┐
│ Execute permission │
│ change in back-office │
└────────┬──────────────┘
│
▼
┌───────────────────────────────────┐
│ Does it involve add/deduct funds? │
└────────┬──────────────────┬───────┘
│ Yes │ No
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ Must report to │ │ Reply "Done" in │
│ finance group │ │ group │
│ Include: Platform│ └──────────────────┘
│ /User ID/ │
│ Operation type/ │
│ Amount/Reason │
└──────────────────┘
📘 Source: 13-会员与风控/01-会员列表 📝 Source: Study & discussion
4.4 Order Callback Processing¶
Scope: Currently two scenarios require the Deputy Lead to execute order callbacks: promotion traffic acquisition and remote testing. Both use the same callback command (third-party channel Telegram bot /testpay order_number), but the permission handling after callback differs.
Core purpose: Assist various teams in completing their tests while ensuring test funds added via callback cannot be accidentally withdrawn.
⚠️ Important rule: If a test callback order fails or encounters any issues, you must register a new account and submit a new order for the callback. You cannot use the same account to submit two orders and callback twice.
Scenario 1 · Promotion Traffic Acquisition Callback¶
Receive traffic callback request in group
(promotion team)
│
▼
┌───────────────────────┐
│ Claim in group │
└────────┬──────────────┘
│
▼
┌───────────────────────────┐
│ Via third-party channel │
│ Telegram bot: │
│ /testpay order_number │
└────────┬──────────────────┘
│
▼
┌───────────────────────────┐
│ Back-office → Disable │
│ withdrawal permission │
│ Add note: [testpay] │
│ │
│ ⚠️ Traffic accounts are │
│ NOT unlocked afterward │
└────────┬──────────────────┘
│
▼
┌───────────────────────────┐
│ Reply in group: "Done" │
└───────────────────────────┘
Scenario 2 · Remote Tester Deposit/Withdrawal Test Callback¶
Remote testers need to complete the full deposit + withdrawal test flow. The difference from traffic acquisition: keep withdrawal permission open (the tester needs to submit a test withdrawal later), but disable auto-disbursement (prevent test funds from being actually paid out).
Receive remote test callback request in group
(testing team)
│
▼
┌───────────────────────┐
│ Claim in group │
└────────┬──────────────┘
│
▼
┌───────────────────────────┐
│ Via third-party channel │
│ Telegram bot: │
│ /testpay order_number │
│ (same as traffic callback) │
└────────┬──────────────────┘
│
▼
┌────────────────────────────────┐
│ ⚠️ Permission handling │
│ (differs from traffic) │
│ │
│ · Withdrawal permission → KEEP │
│ · Auto-disbursement → DISABLE │
│ (prevent real payout of test │
│ funds) │
│ │
│ Add note: [remote test] │
└────────┬───────────────────────┘
│
▼
┌────────────────────────────────┐
│ Tester submits test withdrawal │
│ │ │
│ ▼ │
│ Deputy Lead receives order │
│ → REJECT │
│ (test complete, no real payout)│
└────────┬───────────────────────┘
│
▼
Quick comparison of the two scenarios:
| Dimension | Traffic Callback | Remote Test Callback |
|---|---|---|
| Triggered by | Promotion team | Remote testers |
| Callback command | /testpay order_number |
/testpay order_number (same) |
| Withdrawal permission | Disabled | Kept open (needed for testing) |
| Auto-disbursement | N/A (withdrawal locked) | Disabled (prevent real payout) |
| Subsequent withdrawal order | None (permission locked) | Tester will submit one → Deputy Lead rejects |
| Note keyword | testpay |
remote test |
| Anti-loss mechanism | Lock withdrawal permission | Disable auto-disbursement + manual reject |
📝 Source: Study & discussion
📘 Source: 20-系统管理/04-操作日志 (lock operation audit trail)
4.5 Wagering Requirement Verification¶
A common rejection reason when the Deputy Lead reviews withdrawals is insufficient wagering requirement (valid bet amount).
Four Valid Wagering Calculation Formulas¶
| Mode | Formula | Typical Use | Tendency |
|---|---|---|---|
| ① By bet amount | Valid wagering = Bet amount |
Low-risk games (Slots, etc.) | Most lenient |
| ② By win amount | Valid wagering = Win amount (0 if no win) |
Rarely used | Unfavorable to users |
| ③ Hybrid Mode 1 | No win: Valid wagering = Bet amount; Win: Valid wagering = min(Bet, Win) |
Balanced scenarios | Balanced |
| ④ Hybrid Mode 2 | Valid wagering = min(Bet, |Bet - Win|) |
High-risk games, anti-arbitrage | Most strict |
Rule changes only apply to future orders; historical orders remain unchanged.
📘 Source: 03-有效打码计算方式
Verification Path¶
Withdrawal order flagged by risk control:
suspected insufficient wagering
│
▼
Back-office path: Game Sorting → Game Group List
│
▼
Check which game group the user's games belong to
│
▼
Check the group's "Valid Wagering Calculation Method"
│
▼
Compare against event/turnover threshold
├─ Met → Approve withdrawal
└─ Not met → Reject + note "Remaining wagering: XXX"
→ Notify CS
Shortcut: The back-office has a "Remaining Wagering" direct display (Member Profile → Remaining Wagering field); in most cases manual back-calculation is unnecessary.
📘 Source: 03-有效打码计算方式 + 13-会员与风控/07-打码量变动记录
4.6 Bet Restriction Troubleshooting¶
When CS reports "user says they cannot place bets":
CS escalates: User XXX cannot place bets
│
▼
┌───────────────────────────────┐
│ Step 1: Claim in group │
└──────────┬────────────────────┘
│
▼
┌───────────────────────────────┐
│ Step 2: Investigate in │
│ back-office │
│ Path: Member Mgmt → │
│ User Lock List │
│ Check three lock types: │
│ ① Login lock (no access) │
│ ② Bet lock (can login, │
│ cannot bet) │
│ ③ Withdrawal/Commission lock│
└──────────┬────────────────────┘
│
▼
Lock found?
├─ Yes → Determine lock reason
│ ├─ Agent anti-fraud → Cannot unlock,
│ │ escalate to risk control
│ ├─ Manual lock for violation →
│ │ Confirm with supervisor before unlock
│ └─ Auto-triggered by risk control →
│ Investigate before unlock
│
└─ No → Not lock-related (API limit /
device issue / insufficient balance)
→ Transfer to tech team
❌ Red Line: Must investigate the reason before unlocking. Carelessly unlocking a previously locked account may let a real fraudster through.
Key facts: - Withdrawal password error exceeding limit will simultaneously trigger "Bet Lock" + "Withdrawal Lock" - Withdrawal password can only be "cleared" not "changed"; after clearing, the member must set a new one
📘 Source: 04-禁止投注问题排查 + 13-会员与风控/11-用户锁定列表
4.7 Event Day RTP Adjustment (Periodic Task)¶
This is a manager-level task, but may be delegated to team leads or deputy leads with backend access.
Background¶
Established sites have many veteran users with high VIP tiers. On event days (usually Monday), large bonuses need to be distributed. Without adjusting the RTP (Return to Player) rate in advance, the platform's deposit-withdrawal spread could go negative (platform loss). Lowering RTP for specific user tiers offsets the bonus expenditure.
Execution Time¶
- Night before event day (usually Sunday ~23:30)
- Must be completed before 00:00 on event day
Procedure¶
Sunday ~23:30: Prepare RTP adjustment
│
▼
┌───────────────────────────────┐
│ Step 1: Backend → │
│ Member Management → │
│ Member Tiers │
└──────────┬────────────────────┘
│
▼
┌───────────────────────────────┐
│ Step 2: Adjust RTP for │
│ three tiers: │
│ ① 15-day retention users │
│ ② 30-day retention users │
│ ③ Arbitrage observers │
└──────────┬────────────────────┘
│
▼
┌───────────────────────────────┐
│ Step 3: Click "One-click Set │
│ RTP Rate" │
│ (specific values set by │
│ manager, deputy lead │
│ executes as instructed) │
└──────────┬────────────────────┘
│
▼
┌───────────────────────────────┐
│ Step 4: Confirm all three │
│ tiers done → Report in group │
│ chat: "RTP adjusted" │
└───────────────────────────────┘
Notes¶
- Only for established sites (new sites don't need this)
- RTP values decided by manager — deputy lead only executes
- Time-sensitive: must complete before event starts
- All three tiers must be set, none can be skipped
📝 Source: Study & discussion
4.8 Chargeback/Reversal Order Processing (B-Line Response Task)¶
Background¶
After a member's withdrawal succeeds, the third-party payment auto-callback shows success. But 1–2 days later, the disbursement order may fail at the bank (bank reversal/chargeback) — meaning the money never reached the user. Manual compensation is needed.
Discovery Channel¶
- Third-party payment bots send reversal notifications in Telegram payment groups
- Designated person searches daily using keyword "reversal/chargeback" (冲正) in each payment group
- Unprocessed orders are collected and sent for batch processing
Complete Flow¶
┌─────────────────────────────────────────────┐
│ Step 1: Get order number from reversal │
│ notification │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Step 2: Search in Signal deposit/withdrawal │
│ inquiry group — if found, already processed, │
│ skip │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Step 3: Use bot in payment group to recheck │
│ order status, record processing time │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Step 4: Check user's transaction history in │
│ backend, find the withdrawal order │
│ (e.g. amount = 20) │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Step 5: Look back in transaction history: │
│ is there an "add bonus 20" record already? │
│ │
│ Yes → already processed, skip │
│ No → needs compensation │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Step 6: Add bonus to user for the withdrawal │
│ amount. Remark: "Withdrawal order failed, │
│ manual credit" │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Step 7: Report in Signal group: │
│ platform name / user ID / order number / │
│ remark / processor │
└─────────────────────────────────────────────┘
Key Points¶
- Double verification prevents duplicate compensation (Signal check + transaction history check)
- Standardized remark: "Withdrawal order failed, manual credit"
- Use bonus add (not manual deposit) — doesn't count toward deposit statistics
- Report must include all 5 elements: platform name / user ID / order number / remark / processor
📝 Source: Study & discussion
4.9 Deposit Success Rate Monitoring (Every 30 Minutes)¶
Background¶
Deposit success rate in the Indonesian market directly drives platform revenue. Low success rate = mass deposit failures = user churn (Indonesian users have low patience — one failure and many switch platforms). This requires real-time monitoring and immediate intervention when the rate drops below threshold — not waiting for user complaints.
Key Parameters¶
| Item | Value |
|---|---|
| Inspection frequency | Every 30 minutes |
| Observation window | Deposit success rate over the last 10 minutes |
| Intervention threshold | Success rate < 60% requires intervention |
| First action | Notify the collection merchant to optimize the channel |
| Fallback action | Switch collection channels (adjust deposit method order) |
Full Handling Flow¶
Every 30 minutes (:00 / :30)
│
▼
┌────────────────────────────────────┐
│ (1) Check last-10-min deposit │
│ success rate in back-office │
│ Check each platform one by one │
└──────────┬─────────────────────────┘
│
▼
Success rate < 60%?
│
┌────┴────┐
│ │
No Yes
│ │
▼ ▼
┌──────────┐ ┌────────────────────────────────────┐
│ Keep │ │ (2) Identify which merchant is the │
│ config, │ │ problem (lowest success rate) │
│ continue │ └──────────┬──────────────────────────┘
│ watching │ │
│ │ ▼
│ │ ┌────────────────────────────────────┐
│ │ │ (3) In the merchant's Telegram │
│ │ │ group, notify them to optimize │
│ │ │ the channel │
│ │ │ Message: "Success rate low, │
│ │ │ please optimize" │
│ │ └──────────┬──────────────────────────┘
│ │ │
│ │ ▼
│ │ ┌────────────────────────────────────┐
│ │ │ (4) Keep monitoring for results │
│ │ │ Observe next 10-15 min rate │
│ │ └──────────┬──────────────────────────┘
│ │ │
│ │ ▼
│ │ Recovered?
│ │ │
│ │ ┌────┴────┐
│ │ │ │
│ │ Yes No
│ │ │ │
│ │ ▼ ▼
│ │ ┌──────────┐ ┌────────────────────────────┐
│ │ │ Effective│ │ (5) Switch collection │
│ │ │ → keep │ │ channels │
│ │ │ config, │ │ · Adjust deposit method │
│ │ │ continue │ │ order │
│ │ │ watching │ │ · Demote problem merchant│
│ │ │ │ │ · Promote backup merchant│
│ │ │ │ │ · Keep collection = │
│ │ │ │ │ disbursement order │
│ │ └──────────┘ │ (see 3.6 core rule) │
│ │ └──────────┬─────────────────┘
│ │ │
│ │ ▼
│ │ ┌────────────────────────┐
│ │ │ (6) Post note in shift │
│ │ │ group + log switch │
│ │ └────────────────────────┘
└──────────┘
Key Points¶
- The 30-min cadence is deliberate: the 10-min window gives representative data (filters out transient noise); 30-min intervals catch problems quickly (at most 30-min lag)
- Notify merchant first, then switch: notifying the merchant is the lowest-cost option (the merchant doesn't want to lose volume either) — only switch channels when the merchant truly can't fix it
- Switching aligns with 3.6 principle: when adjusting collection order, adjust disbursement order in sync — keep them consistent
- Log every intervention: post in shift group "XX:30 inspection: Platform A success rate 52%, notified CP-X to optimize / switched to CP-Y" — useful for handover and post-mortem
Reference: 08-Deposit Method Order
📝 Source: Study & discussion
🤖 Automation opportunity: Build real-time success-rate alerting — back-office computes last-10-min rate every 5 min, auto-@Deputy Lead when below 60% with the problem merchant tagged, removing manual half-hourly checks.
4.10 Withdrawal Order 30-Minute No-Callback Handling¶
Background¶
Normally, a disbursement order submitted to a third-party merchant returns a callback (success or failure) within minutes. 30 minutes with no callback = something is wrong on the disbursement side, possible cases:
- Merchant is still "processing" internally (stuck order)
- Merchant channel anomaly (slow bank side, risk control block, merchant system issue)
- Merchant has processed but callback got lost
In any case, the Deputy Lead must proactively intervene and confirm with the merchant — waiting passively leads to direct user complaints of "withdrawal has been 30 min with no money".
Discovery Channel¶
- Back-office withdrawal records page has a dedicated "Submitted 30 min no callback" category/alert
- That list shows all backlogged orders
Full Handling Flow¶
Back-office alert / periodic check of withdrawal records
Find the "30-min no-callback" order list
│
▼
┌────────────────────────────────────┐
│ (1) Count the number of orders │
└──────────┬─────────────────────────┘
│
▼
Order count?
│
┌────┴────┐
│ │
Few Many
(<5) (>=5)
│ │
▼ ▼
┌──────────┐ ┌────────────────────────────────────┐
│ Batch │ │ (2') Group by disbursement merchant│
│ copy │ │ first (same batch may belong │
│ order │ │ to multiple merchants) │
│ numbers │ │ Then send per-merchant batches │
│ to the │ │ to the corresponding group │
│ relevant │ └──────────┬──────────────────────────┘
│ payout │ │
│ group │ │
└────┬─────┘ │
│ │
└─────────┬─────────┘
▼
┌────────────────────────────────────┐
│ (3) In the payout group, confirm │
│ which merchant owns each order │
│ (avoid misrouting) │
│ Use bot to look up merchant │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4) Ask merchant to investigate │
│ and resolve │
│ · Merchant checks internal │
│ status │
│ · Able merchants will push │
│ a corrective callback │
└──────────┬─────────────────────────┘
│
▼
Merchant can resolve?
│
┌────┴────┐
│ │
Yes No
│ │
▼ ▼
┌──────────┐ ┌────────────────────────────────────┐
│ Wait for │ │ (5) Merchant rejects the order │
│ merchant │ │ → system auto-processes reject │
│ corrective│ │ → balance auto-refunded to user │
│ callback │ │ → user can retry withdrawal │
│ Order │ │ (choosing a different payout) │
│ completes│ └────────────────────────────────────┘
└──────────┘
│
▼
┌────────────────────────────────────┐
│ (6) Post in shift group / Signal │
│ deposit-withdrawal group: │
│ · order # / user ID / outcome │
│ · for future audit & traceback │
└────────────────────────────────────┘
Key Points¶
- Confirm merchant ownership first: one batch of 30-min-no-callback orders may belong to multiple merchants — confirm before/during posting to the group, don't dump A-merchant orders into B-merchant's group (wastes time)
- Merchant rejection ≠ financial loss: after merchant rejects, the system auto-refunds the amount to the user (provided funds never actually reached the user); user can retry
- Do NOT manually refund: going through system rejection is the standard path — manually "adding bonus" easily causes double payout
- Difference from 4.11: 4.10 is "30 min no callback" (still waiting for callback); 4.11 is "disbursement interface timeout" (the API call itself timed out). Both must be handled but sources differ.
Reference: 06-Withdrawal Records
📝 Source: Study & discussion
🤖 Automation opportunity: Auto-group 30-min-no-callback orders by merchant and batch-post to the corresponding payout group; Deputy Lead only confirms and follows up; recovered orders auto-close.
4.11 Disbursement Interface Timeout Order Handling¶
Background¶
"Disbursement interface timeout" is a different anomaly from 4.10's "30-min no callback":
- 4.10 (30-min no callback): API call succeeded, but merchant never sends a callback → wait for merchant
- 4.11 (interface timeout): The API call itself timed out (merchant may not have received the request, or received but failed to respond in time) → order status is ambiguous
Timeout orders have ambiguous status — either the merchant never processed it (funds still in our merchant account), or the merchant did process it but couldn't respond in time (funds already paid out). You MUST reconfirm with the merchant before deciding action — acting on guesswork easily triggers double payout = direct financial loss.
⚠️ Important: The disbursement interface timeout page has NO "reject" button. The action entry point is the "Re-payout" button. The flow is: confirm funds are in our account → click "Re-payout" → order automatically enters the payout page → on the payout page, select a different disbursement channel and re-submit.
Discovery Channel¶
- Back-office withdrawal records page → "Disbursement interface timeout orders" category
Full Handling Flow¶
Back-office shows "Disbursement interface timeout" orders
│
▼
┌────────────────────────────────────┐
│ (1) For each order, reconfirm with │
│ the corresponding merchant │
│ (often the same merchant as 4.10)│
│ In merchant's Telegram group, │
│ use bot to check actual status │
└──────────┬─────────────────────────┘
│
▼
Merchant-side order status?
│
┌──────────┼──────────────────────┐
│ │ │
Merchant Merchant not processed Merchant still
already / processing failed processing
paid out funds in our account (pending)
(success)
│ │ │
▼ ▼ ▼
┌──────────┐ ┌───────────────┐ ┌──────────────┐
│ Click │ │ (2) Click │ │ Keep waiting │
│ "Merchant│ │ "Re-payout" │ │ for callback │
│ Paid" │ │ button │ │ Do NOT rush │
│ button to│ │ │ │ to click │
│ callback │ │ │ │ Re-payout │
│ order │ │ │ │ (otherwise │
│ status as│ │ │ │ double payout│
│ success │ │ │ │ risk) │
└──────────┘ └──────┬────────┘ └──────────────┘
▼
┌────────────────────────────────┐
│ (3) Order auto-enters the │
│ [Payout page] │
│ ([05-Payout] doc) │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ (4) On the Payout page, select │
│ **a DIFFERENT disbursement │
│ channel** (NOT the one that │
│ just timed out) │
│ Manually approve │
│ Submit to the new channel │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ (5) Post outcome in shift group │
│ · order # │
│ · original merchant (timeout)│
│ → new merchant │
│ · processor │
└────────────────────────────────┘
Key Points (Red Lines)¶
- You MUST confirm "funds are back in our merchant account" before clicking "Re-payout": this is the financial-loss red line — if the merchant already paid out and you click Re-payout, the system pays again via the new channel = double payout = direct loss
- Merchant still processing → KEEP WAITING: don't rush to click Re-payout; wait for the merchant's final status. Better to let the user wait a few minutes than to risk double payout
- Choose a DIFFERENT disbursement channel on re-submit: once on the Payout page, pick another channel — the original one just timed out, picking the same one likely times out again
- "Re-payout" is NOT "Reject": this page has no reject button — don't hunt for one. "Re-payout" essentially puts the order back in the payout queue for Deputy Lead to choose a new channel
- Relationship with 4.10: when handling 4.11, the relevant merchant is likely the same one that had issues in 4.10. The typical flow is "handle 4.10 no-callback first → then handle 4.11 timeouts"
Reference: - 05-Payout - 06-Withdrawal Records
📝 Source: Study & discussion
🤖 Automation opportunity: Build a merchant-status bot for timeout orders — auto-query actual status in the merchant group, aggregate results for the Deputy Lead, who only needs to click "funds returned → Re-payout" to confirm.
4.12 New-Site Onboarding (Supervisor Assist)¶
When triggered: When the supervisor announces a new site is going live. Ad-hoc, not daily — act only when notified.
Deputy Lead's two responsibilities:
4.12.1 Domain Binding¶
Back-office path: Domain Management → Website Domains
Steps:
1. Receive the domain list + type from the supervisor (primary / backup / redirect, etc.)
2. Add bindings in the back-office one by one, matching the type to what the supervisor provided — don't guess
3. Reply in the supervisor's thread: Completed binding X domains
4.12.2 Salesmartly Customer Support Automation¶
Goal: Replicate the prior site's automation onto the new site, with targeted updates for new scenarios.
Steps:
1. In the Salesmartly back-office, clone the prior site's automation flow onto the new site
2. Make targeted updates for new issues the new site may face, e.g.:
- Attach relevant screenshots for a new FAQ
- Add auto-reply text for the new scenario
3. Configure social-media channels (e.g., Telegram bot) automation
4. After done, message the supervisor: New-site automation is configured
📝 Source: Study & discussion
Notes: - Domain types follow the supervisor's list exactly — don't modify or add your own - Automation flow is cloned from a template — don't rebuild from scratch (faster + less error-prone) - Screenshots / copy for new issues must be confirmed with the supervisor / CS — don't fabricate
4.13 Finance Disbursement Anomaly Order Review (B-Line Reactive)¶
When triggered: When finance posts an anomaly order in the group (finance has already done one round of reconciliation).
Typical anomaly scenario:
A Deputy Lead (yourself or another) manually rejected an order while the third party was still processing it — the front-end refunds the withdrawal amount back to the member's wallet balance; but on the third-party side, the bank account has already been paid out. Net effect: the same money is paid twice — direct platform loss. This is human error (order-side).
Review flow:
Finance group posts anomaly order
│
▼
┌────────────────────────────────────┐
│ (1) Locate the order in back-office │
│ Confirm order # / amount / │
│ user ID / current status / │
│ who operated it historically │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (2) Go to the corresponding payout │
│ merchant group │
│ Use the bot to query the real │
│ order status │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (3) Cross-check both sides │
│ · Back-office "rejected / │
│ refunded to member" │
│ · Third-party "paid out to │
│ bank" │
│ Both disagree → loss risk │
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (4) If needed, talk to a human at │
│ the payout merchant for detail │
│ (when the bot info isn't clear)│
└──────────┬─────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ (5) Reply to finance with the │
│ result, e.g.: │
│ · "Order XXXX — human error" │
│ · "Order XXXX — still │
│ processing at third party" │
│ · "Order XXXX — normal payout" │
└────────────────────────────────────┘
Common result classifications:
| Result | Meaning | Follow-up |
|---|---|---|
| Human error | Third party already paid; back-office was manually rejected → member got double | Reply finance "Order XXXX — human error"; finance/supervisor decides recovery approach |
| Still processing at third party | Payout order not yet finalized | Reply finance "Order XXXX — still processing"; wait for final status before judging |
| Normal payout | Both sides match, amounts consistent, no loss | Reply finance "Order XXXX — normal payout"; case closed |
📝 Source: Study & discussion
Notes: - Do NOT reply finance without doing the cross-check — back-office status AND third-party status must both be seen before classifying - Human error is the most common loss point, especially under 4.11 (disbursement timeout) decision mistakes - Reply wording must be precise ("human error" / "still processing" / "normal payout") — don't describe vaguely - Log every review result in the shift sheet for post-mortem and handover
🤖 Automation opportunity: The 3 steps (back-office status lookup + payout-merchant bot query + result classification) can become a one-click tool — Deputy Lead pastes the order #, the tool fetches both sides and suggests a classification, Deputy Lead confirms and replies finance with one click.
V. Common Issue Handling¶
5.1 Member Forgot Login Password¶
Core principle: Ownership verification comes first. For any password/permission change request, ownership must be verified before taking action.
Handling method (NOT clear the password — reset it instead): In the back-office, reset the login password to a random 6-digit number → send "User ID + random password" to the CS group → CS guides the member to log in with the new password → member logs in and changes the password themselves.
| Member Status | Required Evidence | Action |
|---|---|---|
| Never deposited | None (no ownership anchor) | Reset to random 6-digit password → send to CS group |
| Has deposited | Provide proof of most recent deposit (screenshot + order # + bank statement) — use the user's latest successful deposit; no time-window limit | After verification, same flow: reset to random 6-digit password → send to CS group |
📝 Source: Study & discussion
CS escalates: "Member X forgot login password"
│
▼
┌────────────────────────────────┐
│ Go to member profile → Check │
│ deposit records │
└──────────┬─────────────────────┘
│
▼
Has deposit records?
├─ No → Reset password to random 6-digit
│ → Send "User ID + new password" to CS group
│ → CS guides member to log in with new password
│ → Member changes password themselves
│
└─ Yes → Require proof of most recent deposit
│
▼
Proof verification passed?
├─ Yes → Reset password to random 6-digit
│ → Send "User ID + new password" to CS group
│ → CS guides member to log in with new password
│ → Member changes password themselves
└─ No → Reject + inform CS
"credentials do not match"
Notes: 1. Do NOT clear the password — reset it to a random 6-digit number so the member can still log in and change it themselves 2. "User ID + random password" goes only to the CS group, not to any other group 3. After reset, instruct CS to "guide the member to change the password immediately after logging in" — avoid misuse of the temporary password
5.2 Member Forgot Withdrawal Password¶
Important: Withdrawal password can only be "cleared" not "changed" in the back-office. The member must set a new one next time they withdraw.
5.2.1 Evidence Requirements (split by whether the member has ever withdrawn)¶
| Member Status | Evidence ① | Evidence ② |
|---|---|---|
| Has withdrawn before | Screenshot of last withdrawal — taken from our game APP, showing the member's "withdrawal records" page (amount / time / receiving account) | Screenshot of the bank/ewallet account profile page used for withdrawal — must show the bank name + the first few and last few digits of the account number, for cross-check |
| Never withdrawn | Screenshot of most recent deposit — taken from the bank APP / wallet APP the member used for deposit, showing the payment record (amount / time / counterparty account) | Screenshot of the bank/ewallet account profile page used for withdrawal — must show the bank name + the first few and last few digits of the account number, for cross-check |
Both items are required — a single screenshot alone cannot establish ownership.
📝 Source: Study & discussion 📘 Source: 13-会员与风控/11-用户锁定列表 (withdrawal password can only be cleared, not changed)
5.2.2 Processing Flow¶
| Step | Action | Notes |
|---|---|---|
| 1 | Check if account has withdrawal password bound | Not bound → go through binding flow (not "forgot") |
| 2 | Already bound → check whether member has withdrawal history | Decides which evidence path to take |
| 3 | Request Evidence ① + ② per 5.2.1 | Both required |
| 4 | Cross-check screenshots against back-office records | Amount / time / account digits must all match |
| 5 | Verified → Clear withdrawal password | Not "change" — the back-office only allows clearing |
| 6 | Check whether the member is on the User Lock List | Need to unlock if so |
| 7 | If locked → unlock only the relevant login / betting / withdrawal lock | Unlock only what's needed for this case, don't blanket-unlock |
| 8 | Reply to the CS group / escalation thread — explicitly confirm done (password cleared; mention unlock if applicable) | Close the loop |
| 9 | CS then informs member: must set new withdrawal password at next withdrawal | CS tells member in advance to avoid confusion |
CS escalates: "Member X forgot withdrawal password"
│
▼
Check if account has withdrawal password bound
├─ No → Not "forgot"; have member go through
│ first-time binding flow
│
└─ Yes → Check withdrawal history
│
┌───────┴────────┐
▼ ▼
Has withdrawn Never withdrawn
│ │
▼ ▼
Require 2 proofs Require 2 proofs
① Last withdrawal ① Most recent deposit
screenshot screenshot (from
(from game APP) bank/wallet APP
payment record)
② Bank/ewallet ② Bank/ewallet
profile page profile page
screenshot screenshot
(bank name + (bank name +
first/last digits) first/last digits)
│ │
└───────┬────────┘
▼
Evidence matches?
├─ No → Reject + "credentials do not match"
│ + log in operation records
│ ⚠️ Cannot "let it slide if one is off"
│
└─ Yes → Clear withdrawal password
│
▼
Check whether member is on the [User Lock List]
│
┌───────┴────────┐
▼ ▼
Not listed On the list
│ │
│ ▼
│ Unlock the relevant lock(s)
│ (login / betting / withdrawal —
│ only the ones tied to this
│ case, don't blanket-unlock)
│ │
└───────┬────────┘
▼
Reply in CS group: done (cleared pw; note unlock if any)
▼
CS informs member: must set new password next withdrawal
Notes: 1. Never take action based on "a message in the group" — must go through CS escalation 2. Both pieces of evidence are mandatory — a single screenshot could be stolen; the profile page is for cross-check 3. The bank name + first/last digits of the account in Evidence ② must match the withdrawal account bound in the back-office — this is the key social-engineering defense 4. Only unlock the locks relevant to this case (login / betting / withdrawal) — do NOT blanket-unlock other risk-control locks just because you're handling "forgot withdrawal password" 5. All password reset / clear / unlock operations must be logged in operation records 6. Always reply to the escalation thread to confirm completion — no reply equals not done, closes the loop 7. High-risk situations (before large withdrawal, unfamiliar IP login) → escalate for supervisor review
5.2.3 "Secondary Verification / Data" Tier Mechanism (Password Reset Security)¶
Background: It was discovered that certain remote workers exploited the password-reset process to take over member accounts and withdraw funds to their own accounts. To prevent such incidents, a "Secondary Verification / Data" tier was introduced — any member placed in this tier will have all withdrawal requests routed to manual review, with strict verification by the Deputy Lead.
Two teams involved:
| Team | Responsibility | Trigger |
|---|---|---|
| RESET Team | When resetting the withdrawal PIN, confirm in Signal whether the operation occurred on the same day / recently → once confirmed, disable auto-withdrawal + move member into the "Secondary Verification / Data" tier | When a member requests a PIN change |
| Deputy Lead (WD Team) | Review withdrawal orders from "Secondary Verification / Data" tier members, decide whether to approve | When a member in this tier submits a withdrawal order |
RESET Team Operation Flow:
Member requests withdrawal PIN reset
│
▼
┌────────────────────────────────────┐
│ Search for the member account │
│ in Signal — confirm whether a PIN │
│ change occurred today or recently │
└──────────┬─────────────────────────┘
│
▼
Confirmed valid?
├─ No → Handle per normal flow
│
└─ Yes → Perform the following:
│
▼
┌────────────────────────────────┐
│ (1) Disable auto-withdrawal │
│ for this member │
│ (2) Move into "Secondary │
│ Verification / Data" tier │
│ (3) Add remark: │
│ "WD requires secondary │
│ confirmation, verify if │
│ old withdrawal details" │
└────────────────────────────────┘
⚠️ Same-day login password change + withdrawal password change: If a member changed both the login password and the withdrawal password on the same day, they can be moved directly into the "Secondary Verification / Data" tier.
📝 Source: Study & discussion
Deputy Lead Review Flow (WD Team):
Upon receiving a withdrawal order from a "Secondary Verification / Data" tier member:
Withdrawal order received, remark:
"WD requires secondary confirmation,
verify if old withdrawal details"
│
▼
┌────────────────────────────────────┐
│ Verify: which account is the │
│ member withdrawing to? │
└──────────┬─────────────────────────┘
│
┌───────┴───────┐
│ │
Old WD account New WD account
(old withdrawal (new withdrawal
details) details)
│ │
▼ ▼
┌──────────┐ ┌──────────────────────┐
│ ✅ Approve │ │ ❌ Reject withdrawal │
│ · Delete │ │ · Disable withdrawal │
│ remark │ │ function │
│ · Process │ │ · When CS follows up, │
│ payout │ │ require member to │
│ normally │ │ provide screen │
│ · Remove │ │ recording │
│ from │ │ verification: │
│ "Secondary│ │ prove the new │
│ Verifi- │ │ withdrawal account │
│ cation │ │ belongs to them and │
│ /Data" │ │ was self-operated │
│ tier │ │ · After screen │
└──────────┘ │ recording passes │
│ → Process payout │
│ → Remove from │
│ "Secondary │
│ Verification/Data" │
│ → Change to normal │
│ member tier │
└──────────────────────┘
Quick Reference Table:
| Situation | Action | Reason |
|---|---|---|
| Withdrawal to old account (old WD details) | ✅ Delete remark + process payout + remove from tier | Old account indicates the member's own normal withdrawal |
| Withdrawal to new account (new WD details) | ❌ Reject + disable withdrawal + require screen recording verification | New account may have been bound by an account hijacker; member must prove ownership |
| Screen recording verification passed | ✅ Process payout + remove from tier + change to normal tier | Confirmed as the member's own operation |
📝 Source: Study & discussion
5.3 Promotional Event Rules — Quick Answers for Complaints¶
The Deputy Lead doesn't plan events, but CS will forward user questions about event rules. Here is the quick-answer table for complaints:
| Complaint | Quick Answer | Investigation Points |
|---|---|---|
| "Didn't receive weekly reward" | Check Monday 04:00 settlement, deposit threshold, 7-day expiry | Has expiry window passed? |
| "Can monthly reward be recovered after expiry?" | No, system hard-expires | 30-day window is a hard limit |
| "Why do I need to wager before withdrawing?" | All bonuses have turnover requirements — industry-standard anti-arbitrage | Check specific multiplier |
| "Red packet amount decreased" | System distributes random amounts — can be more or less, this is normal | Explain random mechanism to user |
| "Deposited but no red packet eligibility" | Refreshes at 00:00 next day | Confirm deposit time |
| "Reached challenge goal but no reward" | Confirm valid bet amount | Not all bets count 100% |
📘 Source: 06-VIP奖励活动配置 + 07-投注闯关活动详解 + 08-红包雨活动功能
VIP Reward Key Timestamps: - Weekly reward: Settled every Monday at 04:00 Indonesia time, 7 days to claim, expires after - Monthly reward: Settled on 1st of each month at 04:00 Indonesia time, 30 days to claim, expires after
VI. Collaboration & Communication Standards¶
6.1 Group Matrix¶
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Shift Group │ ←──→ │ CS Group │ ←──→ │ Users (App) │
│ (Internal │ │ │ │ │
│ coordination)│ └──────────────┘ └──────────────┘
└──────┬───────┘
│
▼
┌──────────────┐
│ Finance Group │ ← All add/deduct must be reported
└──────────────┘
│
▼
┌──────────────┐
│ Promo Group │ ← Marketing assets, campaign notices
└──────────────┘
📝 Source: Study & discussion
6.2 Notification Matrix¶
| Scenario | Notify CS Group | Notify Finance Group | Post in Group |
|---|---|---|---|
| Permission toggle (no funds) | — | — | ✅ Claim + Done |
| Permission toggle (with add/deduct) | — | ✅ Include amount & user | ✅ |
| Withdrawal rejected (bank maintenance) | ✅ | — | — |
| Withdrawal rejected (invalid account) | ✅ Include rejection reason | — | — |
| Withdrawal rejected (agent arbitrage suspicion) | ✅ Script: "Risk control manual review" (do not reveal anti-fraud details) | — | ✅ Lock audit trail |
| Deduction complete | ✅ Reply to original requester | ✅ Mandatory report | — |
| Order callback | — | — | ✅ Log in spreadsheet |
| Each shift's push complete | — | — | ✅ Check-in audit trail |
📝 Source: Study & discussion
6.3 Claim Protocol¶
| Action | Script | Notes |
|---|---|---|
| Claim | Reply OK or ✅ check on original message |
Quick one-click, visible to group |
| Done | Reply "Done" + key info | e.g., username, amount, operation type |
| Involves funds | Also post to finance group after completion | All add/deduct must be reported |
📝 Source: Study & discussion
VII. Shift Handover Checklist¶
7.1 Taking Over (You Are the Incoming Shift)¶
- [ ] Review the previous shift's spreadsheet — what orders/deductions/callbacks were processed
- [ ] Check unclaimed/unclosed tasks in the group
- [ ] Confirm current active redemption codes are set up and push is configured
- [ ] Verify Firebase scheduled tasks are configured for the next time point
- [ ] Confirm your alarm reminders are set (1 hour before push time)
7.2 Handing Over (You Are the Outgoing Shift)¶
- [ ] Complete all entries in the shift spreadsheet for all orders/callbacks/deductions
- [ ] Post summary of callback order list and total amount in the group
- [ ] Explicitly hand over all unclosed items to the next shift and get their confirmation reply
- [ ] Separately flag anomalies (e.g., system failures, unfinished withdrawals)
- [ ] Confirm redemption codes for the next shift are ready
📝 Source: Study & discussion
VIII. Automation Recommendations¶
8.1 Overall Approach¶
The Deputy Lead's daily work involves massive amounts of N platforms x M times/day routine operations, each step being an error opportunity. API/tooling can provide:
| Aspect | Manual | API/Tool |
|---|---|---|
| Data format | Hand-copied, inconsistent style each time | Schema-enforced consistency |
| Process consistency | Relies on memory, new hires easily miss steps | Code guarantees same every time |
| Error traceability | Dig through group chat + ask involved person | Full audit log |
| Energy consumption | Repetitive tedium → fatigue → more errors | Machines don't tire |
Even without back-office API support, many areas can be improved with local tools to reduce repetition and human error.
8.1.1 Operational Time-Cost Analysis (Deputy Lead First-Person Perspective)¶
The data below comes from actual on-the-job operation, not estimates.
Push notifications are the single largest time sink of the entire shift. 13 platforms, 5 time slots per day, every single time is pure mechanical copy-paste + button clicking. Zero decision-making involved.
| Task | Platforms | Newbie time/session | Experienced time/session | Daily frequency | Group daily total (experienced) |
|---|---|---|---|---|---|
| Firebase push | 13 | ~60 min | ~30 min | 5x | 2.5 hours |
| JPush (5x) + In-App Message (1x, combined) | 13 | ~50 min | ~30–40 min | JPush 5x / In-App 1x | 2.5–3.3 hours |
| Redemption code creation (once per rotation) | 13 | ~30 min | ~15–20 min | 1x | ~15–20 min |
| Push-related total | ~5–6 hours/day |
📝 Source: Study & discussion
Key insight: In a 12-hour day shift, push-related mechanical tasks alone consume 40–50% of the time. The Deputy Lead's role in these tasks is essentially a human copy-paste machine, not a decision-maker.
Before vs. after automation:
| Task | Current (manual) | After automation | Deputy Lead role shift |
|---|---|---|---|
| Firebase push | 30 min × 5 = 2.5h per session | ✅ Tampermonkey automation script developed, greatly reduces copy-paste | Set copy + review delivery results |
| JPush | 13 platforms per session | ✅ Tampermonkey automation script developed, greatly reduces copy-paste | Check delivery effectiveness |
| In-App Message | 19:00 manual send | Back-office upgrade: one-click scheduled send ~5 min/day | Check delivery effectiveness |
| Redemption codes | Manual creation 15–20 min | Back-office auto-generates on schedule + links to push notifications ~0 min | Adjust quantity/amount based on prior day's claim/reach data |
| Total | ~5–6 hours/day | ~15–20 min/day | From executor → monitor + analyst |
📝 Source: Study & discussion
Why redemption codes don't need manual creation: Redemption codes are randomly generated 4-character codes. Humans are no more reliable at "generating random numbers" than code, and in fact manual copy-paste operations are more error-prone (pasting to the wrong platform, mistyping the code, forgetting to update old codes in push notification copy). The back-office could: auto-generate codes daily on schedule → auto-link to JPush and In-App Message → humans only need to adjust redemption quantity and amount based on each site's prior-day claim and reach data.
Where the freed-up time should go: - Pay-in/pay-out channel success rate monitoring — requires human judgment on channel health and anomaly trend identification - Withdrawal review deep investigation — agent anti-arbitrage review requires experience and judgment - Finance anomaly order analysis — identifying human errors requires cross-referencing two systems - Data analysis and operations optimization — analyzing push effectiveness and adjusting strategies is more valuable than executing pushes
One-line summary: Free people from "doing what machines should do" so they can do "what only humans can do."
8.2 Tool Inventory¶
| # | Tool | Pain Point | API Required? | Priority | Notes |
|---|---|---|---|---|---|
| T1 | Redemption Code Copy Generator | Manual copy replacement for N platforms | No (pure frontend/Sheets) | ⭐⭐⭐ | Easiest quick win |
| T2 | Reward Distribution Data Pipeline | Export → filter → calculate → fill template | No (Python/Node) | ⭐⭐⭐ | Biggest time saver |
| T3 | SMS List Filter Tool | Manual phone number filtering | No (Python/Excel macro) | ⭐⭐ | |
| T4 | Push Cadence Reminder | Relying on memory for timing | No (cron/phone alarm) | ⭐⭐ | |
| T5 | Subordinate Behavior Pattern Detector | Auto-detect subordinate deposit/turnover patterns | Yes | ⭐⭐ | |
| T6 | Push Copy Rotator | Manual fixed text selection | No (local tool) | ⭐⭐ | No repeat within 24h |
| T7 | Multi-platform push automation | Firebase/JPush xN sites mechanical copy-paste | No (Tampermonkey) | ⭐⭐⭐⭐ | ✅ Firebase + JPush Tampermonkey scripts ready |
| T8 | Dep-Wdl Spread Monitor & Alert | Check daily report per platform + mental math | Yes | ⭐⭐⭐⭐⭐ | |
| T9 | 20:00 Linked (Inspection + Rebate) | Single cron for inspection + rebate | Yes | ⭐⭐⭐⭐⭐ | Merge with T8 |
| T10 | Withdrawal Notes Auto-Decision Engine | 8 notes x 3 scenarios x 4 hard rules | Yes | ⭐⭐⭐⭐ |
Implementation Tiers:
┌─────────────────────────────────────────────────┐
│ ✅ Already in Place │
│ T7 Multi-platform Push (Tampermonkey) │
└─────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────┐
│ Immediately Doable (No API) │
│ T1 Copy Gen T2 Data Pipeline T3 List Filter │
│ T4 Cadence Reminder T6 Copy Rotator │
└───────────────────┬─────────────────────────────┘
│ After gaining experience
▼
┌─────────────────────────────────────────────────┐
│ Requires Backend Support (API) │
│ T5 Behavior Pattern T8 Spread Monitor │
│ T9 20:00 Linked T10 Notes Decision │
└─────────────────────────────────────────────────┘
Detailed technical designs and API requirements spec at: 12-自动化路线图/
8.3 Automation Annotations Summary by Workflow¶
| Section | Automation Opportunity | Corresponding Tool |
|---|---|---|
| 3.1 Push notification | ✅ Tampermonkey scripts ready, greatly reduces Firebase/JPush copy-paste | T7 |
| 3.2 Redemption Codes | Copy rotator, no repeat within 24h | T6 |
| 3.3 Marketing SMS | Fixed filters + fixed copy, one-click export | T3 |
| 3.3 Batch Suite (SMS + Bonus) | Full data pipeline, biggest time saver | T2 |
| 3.5 Dep-Wdl Spread + Rebate | Read data → compare threshold → send notification — purest automation | T8+T9 |
| 4.1 Withdrawal Review | Rule engine replaces human memory | T10 |
| 4.1.5 Agent Review | Auto-detect subordinate behavior patterns | T5 |
IX. Pending Confirmation Checklist¶
Truly open items only. Other items previously on this list have been integrated into the main text or are already covered by the tools/ toolkit.
9.1 Withdrawal Password Reset Limit¶
- [ ] Failure-attempt limit on withdrawal password reset? (Possible lead in 11-User Lock List)
9.2 Complete Lock-Type List¶
- [ ] Full list of all lock types in the User Lock List referenced from 5.2.2. (Main text only confirms login / betting / withdrawal as the common ones; defer to the platform manual for the complete list.)
9.3 Disbursement Timeout¶
- [ ] Details of the third-party channel's retry / callback mechanism after 4.11 disbursement interface timeout? (Deputy Lead currently only does "check status + Re-payout / Merchant Paid" UI ops; the underlying third-party retry policy needs alignment with tech.)
X. Lessons Learned & Pitfalls¶
Reserved for ongoing additions from daily work. Record each non-obvious lesson or pitfall.
10.1 Pitfalls Encountered¶
| Date | Scenario | Wrong Approach | Correct Approach | Reason |
|---|---|---|---|---|
| — | — | — | — | — |
10.2 Efficiency Improvements¶
| Date | Scenario | Approach | Impact |
|---|---|---|---|
| — | — | — | — |
10.3 Boundary Judgments¶
| Date | Situation | Judgment | Basis |
|---|---|---|---|
| — | — | — | — |
Appendix A · Quick Reference Card (Printable)¶
┌──────────────────────────────────────────┐
│ Push Schedule │
│ ━━━━━━━━━━━━━━━━━━━━ │
│ Night 00:00 │
│ Day 11:00 / 15:00 / 19:00 / 21:00 │
│ │
│ Each push = Firebase(auto) + JPush │
│ (manual); 19:00 also + In-App Msg │
│ + Delete old In-App Msg │
│ │
│ In-App Msg must paste HTML via │
│ code editor │
│ │
│ Set alarm 1 hour in advance! │
└──────────────────────────────────────────┘
┌──────────────────────────────────────────┐
│ Withdrawal Order Notes Quick Ref │
│ ━━━━━━━━━━━━━━━━━━━━ │
│ 1 Agent Wdl ......... Go to 4.1.5 flow │
│ 2 Tier not allowed .. Full acct audit │
│ 3 Auto-payout fail .. Query status→act │
│ 4 Exceeds max ....... Full audit flow │
│ 5 2min x 4 ......... First: balance→act │
│ 6 1st wdl low turnov Direct approve │
│ 7 Channel limit ..... Check merchant→ │
│ switch wallet │
│ 8 Disbursement fail . Query order status │
│ + confirm w/ 3rd │
└──────────────────────────────────────────┘
┌──────────────────────────────────────────┐
│ Withdrawal Order: Lock First! │
│ ━━━━━━━━━━━━━━━━━━━━ │
│ Agent wdl → Arbitrage review flow → │
│ Majority-vote verdict │
│ Regular auto-fail → Check order status │
│ · Account issue → Act by status │
│ · Bank maintenance → Reject + notify CS│
│ · Channel limit → Check w/ merchant │
│ · Tier no auto → Full audit first │
└──────────────────────────────────────────┘
┌──────────────────────────────────────────┐
│ Deduction Processing Flow │
│ ━━━━━━━━━━━━━━━━━━━━ │
│ Claim → Check balance → Deduct → │
│ Reply CS │
│ → Report to finance group │
│ (Platform/ID/Amount/Reason) │
└──────────────────────────────────────────┘
Appendix B · Related Document Index¶
Industry General Knowledge (Sections 00-10)¶
- 04-运营体系/03-奖励体系设计 — Reward amounts, turnover requirements, anti-abuse strategies
- 04-运营体系/05-客服运营 — Complete workflow for CS team collaboration
- 06-合规法务/02-KYC与AML — Compliance background for withdrawal review
- 07-财务支付/02-支付体系与通道 — Technical background on why auto-payout fails
- 10-业务知识库/00-通用管理知识/01-团队管理基础 — How the Deputy Lead conducts 1:1s and team building
- 10-业务知识库/00-通用管理知识/02-远程团队协作 — Async communication, toolchain, timezone management
Feifan Platform Manuals (11-平台手册/非凡包网/)¶
Full index: 11-平台手册/非凡包网/README.md
| # | Document | Corresponding Guide Section |
|---|---|---|
| 01 | 自动出款功能详解 | 4.1.2 |
| 02 | 防恶意注册风控机制 | — |
| 03 | 有效打码计算方式 | 4.5 |
| 04 | 禁止投注问题排查 | 4.6 |
| 05 | 充值订单收回款项 | 4.2 |
| 06 | VIP 奖励活动配置 | 5.3 |
| 07 | 投注闯关活动详解 | 5.3 |
| 08 | 红包雨活动功能 | 5.3 |
Automation Roadmap (12-自动化路线图/)¶
- README — Section overview
- 01-代理提现审核API需求书 — P1 highest priority API
Appendix C · Deputy Lead Toolbox User Guide¶
Tool URL: https://igaming-t1.pages.dev/ Access password: igaming2026 Tech stack: Cloudflare Pages + pure frontend (zero data leakage) Admin password: Contact Bob to obtain (required for editing platform configurations)
Core Principles¶
- Zero data leakage: CSV files / phone numbers / amounts are all processed locally in the browser; refreshing the page clears everything
- Cloud-synced configuration: Formula tiers, platform info, and other business rules sync via CF KV — one person edits, everyone sees the update
- Zero installation: Opens in any browser, no software installation required (except the FCM Tampermonkey script)
C.1 Tool Overview¶
The toolbox contains 14 functional Tabs, covering all repetitive operations for Deputy Lead day and night shifts:
| Tab Name | Icon | Corresponding Workflow | Description |
|---|---|---|---|
| 兑换码 (Redemption Code) | 🎲 | §4.1 Redemption code mgmt | Generate daily 4-digit codes, no repeats within 30 days, cloud-synced |
| 兑换码站内信 (Code In-App Message) | ✉️ | §4.1 In-app message push | Generate in-app message HTML per platform × date (code + deposit promo) |
| SMS 回访 (SMS Callback) | 📱 | §4.2 SMS callback | 3 direction templates with one-click copy, built-in Leet Speak anti-detection |
| 推送文案 (Push Copy) | 🔔 | §4.1 Push notification | Firebase/Jpush push copy (with code + 12 generic activity messages) |
| 新人首充 (New Member First Deposit) | 🎁 | Member inquiry | Enter deposit amount → real-time bonus/wagering calculation → one-click Indonesian script |
| 回访彩金助手 (Callback Bonus Assistant) | 🗄️ | §4.3 Bonus distribution | Upload 3 CSVs → auto-apply formula → output XLSX + TXT |
| 周拉回 (Weekly Pull-Back) | 🔄 | §4.2 Weekly pull-back | Friday prep, Saturday send, 0.88 bonus + phone number TXT |
| 每日返水 (Daily Rebate) | 🪙 | §4.13 Deposit-withdrawal spread inspection | Platforms with >10% spread at 20:00 WIB, deposit amount × 2% rebate |
| 交班汇报 (Shift Handover Report) | 📋 | §4.7 Shift handover | Quick order entry, one-click handover report + cloud archive |
| SMS 测试 (SMS Test) | 🧪 | SMS API verification | Single/batch send testing with send logs and status queries |
| SMS 监控 (SMS Monitor) | 📡 | SMS operations | Today's send summary, failure TOP, Cron polling status, auto-backfill |
| 客损拉回 (Loss Recovery Tracking) | 📊 | Effectiveness tracking | Upload next-day callback CSV to calculate recovery rate, 7-day/30-day trends |
| FCM | 🔥 | §4.1 Push scheduling | Prepare next-day Firebase push Campaigns, works with Tampermonkey auto-fill |
Auxiliary features (top-right corner):
| Feature | Description |
|---|---|
| WIB Clock | Real-time Indonesia time (UTC+7) with countdown to next task |
| Group Switch | Select current platform group (A/B/...), shows only that group's platforms |
| Language Switch | Chinese / English / Indonesian trilingual |
| Admin Button | Enter admin password to unlock platform configuration editing |
| Cloud Sync | Click to manually pull latest cloud configuration |
C.2 Tab-by-Tab Usage Guide¶
C.2.1 Redemption Code Management¶
Function: Generate daily/next-day 4-digit numeric redemption codes for all platforms.
Core rules: - 4-digit numbers, Indonesia-friendly (avoids repeated digits / sequential digits) - No repeats within 30 days for the same platform - No duplicates across all platforms on the same day - Option to prioritize "double-pair digits" (e.g., 5588); falls back to triple digits (e.g., 1888) when insufficient
Steps: 1. Click "生成今日全部" (Generate All Today) → all platforms auto-generate today's codes 2. Click "生成明日全部" (Generate All Tomorrow) → pre-generate tomorrow's codes (for designers to prepare graphics) 3. Click "复制今日" (Copy Today) → all platform codes copied to clipboard 4. Click "复制明日（给美工）" (Copy Tomorrow for Designers) → tomorrow's codes copied for graphic design 5. To modify a single platform's code: click the "修改" (Edit) button on the platform card, enter the new code already set in the backend
Notes: - After generation, a time lock prevents re-generation on the same day (unlocks after 22:00 WIB during shift change) - Re-generation overwrites old codes, affecting designer graphics, backend config, and already-sent copy — proceed with caution - Generated codes sync to cloud; other colleagues can see them by refreshing the page
C.2.2 Code In-App Message¶
Function: Generate two in-app messages per platform (redemption code notification + deposit promotion), ready to copy-paste into the backend.
Steps: 1. Select mode: "单平台" (Single Platform) or "批量全部" (Batch All) 2. Single platform mode: select platform → click "生成" (Generate) 3. Batch mode: click "一键生成全部" (Generate All) → all platforms' in-app messages generated at once 4. Each platform generates two cards: - In-App Message ① · Redemption Code: includes platform name, code, social links; 15 copy variants auto-rotate by date - In-App Message ② · Deposit Promotion: colored HTML template (red title + bold black body) 5. Click "复制（带格式）" (Copy with Formatting) → paste into backend rich-text editor with colors/bold/links preserved 6. Click "源码" (Source Code) → copy raw HTML, requires switching to "code mode" in the backend editor
Notes: - Redemption codes come from codes already generated in the "兑换码" Tab; to change them, go there first - 15 copy variants rotate on a day 1-15 / 16-30 dual-cycle, switching automatically each day - If a platform is missing its original copy template, a fallback warning will appear
C.2.3 SMS Callback¶
Function: Generate SMS copy per platform by callback direction, with a batch sending pool.
3 callback directions:
| Direction | Target Users | Copy Field | Main Promotion |
|---|---|---|---|
| A · Not Deposited | Registered but never deposited | smsText1 | First deposit 100% + 88K code + 99K red envelope rain + spin 1000K |
| B · Has Deposited | Has deposit records (loss/yesterday-deposit/day-before shared) | smsText2 | 30X lucky bonus + VIP 100,000K + mission 9,999K |
| ZLH · Weekly Pull-Back | Registered within 30d + inactive 10+d + deposits ≥ 2 | smsTextZlh | Prepared Friday, sent Saturday, dedicated copy |
Steps: 1. Select callback direction (A / B / ZLH) 2. Page auto-displays all platforms' corresponding copy + mobile preview simulation 3. Click the copy button on each platform card to get the copy 4. Batch Sending Pool (purple section below): - Select data date → shows that day's pending send list - Check items to send - Configure test phone number (verify delivery) - Click "一键发送已勾选" (Send All Checked)
SMS copy auto-matching rules (batch sending pool):
- sms source → Not Deposited copy A
- kslh / czlh / lh source → Has Deposited copy B
- zlh source → Weekly Pull-Back copy
Notes:
- Copy has built-in Leet Speak anti-detection (e.g., k0de, cuma2, ga..c0r) — do not "correct" them
- Before sending, verify API connectivity in the "SMS 测试" Tab first
- Manual TXT import is in the collapsible panel, used for re-sends / manual import corrections
C.2.4 Push Copy¶
Function: Generate push copy for Firebase (Android/PWA) and Jpush (iOS).
Two modes:
Mode 1 · Push with Redemption Code (per platform × date): 1. Select batch (5 batches per day, each batch randomly assigned different copy variants) 2. Each platform shows Firebase and Jpush copy 3. No repeats across batches for the same platform; no repeats across platforms within the same batch 4. Click copy buttons to get Title / Firebase / Jpush copy separately
Mode 2 · Generic Activity Copy (12 items, no redemption code): - VIP permanent salary, Rebate 3%, Agent plan 5%, Daily relief fund 25% - Generic redemption code, Check-in 128K, Invite friends 25K, Deposit reward 2500K - Weekly Cashback 30%, Refer friend 1000K, Download APP 5000K, Cumulative deposit 2500K
Steps: 1. Switch to "推送文案" (Push Copy) sub-tab → select batch 2. On each platform card, click "标题" (Title), "Firebase", "Jpush" to copy separately 3. Advanced: manually specify copy variant (expand collapsible panel)
C.2.5 New Member First Deposit Bonus Calculator¶
Function: Quickly look up the bonus and wagering requirements for a given deposit amount during member inquiries.
9-tier rules:
| Tier | Min Deposit (K) | Bonus % | Wagering Multiplier |
|---|---|---|---|
| A | 10 | 20% | 3x |
| B | 30 | 25% | 5x |
| C | 50 | 30% | 6x |
| D | 100 | 35% | 7x |
| E | 300 | 50% | 9x |
| F | 500 | 60% | 11x |
| G | 1,000 | 70% | 12x |
| H | 5,000 | 80% | 13x |
| I | 10,000 | 100% | 15x |
Steps: 1. Enter deposit amount (unit: K, 1K = 1,000 IDR) 2. Real-time display: matched tier, bonus amount, playable principal, wagering requirement 3. Click "复制印尼语话术" (Copy Indonesian Script) → send directly to the member
Wagering formula: TO requirement = (Deposit + Bonus) × Wagering Multiplier
C.2.6 Callback Bonus Assistant (Day-Shift Core Tool)¶
Function: Upload 3 backend-exported CSVs, auto-filter / apply formula / deduplicate, output Treasure Box XLSX + phone number TXT.
Steps: 1. Step 1: Select platform 2. Step 2: Upload 3 CSVs: - ① Export A · 用户回访 (User Callback, T-1 registration) - ② Export B · 用户统计 (User Statistics, T-1 members) - ③ Export C · 用户统计 (User Statistics, T-2 members) 3. Step 3 (optional): Expand to view/modify formula and tier configuration 4. Step 4: Click "一键处理" (Process All) 5. Step 5: Download output files
Formula explanation (see C.3 Configuration Guide for details):
- Input field: profit_loss (deposit-withdrawal spread), NOT deposit
- Losers (spread < 0): fixed bonus 0.38
- Winners: matched to 9-tier ladder by spread, max 777.77
- Output XLSX columns: Member ID / Treasure Box Reward Amount / Wagering Multiplier (default 1) / Recharge Doubling (default "开启" / Enabled)
Privacy policy: - Sensitive data (CSV containing member IDs / phone numbers) → parsed client-side in browser memory only; cleared on refresh - Formula configuration → synced via CF KV (business rules, non-sensitive)
C.2.7 Weekly Pull-Back¶
Function: Weekly task prepared on Friday, distributed on Saturday.
Filtering criteria (division of labor): - Pre-filtered in backend (before export): ① Registered within 30 days ② Last online > 10 days ago - Auto-filtered by tool (after upload): ③ Deposit count ≥ 2 (anti-arbitrage / anti-abuse)
Steps: 1. Set reference date (default: today), select platform 2. Set bonus amount (default: 0.88) 3. Upload the user callback CSV pre-filtered by backend criteria (supports multi-select for split files) 4. Click "一键处理" (Process All) → output bonus XLSX + phone number TXT 5. Helper: expand "日期计算器" (Date Calculator) to view 30-day filter timestamps
C.2.8 Daily Rebate¶
Function: 20:00 WIB deposit-withdrawal spread inspection; execute rebate for platforms with spread > 10%.
Formula: Bonus = Deposit Amount × 0.02 (default 2%)
Steps: 1. Select platform 2. Confirm rebate ratio (default: 0.02) 3. Upload the platform's user statistics CSV for the day 4. Click "一键处理" (Process All) 5. Tool auto-processes: filter deposit amount > 0 → calculate bonus → remove zero-bonus rows → output Treasure Box XLSX
Notes: - Prerequisite: only execute for platforms where the backend daily report shows spread > 10%; the tool itself does not make this judgment - Does not deduplicate with §4.3 callback bonuses; distributed independently
C.2.9 Shift Handover Report¶
Function: Quickly enter orders processed during the shift, generate a handover report with one click and archive to cloud.
Steps: 1. Enter the handover person's name (auto-saved) 2. Select platform → enter order number → press Enter to quick-add (1 order = 10K) 3. Batch mode: expand collapsible panel → paste multiple order numbers 4. Click "交班汇报" (Handover Report) → auto-copy report + cloud archive + clear current list 5. Click "历史归档" (Historical Archive) to query past handover records
C.2.10 SMS Test¶
Function: Verify SMS API connectivity — test single messages first, then batch.
Three sections: 1. Single test: Enter phone number + SMS content → send test → view result 2. TXT batch send: Upload number file + custom copy → batch send (for re-sends / manual dispatch) 3. Send status query: Enter sendCode to check delivery status 4. Send log: Last 20 send records with complete number lists and per-number status
C.2.11 SMS Monitor¶
Function: Full summary and real-time monitoring of today's SMS sends.
Main features: - Today's overview (send volume / success rate / cost) - Test number zone (verify whether your own phone received the message) - Per-platform breakdown statistics - Failure TOP ranking (excluding non-TK carrier numbers) - Cron polling status (persistent queue, auto-consumes and backfills status every minute) - One-click backfill all statuses / manual refresh
C.2.12 Loss Recovery Tracking¶
Function: Track pull-back effectiveness after Bonus Assistant processing.
Steps: 1. Select date (loss occurrence date) 2. Three views: daily detail / 7-day trend / 30-day statistics 3. Click "一键复制汇报" (Copy Report) → generate a recovery effectiveness report for the Team Lead
Data source: The Bonus Assistant automatically archives loss data to cloud during processing.
C.2.13 FCM Console Assistant¶
Function: Prepare next-day Firebase push Campaign data within the toolbox; works with the Tampermonkey script to auto-fill in Firebase Console.
Steps: 1. Set target date (default auto: switches to tomorrow after 22:30 WIB) 2. Page displays all Campaigns to be created (5 time slots × N platforms) 3. Click "下载 Tampermonkey 脚本" (Download Tampermonkey Script) to install the automation script (see C.4) 4. Go to Firebase Console to operate (see C.4)
C.3 Configuration Guide¶
Important: All configuration changes require admin privileges. Click the "管理" (Admin) button in the top-right corner → enter admin password → unlock.
C.3.1 Platform List Management¶
Location: tools/t1-promo-copy/public/js/data.js → DEFAULT_PLATFORMS array
Currently configured with 14 platforms (7777W, RP66, RPRR, RP55, YYRR, SL888, 888R, SL999, 99SL, RP99, 9SL, RK55, VC55, FW66).
Configurable fields per platform:
| Field | Description | Example |
|---|---|---|
id |
Unique platform identifier | '7777W' |
code |
Default redemption code (usually empty, auto-generated by tool) | '' |
social.type |
Social platform type | 'Telegram' or 'Facebook' |
social.color |
Brand color (hex) | '#FF00FF' |
social.url |
Social link URL | 'https://t.me/vip_7777w' |
social.label |
Link display text | 'Link Channel Telegram : ...' |
domain |
Platform domain (used in SMS copy) | 'dge753.com' |
userCount |
Proof count (used in social proof copy) | 18599 |
maxReward |
Maximum reward amount | '88K' or '99K' |
pushImage |
Push icon path | '/api/icon/7777W' |
backendUrl |
Backend URL | 'https://demo.indback789.com/' |
letterHtml |
In-app message HTML template | Contains {KODE} placeholder |
group |
Platform group | 'A' |
smsText1 |
Not-deposited direction SMS copy | Leet Speak format |
smsText2 |
Has-deposited direction SMS copy | Leet Speak format |
smsTextZlh |
Weekly pull-back SMS copy | Empty means not configured |
textColor |
Text color (special platforms like 9SL use black) | 'black' |
Online modification (recommended): 1. Click "管理" (Admin) → enter password to unlock 2. Edit platform fields directly in the admin panel 3. Click "保存所有修改" (Save All Changes) → auto-syncs to cloud 4. Other colleagues can see updates by refreshing the page
Code modification (for adding new platforms):
1. Edit tools/t1-promo-copy/public/js/data.js
2. Add new platform object at the end of the DEFAULT_PLATFORMS array
3. Deploy: cd tools/t1-promo-copy && npm run deploy
C.3.2 Redemption Code Copy Templates¶
Location: data.js → KODE_VARIANTS array (15 items)
15 copy variants map to monthly dates by day field (1-15); days 16-30 cycle back to 1-15.
Configurable fields per copy variant:
| Field | Description |
|---|---|
day |
Date number (1-15) |
styleKey |
Style key name (e.g., var_urgent) |
title |
Push title template (contains {KODE} placeholder) |
alt_title |
Alternative title for specific platforms |
alt_for |
List of platforms using the alternative title |
body |
Body template (contains {KODE}, {SOCIAL_PLATFORM}, {SOCIAL_LINK}, {USER_COUNT}, {MAX_REWARD} placeholders) |
To modify copy: Edit the corresponding day object in data.js, preserving placeholder format.
C.3.3 Deposit Promotion Template¶
Location: data.js → DEPOSIT_PROMO_TEMPLATE constant
This is the HTML template for the second in-app message, with color styling. When modifying, preserve the {MAX_REWARD} placeholder and HTML style tags.
C.3.4 SMS Callback Direction Configuration¶
Location: data.js → SMS_DIRECTIONS array (3 items)
| Direction ID | Description | Corresponding Copy Field |
|---|---|---|
A |
Not-deposited copy | smsText1 |
B |
Has-deposited copy | smsText2 |
ZLH |
Weekly pull-back copy | smsTextZlh |
To modify direction descriptions or field mappings: edit the SMS_DIRECTIONS array.
To modify a platform's SMS copy content: edit that platform object's smsText1 / smsText2 / smsTextZlh.
C.3.5 Push Activity Copy Configuration¶
Location: data.js → PUSH_ACTIVITIES array (12 items)
Each activity contains:
| Field | Description |
|---|---|
id |
Activity identifier (e.g., vip_salary) |
label |
Chinese label |
title |
Push title |
firebase |
Firebase push copy (Android/PWA) |
jpush |
Jpush push copy (iOS, with emoji) |
To modify activity copy: edit the firebase and jpush fields of the corresponding activity in the PUSH_ACTIVITIES array.
C.3.6 Callback Bonus Formula Configuration¶
Location: tools/data/t2-reward/formula-config.v3.json
Core parameters:
| Parameter Path | Current Value | Description |
|---|---|---|
profiles.default.inputField |
profit_loss |
Input field = deposit-withdrawal spread (NOT deposit amount) |
profiles.default.loserBonus |
0.38 |
Loser fixed bonus |
profiles.default.loserCondition |
profit_loss < 0 |
Loser determination condition |
profiles.default.doubling |
true |
Whether to enable doubling-eligible tiers |
Winner 9-tier ladder (doubling-eligible tiers):
| Tier | Spread Threshold | Bonus |
|---|---|---|
| 1 | >= 44,444,444 | 777.77 |
| 2 | >= 33,333,333 | 577.77 |
| 3 | >= 2,222,222 | 107.77 |
| 4 | >= 1,000,000 | 50.77 |
| 5 | >= 1,000 | 8.80 |
| 6 | >= 500 | 5.50 |
| 7 | >= 200 | 2.80 |
| 8 | >= 50 | 1.80 |
| 9 | >= 10 | 1.08 |
To modify the bonus formula:
1. Edit tools/data/t2-reward/formula-config.v3.json
2. Modify threshold (threshold) or payout (bonus) in the tiersDoubling array
3. To modify the loser bonus, change the loserBonus value
Output XLSX template configuration:
| Parameter Path | Description |
|---|---|
rewardTemplate.defaults.wagerMultiplier |
Wagering multiplier, default 1 |
rewardTemplate.defaults.rechargeDoubling |
Recharge doubling, default "开启" (Enabled) |
rewardTemplate.filterBonusZero |
Whether to filter out zero-bonus rows, default true |
rewardTemplate.platformOverrides |
Platform-specific override configuration (reserved) |
C.3.7 SMS Fixed Bonus Configuration¶
Location: tools/data/t3-sms/sms-bonus-config.v1.json
| Platform | Fixed Bonus | Notes |
|---|---|---|
| 7777W | 0.2 | Confirmed |
| RP66 | 0.2 | Confirmed |
| RP55 | 0.2 | Confirmed |
| YYRR | 0.1 | Original doc ambiguous, tentatively set to 0.1 |
| Others | null | Pending confirmation, defaults to 0.1 |
C.3.8 New Member First Deposit Tier Configuration¶
Location: index.html → BONUS_TIERS constant (around line 3115)
To modify tier rules: edit the min (minimum deposit), pct (bonus percentage), and to (wagering multiplier) of each object in the BONUS_TIERS array.
C.3.9 Deployment¶
After all code file modifications, deployment is required for the whole team to see updates:
cd tools/t1-promo-copy
npm run deploy
Deployment uses Cloudflare Wrangler, configured in wrangler.toml:
- Project name: igaming-t1
- Output directory: public/
- KV binding: T1_DATA (multi-client shared data store)
Online modifications (platform info changed via admin panel) do not require deployment — saving auto-syncs to KV.
C.4 Firebase Push Automation Script¶
C.4.1 Overview¶
3F Firebase Console Helper is a Tampermonkey userscript (current version v5.7.11) that auto-injects an assistant overlay on the following pages:
- Firebase Console (
console.firebase.google.com): Push Campaign auto-fill - Platform Backend (
*.indback789.com/*.indback666.com): Jpush push assistant + agent audit
C.4.2 Installation Steps¶
- Install the Tampermonkey browser extension: https://www.tampermonkey.net/
- Important: After installation, go to Tampermonkey settings → change Site access to "On all sites" (otherwise the script will not auto-run)
- Obtain the script (two options):
- In the toolbox "FCM" Tab, click "下载 Tampermonkey 脚本" (Download Tampermonkey Script)
- Visit https://igaming-t1.pages.dev/3f-fcm-console-helper.user.js directly
- Tampermonkey pops up an install confirmation → click "Install"
- Auto-update:
@updateURLand@downloadURLare already configured to the toolbox URL
C.4.3 Firebase Console Usage Flow¶
The script displays a red/green badge (draggable) in the top-right corner of the Firebase Console page, and an operation overlay on the right side of the page.
Recommended workflow: 1. In Firebase Console, Duplicate yesterday's Campaign (inherits Target + image) 2. Enter the edit page 3. Find the corresponding batch in the right-side overlay → click the "🔥 Fill In" button 4. The script auto-fills title, body, and other fields 5. Manually modify the date (schedule for the target date) 6. Click Publish → return to the overlay and click "✅ Done"
Date modes (three buttons at top of overlay): - ⏱ Auto: Automatically switches to tomorrow after 22:30 WIB - 📅 Today: Force use today's data - ➡️ Tomorrow: Force use tomorrow's data
C.4.4 Platform Backend Features¶
On platform backend pages, the script auto-detects which platform you're on (via hostname mapping) and provides: - Jpush push page: assists with push content filling - Agent audit page: IP collision detection assistant (disabled by default, requires manual activation)
To enable agent audit (run in F12 Console):
localStorage.setItem('fcm_3f_agent_enabled', '1'); location.reload();
To disable:
localStorage.removeItem('fcm_3f_agent_enabled'); location.reload();
C.4.5 Notes¶
- Both badge and overlay are draggable; positions are auto-saved
- If you cannot see the badge/overlay, check Tampermonkey's Site access setting
- The script uses a DOM lock to prevent duplicate injection
- Supports SPA page navigation (interval-based environment change detection)
C.5 FAQ¶
Q1: Toolbox shows a blank page after opening?¶
- Check whether your network can access Cloudflare (some regions may require a proxy)
- Clear browser cache and retry
- Confirm the URL is https://igaming-t1.pages.dev/
Q2: Redemption code generate button is greyed out?¶
- Codes have already been generated today — time lock is active
- Wait until 22:00 WIB (shift change period) for it to unlock
- Or use the "修改" (Edit) button to manually enter the code already set in the backend
Q3: CSV upload shows a format error?¶
- Confirm it is the original CSV downloaded from the backend "导出" (Export) function
- CSV filename should start with the platform name (e.g.,
SL888-用户统计xxx.csv) - Confirm CSV encoding is UTF-8
- For split-exported multiple files, the 周拉回 (Weekly Pull-Back) Tab supports multi-select
Q4: In-app message loses color formatting after pasting into backend?¶
- Use the "复制（带格式）" (Copy with Formatting) button (not the "源码" / Source Code button)
- Make sure the backend editor is in rich-text mode (not code mode)
- If still not working, use the "源码" button → switch backend to code mode → paste
Q5: SMS sending balance is 0?¶
- Contact Bob to top up the AboSend account
- Check the balance card in the "SMS 测试" (SMS Test) Tab for current balance
Q6: Tampermonkey script installed but badge not visible?¶
- Confirm Tampermonkey's Site access is set to "On all sites"
- Open F12 console on the target page, search for
[3F-Helper]logs - If you see
重复注入检测 · 跳过(duplicate injection detected · skipped), the script was double-loaded — refresh the page - Check whether the page is Firebase Console or a platform backend (the script only works on these two types of pages)
Q7: Modified data.js but team can't see the update?¶
- Code file changes require deployment:
cd tools/t1-promo-copy && npm run deploy - Platform info changed via admin panel online does not require deployment — saving auto-syncs
Q8: Bonus Assistant results don't match backend data?¶
- Confirm you're using the correct CSV type (用户回访 / User Callback vs 用户统计 / User Statistics)
- Confirm the formula configuration tiers and bonus values match the latest business rules
- Input field is
profit_loss(deposit-withdrawal spread), NOTdeposit(deposit amount) - If in doubt, expand the formula config panel in Step 3 to check current parameters
Q9: Will concurrent operations by multiple colleagues conflict?¶
- Redemption codes: cloud-synced, last save wins. Recommend designating one person per group to generate codes
- Configuration changes: same principle, last save overwrites previous
- CSV processing: purely local computation, no conflicts
- Shift handover reports: archived by handover person's name, no conflicts
Q10: How to backup/restore data?¶
- Admin panel has an "导出 v3 备份" (Export v3 Backup) button to download JSON backup
- "迁移 v3 → v4" (Migrate v3 → v4) is for data migration during version upgrades
- "LS 用量诊断" (LS Usage Diagnostics) shows localStorage usage distribution
📝 Source: Study & discussion