03 · 副组长工作指南（运营值班 Playbook）¶

目标读者：新任运营副组长、需要对齐值班 SOP 的老同事、后续交接人 核心问题：第一天独立值班，就能清楚每个时间点做什么、每个任务如何闭环、踩到异常时找谁定位：岗位操作手册（Playbook），不是岗位说明书（JD）。配合 01-团队管理基础、02-远程团队协作使用作者：Bob ｜ 最后更新：2026-04-12

📚 配套手册：11-平台手册/非凡包网/ —— 12 份主题文档 + 9 个子目录共 79 份子手册（会员与风控 14 / 财务与支付 10 / 活动配置 13 / 营销工具 5 / 活动记录 18 / 推广渠道 11 / 游戏管理 3 / 系统管理 4 / 前台用户端 1），合计 91 份文档

目录¶

一、角色定位与红线
二、每日工作时间线（印尼时间 UTC+7）
工作总清单 · 一页速览
三、节拍任务工作流（A 线）
3.1 推送通知全链路
3.2 兑换码管理
3.3 白班批量任务套件（SMS + 彩金合并）
3.4 周拉回（每周五准备 + 周六发放）
3.5 存提差巡检 + 条件返水
3.6 代收代付渠道管理
四、响应任务工作流（B 线）
4.1 提现订单审核
4.2 扣款处理
4.3 会员权限变更
4.4 订单回调处理
4.5 打码量核查
4.6 禁投问题排查
4.12 开新台子（协助组长）
4.13 财务代付异常订单核查
4.14 卡单补偿 + 拉回（夜班日常）
五、常见问题处理
5.1 会员忘记登录密码
5.2 会员忘记提款密码
- 5.2.3 "二次验证/Data"层级机制
5.3 会员改绑银行卡 / 钱包账号
5.4 活动规则客诉速答
六、协作与通讯规范
七、交接班清单
八、自动化建议
九、待确认问题清单
十、经验积累 & 踩坑
附录 A · 快速参考卡
附录 B · 相关文档索引
附录 C · 副组长工具箱使用指南

一、角色定位与红线¶

1.1 三合一角色画像¶

运营副组长本质是 "营销执行 + 风控二审 + 协作调度" 的三合一角色：

                      ┌─────────────────────┐
                      │   运营副组长（值班）  │
                      └─────────┬───────────┘
                                │
             ┌──────────────────┼──────────────────┐
             │                  │                  │
     ┌───────▼──────┐   ┌──────▼───────┐   ┌──────▼──────┐
     │ 营销执行 ~45% │   │ 风控二审 ~30% │   │ 协作调度 ~25% │
     │ 产出层        │   │ 决策层        │   │ 流程层        │
     │ 用户触达+激励 │   │ 资金/账户二审 │   │ 跨团队协调留痕│
     └──────────────┘   └──────────────┘   └──────────────┘

三合一职责详细对照（覆盖全部正文章节）：

营销执行（产出层）	风控二审（决策层）	协作调度（流程层）
推送通知（Firebase / Jpush 5 次/天 + 站内信 1 次/天）→ 3.1	提现订单审核（含代理反套利审核）→ 4.1	任务认领（防重复，所有 B 线动作前置）→ 4
兑换码管理（设码 / 换码） → 3.2	扣款执行（稽核发现 → 客服沟通 → 用户同意 → 副组长执行） → 4.2	订单回调处理（按客服/财务/风控通知操作）→ 4.4
SMS 用户回访（注册未充值 + 客损拉回）→ 3.3	会员权限变更（开/关投注 / 提现 / 登录）→ 4.3	代收代付渠道管理（接班第一件事 + 每小时巡检）→ 3.6
批量宝箱发放（昨日存款 / 前天存昨没存拉回，每日）→ 3.3.4 / 3.3.5	打码量核查 → 4.5	充值成功率监控（每半小时）→ 4.9
周拉回（30 天内 + 10 天未登录 + ≥ 2 次充值，每周）→ 3.4	禁投问题排查 → 4.6	提现 30 分钟未回调处理 → 4.10
存提差条件返水（20:00 · 0.02 比例 · 组长确认）→ 3.5	密码重置（登录密码 + 提款密码 · 含社工防御 + 二次验证/Data 层级审核）→ 5.1 / 5.2 / 5.2.3	冲正退款订单处理 → 4.8
高峰期最优充值渠道开关（仅新用户，19:00 开 / 03:00 关）→ 3.6 子任务	用户锁定列表解锁（密码重置时联动 + 套利后解锁）→ 5.2.2	代付接口超时订单处理 → 4.11
活动日 RTP 回报率调整 → 4.7	财务代付异常订单核查（人工失误识别）→ 4.13	开新台子协助（域名绑定 + Salesmartly / Telegram 机器人自动化配置）→ 4.12
—	—	财务群报备（每次资金动作必做）+ 客服群响应 + 交接班（早 10:00 / 晚 22:00）

📝 来源：学习讨论

1.2 职责边界——我不是谁¶

角色	不是	原因
活动策划	不决定优惠码金额/数量/文案的策略	兑换码由副组长自行设置，金额/数量等参数按团队规定执行
财务审核	不独立发起扣款决策	稽核团队发现问题→客服沟通→用户同意后副组长二审后执行，完成后财务群报备
一线客服	不直接回复用户咨询	用户问题走客服团队，只处理客服转过来的权限/扣款类

📝 来源：学习讨论

1.3 三条不可逾越的红线¶

为什么这三条是红线（副组长岗位特点决定的最高发风险）：

防重复：副组长操作的全是真金白银——提现审核、扣款、加款、补偿。任何一笔重复执行 = 直接资损。"群内认领"机制就是防止两人同时处理同一单。

防套利：套利金额 = 平台净亏损——套利者把平台资金当本金做对冲，提现走人，平台真实损失。备注 1（代理提款）+ 备注 2（套利观察层级）+ §4.1.5 代理审核都是为这条红线服务。

防断链：副组长每个决策（驳回 / 通过 / 扣款 / 加款）都可能在事后被追溯（资损调查、合规审计、用户投诉）。没留痕 = 没法证明清白——群通告 / 后台备注 / 表格 / 财务报备四类留痕缺一不可。

┌──────────────────────────────────────────────────────────────┐
│                       三条红线                                │
│                                                              │
│  ① 防重复                                                    │
│     群里任务必须"认领后再做"，尤其是会员权限、扣款、订单回调     │
│     重复操作 = 资损                                           │
│                                                              │
│  ② 防套利                                                    │
│     代理提现必须走套利审核（按五条标准）                         │
│     提款自动出款失败 → 不管是不是首提，必须要查询订单的真实状态，根据下面列出的订单状态做相应的处理                 │
│                                                              │
│  ③ 防断链                                                    │
│     每个动作都要留痕：后台备注 / 群内通告 / 表格记录 /          │
│     财务客服通知，方便交班和事后复盘                            │
└──────────────────────────────────────────────────────────────┘

📝 来源：学习讨论

二、每日工作时间线（印尼时间 UTC+7）¶

副组长的工作节奏是两条并行的线：

A 线（节拍任务）：按固定时间点执行，5 次推送 + 佣金 + 短信 + 巡检 + 返水
B 线（响应任务）：提现/权限/扣款/回调等随到随办

  时间(UTC+7)   夜班              白班              动作说明
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  00:00         ████████          ░░░░░░░░          A线 推送 ①（夜班唯一）
                                                    Firebase 自动 + 手动 Jpush（PWA/书签）
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                                    📌 印尼市场高峰 19:00–03:00，夜班推送关键
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  02:00~10:00   ░░░░░░░░          ░░░░░░░░          B线 响应窗口：提现/权限/扣款/回调
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  10:00                           >>                白班接班 + 交接确认
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  10:00~10:15                     ████████          A线 代收代付渠道管理（接班第一件事）
                                                     查 CP/ATM 余额 → 配置代付 → 核对渠道顺序
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  10:15~11:00                     ████████          A线 白班批量任务套件（SMS 回访 + 彩金发放，4 子任务）
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  11:00                           ████████          A线 推送 ②（Firebase + Jpush）
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  15:00                           ████████          A线 推送 ③（Firebase + Jpush）
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  19:00                           ████████          A线 推送 ④（Firebase + Jpush + 站内信）
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  20:00                           ████████          A线 存提差巡检(全平台)
                                                     +-- >10%平台 → 通知主管
                                                     +-- >10%平台 → 触发当日返水(0.02)
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  20:00~20:40                                       巡检(<=15min) + 返水(<=25min)
                                                    必须在 21:00 推送前完成
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  21:00                           ████████          A线 推送 ⑤（Firebase + Jpush）
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  22:00         >>                                  夜班接班 + 交接确认
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

关键心法：Firebase 是自动定时，设置一次到点自己跑；Jpush 必须人肉到点发送（不能预定时），每次推送前 1 小时务必设闹钟；站内信只在 19:00 发一次。

📝 来源：学习讨论

A 线节拍任务速查¶

#	任务	频率	时间点	详见
1	推送通知（Firebase + Jpush + 站内信）	Firebase/Jpush 5 次/天，站内信 1 次/天	Firebase/Jpush: 00:00 / 11:00 / 15:00 / 19:00 / 21:00；站内信: 19:00	3.1
2	兑换码管理	需要更换时	副组长自行设置	3.2
3	白班批量任务套件（SMS 回访 + 彩金发放，4 子任务）	1 批次/天	白班接班后	3.3
4	周拉回（30 天内注册 + 10 天未登录 + ≥ 2 次充值 → 0.88 + SMS）	1 次/周	周五准备，周六发放（与 3.3 一起）	3.4
5	存提差巡检 + 条件返水	1 次/天	20:00	3.5
6	代收代付渠道管理	每日	接班第一件事	3.6

B 线响应任务速查¶

任务	触发方式	详见
提现订单审核	订单到达时	4.1
扣款处理	客服反馈时	4.2
会员权限开/关	客服反馈时	4.3
订单回调处理	群内推送时	4.4
充值成功率监控	每半小时（定时）	4.9
提现 30 分钟未回调	后台提醒时	4.10
代付接口超时订单	后台提醒时	4.11

工作总清单 · 一页速览¶

第一次接班前先看这张图——所有副组长需要负责的工作都在这里，A 线 / B 线只是其中两类。细节展开见后续章节。

副组长职责地图（4 大类）
│
├─ A 线 · 节拍任务（按点执行，优先级最高，不受打扰）
│   │
│   ├─ 📣 推送触达
│   │   ├─ 3.1 推送通知（Firebase/Jpush 5 次 + 站内信 1 次）
│   │   └─ 3.2 兑换码管理（换码时做，不定期）
│   │
│   ├─ 👥 用户运营
│   │   ├─ 3.3 白班批量任务套件（每日 1 批 · 4 子任务：SMS + 彩金）
│   │   └─ 3.4 周拉回（每周 · 周五准备 + 周六发放）
│   │
│   └─ 💰 资金运营
│       ├─ 3.5 存提差巡检 + 条件返水（每日 20:00）
│       ├─ 3.6 代收代付渠道管理（接班第一件事 + 每小时巡检）
│       └─ 3.6 子任务：高峰期最优充值渠道开关（19:00 开 / 03:00 关）
│
├─ B 线 · 响应任务（事件触发，四步：认领 → 执行 → 回复 → 报备）
│   │
│   ├─ 🚨 提现决策链
│   │   ├─ 4.1 提现订单审核（风险最高、决策最复杂）
│   │   ├─ 4.10 提现 30 分钟未回调
│   │   └─ 4.11 代付接口超时订单
│   │
│   ├─ 🔧 账户干预
│   │   ├─ 4.2 扣款处理
│   │   ├─ 4.3 会员权限变更
│   │   ├─ 5.1 会员忘记登录密码
│   │   └─ 5.2 会员忘记提款密码
│   │
│   ├─ 🔁 资金流转
│   │   ├─ 4.4 订单回调处理
│   │   ├─ 4.13 财务代付异常订单核查（人工失误识别）
│   │   └─ 4.14 卡单补偿+拉回（夜班 8 点前，1%彩金+站内信+短信）
│   │
│   └─ 📊 监控告警
│       └─ 4.9 充值成功率监控（每半小时）
│
├─ 🤝 协作类（贯穿全天 + 不定期协助组长）
│   ├─ 交接班（早 10:00 + 晚 22:00，见七）
│   ├─ 群内沟通（客服群 / 风控群 / 财务群 / 值班群，见六）
│   ├─ 财务群报备（每次涉及资金的动作都要报备）
│   └─ 4.12 开新台子协助（域名绑定 + 客服自动化 + 机器人配置）
│
└─ 📚 成长类（长期持续）
    ├─ 学习平台手册（附录 B · 91 份子手册索引）
    ├─ 经验积累（十 · 踩坑 & 提效记录）
    └─ 自动化建议反馈（八 · 工具清单）

按频率分类的总表（跳转链接全量）：

频率	工作项	类型	详见
每日 · 定点推送	推送通知（Firebase/Jpush 5 次 + 站内信 1 次）	A 线	3.1
每日 · 接班第一件事	代收代付渠道管理（配置 + 核对）	A 线	3.6
每日 · 每小时	代收代付渠道余额巡检	A 线	3.6 子任务
每日 · 白班接班后	白班批量任务套件（SMS + 彩金 4 路）	A 线	3.3
每日 · 20:00	存提差巡检 + 条件返水	A 线	3.5
每日 · 19:00 开 / 03:00 关	高峰期最优充值渠道（仅新用户）	A 线	3.6 子任务
每日 · 每半小时	充值成功率监控	B 线	4.9
每日 · 事件触发	提现审核 / 扣款 / 权限 / 回调 / 密码重置	B 线	4.1 / 4.2 / 4.3 / 4.4 / 5.1 / 5.2
不定期 · 财务群触发	财务代付异常订单核查（人工失误识别）	B 线	4.13
每日 · 夜班 8 点前	卡单补偿+拉回（1%彩金+站内信+短信）	B 线	4.14
不定期（换码时）	兑换码管理	A 线	3.2
不定期 · 组长通知	开新台子协助（域名绑定 + 客服自动化 + 机器人配置）	协作	4.12
每周 · 周五+周六	周拉回（30 天内+10 天未登录+≥2 次充值）	A 线	3.4
持续	交接班 / 群沟通 / 财务报备	协作	六 / 七
持续	学习 / 积累 / 自动化反馈	成长	八 / 十 / 附录 B

三、节拍任务工作流（A 线）¶

3.1 推送通知全链路（Firebase + 极光 + 站内信）¶

整个推送任务分为三个阶段。每次拿到新的优惠码时执行阶段一和阶段二（一次性），之后每天按 5 个时间点反复执行阶段三。

三个推送渠道目标用户不同，频率也不同：

渠道	目标用户	频率	时间点
Firebase（FCM）	APK 用户（Android 原生包）	5 次/天	00:00 / 11:00 / 15:00 / 19:00 / 21:00
极光推送（Jpush）	PWA / 书签用户（iOS + Android，只要装了 PWA 都能收）	5 次/天	00:00 / 11:00 / 15:00 / 19:00 / 21:00
站内信	所有登录用户（Web + App）	1 次/天	19:00

关于"极光推送"的含义：后台菜单叫"极光推送"，但它的目标是 PWA / 书签用户（把站点加到主屏幕的用户），设备系统不限——iOS 和 Android 只要装了我们的 PWA 都会收到。它和 Firebase（面向原生 APK）是两条独立通道。

为什么时间点都是 00:00 / 11:00 / 15:00 / 19:00 / 21:00？ 印尼市场用户高峰期是 19:00–03:00（晚间娱乐黄金档），这几个时间点覆盖上线前预热、白天持续触达、高峰期集中触达。Firebase 和 Jpush 五个时间点都发，站内信只在 19:00 发一次——保证不同设备形态的用户都能被覆盖。 11 点是普通上班族午饭时间，可能会经常检查手机。15 点是很多印尼官员下班时间，也比较容易触达。

┌─────────────────────────────────────────────────────────────────┐
│                       全链路一览                                 │
│                                                                 │
│  阶段一：准备（每次换新码时做一次）                               │
│    副组长设码 → 发UI做图 → 下载图 → 重命名 → 后台创建 → 更新文案库 │
│                                                                 │
│  阶段二：排程（每次推送前，空闲时提前配好下一个时间点）            │
│    十几个平台逐一在 Firebase 配置定时任务（可复制旧任务修改）      │
│                                                                 │
│  阶段三：执行                                                    │
│    00:00 → Firebase + Jpush                                      │
│    11:00 → Firebase + Jpush                                      │
│    15:00 → Firebase + Jpush                                      │
│    19:00 → Firebase + Jpush + 站内信                              │
│    21:00 → Firebase + Jpush                                      │
│    注意：每次发新站内信前，先删旧站内信                           │
└─────────────────────────────────────────────────────────────────┘

阶段一 · 准备：需要更换兑换码时做一次¶

  副组长自行决定新码
        │
        │  (1) 设置兑换码（新站用站点名如SL888，之后用随机四位数字）
        ▼
  ┌───────────────────────┐
  │ (2) 发给 UI 团队做图   │  ← 提供兑换码，UI 出营销图
  └────────┬──────────────┘
           │
           ▼
  ┌───────────────────────┐
  │ (3) 下载图片到本地      │
  └────────┬──────────────┘
           │
           ▼
  ┌───────────────────────┐
  │ (4) 图片重命名为"平台名" │  ← 规范化，方便下一棒值班识别
  └────────┬──────────────┘
           │
           ▼
  ┌───────────────────────┐
  │ (5) 发送到团队群       │  ← 同步信息，避免重复下载
  └────────┬──────────────┘
           │
           ▼
  ┌───────────────────────────────────────┐
  │ (6) 进入每个平台后台，创建新兑换码：    │
  │     · 生成数量：1 个                   │
  │     · 单码使用次数：50,000             │
  │     · 使用对象：当天充值用户            │
  │     · 金额：1-2 之间随机               │
  │     · 打码量 = 金额                    │
  │     · 把系统自动设的兑换码改为我们设的     │
  │     · 复核兑换码是否输入正确            │
  └────────┬──────────────────────────────┘
           │
           ▼
  ┌───────────────────────────────────────┐
  │ (7) 更新 Google 表格"推广文案库"       │
  │     将新码替换进对应平台的文案模板      │
  └───────────────────────────────────────┘

关键参数表：

参数	当前值	备注
生成数量（兑换码个数）	1	每次只创建 1 个兑换码，所有平台统一
单码使用次数	50,000	同一个兑换码可被最多 5 万个会员领取
使用对象	当天充值用户	后台筛选条件默认值
金额区间	1 ~ 2（随机）	新平台从 2.2 开始逐步下调至 1.0，之后在 1-2 随机
打码倍率	1x（= 金额）	流水要求
Firebase 推送频次	5 次/天（APK/Android 原生）	00:00 / 11:00 / 15:00 / 19:00 / 21:00
极光推送频次	5 次/天（PWA/书签，iOS+Android）	00:00 / 11:00 / 15:00 / 19:00 / 21:00
站内信推送频次	1 次/天（全端登录用户）	19:00

📝 来源：学习讨论

🤖 自动化进展：Firebase 和极光推送已开发 Tampermonkey 自动化脚本工具，可极大减少机械复制粘贴工作，节省时间提高效率。技术方案沉淀在 02-技术体系/16-firebase/。注意：当前推送时点（整点）落在 FCM 全球流量高峰，建议平移 +3 分钟避开拥堵。

阶段二 · 排程：在 Firebase 配置定时任务¶

重要：不是一次性配好 5 个时间点的任务。实际操作是每次只配下一个时间点，利用空闲时间提前配好。因为有十几个平台都要逐个配置，工作量不小，所以各班次自己负责自己时段的配置。

为什么不一次配好 5 个时间点： - 灵活应对临时变更——优惠码或文案可能当天调整，逐次配避免一次配死 - 工作量散布在全天——避免某个班次的工作量峰值 - 容错能力——某次配置出错只影响那一个时间点，不会整天毁

  当前推送完成后（或空闲时间）
        │
        ▼
  ┌───────────────────────────────────────────┐
  │ 对每个平台（十几个）逐一配置下一个时间点：  │
  │                                           │
  │  进入该平台的 Firebase Console              │
  │         │                                 │
  │         ▼                                 │
  │  复制上一轮的定时任务（省时）                │
  │         │                                 │
  │         ▼                                 │
  │  编辑：                                    │
  │   · 标题 → 从 Google 文案库复制             │
  │   · 内容 → 从 Google 文案库复制             │
  │   · 图片 → 对应平台的图（检查！）            │
  │   · 时间 → 下一个节拍点                     │
  │         │                                 │
  │         ▼                                 │
  │  复核：平台名↔图片↔文案↔优惠码 是否一致     │
  │         │                                 │
  │         └→ 下一个平台，重复以上步骤          │
  └───────────────────────────────────────────┘

各班次分工：

班次	负责配置的推送时间点	配置时机
夜班	00:00 的推送	接班后空闲时配好
白班	11:00 / 15:00 / 19:00 / 21:00	每次推送完成后，利用空闲提前配下一个

高频踩坑点：

踩坑场景	后果	预防措施
图片张冠李戴	推 A 平台的通知却用了 B 平台的图	每个平台配完后对照平台名称复查一遍
文案里优惠码没同步更新	用户领到过期码	以 Google 文案库为唯一来源（Single Source of Truth）
Firebase 时区设错	推送时间偏移	Firebase 按印尼时区（UTC+7）设置，不需要换算
漏配某个平台	该平台用户收不到推送	配完后对照平台清单逐一打勾确认

📝 来源：学习讨论

阶段三 · 执行：到点发送¶

原理：Firebase 和 Jpush 都是 5 次/天（00:00 / 11:00 / 15:00 / 19:00 / 21:00），站内信只在 19:00 发（1 次/天）。到点按渠道各自频率发。

各时间点动作对照表：

时间点	Firebase（APK/Android）	Jpush（PWA/书签）	站内信（全端）	备注
00:00	✅ 自动触发	✅ 手动发	—	夜班唯一一次
11:00	✅ 自动触发	✅ 手动发	—
15:00	✅ 自动触发	✅ 手动发	—
19:00	✅ 自动触发	✅ 手动发	✅ 手动发	站内信仅此时发
21:00	✅ 自动触发	✅ 手动发	—	白班最后一次

  T-60 分钟（设闹钟提前准备）
         │
         │  Jpush 不能预定时，必须人工守着到点发
         │  站内信仅 19:00 需要准备
         ▼
  准备推送：
    · 打开后台 Jpush 页面（草稿准备好）
    · 19:00 时：打开后台站内信页面（HTML 粘贴好）
    · Firebase → 阶段二已排好定时，不用人工操作
         │
         ▼
  T-0：到点发送：
    ┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
    │ ① Firebase       │  │ ② Jpush          │  │ ③ 站内信          │
    │ （自动触发）       │  │ 点"发送"按钮      │  │ · 开启代码编辑器  │
    │ 5 个时点全发       │  │ 5 个时点全发       │  │ · 覆盖粘贴 HTML   │
    │ （APK/Android）   │  │ （PWA/书签）      │  │ · 点发送           │
    │                  │  │                  │  │ · 删除旧站内信     │
    │                  │  │                  │  │ 仅 19:00           │
    └──────────────────┘  └──────────────────┘  └──────────────────┘
         │
         ▼
  T+5：在值班群打一条 "已发 HH:MM 推送（Firebase + Jpush [+ 站内信]）"

避坑提醒：

00:00 / 11:00 / 15:00 / 21:00 只发 Firebase + Jpush，不发站内信
仅 19:00 三个渠道都发（站内信每天只此一次）
Jpush 不能预定时，必须人肉到点发，每次提前 1 小时设闹钟
站内信每次发新的前先删旧站内信，避免堆积
交接班时务必确认对方知道站内信只在 19:00 发一次

📝 来源：学习讨论

3.2 兑换码管理¶

兑换码由副组长负责为每个平台设置，设置好后发给 UI 团队制作推送图片，然后进入推送流程。

兑换码命名规则¶

场景	命名方式	示例
新站点	直接使用站点名称	SL888
后续更换	随机四位数字	3847

完整流程¶

  副组长为每个平台设置兑换码
  （新站用站点名，之后用随机四位数字）
  【已可以直接用自动工具批量创建和管理】
        │
        ▼
  ┌───────────────────────────────┐
  │ (1) 后台创建兑换码              │
  │     参数见下方表格              │
  └────────┬──────────────────────┘
           │
           ▼
  ┌───────────────────────────────┐
  │ (2) 将兑换码发给 UI 团队       │
  │     UI 制作对应平台的推送图片   │
  └────────┬──────────────────────┘
           │
           ▼
  ┌───────────────────────────────┐
  │ (3) 收到图片后下载+重命名      │
  │     按平台名重命名，发团队群   │
  └────────┬──────────────────────┘
           │
           ▼
  ┌───────────────────────────────┐
  │ (4) 更新 Google 表格"推广文案库"│
  │     将新码替换进对应平台文案    │
  └────────┬──────────────────────┘
           │
           ▼
  进入 3.1 阶段二（Firebase 排程）

📝 来源：学习讨论

后台创建参数¶

参数	值	备注
生成数量	1	每次只创建一个兑换码（所有平台统一）
单码使用次数	50,000	同一个兑换码可被最多 5 万个会员各使用一次
使用对象	当天充值用户	后台筛选条件，当前默认值
可兑换金额	1 ~ 2（随机）	后台填写区间，印尼平台的单位都是 K，1 就相当于 1000 印尼盾
打码要求	= 金额（1 倍）	即流水要求等于金额本身
有效期	一天	一般兑换码是夜班接班的时候设置，大概是晚上 22 点以后设置，有效期就设置为第二天的 23:59:59

重要说明：实际上创建兑换码的时候，系统已经自定义生成带数字和字母的四位随机数作为兑换码，但是因为印尼市场用户不习惯带字母的随机数？所以创建了兑换码后，需要点击自定义兑换码按钮，把系统生成的兑换码，改为副组长前面统一设置的兑换码。

新平台策略：新上线平台设置兑换码的可兑换金额从 2.2 开始，逐步下调至 1.0，稳定后在 1-2 随机。

为什么是 1-2 这个区间随机：激励成本平衡——金额太低无吸引力（用户懒得领），太高成本压力大且容易招套利。随机区间也避免了同一金额被批量薅。

📝 来源：学习讨论

与推送文本的关联¶

兑换码创建完成后，必须同步更新 Google 表格"推广文案库"中对应平台的文案模板，确保推送文本里的兑换码是最新的。文案库是 Single Source of Truth——阶段二排程和阶段三执行的文本全部从这里复制。

🤖 自动化机会：推送文本轮转工具——每个平台随机选一条文本，24 小时内不重复使用，确保同一网站每次推送不重复。已构建在 tools/t1-promo-copy/ 小工具中统一管理文案，代码可直接查看复用。

📚 推送文案库：各平台兑换码文案见 07-各平台兑换码文案库；推送排程与活动文案见 06-推送排程与文案库；SMS 回访文案见 09-SMS回访文案库；站内信与系统消息文案见 10-站内信与系统消息文案库

3.3 白班批量任务套件（SMS 回访 + 彩金发放）¶

要做什么：白班接班后跑一个批量套件——从后台拉数据 → 按 4 种筛选分流 → 每路都产出手机号 TXT；其中 3 路（子任务 1/3/4）额外产出彩金 Excel 导入宝箱，子任务 2（客损拉回）只产出 TXT + 客损人数报告 → 最后去 SMS 平台统一发短信。

要达到的目的：覆盖 4 类用户（注册未充值 / 客损 / 昨日有存款 / 前天存昨没存），通过彩金 + SMS 两种方式提升首充转化与留存拉回。

时间点：每日白班接班后（代收代付渠道管理完成后）一次性跑完。

3.3.1 4 个子任务总览矩阵¶

#	名称	数据源	筛选条件	金额逻辑	TXT 文件名（手机号）	XLSX 文件名（彩金模板）	最终 SMS 文本
1	注册未充值	用户回访页 · 昨天注册	存款=0 + 投注=0 + 备注空	周一至五 0.2 / 周六日 0.3	`MMDD+sms+平台.txt`（例：`0108smsRPRR.txt`）	`昨日 MMDD+注册未充值+平台.xlsx`（例：`0107注册未充值RPRR.xlsx`）	未充值用户回访
2	客损拉回	复用子任务 1 的原始表格	有充值 + 0 投注 + 备注空	—（不发彩金，只发 SMS + 统计客损人数）	`MMDD+kslh+平台.txt`（例：`0108kslhRPRR.txt`）	`平台-MMDD客损:XXX`（人数表，完成后统一发给组长）	客损拉回
3	昨日有存款拉回	用户统计页 · 昨天	按公式计算；存提差<0 单独送 0.38；去掉彩金=0	团队 Excel 公式（⚠️ 第五档起"可翻倍 vs 不翻倍"公式不同，当前用可翻倍，若切换要换公式）	`MMDD+czlh+平台.txt`（TXT 排除 15 日 / 30 日层级，详见 3.3.4）	`昨日 MMDD+czlh+平台.xlsx`（例：`0107czlhRPRR.xlsx`）	客损拉回
4	前天存昨天没存拉回	用户统计页 · 前天	与子任务 3 中"昨天有存款"会员比对，去掉重复；剩余按与 3 相同公式送彩金；去掉彩金=0	同子任务 3 公式	`MMDD+lh+平台.txt`（TXT 排除 15 日 / 30 日层级，理由同子任务 3）	`昨日 MMDD+lh+平台.xlsx`（例：`0107lhRPRR.xlsx`）	客损拉回

📝 来源：学习讨论

文件命名规则： - TXT（手机号清单） = 今日日期（发送日）+ 类型代号 + 平台名 - XLSX（彩金模板） = 昨日日期（数据来源日）+ 类型描述 + 平台名 - 类型代号：sms（注册未充值）/ kslh（客损）/ czlh（昨日存款）/ lh（前天存昨没存）

3.3.2 子任务 1 · 注册未充值¶

  后台 营销工具 → 用户回访页面 → 筛选昨天注册 → 导出表格
        │
        ▼
  表格内筛选：存款=0 + 投注=0 + 备注为空
        │
        ├─ 复制【手机号】 → 新建记事本 0108smsRPRR.txt
        │
        └─ 复制【用户 ID】 → 填入"导入宝箱"Excel 模板
              │
              ▼
          金额：周一至五 0.2 / 周六日 0.3
              │
              ▼
          Excel 另存为 0107注册未充值RPRR.xlsx
              │
              ▼
  后台 运营配置 → 活动配置 → 【邀请活动】行的「活动配置」按钮
        │
        ▼
  侧边导航 → 进入「导入宝箱配置」页面
        │
        ▼
  【未领取宝箱数量】行点击「查看」→「导入宝箱奖励」
        │
        ▼
  选择刚才保存的 0107注册未充值RPRR.xlsx → 导入完成

共用模板说明：导入宝箱 Excel 模板可以从后台先下载一次模板保存到本地，之后每次清空旧数据填新数据即可复用。

📝 来源：学习讨论

3.3.3 子任务 2 · 客损拉回¶

复用子任务 1 导出的原始表格（不用再次导出），只是换一组筛选条件。

  在子任务 1 的原始表格中，重新筛选：
    【有充值】+【0 投注】+【备注为空】
        │
        ├─ 统计客损人数 → 单独记录到一个表格
        │    文件名：平台名-0108客损：XXX（XXX = 人数）
        │    所有平台都跑完后，统一汇总发给组长
        │
        └─ 复制【手机号】 → 新建记事本 0108kslhRPRR.txt

与子任务 1 的差异：客损拉回不发彩金（不走导入宝箱），只发 SMS + 向组长报告人数。

为什么客损用户不发彩金：客损用户已经在平台充过钱、投过注——SMS 提醒就足够拉回；而新注册未充值用户（子任务 1）和沉睡未存款用户（子任务 3/4）需要"彩金钩子"激励首充或回流。所以策略不同——客损只 SMS 触达，新用户/沉睡用彩金。

📝 来源：学习讨论

3.3.4 子任务 3 · 昨日有存款拉回¶

  后台 营销工具 → 用户统计页面 → 导出昨天会员数据
        │
        ▼
  在导出表格内粘贴「团队维护的彩金公式」
  ⚠️ 第五档起"可翻倍 vs 不翻倍"公式不同，当前统一用【可翻倍】
     若切换为不翻倍版本，要同步替换公式
        │
        ▼
  套用公式到所有行 → 自动算出每人应发彩金
        │
        ├─ 筛选【存提差为负数】的会员 → 单独送 0.38 彩金
        │    （这批是"会员赢钱"的，按固定金额回补）
        │
        ▼
  清除所有筛选 → 重新筛选【彩金 ≠ 0】的会员（去掉彩金=0 的行）
        │
        ▼
  复制【用户 ID + 金额】→ 导入宝箱模板
  表格另存为 0107czlhRPRR.xlsx
        │
        ├─ 另外复制【手机号】 → 记事本 0108czlhRPRR.txt
        │   ⚠️ **生成 TXT 时按层级过滤**：排除 **15 日留存层级 + 30 日留存层级**
        │       的会员手机号（彩金照发，但不发短信，详见下方说明）
        │
        ▼
  走与 3.3.2 相同的"运营配置 → 活动配置 → 邀请活动 → 导入宝箱奖励"路径
  选择 0107czlhRPRR.xlsx → 导入发放

为什么 15 日 / 30 日层级不发短信（彩金照发）：

粘性高自然到访：这两个层级的会员粘性较高，不发短信也会经常上线查看并领取导入宝箱彩金——彩金触达不需要短信加成

节省短信成本：所有平台每日加起来的短信费用是一笔可观开支，对必然会上线的高粘性用户发短信 = 浪费成本

避免打扰：常上线的用户多收一条短信反而是打扰负担，影响用户体验

底层逻辑：随着平台进入正轨，要主动优化各方面的开支——节省不必要的成本以加速回本。仅适用子任务 3 / 4（昨日有存款 / 前天存昨没存）；子任务 1 注册未充值、子任务 2 客损拉回、§3.4 周拉回仍按原规则发 SMS（这些用户粘性低，需要短信触达激活）。

公式位置：可翻倍 / 不翻倍两套公式均已落在 tools/ 目录下的小工具中，副组长可直接查看代码或在工具中套用，无需再手动粘贴。

📝 来源：学习讨论

3.3.5 子任务 4 · 前天存昨天没存拉回¶

目标：挽回前天有存款但昨天断档的流失预警用户。关键在"去重"——两天都有存款的用户已在子任务 3 里送过，不能重复发。去重逻辑（比对前天/昨天两份清单）也已落在 tools/ 小工具里，可直接复用。

  后台 营销工具 → 用户统计页面 → 导出【前天】会员数据
        │
        ▼
  提取"前天有存款"的会员清单
        │
        ▼
  与子任务 3 中"昨天有存款"的会员清单比对
        │
        ▼
  筛选重复项 → 把重复会员【去掉】
  （两天都存过 = 已在子任务 3 发过，这里不再发）
        │
        ▼
  剩余会员 = 前天存 + 昨天没存 → 目标用户群
        │
        ▼
  按【与子任务 3 相同的公式】送彩金
        │
        ▼
  清除筛选 → 重新筛选去掉【彩金=0】的会员
        │
        ▼
  复制【用户 ID + 金额】→ 导入宝箱模板
  表格另存为 0107lhRPRR.xlsx
        │
        ├─ 复制【手机号】 → 记事本 0108lhRPRR.txt
        │   ⚠️ **生成 TXT 时按层级过滤**：排除 **15 日留存层级 + 30 日留存层级**
        │       的会员手机号（彩金照发，不发短信——理由同 3.3.4 子任务 3 末尾说明）
        │
        ▼
  走与 3.3.2 相同的"导入宝箱"路径 → 导入发放

📝 来源：学习讨论

3.3.6 SMS 统一发送（所有子任务完成后）¶

到这里，副组长手上应该有 4 个 TXT 文件（sms / kslh / czlh / lh），加 3 个彩金 XLSX 已导入完成（子任务 1/3/4），子任务 2 的客损人数表已发给组长。

  手上：4 个 TXT + 子任务 2 客损人数表已发组长
        │
        ▼
  ┌─────────────────────────────────────────────┐
  │ ① 插测试号                                  │
  │   每个 TXT 随机混入几个能核对的测试号       │
  │   来源：客服群里问人要 / 交接班时上一棒会给  │
  │        （各站点通常已有固定测试号记录）      │
  │   位置：和真实号码混合，不扎堆开头或结尾     │
  └──────────┬──────────────────────────────────┘
             │
             ▼
  ┌─────────────────────────────────────────────┐
  │ ② 汇总总量                                  │
  │   4 个 TXT 行数相加 = 今日总发送量           │
  │   （渠道报价时要用）                         │
  └──────────┬──────────────────────────────────┘
             │
             ▼
  ┌─────────────────────────────────────────────┐
  │ ③ 文案预检                                  │
  │   把两种文案（未充值回访 + 客损拉回）        │
  │   发给 SMS 渠道 → 查禁词 → 按反馈改文案      │
  │   ⚠️ 禁词表会随运营商策略变，每次发送前都要做 │
  └──────────┬──────────────────────────────────┘
             │
             ▼
  ┌─────────────────────────────────────────────┐
  │ ④ 渠道报价 + 组长审批                        │
  │   总量 → 渠道报价 → 提交组长审批             │
  │   组长通过后才进入发送                       │
  └──────────┬──────────────────────────────────┘
             │
             ▼
  ┌─────────────────────────────────────────────┐
  │ ⑤ 正式发送                                  │
  │   按 TXT ↔ 文本映射（见下表）                │
  │   在 SMS 平台逐个提交发送                    │
  └──────────┬──────────────────────────────────┘
             │
             ▼
  ┌─────────────────────────────────────────────┐
  │ ⑥ 核对测试号                                │
  │   ├─ 全部收到 → 渠道正常，批次 OK           │
  │   └─ 有未收到 → 立即联系渠道排查             │
  │     （渠道故障 / 余量不足 / 禁词触发等）     │
  └─────────────────────────────────────────────┘

号码清单 ↔ SMS 文本映射表（步骤 ⑤ 对应关系）：

号码清单类型	对应 SMS 文本
`MMDD+sms+平台`（子任务 1）	未充值用户回访
`MMDD+kslh+平台`（子任务 2）	客损拉回
`MMDD+czlh+平台`（子任务 3）	客损拉回
`MMDD+lh+平台`（子任务 4）	客损拉回

号码清单文件格式：不同 SMS 供应商要求不同——有的要 .txt 格式，有的要 .xlsx 表格。按供应商要求提供即可，命名规则保持一致。

文本具体内容（含各平台的变体、leet-speak 防禁词写法）见 09-SMS回访文案库，不在本节枚举。

关于两种 SMS 文本的说明：文案按"未充值用户回访"和"有充值客损拉回"分两种主推方向，主要为了规避短信出现敏感信息——两个场景表达上需要针对性区分。具体文案会根据运营商禁词反馈、活动调整等情况不时优化。

📝 来源：学习讨论

3.3.7 共用参数与后台路径速查¶

导入宝箱模板的硬性参数（所有用到宝箱导入的子任务都适用）：

参数	值	说明
打码倍数	1 倍	团队规定
充值翻倍	开启	团队规定（与"第五档可翻倍"公式配套）

参数要变更先跟组长确认，不要自行调整。

后台路径速查：

动作	路径
导出昨日注册用户（子任务 1 基础数据）	营销工具 → 用户回访 → 选昨天注册导出
导出昨日/前天会员数据（子任务 3/4 基础数据）	营销工具 → 用户统计 → 选日期导出
下载导入宝箱模板（首次使用）	运营配置 → 活动配置 → 邀请活动 → 活动配置 → 侧边导航 → 导入宝箱配置
导入宝箱奖励（每次发彩金）	上述导入宝箱配置页 → 未领取宝箱数量行"查看" → 「导入宝箱奖励」按钮

3.3.8 哪些奖励不用副组长操作¶

以下活动已由系统自动结算，不出现在本节批量任务里：

活动	结算时点	领取期限
VIP 升级奖励	达标即时发放	—
VIP 周奖励	每周一凌晨 4:00（UTC+7）	7 天内领取，逾期作废
VIP 月奖励	每月 1 日凌晨 4:00（UTC+7）	30 天内领取，逾期作废
投注闯关	达成投注额即时	依活动配置
红包雨	每日充值后触发，次日 0 点重置	当次有效

本节的"手动批量"专指基于每日存提数据的宝箱彩金发放（子任务 1/3/4）+ 客损 SMS（子任务 2）。

📘 来源：06-VIP奖励活动配置 + 07-投注闯关活动详解 + 08-红包雨活动功能

3.3.9 自动化机会 🤖¶

现状：已实现数据辅助自动化处理（公式套用、去重比对、文件命名统一），落在 tools/ 小工具里。SMS 渠道已确认不开放 API，导出数据、导入宝箱、SMS 平台粘贴这几步仍需手动。

进一步空间： 1. 后台定时任务为符合条件的会员打标签（注册未充值 / 客损 / 昨日存款 / 前天存昨没存），副组长只需按标签导出——需要后台支持 2. 拉数据自动化：需要后台开放 API，目前只能手动导出

SMS API 对接这条路已关闭（渠道侧确认不开放），不再列为候选项。

完整需求盘点见 12-自动化路线图/02-自动化机会盘点。

3.4 周拉回（每周一次 · 周五准备 + 周六发放）¶

为什么周五准备 / 周六发放： - 周五是工作日尾声——用户心理上准备进入周末娱乐时段 - 周六是周末高峰起点——0.88 彩金到账可激发当日首玩 - 周五准备给副组长留时间——审核名单、核对金额、和组长对齐口径，避免周六现做现错

要做什么：每周筛一次"注册 30 天内、连续 10 天以上未登录、至少有 2 次充值"的沉默会员，送 0.88 彩金 + SMS 触达拉回。

要达到的目的：把有过充值、近期没上线的中价值会员召回到站点。

节奏： - 周五：导出数据 → 筛选 → 准备彩金 Excel 和手机号 TXT - 周六：导入宝箱发 0.88，发 SMS（与 3.3 日批量一起做）

3.4.1 周五 · 筛选与导出¶

后台路径：营销工具 → 用户回访页面

筛选条件（三条叠加）：

#	维度	条件	举例（处理当天 = 周五 4/1，前一天 = 周四 3/31）
1	注册时间	以处理当天的前一天（周四）为截止，往前数 30 天	筛 3/1 00:00 – 4/1 00:00 区间内注册的会员
2	最后在线时间	超过 10 天未登录	最后结束在线时间早于 3/22 00:00
3	充值次数	去掉未充值会员 + 去掉仅 1 次充值会员	充值次数 ≥ 2（防套利、防刷子）

筛选结果导出为表格。

3.4.2 周五 · 整理两类产出¶

① 彩金 Excel（周六导入宝箱用）

字段	值
用户 ID	从筛选结果复制
赠送金额	0.88（当前默认值；可能随平台运营情况 / 活动效果调整金额，或整个活动临时暂停——以组长通知为准）

另存为新表格。

② 手机号 TXT（周六 SMS 发送用）

项	值
内容	筛选结果的手机号清单
命名格式	`<站点名>+zlh+<日期>`（`zlh` = 周拉回）

3.4.3 周六 · 发放（与 3.3 一起做）¶

导入宝箱：和 3.3 子任务 3/4 走同一路径（运营配置 → 活动配置 → 邀请活动 → 活动配置 → 侧边导航 → 导入宝箱配置 → "未领取宝箱数量"行"查看" → "导入宝箱奖励"），选周五准备好的彩金 Excel → 导入
SMS 发送：把周拉回的 TXT 和 3.3 的 4 个 TXT 一起提交到 SMS 平台发送

📝 来源：学习讨论

3.5 存提差巡检 + 条件返水（每日 20:00）¶

流程概览：每日 20:00 逐平台看日报表的存提差比例 → 超过 10% 的平台先发清单给组长 → 组长确认是否按 0.02 返水 → 确认后批量执行返水。必须在 20:40 前完成，为 21:00 推送留时间。

为什么是 10% / 0.02 / 必须组长确认：

10% 和 0.02 这两个具体数值由经理决定——副组长按当前规则执行，不需深究算法来源

机制目的：存提差比例 > 阈值时说明用户当天输得比较多，平台用一笔小额返水（占存提差的一定比例）作为留存激励——避免大输的用户一气之下流失

必须组长确认才返水：组长会综合当天成本压力、流动性、用户群体特征做决策，副组长不单方面发起——这是为什么 §3.5 是 A 线节拍任务里唯一需要组长决策的项

关键参数¶

项	值
巡检时点	每日 20:00（印尼时间 UTC+7 硬时点）
巡检路径	每个平台后台 → 报表管理 → 日报表 → 点【查询】按钮刷新当日数据
用户数据来源	每个平台后台 → 营销工具 → 用户统计 → 导出当天用户数据
阈值	单平台存提差比例 > 10%（后台日报表"存提差比例"列直接显示百分比，不用手算）
"平台"定义	一个平台 = 一个网站；每个不同网站算一个独立平台
返水比例	0.02（固定）
返水触发条件	仅对 > 10% 的平台执行，且必须组长确认后才返水
返水操作入口	走 3.3 同款"导入宝箱"路径（运营配置 → 活动配置 → 邀请活动 → 导入宝箱配置 → 导入宝箱奖励）
宝箱最大金额	导入前先看返水模板里的最大金额；超过当前宝箱配置 → 临时调高 → 用户领完后恢复原始最大值
时间窗口	20:00 ~ 20:40（巡检 + 报组长 + 等确认 + 批量返水全部完成）

📝 来源：学习讨论

与 3.3 批量套件的根本区别¶

维度	3.3 批量套件（子任务 3/4 彩金）	3.5 存提差返水
数据范围	昨天 / 前天（历史数据）	T0 当天
触发条件	无（每天必做）	仅存提差 > 10% 且组长确认
计算方式	存提差分段公式	固定 0.02 比例
是否需上级确认	否（直接执行）	是（必须等组长确认后才返水）
性质	存提差回补	条件触发的留存激励

完整流程¶

  20:00（印尼时间 · 硬时点 · 建议 19:50 设闹钟）
        │
        ▼
  ==============================
  第一步：逐平台巡查
  ==============================
        │
        ▼
  ┌────────────────────────────────────┐
  │ (1) 登录每个平台后台                │
  │     报表管理 → 日报表               │
  │     点击【查询】按钮刷新当日数据      │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (2) 直接看「存提差比例」那列         │
  │     · > 10% → 记下平台名            │
  │     · ≤ 10% → 跳过，下一个平台      │
  │     （后台已显示百分比，不用手算）   │
  └──────────┬─────────────────────────┘
             │
             ▼
  对每个平台重复 (1)(2)，直到全部平台巡查完
             │
             ▼
  ==============================
  第二步：汇总 + 报组长确认
  ==============================
             │
             ▼
        有超阈值平台吗？
             │
        ┌────┴────┐
        │         │
       无         有
        │         │
        ▼         ▼
  ┌──────────┐  ┌─────────────────────────────────┐
  │ 群内打卡  │  │ (3) 整理超阈值平台清单           │
  │ "20:00   │  │     发给组长，请组长确认是否按    │
  │  巡检完成 │  │     0.02 比例返水                │
  │  无异常"  │  └──────────┬──────────────────────┘
  │          │             │
  │ → 准备   │             ▼
  │ 21:00推送 │       组长确认结果？
  │          │             │
  │          │        ┌────┴────┐
  │          │        │         │
  │          │     不返水      确认返水
  │          │        │         │
  │          │        ▼         ▼
  │          │  ┌──────────┐  ┌─────────────────┐
  │          │  │ 跳过返水 │  │ 第三步：批量返水  │
  │          │  │ 群内记录 │  └────────┬────────┘
  │          │  └──────────┘           │
  └──────────┘                          │
                                        ▼
  ============================================
  第三步：批量返水（仅在组长确认后执行）
  ============================================
                                        │
                                        ▼
  ┌────────────────────────────────────┐
  │ (4a) 准备返水 Excel 模板            │
  │      · 比例：0.02（固定）          │
  │      · 范围：该平台该日符合返水规则 │
  │        的用户                       │
  │      · 算出每个用户的返水金额      │
  │                                    │
  │      ⚠️ 算完后**先看一眼最大金额** │
  │      （所有用户中返水金额的最大值） │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (4b) 检查"宝箱最大金额"配置         │
  │      返水的最大金额 > 当前宝箱      │
  │      最大金额？                    │
  │      ├─ 是 → 临时**调高宝箱最大    │
  │      │       金额**到能覆盖返水    │
  │      └─ 否 → 直接进入 (4c)         │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (4c) 走与 3.3 子任务 3/4 相同的路径 │
  │      运营配置 → 活动配置 →          │
  │      邀请活动 → 活动配置 →          │
  │      侧边导航 → 导入宝箱配置 →      │
  │      "未领取宝箱数量"行查看 →       │
  │      "导入宝箱奖励"                 │
  │      → 选 (4a) 准备好的返水模板      │
  │      → 导入                         │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (4d) 等用户领取后**恢复宝箱原始最大 │
  │      金额**（如果 4b 调高过的话）   │
  │      ⚠️ 这一步不能漏！调高的最大值  │
  │      只为本次返水临时用，不复原会  │
  │      影响后续其他活动的宝箱配置     │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (5) 群内打卡 + 值班表格登记         │
  │     · 哪个平台返水                  │
  │     · 比例 0.02                    │
  │     · 组长确认人                    │
  │     · 是否调过宝箱最大值（已恢复）  │
  └──────────┬─────────────────────────┘
             │
             ▼
            准备 21:00 推送 ⑤

业务逻辑说明¶

晚上 8 点根据当天存提差比例判断——超过 10% 说明用户当天输得比较多（提款远少于存款），平台返水 0.02（2%）作为留存激励：让用户拿到一点回馈后继续游戏，换取后续活跃和复充。

📝 来源：学习讨论

注意事项：

20:00 是印尼时间硬时点，和 Firebase 推送同一时区，不需要换算
巡检结果无论有无超阈值都要在群里打卡 "20:00 巡检完成"
超阈值 ≠ 一定返水——必须等组长确认后才操作，不要自行决定
跨平台同时超阈值时，整理成一份清单发组长（一次性请示，避免反复打扰）
所有"报组长 / 组长确认"的对话截图存档
全平台都 ≤ 10% 时，返水步骤直接跳过，值班表格记"全平台未触发"
返水走 3.3 同款"导入宝箱"路径——本质是同一个入口，只是模板内容是返水金额
⚠️ 宝箱最大金额可能需要临时调高：返水模板里如果有用户的金额超过当前宝箱配置的最大值，必须先调高再导入；导入完成后，立即恢复原始最大值，避免影响后续其他活动的宝箱配置
上传前肉眼核对返水模板（用户 ID / 金额 / 行数），避免发错钱

📝 来源：学习讨论

🤖 自动化机会：巡检阶段可做成脚本自动拉取所有平台日报表的"存提差比例"列，超阈值平台自动汇总成清单 @ 副组长 + 组长，副组长一键转发请示；返水模板生成可与 3.3 子任务 3/4 共用同一个工具链（tools/ 已实现公式套用）。

3.6 代收代付渠道管理（每日各个班交接后的第一件事）¶

为什么 2000 万印尼盾余额参考线：❓ 待跟组长确认数字来源。一般推断： - 是日均代付流水的某个倍数——保证商户能撑一天的代付需求不耗尽 - 或是历史经验值——低于此线一段时间内出现过代付失败 - 副组长按当前规则巡检，发现接近此线及时反馈组长充值，不要等到耗尽才报

优先级：交接班后第一件事，在 SMS 回访和佣金发放之前执行。

核心目标：确保三方支付渠道资金充足、配置正确、成功率达标，保障用户存取款顺畅。

关键参数¶

项	值
执行时点	白班接班后立刻（10:00）+ 全天每小时巡检
商户角色	CP 与 ATM 的代收/代付身份是动态调整的，不是固定分配
资金参考线	渠道余额约 2000 万印尼盾以上为佳（低于此值调低权重）
核心配置原则	代收多的商户同时代付也多（"收得多的，出得也多"）
渠道顺序	代收排序 = 代付排序（保持一致，核心原则）
成功率监控	稽核团队每小时排查 → 反馈主管 → 主管决策

为什么 CP/ATM 的角色要动态调整？

同一个三方商户，既可以做代收（收用户的存款），也可以做代付（给用户出款）。哪个商户这一班被用来代收多、哪个被用来代付多，不是固定分工，而是根据实时成功率和余额动态调整。

核心原则：代收多的商户同时代付也多。理由：

✅ 收的钱及时通过代付花出去 → 资金周转顺畅

✅ 避免单商户余额堆积（只收不付 → 商户处账户堆了一堆没花出去，占用我方额度）

✅ 避免单商户余额快速耗尽（只付不收 → 余额一下就空了，大额提款接不住）

✅ 排序一般保持代收代付一致 → 同一商户在两侧排序位置相同，进出自然平衡

所以每次巡检时都要重新评估，不是"这个商户永远是代收方"——而是"这个小时谁收得多，这个小时就让谁也付得多"。

📝 来源：学习讨论

完整流程¶

  白班接班（10:00 · 第一件事）
        │
        ▼
  ==============================
  第一步：查渠道余额
  ==============================
        │
        ▼
  ┌────────────────────────────────────┐
  │ (1) 在对应渠道的 Telegram 群中     │
  │     通过机器人命令查询余额          │
  │     逐个查看 CP/ATM 渠道余额       │
  │     记录每个渠道的当前余额          │
  └──────────┬─────────────────────────┘
             │
             ▼
        余额 >= 2000 万印尼盾？
             │
        ┌────┴────┐
        │         │
       是         否
        │         │
        ▼         ▼
  ┌──────────┐  ┌──────────────────────────────────┐
  │ 余额充足  │  │ 余额偏低的渠道：                 │
  │ → 进入    │  │ → 调低该渠道代付权重             │
  │ 第二步    │  │ → 排到后面，优先用余额多的       │
  │          │  │ → 考虑调整对应代收渠道权重        │
  │          │  │  （提高代收量来增加代付余额）      │
  └──────────┘  └──────────┬───────────────────────┘
                           │
                           ▼
  ==============================
  第二步：配置代付策略
  ==============================
        │
        ▼
  ┌────────────────────────────────────┐
  │ (2) 查看各渠道代收流水              │
  │     确认哪个渠道收的多              │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (3) 调整代付配置                    │
  │     原则：收的多的渠道优先代付       │
  │     避免单个渠道资金被掏空          │
  └──────────┬─────────────────────────┘
             │
             ▼
  ==============================
  第三步：核对渠道顺序
  ==============================
        │
        ▼
  ┌────────────────────────────────────┐
  │ (4) 对比代收/代付渠道配置顺序       │
  │     两边顺序应基本一致              │
  │     如不一致 → 调整对齐             │
  └──────────┬─────────────────────────┘
             │
             ▼
  ==============================
  第四步：执行主管通知的变更（如有）
  ==============================
        │
        ▼
  ┌────────────────────────────────────┐
  │ (5) 检查是否有主管通知的渠道变更     │
  │     · 开启/关闭某个渠道             │
  │     · 调整渠道权重                  │
  │     按通知内容执行配置              │
  └──────────┬─────────────────────────┘
             │
             ▼
        ┌──────────────────┐
        │ 完成 → 进入       │
        │ SMS 回访 / 佣金   │
        └──────────────────┘

  ─────────────────────────────────────
  持续监控（贯穿全天）
  ─────────────────────────────────────

  ┌────────────────────────────────────┐
  │ 稽核团队每小时排查三方渠道成功率    │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ 反馈给主管                          │
  └──────────┬─────────────────────────┘
             │
             ▼
        成功率异常？
             │
        ┌────┴────┐
        │         │
       否         是
        │         │
        ▼         ▼
  ┌──────────┐  ┌─────────────────────────────┐
  │ 继续监控  │  │ 主管决定是否切换渠道          │
  │          │  │         │                    │
  │          │  │         ▼                    │
  │          │  │ 通知副组长/相关团队执行切换    │
  │          │  │         │                    │
  │          │  │         ▼                    │
  │          │  │ 执行渠道开关/权重调整          │
  │          │  │ → 确认生效 → 群内报备          │
  └──────────┘  └─────────────────────────────┘

注意事项：

这是白班最优先的任务，在 SMS 回访和佣金发放之前完成
余额低于 2000 万印尼盾的渠道不是不能用，而是要调低权重排到后面，优先使用余额较多的渠道代付
渠道开关和权重调整必须按主管通知执行，不能自行决定
成功率监控是稽核团队的职责，副组长负责执行切换动作
所有渠道变更操作截图存档，群内报备
三方代付银行维护通知：三方代付有时会通知因印尼银行系统维护或网络波动等原因暂停银行下发服务，收到通知后在后台代付渠道中把 bank 代付类型暂时关闭，等三方通知恢复正常后再重新开启

📝 来源：学习讨论

🤖 自动化机会：渠道余额查询和成功率监控可做成自动化看板，每小时自动拉取各渠道余额和成功率数据，低于阈值自动告警推送到群里，减少人工逐个检查的时间。渠道顺序一致性检查也可脚本化——对比代收/代付配置，不一致时自动提醒。

子任务 · 每小时代收三方商户余额巡检¶

目的：确保代付渠道随时有足够余额处理用户提现，防止余额耗尽导致提现失败。这是 3.6 接班配置完成之后，贯穿全天的周期性守护任务。

为什么要每小时做一次？

代付余额是实时消耗的（用户每提一笔就扣一笔），不是静态值
如果排序第一的代付商户余额被掏空了，后续提现会批量卡在那一个商户上 → 用户投诉、成功率暴跌
及时把排序第一的位置换成"余额更充足的商户"，能把压力均匀分摊到所有代付商户上
1 小时的巡检频率是经验值：足够及时（不至于让一个商户彻底被掏空），也不至于让副组长陷入无意义的密集操作

每小时巡检流程：

  每小时整点（或整点前 5 分钟）
        │
        ▼
  ┌────────────────────────────────────┐
  │ (1) 逐个商户 Telegram 群用机器人   │
  │     命令查询代付余额                │
  │     记录当前排序前 3 的商户余额     │
  └──────────┬─────────────────────────┘
             │
             ▼
        排序第一的代付商户余额偏低？
             │
        ┌────┴────┐
        │         │
       否         是
        │         │
        ▼         ▼
  ┌──────────┐  ┌────────────────────────────────────┐
  │ 维持原   │  │ (2) 调整代收代付渠道排序            │
  │ 配置，   │  │     · 把余额高的代付商户提到前面    │
  │ 继续监控 │  │     · 同步调整代收排序              │
  │          │  │       （保持代收代付一致 ← 核心原则）│
  │          │  └──────────┬─────────────────────────┘
  │          │             │
  │          │             ▼
  │          │  ┌────────────────────────────────────┐
  │          │  │ (3) 这是临时调整 → 必须设定时提醒  │
  │          │  │     · 1-2 小时后再次巡检          │
  │          │  │     · 视情况调整回去或继续保持     │
  │          │  │     · 群内简短报备                 │
  │          │  └──────────┬─────────────────────────┘
  │          │             │
  │          │             ▼
  │          │        同时发现大额提款 +
  │          │        代付余额不足以处理？
  │          │             │
  │          │        ┌────┴────┐
  │          │        │         │
  │          │       否         是
  │          │        │         │
  │          │        ▼         ▼
  │          │  ┌──────────┐  ┌────────────────────────────┐
  │          │  │ 继续按   │  │ (4) 立即通知组长协调处理    │
  │          │  │ 调整后   │  │     · 可能需要紧急补资      │
  │          │  │ 配置运行 │  │     · 或紧急开启备用商户    │
  │          │  │          │  │     · 或与商户侧协商垫付    │
  │          │  └──────────┘  │     副组长不自行决策，听组长│
  │          │                └────────────────────────────┘
  └──────────┘
        │
        ▼
  记录本小时巡检结果 → 等待下一个整点

关键要点：

核心原则：代收排序 = 代付排序（这是 3.6 全章节一以贯之的原则，不能因为临时调整而破坏）
临时调整要有"回归"动作：一旦临时把某个商户降权/提权，必须设好定时提醒（建议手机日历 / Telegram 机器人），到点再次评估
大额提款 + 余额不足属于升级事项：副组长不自行决策，立即通知组长——这类事涉及资金补给/商户协商，超出副组长权限
巡检结果要留痕：每小时在值班群简要报备（"XX:00 巡检：排序 1 的 ATM-A 余额 XX，正常"），方便交班和回溯
巡检 + 接班配置是一条连续流水线：10:00 做完接班配置，10:00 就是第一次巡检的基准点，之后 11:00 / 12:00 / ... 按整点滚动

📝 来源：学习讨论

🤖 自动化机会：把每小时巡检做成 Telegram 机器人定时任务——整点自动查各商户余额、自动判断排序第一商户是否低于阈值、低于阈值自动在值班群@副组长并给出"建议调整到 XX 商户"的建议，副组长只需点按钮确认执行。

子任务 · 高峰期最优充值渠道开关（仅新用户）¶

目的：印尼市场高峰期不计成本（费率高一点没关系），把当前充值体验最好的渠道开启给新用户使用，用更高的成本换高峰期的新用户留存。

关键参数：

项	值
开启时点	约印尼 19:00 ⚠️
关闭时点	约凌晨 03:00 ⚠️
适用对象	仅新用户（通过分组权限/通道可见性限制，避免老用户也走这个高费率通道）
通道选择	当前充值体验最优的渠道——具体哪个通道以本站实际配置为准，可能随平台调整而变动
频率	每天滚动一次（晚开早关）

操作流程：

  高峰期开始前（约印尼 19:00）
        │
        ▼
  ┌────────────────────────────────────┐
  │ (1) 后台 → 代收渠道配置             │
  │     找到当前【用于高峰期新用户】的   │
  │     最优充值渠道（以本站配置为准）  │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (2) 开启该通道                      │
  │     权限设置：仅新用户可见/可用      │
  │     （不要让老用户也用，否则成本高）│
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (3) 群内简短报备：                  │
  │     "已开启 <渠道名>          │
  │      （仅新用户）"                  │
  └──────────┬─────────────────────────┘
             │
             ▼
        高峰期持续运行
        （19:00 ~ 凌晨 03:00）
             │
             ▼
  高峰期结束（约凌晨 03:00）
             │
             ▼
  ┌────────────────────────────────────┐
  │ (4) 关闭该高峰期专用通道            │
  │     群内简短报备：                  │
  │     "已关闭 <渠道名>"         │
  └────────────────────────────────────┘

注意事项： - 不要全天开：费率高于常规通道，全天开会让成本失控 - 仅限新用户：开启时务必检查权限/分组配置，老用户必须走常规通道 - 具体通道不固定：哪个通道当前是"最优"随平台配置变动，交接班时必须确认当前高峰期用的是哪个通道；不同平台可能配置不一样，别套别家的名称 - 时间窗口：19:00 / 03:00 - 开关动作要留痕：截图配置变更前后状态 + 群内报备时间点 - 遇异常：高峰期内若该通道成功率突然下降，立即跟主管同步，可能需要临时关闭或切换到备用渠道

📝 来源：学习讨论

🤖 自动化机会：这个需要副组长的经验和对平台/代收代付渠道的熟悉来操作，不适合做自动化，最多自己设置闹钟提醒到时间设置或者关闭。

四、响应任务工作流（B线 · 随到随办）¶

B线特征：没有固定时刻，由客服群、风控群、财务群的消息触发。收到即处理，遵循"认领→执行→回复→报备"四步通用框架。

4.1 提现订单审核（风险最高、决策最复杂）¶

提现审核是副组长日常工作中风险最高、决策分支最多的任务。一笔判断失误可能导致真金白银的资损，或者放过套利用户。

4.1.1 通用前置步骤¶

  收到提现订单通知
        │
        ▼
  ┌───────────────────────────────┐
  │ 第一动作：【锁定订单】         │  ← 防止其他同事重复处理
  │ （后台点击"锁定"按钮）         │
  └────────┬──────────────────────┘
           │
           ▼
  ┌───────────────────────────────┐
  │ 读取订单【备注】字段            │
  └────────┬──────────────────────┘
           │
           ▼
  ┌───────────────────────────────┐
  │ 判断订单类型                    │
  │   ├─ 备注含"代理提款" → 代理   │ → 走 4.1.5 代理提现流程
  │   └─ 其它 → 普通用户           │ → 走 4.1.4 普通用户流程
  └───────────────────────────────┘

4.1.2 自动出款四层开关（前置知识）¶

系统有四层开关，全部打开才能自动出款，任何一层不通过就会转入人工审核：

  ┌─────────────────────────────────────────────┐
  │              自动出款四层开关                  │
  │                                              │
  │  第1层：站点总开关 ON                          │
  │         │                                    │
  │         ▼                                    │
  │  第2层：该第三方代付通道 ON                     │
  │         │                                    │
  │         ▼                                    │
  │  第3层：会员所在层级允许自动                    │
  │         │                                    │
  │         ▼                                    │
  │  第4层：会员个人开关 ON                        │
  │         │                                    │
  │         ▼                                    │
  │  全部通过 → 自动出款                           │
  │                                              │
  │  任何一层不通过 → 转入人工审核                  │
  └─────────────────────────────────────────────┘

强制转人工的情况（无论四层开关如何）：超出自动出款限额、首存流水不足、包含代理彩金、提款间隔过短。

📘 来源：01-自动出款功能详解

4.1.3 提现订单备注处理手册（8 条规则）¶

备注总览表¶

#	备注内容	处理动作摘要	详细流程
1	代理提款	下级行为模式排查 + 账变审核	走 4.1.5 代理提现审核流程
2	用户层级不允许自动出款	套利观察层 / 已确认套利用户；关注优惠+投注方式+倍数，完整排查流程	见下方备注 2 详解
3	自动出款失败	查询订单真实状态，按状态处理	见下方备注 3 详解 + 订单状态处理表
4	超过最大自动出款金额	后台阈值 = 5000【注意在后台查询确认各自平台设置】；转人工审核（游戏作弊 / 刷优惠 / 是否真实客户行为）	见下方备注 4 详解
5	2 分钟内提款 4 次	首次警告，根据余额决定驳回/通过；如是 bug 套利立即紧急关停自动出款	见下方备注 5 详解
6	首提流水不足	规则已关停，直接审核通过	见下方备注 6 详解
7	出款通道金额限制	通常因"没有可用渠道"——轮巡所有商户都失败；跟商户核实是维护/波动还是不支持，让会员换钱包或按商户反馈处理	见下方备注 7 详解
8	代付下发失败	先查询订单状态，跟三方确认具体失败原因，根据原因处理	见下方备注 8 详解

📝 来源：学习讨论

备注 1：代理提款¶

触发源：用户领取过邀请奖励 / 拼多多奖励 / 宝箱优惠中任一种，领取后的第一笔提款就会自动挂上"代理提款"备注。

审核目的：判断该代理是真实代理（有真实下级用户、正常游戏行为）还是套利代理（自己注册小号刷优惠）。

处理方式：走 4.1.5 代理提现审核流程（下级行为模式检测 + P1/P2 处罚）。

📝 来源：学习讨论

备注 2：用户层级不允许自动出款¶

触发源：用户当前所在层级被后台配置为"不允许自动出款"——典型层级包括： - "套利观察层级"（曾经被怀疑套利）或"已确认套利"（已判定过套利） - "二次验证/Data"层级（密码重置安全验证，详见 5.2.3）

审核重点（视层级类型不同）：

套利观察层级： - 领取的优惠类型（邀请奖励 / 拼多多 / 宝箱 / 其他） - 投注方式（是否集中在低风险 / 高返水的打法） - 投注倍数（是否刚够流水就提款）

二次验证/Data 层级： - 查看备注是否为"WD 需二次确认，是否为旧提现资料" - 核查提现账号：户名和账号是否与原绑定信息一致 - 旧账号（一致）→ 删备注 + 出款 + 拉出层级 - 新账号（不一致）→ 驳回 + 关提现 + 直接进入视频验证（之前已收过截图，不重复要；视频规格详见 5.2.3）

收到备注 2 订单
      │
      ▼
按 4.1.5 四条标准排查
      │
      ▼
账变记录排查
      │
      ├─ 筛选充值记录，查看金额和时间分布
      │
      ▼
投注记录排查
      │
      ├─ 查看投注是否正常（时间间隔、金额、游戏类型、投注倍数）
      │
      ▼
综合判断
      │
      ├─ 正常会员 → 审核通过，下发
      └─ 存在套利/异常行为 → 根据排查结果处理（驳回/上报/冻结）

📝 来源：学习讨论

备注 3：自动出款失败¶

收到备注 3 订单
      │
      ▼
拿订单号去查询真实订单状态
      │
      ▼
根据返回状态，查【订单真实状态处理表】
      │
      ├─ 账号无效/格式错误  → ⚠️ 先走账号错误智能判定（见下方），不要直接标无效
      ├─ 账户状态异常       → 跟三方确认真实情况（限额/冻结/其他），根据具体问题处理
      ├─ 风控拦截          → 跟三方确认：用户账号风控→改账号无效；三方出款账号问题→根据情况处理
      ├─ 金额超限          → 跟三方确认：非用户原因→驳回让用户重提；用户账号限额→走限额优化流程（见下方）
      ├─ 系统/网络类失败    → ⚠️ 先查历史（见下方防循环驳回机制），再决定驳回还是升级处理
      ├─ 账户信息校验异常   → 跟三方确认：用户账户问题→走账号无效流程；其他→根据情况处理
      ├─ 收款账户状态异常    → 更改用户取款账户状态为无效，驳回订单
      └─ 交易限额          → 走限额优化流程（见下方）；如果是其他状态→根据具体情况处理

⚠️ 防循环驳回机制（适用于状态 5/6/8/9 等系统/网络类失败）

问题：三方查单接口返回的失败原因不一定准确，三方客服回复的具体原因也不一定是真实状态。如果简单地一直驳回让用户重提，用户可能陷入"提款→失败→驳回→重提→又失败"的循环，严重影响体验。

操作流程：驳回前先查该用户当天的提现历史：
准备驳回（系统/网络类失败）
      │
      ▼
先查提现记录：该用户当天是否有其他订单被驳回？
      │
  ┌───┴───┐
  │       │
 没有     有
 （首次） （重复失败）
  │       │
  ▼       ▼
正常驳回  检查：多次提现用的是不是同一个钱包/银行账号？
要求重提       │
          ┌───┴───┐
          │       │
         不同     同一个账号多次被驳回
         账号      │
          │       ▼
          ▼   跟三方人工确认具体问题：
        正常   · 是用户账户信息错误？
        驳回   · 是账户限额？
        重提   · 是渠道临时故障？
               · 还是其他原因？
                    │
                    ▼
              根据确认结果处理：
              · 账户问题 → 关提现权限 + 通知客服
                让用户联系客服更换钱包/银行
              · 渠道问题 → 换渠道手动出款
              · 无法确认 → 暂停提现权限 +
                通知客服让用户更换提款方式
核心原则：同一用户、同一账号、当天被驳回 2 次及以上 → 不能再简单驳回重提，必须查明原因再处理。

⚠️ 账号错误智能判定（适用于状态 1/3/7 等"账号无效/账户错误/信息校验异常"类失败）

问题：三方返回"收款人信息错误"或"账号信息错误"时，不一定是用户账号真的有问题——特别是多平台批量出现时，很可能是代付渠道波动。直接标注账号无效会影响用户体验，尤其是首提用户。

判定流程：
三方返回"账号无效/信息错误"
      │
      ▼
该用户是否曾用这个账号成功提款过？
      │
  ┌───┴───────────────────────┐
  │                           │
 有过成功记录                   没有（首次使用）
  │                           │
  ▼                           ▼
大概率是渠道波动             进入用户详情页
（曾经能出款现在报错         查看绑定的钱包/银行卡信息
 不太可能是账号问题，              │
 可能是跨行维护/                   ▼
 三方接口波动/                提现方式是什么？
 银行卡限额等）                    │
→ 驳回让用户重提          ┌───────┴───────┐
                         │               │
                       钱包             银行卡
                         │               │
                         ▼               ▼
                   手机号和账号       银行卡信息
                   是否一致？         是否合理？
                     │               （卡号位数/
                 ┌───┴───┐           格式是否正常）
                 │       │               │
               差1-2位   完全一致     ┌───┴───┐
               （疑似    或完全不同   │       │
                输错）       │      格式     格式
                 │          │      异常     正常
                 ▼          ▼       │       │
              走账号     大概率      ▼       ▼
              无效流程   渠道波动   走账号   大概率
                       → 驳回     无效流程  渠道波动
                         重提              → 驳回
                                            重提
辅助判断信号： - 多平台批量出现同类"账号错误"失败 → 大概率是代付渠道波动，不是用户问题 - 首提用户出现账号错误 → 优先检查绑定信息，不要直接标无效（首提体验差影响留存） - 用户之前成功提过款的同一个账号又报错 → 几乎确定是渠道波动（跨行维护/三方接口波动/银行卡限额等），不是账号信息错误 - 银行卡提现报"账户信息错误" → 三方返回的错误原因经常不准确，实际可能是跨行交易维护、银行卡限额、或渠道临时故障，不能简单按"账户信息错误"处理 - 核心思路：不要简单依据三方的错误原因去处理，要看用户的账号和之前出款情况做综合判断，尽量减少用户提现障碍

📝 来源：学习讨论

⚠️ 限额优化处理流程：不同的银行和钱包都有不同的日限额/月限额，用户是否完成 KYC 也会影响限额。处理限额问题时，先查用户是否绑定了多个提现方式再决定处理方案：
确认是限额问题
      │
      ▼
查看用户账户绑定的提现方式数量
      │
  ┌───┴───┐
  │       │
多个      只有一个
（≥2 个    银行卡/钱包
 银行卡/
 钱包）
  │       │
  ▼       ▼
不关闭    按原流程：
提现功能  关闭提现权限
直接驳回  + 备注限额日期
订单并    （如 DANA LIMIT 4/25）
说明：    + 驳回订单
"当前     + 通知客服群
XX 限额   让用户联系客服
请更换
其他方式
提现"
核心逻辑：绑定了多个提现方式的用户通常对限额有认知，直接告诉他换一个方式重新提现就行，不需要关权限、不需要联系客服、不需要等我们再开权限——减少 3 个环节，提升用户体验。只有一种提现方式的用户才需要走关权限+联系客服的完整流程。

⚠️ 代付系统不支持的银行：以下银行代付系统不支持，系统会直接显示"自动出款失败"（不会提及三方）： - BANK JAGO SYARIAH - BANK JAGO UUS - BANK ALADIN SYARIAH - SUPERBANK - BANK MANDIRI TASPEN

📝 来源：学习讨论

订单真实状态处理表（用于备注 3 查询订单状态后对照处理）：

#	订单状态	原因说明	后台操作	核心原则
1	账号无效 / 格式不正确 / 校验异常	账户不存在 / 格式错误 / 与渠道不匹配	⚠️ 先走账号错误智能判定：曾成功提过款→大概率渠道波动驳回重提；首次→查绑定信息是否输错；确认是用户问题→标无效+驳回	智能判定
2	收款账户状态异常	账户被冻结 / 未激活 / 注销	跟三方确认真实情况（是用户账号限额还是其他），根据具体问题给出相应处理	先确认再处理
3	账户错误或风控拦截	账户被风控系统拦截	跟三方确认：用户账号风控 → 改账号无效 + 驳回；三方出款账号问题 → 根据具体情况处理	区分用户侧 vs 渠道侧
4	金额超限 / 日/月度超限	超过银行或账户限额	跟三方确认：与用户账户无关 → 驳回让用户重提；用户账号限额 → 走限额优化流程（多提现方式→直接驳回说明换方式；单提现方式→关权限+通知客服）	限额优化
5	系统繁忙 / 系统错误 / 请求超时 / 网络波动	系统拥堵或波动/也有可能客户的提款账号/钱包有问题	⚠️ 先走防循环驳回检查（查当天历史），首次可驳回重提；同一账号重复失败→跟三方确认真实原因	防循环驳回
6	请求失败 / 交易失败	—	⚠️ 先走防循环驳回检查，首次可驳回重提；重复失败→查明原因	防循环驳回
7	账户信息校验异常	姓名、账号不一致	跟三方确认：用户账户问题 → 走账号无效流程；其他 → 根据具体情况处理	先确认再处理
8	网络错误	网络波动	⚠️ 先走防循环驳回检查，首次可驳回重提；重复失败→查明原因	防循环驳回
9	请求过于频繁	请求频繁	⚠️ 先走防循环驳回检查，首次可驳回重提；重复失败→查明原因	防循环驳回
10	交易限额	用户的银行卡或者钱包达到交易限额	走限额优化流程：多提现方式→驳回说明换方式提现；单提现方式→关闭提现权限+备注限额日期+通知客服；其他 → 根据情况处理	限额优化

核心处理原则： - 状态 1（账号无效）：⚠️ 不要直接标无效——先走账号错误智能判定（查历史成功记录 + 检查绑定信息 + 判断是否渠道波动） - 状态 5/6/8/9（系统/网络问题）：首次可驳回让用户重提；同一账号当天重复失败→ 必须查明原因再处理（见防循环驳回机制） - 状态 2/3/4/7/10（需确认的）：必须先跟三方渠道确认真实原因，区分是用户账户的问题还是渠道侧的问题，再根据具体情况处理

⚠️ 三方查单接口的失败原因不一定准确，三方客服回复的原因也不一定反映真实状态。遇到重复失败时不要盲目相信接口返回值，要综合判断。

📝 来源：学习讨论

驳回后通知客服群（要求用户重新提交时）¶

底层逻辑：当我们驳回提款订单并要求用户重新提交时，必须把驳回信息发到客服群。这样客服后续接到用户咨询、查到该用户 ID 时，第一时间就能知道为什么被驳回，可以高效准确地回复用户，不必再来副组长这边二次确认。

适用场景（凡是要求用户重新提交提款订单的驳回，都需要发群）： - 状态 4 金额超限 → 驳回让用户重提 - 状态 5/6/8/9 系统/网络问题首次失败 → 驳回让用户重提 - 状态 10 交易限额（多提现方式） → 驳回说明换方式 - 渠道波动确认非用户问题 → 驳回让用户重提

标准群消息格式：

平台名称：[平台名]
用户 ID：[会员账号]
驳回原因：[简要说明，并附"请用户重新提交提款订单"]

示例：

平台名称：7777W
用户 ID：6281234567890
驳回原因：金额超限（三方确认非用户账号问题），请用户重新提交提款订单

平台名称：RP55
用户 ID：6289876543210
驳回原因：网络波动导致出款失败（首次），请用户重新提交提款订单

⚠️ 不发群的情况：以下情况是最终驳回（不要求用户重新提交），按现有备注流程处理，不需要发到客服群： - 账号无效（状态 1，确认是用户问题）→ 关权限走账号错误流程 - 套利违规（BH BAT / BH RK）→ 走 P1/P2 备注流程，发对应稽核群 - 单一提现方式且账号限额（状态 10 单方式）→ 关权限 + 通知客服走限额优化

📌 客服侧的对应动作：客服收到驳回信息后，存档到自己的待跟进清单。当用户来咨询"为什么提款失败/被驳回"时，直接根据驳回原因回复用户"请重新提交提款订单"。如有疑问再 @ 副组长确认。

📝 来源：学习讨论

备注 4：超过最大自动出款金额¶

触发源：当前后台设置的最大自动出款金额 = 5000，超过此值自动转人工审核。

审核目的：转人工审核用户行为是否包含游戏作弊 / 刷优惠 / 是否是真实客户行为。

收到备注 4 订单
      │
      ▼
资金账变排查
      │
      ├─ 筛选充值记录：查看当天充值金额和时间分布
      │   （是否短时间大量充值？金额是否异常？）
      │
      ▼
投注记录排查
      │
      ├─ 查看多个投注之间的时间间隔
      │   （是否机器人式密集投注？）
      │
      ▼
平台盈亏排查
      │
      ├─ 筛选亏损记录，查看投注金额和中奖金额
      │   是否在正常范围？
      │       │
      │       ├─ 不确定 → 到前台/App 查看对应游戏规则，
      │       │            对比中奖概率和赔率是否合理
      │       │
      │       └─ 明显异常 → 根据排查结果处理
      │
      ▼
综合判断
      │
      ├─ 确认是正常用户 → 审核通过，手动下发
      └─ 存在异常行为   → 根据排查结果处理（驳回/上报/冻结）

📝 来源：学习讨论

备注 5：2 分钟内提款 4 次¶

两个业务原理（理解后才知道为什么要拦截）：

降低手续费损耗：分多笔小额提款会产生多次手续费，提醒客户一次性提完，既省成本也省客户自己的手续费
拦截游戏 bug 套利：当游戏出现 bug（例如"输钱不扣本金"这类让用户无限盈利的缺陷），用户单笔大额提款会触发人工审核被拦截，此时用户会尝试小额多次提款绕过大额拦截——这个机制专门拦截这种小额高频模式

⚠️ 如果识别为游戏 bug 套利：此机制也能拦截并紧急关停自动出款。

收到备注 5 订单
      │
      ▼
是否首次触发高频提款警告？
      │
      ├─ 否（再犯）→ 按实际情况升级处理
      │
      └─ 是（首次）
            │
            ▼
      查看用户最后一次提款账户余额
            │
            ├─ 有余额 → 驳回本次提款
            │            备注说明："请一次性提取全部余额"
            │
            └─ 没有余额 → 直接通过本次提款申请，出款

      （若识别为 bug 套利 → 机制可拦截并紧急关停自动出款）

📝 来源：学习讨论

备注 6：首提流水不足¶

触发源：后台原本设置"首次提款打码量未达 1.5 倍"时自动转人工审核。

业务原理（原规则）：客户首次存款后刷优惠、低倍打码快速出款的，转人工方便了解用户行为。

当前状态：此规则已关停。关停原因：很多新客户首次存款后会先小额测试网站信誉度（看能不能顺利出款），如果这个机制拦截新客首提，会直接劝退新用户。

当前处理方式：直接审核通过，允许提款。

一般性规则：其他场景下，未达打码量的会员根本提不了款（系统前端会直接拦截），不需要副组长人工判断。备注 6 是老平台遗留问题的兜底路径，新平台基本不会触发。

📝 来源：学习讨论

备注 7：出款通道金额限制¶

原理：这个备注通常出现是因为"没有可用渠道"——系统会自动轮巡一遍所有商户，如果某个通道（例如 DANA）正在维护或波动，大概率所有商户都轮巡失败，系统就会把这笔订单归纳为"出款通道金额限制"。注意：不同商户对同一种钱包的支持情况可能不同——例如 DANA 支付，有的商户内部有配置，有的可能没有。

处理方式： 1. 跟对应商户方核实：这个通道当前是在维护 / 波动，还是完全不支持？ 2. 根据商户反馈决定： - 商户临时维护或波动 → 让会员等待，或改用其他钱包提款 - 商户不支持该通道 → 让会员改用其他可用的钱包 / 银行卡提款 - 商户反馈异常 → 依据具体反馈信息处理

📝 来源：学习讨论

备注 8：代付下发失败¶

为什么不能直接手动重新下发：和 §4.11 代付接口超时同理——风险是重复出款（双倍资损）。

"失败"不等于"钱真的没出去"——可能商户那边其实已扣款下发，只是返回报错。副组长直接重新下发就会双倍出款，平台真实亏掉两倍金额。

所以必须先向商户查询订单实际状态：商户确认未下发 → 才能换通道重新出款；商户确认已下发 → 等回调，不操作；商户能直接补发 → 让商户处理。

触发源：副组长手动使用代付通道给用户出款时失败，系统自动备注"代付下发失败"。

常见失败原因（与备注 3"自动出款失败"相似）： - 商户 API 接口波动 - 客户钱包信息有误 - 限额等

处理方式：

仍然需要向对应商户查询订单反馈结果，再根据反馈结果去做对应的处理。

📝 来源：学习讨论

关键金额/时长硬规则速查表：

硬规则	数值	适用场景
电子钱包月限额（Dana/Ovo/Linkaja/Gopay/ShopeePay）	需跟对应三方渠道确认（非固定值）	备注 3
出款通道单笔上限	需跟对应三方渠道确认（非固定值）	备注 7
最大自动出款金额	5000（单位以后台配置为准）	备注 4
高频提款阈值	2 分钟内 4 次	备注 5
高频提款首犯（有余额）	驳回，要求一次性提取	备注 5
高频提款首犯（无余额）	直接通过出款	备注 5
首提流水不足阈值（已关停）	1.5 倍打码内转人工（当前规则已关停）	备注 6

📝 来源：学习讨论

🤖 自动化机会：8 条备注规则中，备注 6（直接通过）可由脚本自动处理。备注 2 和备注 4 需要完整排查流程，适合做半自动化辅助（机器人自动拉取账变/投注数据，人工最终判断）。完整的规则引擎设计见 12-自动化路线图/。

4.1.4 普通用户提现决策树¶

普通用户提现（备注不是"代理提款"）
      │
      ▼
读取订单【备注】字段
      │
      ├─ 备注 2："用户层级不允许自动出款"
      │       │
      │       ▼
      │   完整排查流程
      │       │
      │       ├─ 1. 按 4.1.5 四条标准排查下级行为模式
      │       ├─ 2. 账变记录：充值金额和时间分布是否正常？
      │       └─ 3. 投注记录：是否正常投注行为？
      │              │
      │              ├─ 正常 → 审核通过，下发
      │              └─ 异常 → 根据排查结果处理
      │
      ├─ 备注 3："自动出款失败"
      │       │
      │       ▼
      │   查询订单真实状态（拿订单号查）
      │       │
      │       └─ 对照【订单真实状态处理表】分类处理
      │           ├─ 账号/格式问题  → 核对或重试
      │           ├─ 账户冻结/注销  → 换账户或联系用户
      │           ├─ 风控拦截      → 换账户/降频/降额
      │           ├─ 金额超限      → 拆单/换账户/KYC提额
      │           ├─ 系统/网络问题  → 延迟重试
      │           ├─ 交易失败  → 重试或换支付方式
      │           └─ 三方找不到订单号   → 一般是用户使用了三方不支持的银行的卡来提现  → 给用户备注：推荐使用钱包(让客服看到） ，然后关掉用户的提现权限，通知客服群
      │
      ├─ 备注 4："超过最大自动出款金额"
      │       │
      │       ▼
      │   完整排查流程（能制定标准化操作流程和条件的话，后台添加一个功能就可以减少大量人工误判可能）
      │       │
      │       ├─ 1. 资金账变：当天充值金额和时间分布
      │       ├─ 2. 投注记录：多笔投注时间间隔是否正常
      │       └─ 3. 平台盈亏：投注/中奖金额是否在正常范围
      │              │
      │              ├─ 确认正常 → 审核通过，手动下发
      │              └─ 存在异常 → 根据排查结果处理
      │
      ├─ 备注 5："2 分钟内提款 4 次"
      │       │
      │       ▼
      │   是否首次触发？
      │       │
      │       ├─ 首次 → 查最后一次提款账户余额
      │       │          │
      │       │          ├─ 有余额 → 驳回，备注"请一次性提取"
      │       │          └─ 无余额 → 直接通过出款
      │       │
      │       └─ 再犯 → 按实际情况升级处理
      │
      ├─ 备注 6："首提流水不足"
      │       └─ 直接审核通过，允许提款（老平台问题，后面新平台基本不会有这个问题了）
      │
      ├─ 备注 7："出款通道金额限制"
      │       └─ 通常因"没有可用渠道"——系统轮巡所有商户都失败时触发
      │          （例如 DANA 正在维护/波动）。跟商户核实：是维护/波动
      │          还是不支持该通道？根据反馈：维护就等或让会员换钱包，
      │          不支持就让会员换其他可用钱包/银行卡
      │
      ├─ 备注 8："代付下发失败"
      │       └─ 先查询订单状态，跟三方确认具体失败原因，根据原因处理
      │
      └─ 其它备注 → 参考备注处理手册，必要时升级上级

关键心法： 1. 备注 2 和备注 4 不能直接通过——必须走完整排查流程（账变 + 投注），确认是正常用户才放行。 2. 备注 3 先查真实状态——不要凭备注猜原因，拿订单号查询真实订单状态再对症处理。 3. 备注 8 直接驳回——后台已经把所有渠道都试过了，再换通道也没用，让用户重新提交。但同样要注意防循环驳回——同一用户同一账号当天被驳回 2 次以上就要查明原因。 4. 限额类规则没有固定数字——电子钱包限额、出款通道上限都要跟对应三方渠道确认。

📝 来源：学习讨论

4.1.5 代理提现审核流程¶

"代理提款"备注怎么来的：只要用户领取过邀请奖励或拼多多奖励，那么他领取奖励后的第一笔提款就会自动挂上"代理提款"备注，强制走人工审核。

代理的合规玩法（允许的）：领过邀请奖励的用户通常本身就是代理（有下级），他可以不充值、不投注，只靠开发下级用户、从下级充值投注中分得佣金，然后直接提现拿奖励。前提是下级必须是独立真实用户。

套利的本质：代理自己注册一堆小号当下级，用小号去充值投注给自己刷佣金，然后提现。判断套利不看代理本身有无游戏，而是看下级是不是真实独立用户。

账变数据留存期限：账变记录只保留最近 60 天，超过 3 个月的记录无法查询。对于历史领奖时间较久的用户，排查时可能查不到早期数据，需要以可查范围内的数据为准。

套利审核五条标准（2026-04 版）¶

审核总原则：不是恶意刷宝箱的会员，尽量保留。根据上级质量、下级活跃度，灵活判断扣款/不扣款、拉层/拉出层。宁可错放，不要错杀，尽量留住会员。

📝 来源：学习讨论

第一条 · P2 套利模式检测（主要判据）

查看代理的下级用户行为模式：

检测项	条件
下级存款金额	50–60（后台单位 K IDR）
下级打码量	600 左右（后台单位，刚好够领宝箱）
符合上述模式的下级占比	≥70%

三项同时满足 → 判定触发 P2 套利。

小代理特殊处理：下级 ≤3 人，如果只领取了一个邀请奖励，可以酌情给过——让他稍微获利有动力去发展下级。

📝 来源：学习讨论

第二条 · 保留正常会员的条件（不扣款、不拉层）

前提：不触发第一条规则。

保留条件	说明
下级中至少有一个	大量存款、大量打码、近期活跃（3~5 天内有过存款）❓ "大量"的具体数值有待进一步确认
且不触发第一条	整体不符合"存款 50-60 + 打码 600 + ≥70%"的套利模式

满足条件 → 不拉进套利层，可享用所有优惠，删除原有 P2 备注，重新备注"不扣款，日期+经手人"（例：不扣款，可以出 4.21 AA）。

📝 来源：学习讨论

第三条 · 拉出套利观察层（恢复正常）

适用于：老客户（曾被拉进套利观察层）。

退出条件	说明
充值 + 提款	≥40 笔
近期仍有存款	近期仍在活跃充值
下级活跃	下级有活跃存款，且活跃时间超过 1 个月

满足条件 → 备注都删掉，视为正常会员，重新观察。

恢复后的会员如果再次领取邀请/拼多多奖励并提现，仍按 P1 会员的标准去排查。

📝 来源：学习讨论

第四条 · 副组长二重审核（扣款前的再次判断）

不论 P2 是稽核团队标记还是副组长自己发现，在实际执行扣款前，副组长必须按第一条到第三条标准再次判断：

符合 P2 标准 → 正常走扣款流程，扣后解开投注/提款权限（仍在观察层，佣金权限保持开放）
不符合 P2 标准 → 不扣款，取消 P2 备注，拉出套利观察层，按用户注册日期改为 7 日留存或 30 日留存层级，备注"不扣款，日期+经手人"

📝 来源：学习讨论

套利行为辅助判定参考（补充第一条）¶

#	行为模式	判定结论
1	领取奖励后，无正常游戏下注，充值一笔 → 投注获利 → 取款	有套利嫌疑
2	领取奖励后，正常游戏投注获利 → 取款（完全使用奖金进行套利）	有套利嫌疑
3	下级列表中 5 个以上会员的累计充值和累计有效打码数据一模一样或差距很小（特别是充值数据相同）	有套利嫌疑

以上 3 条模式作为辅助参考，帮助进一步判断，主要判据仍以第一条为准。

代理提款审核完整工作流¶

═══════════════════════════════════════════
  代理提款审核完整流程（2026-04 新标准）
═══════════════════════════════════════════

  看到备注"代理提款"
        │
        ▼
  锁定订单 → 打开会员信息详情页
        │
        ▼
========================================
  第一步：按第一条标准排查下级行为模式
  （主要判据）
========================================
        │
        ▼
  ┌───────────────────────────────────────┐
  │ 查看代理的下级用户：                    │
  │ · 下级的存款金额和打码量                │
  │ · 是否符合"存款 50-60 + 打码 ~600"模式 │
  │ · 这类下级占总下级数的比例              │
  └────────┬──────────────────────────────┘
           │
           ▼
========================================
  第二步：查账变记录
========================================
        │
        ▼
  ┌───────────────────────────────────────┐
  │ 排查【账变记录】：                      │
  │ · 是否领取了邀请奖励 / 拼多多奖励       │
  │ · 是否有正常充值                        │
  │ · 是否有正常游戏下注                    │
  │ · 参考辅助判定标准（3 条行为模式）       │
  └────────┬──────────────────────────────┘
           │
           ▼
========================================
  第三步：综合判定
========================================
        │
        ▼
  ┌─────────────────────────────────────┐
  │ 是否触发第一条？                      │
  │ （≥70% 下级符合套利模式）             │
  └────────┬────────────────────────────┘
           │
     ┌─────┴─────────┐
     │               │
  不触发            触发
     │               │
     ▼               ▼
  检查第三条        进入 P1/P2 处理
  （保留条件）
     │
     ▼
  ┌──────────────┐
  │ 满足第三条？   │
  │ （≥1 个下级    │
  │  大量存款+     │
  │  大量打码+     │
  │  近期活跃）    │
  └──────┬───────┘
     ┌───┴───┐
     │       │
    是      否
     │       │
     ▼       ▼
  审核通过   审核通过
  + 不拉层   （普通放行）
  + 删 P2
    备注

═══════════════════════════════════════════
  触发套利 → P1 / P2 处理流程
═══════════════════════════════════════════
        │
        ▼
  查看会员【备注】栏
        │
  ┌─────┴────────────────────────────┐
  │                                  │
 有 P1 备注                        无备注
 （之前警告过）                     （首次发现）
  │                                  │
  ▼                                  ▼
 P1 日期是当天吗？            ┌──────────────┐
  │                           │ P1 警告        │
  ┌──┴──┐                    │ · 备注"P1 警告  │
  │     │                    │   日期+经手人"  │
 是    否                    │ · 驳回提款      │
  │     │                    │ · 用户再次提交  │
  ▼     ▼                    │   → 直接通过放款│
┌────┐  排查账变              └──────────────┘
│直接│     │
│通过│  ┌──┴──┐
│放款│  │     │
│(不 │ 已改正  仍在套利
│重复│  │     │
│处理│  ▼     ▼
└────┘ 通过  进入 P2 处理 ↓

  ≤3 个下级 + 只领了一个邀请奖励
  → 酌情给过（让他有动力发展下级）

========================================
  P2 处理流程
========================================

  P2 可由两条路径触发：
  ┌─────────────┬──────────────────┐
  │ 路径 A       │ 路径 B            │
  │ 稽核团队     │ 副组长自己        │
  │ 发现仍在套利 │ 审核时发现仍套利  │
  └──────┬──────┴──────┬───────────┘
         │             │
         ▼             ▼
  P2 处理动作（不论谁触发，操作相同）：
  ┌───────────────────────────────────────┐
  │ (1) 关闭投注权限                        │
  │ (2) 关闭提款权限                        │
  │     ⚠️ 佣金权限保持开放                  │
  │ (3) 拉入套利观察层                      │
  │ (4) 备注"P2 警告 日期+经手人"           │
  │ (5) 驳回订单                            │
  │ (6) 通知客服                            │
  └────────┬──────────────────────────────┘
           │
           ▼
  用户联系客服 → 确认可以扣款处理
  → 客服通知副组长执行扣款
           │
           ▼
  ╔══════════════════════════════════╗
  ║  第五条 · 副组长二重审核          ║
  ║  按第一条~第四条标准再次判断      ║
  ╚══════════════════════════════════╝
           │
     ┌─────┴─────┐
     │           │
  符合 P2      不符合 P2
     │           │
     ▼           ▼
  走扣款流程   不扣款处理：
  （见 4.2）   · 取消 P2 备注
  · 扣除彩金   · 拉出套利观察层
  · 扣后解开   · 按注册日期改为
    投注/提款     7日/30日留存层级
  · 仍留在     · 备注"不扣款，
    观察层       日期+经手人"
  · 佣金权限
    保持开放
  · 财务群报备

📝 来源：学习讨论

备注格式规范¶

邀请奖励（BH BAT）备注模板：

场景	账号备注	驳回备注	发群	关闭按钮
P1 警告（首次）	`BH BAT，Peringatan/P1 {经手人代号}{日期}`	`Pelanggaran Terdeteksi! Peringatan ini hanya berlaku sekali. Mohon untuk bermain secara tepat dan benar.`（检测到违规！此警告仅一次有效，请正确游戏）	不发群	—
P2 处理（二次）	`BH BAT，P2 tarik Bonus+Kemenangan {经手人代号}{日期}`	`Segera hubungi live chat`（请立即联系在线客服）	后台名称+会员账号+备注内容	投注+提款（2个）
未存款封锁	`BH BAT, tanpa deposit Blockir {经手人代号}{日期}`	`Segera hubungi live chat`	备注内容	投注+充值+提款（3个）

BH BAT = 邀请奖励套利标识；{经手人代号} 如 bx/jl/aa；{日期} 如 0215（2月15日）

拼多多奖励（BH RK）备注模板：

场景	账号备注	驳回备注	发群	关闭按钮
P1 处理（首次）	`BH RK，P1 tarik bonus+kemenangan {经手人代号}{日期}`	`Segera hubungi live chat`	后台名称+会员账号+备注内容	投注+提款（2个）
未存款封锁	`BH RK，tanpa deposit Blockir {经手人代号}{日期}`	`Segera hubungi live chat`	备注内容	投注+充值+提款（3个）

BH RK = 拼多多奖励套利标识

⚠️ 邀请 vs 拼多多关键区别： - 邀请奖励：P1 只是警告（不发群、不关按钮）→ 再犯才进 P2（关按钮+扣款） - 拼多多：P1 直接关 2 个按钮 + 发群 → 没有单独的 P2。用户联系客服后由副组长审核，确认是拼多多套利则直接走邀请 P2 的扣款流程（扣除彩金+盈利）

其他场景备注：

场景	备注模板	示例
二次审核推翻（不符合 P2）	`不扣款，可以出 {日期} {经手人}`	`不扣款，可以出 4.21 AA`
观察层拉出恢复	删除所有备注，视为正常会员	—

📘 来源：06-稽核组长工作指南（备注模板与稽核团队统一使用）

正常代理 vs 套利代理 · 判定公式¶

看下级用户，不看代理本身。 - 代理本身可以不充值、不投注——"代理没充值没游戏" 不是套利标志 - 下级行为正常（不符合"存款 50-60 + 打码 600 + ≥70%"模式）→ 代理提奖励合规 - 下级行为高度雷同（符合上述模式 ≥70%）→ 套利嫌疑

📘 来源：04-禁止投注问题排查（锁定操作路径） 📝 来源：学习讨论（完整审核流程和套利判定标准）

🤖 自动化机会：下级行为模式排查 + 账变记录检查是副组长最耗时的工作之一。可通过脚本自动扫描下级的存款/打码量分布、计算符合套利模式的比例、标记异常代理。完整 API 需求书见 12-自动化路线图/01-代理提现审核API.md。这些排查如果能标准化为后台一键功能——输入代理 ID 自动拉取下级数据、计算套利比例、给出判定建议——副组长只需确认结果并执行操作，试运行一段时间后可完全自动化处理，保留副组长随机抽查。

4.2 扣款处理¶

为什么扣款 / 权限变更 / 加款这类操作必须群内报备 + 后台备注 + 财务报备三层留痕：基于 §1.3 防断链红线。

这类操作涉及会员账户的核心资金状态——事后如果出现争议（用户投诉、合规审查、内部资损追溯），必须有完整记录证明谁在什么时间做了什么决定。群通告 + 后台日志 + 财务报备多重留痕，缺一会让副组长无法证明清白。

副组长可以直接执行扣款操作，但扣款不是副组长自行发起的——完整链路是：稽核团队发现问题 → 关闭用户相关权限 → 客服与用户沟通 → 用户同意扣款 → 客服发消息给副组长 → 副组长执行扣款 → 恢复权限 → 通知客服 → 财务群报备。

  稽核团队发现问题
  （关闭用户提现等权限）
        │
        ▼
  客服与用户沟通扣款事宜
        │
        ▼
  用户同意扣款?
  ├─ 否 → 客服反馈稽核团队，走升级流程
  │
  └─ 是 → 客服在群内发起扣款需求
              │
              ▼
        ┌───────────────────────┐
        │ (1) 群内认领            │
        └────────┬──────────────┘
                 │
                 ▼
        ┌───────────────────────────────────────────┐
        │ (2) 查用户【账变记录】                      │
        │     核实需要扣除的金额：                     │
        │     · 邀请奖励                              │
        │     · 拼多多奖励                            │
        │     · 通过上述奖励产生的盈利                  │
        │     扣除原则：只保留用户自己充值的金额，       │
        │     或者用户在获得奖励之前的账户余额           │
        └────────┬──────────────────────────────────┘
                 │
                 ▼
  ======================================================
    (2.5) 交叉验证（必做，确认稽核判断准确性）
  ======================================================
        ┌───────────────────────────────────────────┐
        │ · 按 4.1.5 四条标准重新审核                  │
        │ · 查看下级行为模式是否符合套利特征            │
        │ · 确认稽核团队的判断是否准确                 │
        │                                            │
        │ · 确认有问题 → 继续执行扣款                 │
        │ · 发现异议 → 反馈稽核团队，暂停扣款         │
        └────────┬──────────────────────────────────┘
                 │
                 ▼
        ┌───────────────────────┐
        │ (3) 后台执行扣款        │
        │     路径：会员管理 →    │
        │     会员列表 → 点UID → │
        │     账号数据 → 修改余额 │
        └────────┬──────────────┘
                 │
                 ▼
        ┌───────────────────────────────┐
        │ (4) 恢复用户被关闭的权限       │
        │     （提现/投注等，按稽核要求） │
        └────────┬──────────────────────┘
                 │
                 ▼
        ┌───────────────────────┐
        │ (5) 群内通知客服        │
        │     "已扣款+已恢复权限" │
        └────────┬──────────────┘
                 │
                 ▼
        ┌───────────────────────┐
        │ (6) 财务群报备          │  ← 硬性报备
        │ 含：平台 / 用户ID /    │
        │     扣款金额 / 原因    │
        └───────────────────────┘

财务群报备模板：没有单独维护的模板文件，直接参照群里其他同事最近的报备消息照抄格式（关键字段照上面流程图的 4 项：平台 / 用户 ID / 扣款金额 / 原因）即可。

扣款金额计算原则：

需要扣除	需要保留
邀请奖励金额	用户自己充值的金额
拼多多奖励金额	获得奖励之前的账户余额
通过上述奖励产生的盈利	—

核心逻辑：奖励相关的钱（含盈利）全部扣除，用户自己的钱全部保留。需要查账变记录逐笔核实，不能粗暴地按当前余额一刀切。

📝 来源：学习讨论

⚠️ 扣款 ≠ 收回款项（两个完全不同的动作）¶

维度	扣款（本节）	收回款项
触发原因	用户违规 / 负欠 / 风控扣减	刚刚误确认的一笔充值订单
时效	无时限，可随时操作	订单确认后 30 分钟内（过期按钮消失）
操作路径	会员管理 → 会员列表 → 点 UID → 账号数据 → 修改余额	财务管理 → 入款记录 → 收回款项
作用对象	会员现有余额	该次充值订单（余额扣除 + 订单变取消 + 流水回滚）
谁触发	客服反馈	财务/管理员发现误确认时自救
财务报备	✅ 必须	✅ 大额或频繁收回需联动财务

判定口诀： - 客服说"这个用户有违规需要扣钱" → 走扣款 - 管理员/财务说"我刚才确认错了一笔充值，赶紧撤" → 走收回款项（30 分钟倒计时！）

📘 来源：05-充值订单收回款项 + 13-会员与风控/01-会员列表

两种"加减款"类型必须分清¶

类型	是否计入充值统计	用途
人工加减款	✅ 计入存款	补充值、财务调整
彩金加减款	❌ 不计入存款	活动补偿、漏发彩金（日常用这个）

操作路径：会员管理 → 会员列表 → 点 UID → 账号数据 → 修改余额（弹窗内选择类型）。

补充要点： - 所有人工加减款自动写入操作记录，含操作前余额 / 操作后余额 / 操作人 / 原因备注 - 副组长操作时必须填写备注（含工单号 / 客诉号）——审计护身符 - 单次/单日上限在 系统管理 → 后台账号 配置，超限系统直接拒绝

📘 来源：13-会员与风控/01-会员列表 + 17-活动记录/10-彩金加减款记录

4.3 会员权限变更¶

  客服在群内发起需求
        │
        ▼
  ┌──────────────────────────────┐
  │ 在群内认领                    │
  │ 话术：对消息回复 OK / ✅ 打勾 │
  └────────┬─────────────────────┘
           │
           ▼
  ┌───────────────────────┐
  │ 后台执行权限变更        │
  └────────┬──────────────┘
           │
           ▼
  ┌───────────────────────────────────┐
  │ 是否涉及加款/扣款？                  │
  └────────┬──────────────────┬───────┘
           │ 是                │ 否
           ▼                   ▼
  ┌──────────────────┐   ┌──────────────────┐
  │ 必须在财务群报备  │   │ 群内回复"已处理"  │
  │ 写清：平台/用户ID │   └──────────────────┘
  │ /操作类型/金额/原因│
  └──────────────────┘

📘 来源：13-会员与风控/01-会员列表 📝 来源：学习讨论

4.4 订单回调处理¶

适用范围：目前有两种场景需要副组长执行订单回调——推广投流和远程测试。两者回调操作相同（都是通过三方渠道机器人 /testpay 订单号），但回调后的权限处理不同。

核心目的：配合各团队完成测试，同时确保回调添加的测试金额不会被意外提取。

⚠️ 重要规则：如果测试回调的订单没成功或出现任何问题，必须重新注册新账号、重新提交订单来进行回调。不能用同一个账号提交两笔订单来回调两次。

场景一 · 推广投流订单回调¶

  群里收到投流订单回调需求（推广团队）
        │
        ▼
  ┌───────────────────────┐
  │ 群内认领               │
  └────────┬──────────────┘
           │
           ▼
  ┌───────────────────────────┐
  │ 通过三方渠道 Telegram 机器人│
  │ 执行：/testpay 订单号      │
  └────────┬──────────────────┘
           │
           ▼
  ┌───────────────────────────┐
  │ 后台 → 关闭提款权限        │
  │ 做好备注：【testpay】      │
  │                           │
  │ ⚠️ 投流账户不做解锁处理     │
  └────────┬──────────────────┘
           │
           ▼
  ┌───────────────────────────┐
  │ 群内回复"已处理"          │
  └───────────────────────────┘

场景二 · 远程测试人员充值/提款测试回调¶

远程测试人员需要走完整的充值+提款测试流程。与投流的区别在于：保留提款权限（测试人员后续要提交测试提款订单），但关闭自动出款（防止测试金额被真实出款）。

  群里收到远程测试订单回调需求（测试团队）
        │
        ▼
  ┌───────────────────────┐
  │ 群内认领               │
  └────────┬──────────────┘
           │
           ▼
  ┌───────────────────────────┐
  │ 通过三方渠道 Telegram 机器人│
  │ 执行：/testpay 订单号      │
  │ （与投流回调操作相同）      │
  └────────┬──────────────────┘
           │
           ▼
  ┌────────────────────────────────┐
  │ ⚠️ 权限处理（与投流不同）       │
  │                                │
  │ · 提款权限 → 保留（不关）       │
  │ · 自动出款 → 关闭               │
  │   （防止测试金额被真实出款）     │
  │                                │
  │ 做好备注：【远程测试】          │
  └────────┬───────────────────────┘
           │
           ▼
  ┌────────────────────────────────┐
  │ 测试人员提交测试提款订单        │
  │          │                     │
  │          ▼                     │
  │ 副组长收到提款订单后 → 驳回     │
  │ （测试完成，不实际出款）        │
  └────────┬───────────────────────┘
           │
           ▼

两种场景对比速查：

维度	投流回调	远程测试回调
触发方	推广团队	远程测试人员
回调命令	`/testpay 订单号`	`/testpay 订单号`（相同）
提款权限	关闭	保留（测试需要）
自动出款	不涉及（提款已关）	关闭（防止真实出款）
后续提款订单	无（权限已锁）	测试人员会提交 → 副组长驳回
备注关键字	`testpay`	`远程测试`
防资损手段	锁提款权限	关自动出款 + 人工驳回

📝 来源：学习讨论

📘 来源：20-系统管理/04-操作日志（锁定操作留痕）

4.5 打码量核查¶

为什么有 4 种计算方式：游戏的风险等级不同——不同游戏被套利的方式不同，需要的打码强度也不同：

计算方式	适用游戏	防什么
按投注	低风险（老虎机等）	防纯薅羊毛（用户领奖金后立即提现）
按中奖	部分中风险	防只算赢的部分套利
混合 1 / 混合 2	高风险（体育、真人）	防对冲套利（用户两边下注锁定盈亏，再提现）

副组长核查打码时，按订单实际打的游戏对应的计算方式来——不能套用其他类型的公式。

副组长审核提现时，常见的拒绝理由是打码量（有效投注额）不足。

四种有效打码计算公式¶

模式	公式	典型适用	倾向
① 按投注金额	`有效打码 = 投注金额`	低风险游戏（Slot等）	最宽松
② 按中奖金额	`有效打码 = 中奖金额`（未中奖为0）	极少使用	对用户不利
③ 混合模式 1	未中奖：`有效打码 = 投注金额`；中奖：`有效打码 = min(投注, 中奖)`	折中场景	平衡
④ 混合模式 2	`有效打码 = min(投注, \|投注-中奖\|)`	高风险游戏、反套利	最严格

规则修改只对后续订单生效，历史订单不变。

📘 来源：03-有效打码计算方式

核查路径¶

  提现订单命中风控：疑似打码不足
        │
        ▼
  后台路径：游戏排序 → 游戏分组列表
        │
        ▼
  查看该用户参与的游戏所属分组
        │
        ▼
  查看分组的"有效打码计算方式"
        │
        ▼
  对比活动/流水门槛
        ├─ 达标 → 通过提现
        └─ 不达标 → 驳回 + 备注"剩余打码 XXX" → 通知客服

快捷方式：后台有"剩余打码量"直接显示页（会员档案 → 剩余打码量栏位），大多数情况下不需要手动反算。

📘 来源：03-有效打码计算方式 + 13-会员与风控/07-打码量变动记录

4.6 禁投问题排查¶

三类锁定的自动触发规则（来源：13-会员与风控/11-用户锁定列表）：

锁定类型	触发条件	阈值配置位置
登录锁定	登录密码错误次数超限	运营配置 → 站点配置 → 登录配置
投注锁定	提现密码错误次数超限（同时触发提款锁定）	运营配置 → 站点配置 → 提现配置
提款锁定	提现密码错误次数超限（同时触发投注锁定）	同上

关键事实：录入提现密码错误 x 次 → 同时触发投注锁定 + 提款锁定 两类。两类阈值独立——登录密码错误和提现密码错误互不干扰。

为什么不能轻率解锁：自动锁定本身就是风控信号。如果是真忘了密码（让用户走重置流程）OK；但密码连续错 = 有人在试密码，可能是账号被盗，这种不能直接解锁，要走 §5.2.3 二次验证流程。

当客服反馈"用户说自己无法下注"时：

  客服转单：用户 XXX 无法投注
        │
        ▼
  ┌───────────────────────────────┐
  │ Step 1：群内认领                │
  └──────────┬────────────────────┘
             │
             ▼
  ┌───────────────────────────────┐
  │ Step 2：后台排查               │
  │ 路径：会员管理 → 用户锁定列表  │
  │ 检查三类锁定：                 │
  │   ① 登录锁定（完全无法访问）   │
  │   ② 投注锁定（能登不能下注）   │
  │   ③ 提现/佣金锁定             │
  └──────────┬────────────────────┘
             │
             ▼
       找到锁定项？
         ├─ 是 → 判断锁定原因
         │       ├─ 代理套利 → 不能解，走风控升级
         │       ├─ 违规人工锁 → 向上级确认再解锁
         │       └─ 风控自动触发 → 调查后再解锁
         │
         └─ 否 → 非锁定导致（API限制/设备异常/余额不足）→ 转技术

❌ 红线：解锁前必须调查原因。轻率解锁曾被锁定的账号，可能放过真实套利用户。

关键事实： - 提现密码错误超限会同时触发"投注锁定"+"提款锁定" - 提现密码只能"清空"不能"改"，清空后会员需重新设置

📘 来源：04-禁止投注问题排查 + 13-会员与风控/11-用户锁定列表

4.7 活动日 RTP 回报率调整（周期性任务）¶

这是经理级别的工作，但有时会交给有后台权限的组长或副组长执行。

背景¶

老站点的老用户多、VIP 等级高。每逢活动日（一般是周一）需要发放大量奖金，如果不提前调整 RTP 回报率，当天该平台的存提差可能直接冲到负数（平台亏损）。通过降低特定层级用户的 RTP，可以对冲活动奖金的支出。

执行时间¶

活动日前一天晚上（一般周日 23:30 左右开始）
必须在活动日 00:00 前完成

操作流程¶

  活动日前一天 ~23:30（如周日晚）
        │
        ▼
  ┌───────────────────────────────────────┐
  │ (1) 后台：会员管理 → 会员层级          │
  └────────┬──────────────────────────────┘
           │
           ▼
  ┌───────────────────────────────────────┐
  │ (2) 对以下三个层级执行操作：            │
  │     · 15 日留存用户                    │
  │     · 30 日留存用户                    │
  │     · 套利观察者                       │
  └────────┬──────────────────────────────┘
           │
           ▼
  ┌───────────────────────────────────────┐
  │ (3) 点击"一键设置回报率"               │
  │     具体回报率数值由经理预先设定        │
  │     副组长按经理指示执行，不自行调整    │
  └────────┬──────────────────────────────┘
           │
           ▼
  ┌───────────────────────────────────────┐
  │ (4) 确认三个层级都已设置完成            │
  │     群内报备："RTP 已调整"              │
  └───────────────────────────────────────┘

注意事项¶

仅针对老站点：新站点用户少、VIP 等级不多，一般不需要调整
回报率由经理决定：副组长只执行，不自行判断应该设多少
时间敏感：必须在活动开始前完成，否则活动期间平台可能亏损
三个层级缺一不可：15 日留存、30 日留存、套利观察者都要设置

📝 来源：学习讨论

4.8 冲正退款订单处理（B 线响应任务）¶

背景¶

会员提现成功后，三方代付当时自动回调成功。但可能过了一两天，该笔下发订单在三方代付那边出现银行处理失败或其他问题，导致银行冲正退款——即钱没有真正到达用户账户。这种情况下需要人工将该笔金额补回给用户。

发现渠道¶

三方代付的机器人会在对应的 Telegram 代付群里发送冲正通知
目前有专人每天在各个代付群里用"冲正"关键词搜索，找出未处理的冲正订单
统一发送给一个人去批量处理

完整处理流程¶

  在代付群发现冲正订单通知
  （或收到批量冲正订单清单）
        │
        ▼
  ┌───────────────────────────────────────┐
  │ (1) 获取订单号                          │
  └────────┬──────────────────────────────┘
           │
           ▼
  ┌───────────────────────────────────────┐
  │ (2) 去 Signal 出入款查单群搜索该订单号  │
  │     看是否已有人处理过                  │
  └────────┬──────────────────────────────┘
           │
           ▼
     Signal 群已有记录？
        ├─ 是 → 说明已处理，跳过该订单
        │
        └─ 否 → 继续处理
              │
              ▼
  ┌───────────────────────────────────────┐
  │ (3) 在对应的代付群用机器人再查一次     │
  │     订单状态，记录处理时间              │
  └────────┬──────────────────────────────┘
           │
           ▼
  ┌───────────────────────────────────────┐
  │ (4) 后台查询用户账变记录               │
  │     找到对应的那笔提现订单              │
  │     例如：提现订单金额 = 20            │
  └────────┬──────────────────────────────┘
           │
           ▼
  ┌───────────────────────────────────────┐
  │ (5) 往回看账变记录：                    │
  │     是否已有一条"添加彩金 20"的记录？   │
  └────────┬──────────────────────────────┘
           │
           ▼
     已有添加彩金记录？
        ├─ 是 → 说明已有人处理过，跳过
        │
        └─ 否 → 需要补款
              │
              ▼
  ┌───────────────────────────────────────┐
  │ (6) 通过"添加彩金"给用户补回金额       │
  │     金额 = 提现订单金额                │
  │     备注："提现订单失败，人工加款"      │
  └────────┬──────────────────────────────┘
           │
           ▼
  ┌───────────────────────────────────────┐
  │ (7) 在 Signal 出入款查单群报备          │
  │     格式：                              │
  │     · 平台名称                          │
  │     · 用户 ID                           │
  │     · 对应订单号                        │
  │     · 备注内容                          │
  │     · 处理人                            │
  └───────────────────────────────────────┘

关键要点¶

双重确认防重复：先查 Signal 群 → 再查账变记录，两道关卡确保不重复补款
备注规范：统一写"提现订单失败，人工加款"，方便后续审计追溯
使用彩金加减款：补回金额走"添加彩金"操作，不走"人工加减款"（不计入充值统计）
报备必须完整：Signal 群报备包含平台/用户ID/订单号/备注/处理人五要素，是否有必要专门发送短信告知用户？特别是比较久以前的订单，有些甚至是上个月的订单，可能我们补余额用户都不知道？

📝 来源：学习讨论

🤖 自动化机会：可通过脚本自动从代付群抓取冲正关键词通知，自动查询订单状态和账变记录，生成待处理清单，减少人工逐群搜索的时间

4.9 充值成功率监控（每半小时）¶

为什么 60% 阈值 / 半小时频率 / 10 分钟窗口：❓ 具体数值由经理 / 技术决定，副组长按当前规则执行。

但要理解这套数字背后的目的： - 半小时频率：足够及时发现异常，又不至于浪费精力（每隔 30 分钟扫一次） - 10 分钟窗口：保证数据样本量（10 分钟内有足够订单做统计），同时也不会被瞬间抖动误判 - 60% 阈值：低于此值意味着大量用户充值失败 = 直接收入流失，必须立即介入

背景¶

印尼市场充值成功率直接决定平台收入。低成功率 = 大量用户充值失败 = 用户当场流失（印尼用户耐心低，一次失败就换平台的不在少数）。所以必须实时监控充值成功率，在跌破阈值时立刻介入优化，不能等用户投诉才发现。

关键参数¶

项	值
巡检频率	每半小时 1 次
观察窗口	近 10 分钟的充值成功率
介入阈值	成功率 < 60% 必须介入
首选动作	通知代收商户优化通道
兜底动作	切换代收渠道（调整充值方式排序）

完整处理流程¶

  每半小时（:00 / :30 整点）
        │
        ▼
  ┌────────────────────────────────────┐
  │ (1) 查看后台近 10 分钟充值成功率   │
  │     逐个平台查                      │
  └──────────┬─────────────────────────┘
             │
             ▼
        成功率 < 60%？
             │
        ┌────┴────┐
        │         │
       否         是
        │         │
        ▼         ▼
  ┌──────────┐  ┌────────────────────────────────────┐
  │ 维持原   │  │ (2) 定位是哪个代收商户的问题         │
  │ 配置，   │  │     （看哪个商户成功率最低）         │
  │ 继续监控│  └──────────┬──────────────────────────┘
  │          │             │
  │          │             ▼
  │          │  ┌────────────────────────────────────┐
  │          │  │ (3) 去对应代收商户的 Telegram 群    │
  │          │  │     通知商户去优化通道               │
  │          │  │     说明：成功率偏低，请优化         │
  │          │  └──────────┬──────────────────────────┘
  │          │             │
  │          │             ▼
  │          │  ┌────────────────────────────────────┐
  │          │  │ (4) 持续监控优化效果                │
  │          │  │     再观察 10-15 分钟的成功率        │
  │          │  └──────────┬──────────────────────────┘
  │          │             │
  │          │             ▼
  │          │        成功率恢复？
  │          │             │
  │          │        ┌────┴────┐
  │          │        │         │
  │          │       是         否
  │          │        │         │
  │          │        ▼         ▼
  │          │  ┌──────────┐  ┌────────────────────────────┐
  │          │  │ 有效！   │  │ (5) 切换其他代收渠道         │
  │          │  │ 保持原   │  │     · 调整充值方式排序       │
  │          │  │ 配置，   │  │     · 把问题商户降权/排后    │
  │          │  │ 继续监控 │  │     · 把替补商户提到前面     │
  │          │  │          │  │     · 保持代收代付排序一致   │
  │          │  └──────────┘  │       （见 3.6 核心原则）    │
  │          │                └──────────┬─────────────────┘
  │          │                           │
  │          │                           ▼
  │          │                  ┌────────────────────────┐
  │          │                  │ (6) 群内报备 + 记录本   │
  │          │                  │     次切换，便于回溯     │
  │          │                  └────────────────────────┘
  └──────────┘

关键要点¶

半小时频率不是随意定的：10 分钟窗口保证数据有代表性（排除偶发抖动），30 分钟巡检间隔保证能快速发现问题（最多延迟 30 分钟）
先通知商户、再切渠道：通知商户优化是成本最低的方案（商户自己也不愿失去流水），只有商户确实搞不定才切渠道
切渠道要和 3.6 原则对齐：调整代收排序时，代付排序同步调整，保持一致
每次介入要留痕：群内报备"XX:30 巡检发现 A 平台成功率 52%，已通知 CP-X 商户优化 / 已切换到 CP-Y"，方便交班和事后复盘

引用：08-充值方式排序

📝 来源：学习讨论

🤖 自动化机会：把成功率监控做成实时告警——后台每 5 分钟计算一次近 10 分钟成功率，低于 60% 自动 @副组长并标注问题商户，减少人工每半小时手动查询。

4.10 提现订单 30 分钟未回调处理¶

背景¶

正常情况下，代付订单提交给三方商户后，应该在几分钟内拿到回调（成功或失败）。30 分钟仍未回调 = 代付方出了问题，可能的场景：

商户内部还在"处理中"（卡单）
商户通道异常（银行侧慢、风控拦截、商户系统故障）
商户已经处理但回调丢失

不论哪种，都需要副组长主动介入去和商户确认，不能干等——等下去用户会直接投诉"提现 30 分钟没到账"。

发现渠道¶

后台提现记录页面有专门的"已提交 30 分钟未回调订单"分类/提醒
进入该列表就能看到全部积压订单

完整处理流程¶

  后台提醒 / 定期查看提现记录
  发现"30 分钟未回调"订单列表
        │
        ▼
  ┌────────────────────────────────────┐
  │ (1) 先数一下订单数量                │
  └──────────┬─────────────────────────┘
             │
             ▼
        订单数量？
             │
        ┌────┴────┐
        │         │
       少         多
     (<5)       (>=5)
        │         │
        ▼         ▼
  ┌──────────┐  ┌────────────────────────────────────┐
  │ 直接批量│  │ (2') 先按代付商户分组                │
  │ 复制订单│  │      （同一批订单可能分属多个商户）   │
  │ 号发到  │  │      再按商户分别批量发到对应群      │
  │ 对应代付│  └──────────┬──────────────────────────┘
  │ 群      │             │
  └────┬────┘             │
       │                  │
       └────────┬─────────┘
                ▼
  ┌────────────────────────────────────┐
  │ (3) 在代付群先确认订单归属商户      │
  │     （避免张冠李戴）                 │
  │     用机器人查该订单号的商户方       │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (4) 让对应商户排查并解决             │
  │     · 商户查内部处理状态             │
  │     · 能处理的商户会主动回调补发     │
  └──────────┬─────────────────────────┘
             │
             ▼
        商户能解决？
             │
        ┌────┴────┐
        │         │
       能         不能
        │         │
        ▼         ▼
  ┌──────────┐  ┌────────────────────────────────────┐
  │ 等待商户│  │ (5) 商户驳回订单                     │
  │ 补发回调│  │     → 系统自动处理订单驳回           │
  │ 订单正常│  │     → 余额自动退回用户账户           │
  │ 完成    │  │     → 用户可以重新发起提现            │
  │         │  │     （选其他代付渠道）               │
  └──────────┘  └────────────────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (6) 在值班群/Signal 出入款群报备    │
  │     · 订单号 / 用户 ID / 处理结果   │
  │     · 方便后续查询和审计            │
  └────────────────────────────────────┘

关键要点¶

订单归属先确认：同一批 30 分钟未回调订单可能分属多个商户，发群前/发群后都要在群内查确认，不要把 A 商户的单丢给 B 商户处理（浪费时间）
商户驳回 ≠ 资损：商户驳回订单后，系统会自动把金额退回用户账户（前提是资金确实没出到用户手里），用户可以重新提现
不要自己手动退款：走系统驳回流程是标准路径，自己手动"加彩金"补回很容易造成重复出款
和 4.11 的区别：4.10 是"30 分钟没回调"（还在等回调），4.11 是"代付接口超时"（接口层面已经超时了），两类都要处理但来源不同

引用：06-提现记录

📝 来源：学习讨论

🤖 自动化机会：30 分钟未回调订单可自动分组并按商户批量推送到对应代付群，副组长只需确认和跟进；恢复成功自动销单。

4.11 代付接口超时订单处理¶

背景¶

"代付接口超时"是另一类异常，和 4.10 的"30 分钟未回调"不是一回事：

4.10（30 分钟未回调）：接口调用成功了，但商户迟迟不给回调 → 等商户
4.11（接口超时）：调用接口时就超时了（商户侧可能根本没收到请求，或收到了但返回慢）→ 订单状态不明

接口超时的订单状态是模糊的——可能商户压根没处理（余额还在我方商户账户），也可能商户处理了但超时回应失败（余额已经扣出去）。必须跟商户二次确认后再决定怎么办，不能凭感觉操作，否则极易造成重复出款资损。

⚠️ 重要提醒：代付接口超时订单页面没有"驳回"按钮，操作入口是 "重新出款" 按钮。流程是：确认资金在我方账户 → 点"重新出款" → 订单自动进入提现出款页面 → 在提现出款页面选其他代付渠道重新出款。

发现渠道¶

后台提现记录页面 → "代付接口超时订单"分类

完整处理流程¶

  后台发现"代付接口超时订单"
        │
        ▼
  ┌────────────────────────────────────┐
  │ (1) 逐笔跟对应代付商户再次确认      │
  │     （通常是之前处理 4.10 的同一商户）│
  │     在商户 Telegram 群用机器人命令   │
  │     查该订单实际状态                 │
  └──────────┬─────────────────────────┘
             │
             ▼
        商户侧订单状态？
             │
  ┌──────────┼──────────────────────┐
  │          │                      │
  商户已     商户未处理/处理失败     商户正在处理
  成功处理   余额已回到我方账户      （等待中）
  （已出款）                         
  │          │                      │
  ▼          ▼                      ▼
  ┌──────────────┐  ┌───────────────┐  ┌──────────────┐
  │ (2a) 点击    │  │ (2b) 点击      │  │ 继续等待回调 │
  │ "商户已出款" │  │   "重新出款"   │  │ 不要急于点   │
  │   按钮       │  │     按钮       │  │ 重新出款     │
  │ 回调订单状态 │  │                │  │ （否则可能重 │
  │ 为成功       │  └──────┬────────┘  │ 复出款）      │
  └──────────────┘         │            └──────────────┘
                       ▼
         ┌────────────────────────────────┐
         │ (3) 订单自动进入                │
         │     [提现出款页面]              │
         │     （[05-提现出款]文档）        │
         └──────────┬─────────────────────┘
                    │
                    ▼
         ┌────────────────────────────────┐
         │ (4) 在提现出款页面选择           │
         │     **其他代付渠道**（不是原来   │
         │     那个，那个刚刚超时了）       │
         │     手动审核通过                 │
         │     提交到新代付渠道出款         │
         └──────────┬─────────────────────┘
                    │
                    ▼
         ┌────────────────────────────────┐
         │ (5) 群内报备处理结果             │
         │     · 订单号                    │
         │     · 原商户（超时）→ 新商户     │
         │     · 处理人                     │
         └────────────────────────────────┘

关键要点（红线）¶

必须先跟商户确认"资金回到我方账户"再点"重新出款"：这是资损红线——如果商户那边已经出款了你又点了重新出款，相当于双倍出款，造成直接资损
商户正在处理中 → 继续等：不要急于点重新出款，等商户最终状态。宁可让用户等几分钟，也不要冒重复出款风险
选新代付渠道重发：订单进入提现出款页面后，选其他代付渠道——原渠道刚刚超时，再选同一个大概率还是超时
"重新出款"不是"驳回"：这个页面没有驳回按钮，不要到处找驳回；"重新出款"的本质是把订单重新放回出款队列，由副组长选新通道
和 4.10 的关系：处理 4.11 的时候，大概率对应的商户就是刚刚在 4.10 里出问题的商户。流程上是"4.10 先处理未回调 → 4.11 处理接口超时"的前后关系

引用： - 05-提现出款 - 06-提现记录

📝 来源：学习讨论

🤖 自动化机会：接口超时订单可以做自动查商户状态的机器人——自动在商户群查询订单实际状态，汇总到副组长面前，副组长只需点按钮确认"资金回到账户→驳回"。

4.12 开新台子（协助组长）¶

为什么副组长协助域名 + 客服自动化这两块：这两块都是用户触达链路的关键——

域名绑定：用户能否打开网站、PWA 是否能跳转，直接决定流量能不能落地。副组长是日常运营的实操方，参与配置能在域名出问题时第一时间发现（同 §3.6 代收代付的逻辑）

Salesmartly 客服自动化：客服是用户问题的第一接口，副组长每天跟客服群打交道，对客服需求最熟悉，参与配置能保证流程贴合实际客服节奏

这两项都是"业务连续性"导向——副组长懂业务，参与配置避免技术团队"独立配置出脱节方案"。

触发时机：组长通知开新站点时。属于不定期协助任务，不是每天做，接到通知才做。

副组长协助范围（两块）：

4.12.1 网址域名绑定¶

后台路径：域名管理 → 网站域名

操作步骤： 1. 接收组长提供的域名列表 + 类型（主域名 / 备用域名 / 跳转域名等） 2. 在后台逐个添加绑定，类型跟组长提供的对齐，不要自己猜 3. 添加完成后在组长通知里回复 已完成 XX 个域名绑定

4.12.2 Salesmartly 客服自动化流程配置¶

目标：把之前台子的自动化流程复制给新台子，并针对新情况做定制。

操作步骤： 1. 在 Salesmartly 客服后台，基于之前台子的自动化流程给新台子添加一套一样的 2. 针对新台子可能出现的新问题做定制更新，例如： - 针对某个新问题提供对应的截图 - 添加自动应答的答复文本 3. 配置自媒体渠道（例如 Telegram 机器人）的自动化流程 4. 配置完成后跟组长同步一句 新台子自动化流程已配完

📝 来源：学习讨论

注意事项： - 域名类型完全按组长提供的列表来，不要擅自改或补 - 客服自动化流程基于模板复制，不要从零手搓——对齐现有模板更快也更不容易出错 - 截图/文案如需新增要跟组长/客服确认内容，不要自己编

4.13 财务代付异常订单核查（B 线响应）¶

触发时机：财务在群里发来异常订单时（财务已经做过一轮比对发现问题）。

典型异常场景：

副组长自己（或其他副组长）在三方还在处理中的时候，手动把订单驳回了——前台会把这笔提款金额退回给会员账户；但是三方那边实际已经给会员的提款账户出款了——相当于同一笔钱出两次，平台直接资损。这种就是订单人工失误。

核查流程：

  财务群发来异常订单
        │
        ▼
  ┌────────────────────────────────────┐
  │ (1) 后台找到这笔订单                 │
  │     确认订单号 / 金额 / 用户 ID /   │
  │     当前状态 / 历史操作人            │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (2) 去对应代付群                    │
  │     用机器人查询订单真实状态         │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (3) 交叉比对两边状态                │
  │     · 后台显示 "已驳回/已退回会员"   │
  │     · 代付三方显示 "已出款到银行"    │
  │     两边不一致 → 有资损风险         │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (4) 必要时跟代付人工核实详细情况     │
  │     （如果机器人查询信息不够明确）   │
  └──────────┬─────────────────────────┘
             │
             ▼
  ┌────────────────────────────────────┐
  │ (5) 核查完成，按结果回复财务         │
  │     例：                            │
  │     · "XXXX 订单 人工失误"          │
  │     · "XXXX 订单 三方仍处理中"      │
  │     · "XXXX 订单 正常已出款"        │
  └────────────────────────────────────┘

核查结果的常见分类：

结果	含义	后续处理
人工失误	三方已出款，后台却被人工驳回 → 会员拿了双倍	回复财务 "XXXX 订单人工失误"，由财务/组长决定追回方式
三方仍处理中	代付订单还没最终结果	回复财务 "XXXX 订单三方仍处理中"，等待最终状态再判断
正常已出款	两边状态一致、金额一致，没有资损	回复财务 "XXXX 订单正常已出款"，事件关闭

📝 来源：学习讨论

注意事项： - 不要跳过后台比对直接回财务——后台状态和代付三方状态必须两边都看到才能定性 - 人工失误是最常见的资损点，特别是在 4.11 代付接口超时场景下人工决策出错 - 回复财务的措辞要精确（"人工失误" / "三方处理中" / "正常已出款"），不要模糊描述 - 所有核查结果记到值班表格，方便事后复盘和交接

🤖 自动化机会：后台订单状态 + 代付群机器人查询 + 结果分类这三步可以做成一键核查工具——副组长贴入订单号，工具自动去两处取状态并比对，给出分类建议，副组长确认后一键回复财务。

4.14 卡单补偿 + 拉回（夜班日常）¶

触发时机：夜班同事在早上 8 点之前，检查一遍 30 分钟未回调订单列表。

背景：用户提现后遭遇卡单（商户长时间未回调），如果用户因此失去信心不再存款，就会流失。通过主动补偿+主动联系，让用户感受到平台的诚意，减少因卡单导致的流失。

筛选条件：

检查前天的 30 分钟未回调订单（相对于检查日，例如 4/27 早上检查 4/25 的订单），逐笔检查是否符合以下条件：

用户最后一次存款时间 → 之后发起了提款 → 提款卡单 → 从最后存款时间到现在没有再存过款

示例：

最后存款时间：2026-04-25 09:01:02
提款时间：    2026-04-25 09:44:36（卡单）
从 09:01:02 之后再无存款记录 → ✅ 符合条件，执行补偿+拉回

完整操作流程：

夜班早上 8 点前
      │
      ▼
打开后台 → 提现记录 → 30 分钟未回调订单列表
      │
      ▼
逐笔检查每个订单：
      │
      ▼
┌────────────────────────────────────┐
│ (1) 点进用户详情页                   │
│     查看最后存款时间                  │
│     和提款时间（卡单的那笔）          │
└──────────┬─────────────────────────┘
           │
           ▼
     最后存款之后有没有再存过款？
           │
     ┌─────┴─────┐
     │           │
   有再存款      没有再存款
   （用户还在    （用户可能因
    活跃）        卡单流失）
     │           │
     ▼           ▼
   跳过，       ✅ 执行三步补偿拉回：
   检查下一笔
                 │
                 ▼
┌────────────────────────────────────┐
│ 步骤 1：彩金加款（1% 补偿）          │
│                                    │
│ · 按卡单金额的 1% 计算彩金           │
│   例：提款 1000 卡单 → 1%×1000 = 10 │
│ · 后台 → 该用户 → 彩金加减款         │
│   （不计入充值）                     │
└──────────┬─────────────────────────┘
           │
           ▼
┌────────────────────────────────────┐
│ 步骤 2：发送指定站内信               │
│                                    │
│ · 后台 → 站内信 → 指定用户发送       │
│ · 文案（印尼语）：                   │
│   "Halo Bos, WD Anda masih dalam  │
│    proses BANK bukan dari pihak    │
│    situs tidak proses ya, sebagai  │
│    tanda maaf kami berikan saldo   │
│    gratis untuk Anda. Mohon        │
│    ditunggu dengan sabar ya.       │
│    Terimakasih."                   │
│                                    │
│ · 含义：告知用户提现仍在银行处理中，  │
│   不是平台不处理，赠送免费彩金致歉   │
└──────────┬─────────────────────────┘
           │
           ▼
┌────────────────────────────────────┐
│ 步骤 3：发送拉回短信                 │
│                                    │
│ · 发送 SMS 通知会员                  │
│ · 文案（印尼语）：                   │
│   "Member setia (situs), saldo     │
│    kompensasi penarikan masih      │
│    dalam proses sudah masuk,       │
│    mohon maaf atas kendala yang    │
│    terjadi."                       │
│                                    │
│ · 含义：通知用户卡单补偿彩金已到账，  │
│   对造成的不便表示歉意              │
└──────────┬─────────────────────────┘
           │
           ▼
     处理下一笔订单，重复以上流程

参数速查：

参数	值	说明
执行时间	夜班早上 8 点前	白班交接前完成
检查范围	前天的 30 分钟未回调订单	相对于检查日
补偿比例	卡单金额的 1%	彩金加款（不计入充值）
补偿频次	每个用户做一次 ❓	待确认：多笔卡单是否每笔都补偿
站内信文案	固定模板（见上方）	每个站统一使用
短信文案	固定模板（见上方）	每个站统一使用

📝 来源：学习讨论

注意事项： - 这是主动拉回动作——用户还没来找我们，我们主动补偿+联系，体现平台诚意 - 只对卡单后没有再存款的用户做——如果用户已经再存款了说明没流失，不需要补偿 - 彩金加款用彩金加减款方式（不计入充值），不要用人工加减款 - 站内信和短信都要发，双渠道触达确保用户看到

五、常见问题处理¶

⚠️ 职责说明：以下 §5.1 ~ §5.3 三类会员资料修改类工作（密码重置、改绑账号）不是副组长亲自执行——由修改专员专门处理。

但副组长必须熟悉这些流程和原理： - 决策时刻——客服转单上来时副组长可能要做风险研判（如是否拉入"二次验证 / Data"层级） - 异常处理——修改专员处理不了或风险升级时由副组长接手 - 对接客服——回应客服对处理周期、凭证标准的疑问 - 培训新修改专员——副组长需指导新专员学习这套流程

§5.4 活动规则客诉速答属于副组长直接对接客服的工作。

5.1 会员忘记登录密码¶

核心原则：所有权验证是第一关。任何涉及密码/权限变更的请求，必须先验证所有权才能动手。

处理方式（不是清空，是改密）：后台把登录密码改为随机 6 位数 → 将"用户 ID + 随机密码"发到客服群 → 客服引导会员用该密码登录 → 会员登录后自行修改密码。

会员状态	需要的证据	处理动作
从未充值过	无（无所有权锚点）	直接改密为随机 6 位数 → 发客服群
有过充值	提供最近一次存款的证明（截图+订单号+银行流水）——取用户最后一次成功存款即可，无时间窗口限制	验证通过后，同样改密为随机 6 位数 → 发客服群

📝 来源：学习讨论

  客服转单："会员 X 忘记登录密码"
        │
        ▼
  ┌────────────────────────────────┐
  │ 进会员档案 → 查充值记录          │
  └──────────┬─────────────────────┘
             │
             ▼
        有充值记录?
        ├─ 无 → 后台改密为随机 6 位数
        │        → 发 "用户ID + 新密码" 到客服群
        │        → 客服引导会员用新密码登录
        │        → 会员自行修改
        │
        └─ 有 → 要求提供最近一次存款证明
                │
                ▼
                证明核对通过?
                ├─ 是 → 后台改密为随机 6 位数
                │       → 发 "用户ID + 新密码" 到客服群
                │       → 客服引导会员用新密码登录
                │       → 会员自行修改
                └─ 否 → 驳回 + 告知客服"凭证不符"

注意事项： 1. 不要清空密码——是改为随机 6 位数，让会员还能登录后自行修改 2. "用户 ID + 随机密码" 只发客服群，不发其他群 3. 改密后告知客服"引导会员登录后立即修改密码"，避免临时密码被滥用

5.2 会员忘记提款密码¶

重要：提款密码在后台只能"清空"不能"改"，会员下次提现需重新设置。

为什么"清空"而不是"修改"：提现密码在系统层只支持重置（清空让用户重设），不支持修改（直接改成新值）——这是产品/系统设计的硬约束。所以修改专员只能"清空"，让会员下次提现时自己重新设置。

为什么需要 §5.2.3 Data 层级二次验证：触发条件是频繁修改登录密码或提款密码 + 疑似账号被盗。这种行为模式高度像"账号被盗后被人改密"或"社工篡改账户信息"。把会员拉入 Data 层级后，所有提现操作都进人工审核，由副组长严格验证，防资损。

5.2.1 凭证要求（根据会员是否有过提款，分两种情况）¶

会员状态	凭证 ①	凭证 ②
有过提款	最后一次提款截图——从我们的游戏 APP 里截取会员的"提款记录"页（看到金额/时间/到账账户）	提款使用的银行/ewallet 账户 profile 页截图——能看到银行名 + 账号的前几位和后几位，用于核对一致性
没有过提款	最近一次存款截图——从会员用来存款的银行 APP / 钱包 APP 点开对应付款记录截图（金额/时间/对方账户）	提款使用的银行/ewallet 账户 profile 页截图——能看到银行名 + 账号的前几位和后几位，用于核对一致性

两项缺一不可——单靠一张截图做不了所有权验证。

📝 来源：学习讨论 📘 来源：13-会员与风控/11-用户锁定列表（提款密码只能清空不能改）

5.2.2 处理流程¶

步骤	动作	说明
1	查账户是否已绑定提款密码	未绑定 → 走绑定流程（不是"忘记"）
2	已绑定 → 查是否有提款历史	决定凭证走哪条路线
3	按 5.2.1 要求凭证 ① + ②	两项都要
4	核对截图信息与后台一致	金额/时间/账号前后几位都要对上
5	核对通过 → 清空提款密码	不是"改"，后台只能清空
6	查会员是否在用户锁定列表中	有的话需解锁
7	若在锁定列表 → 被锁的都解开（登录 / 投注 / 提款全部锁定项）	一次性全部解开——会员已证完归属，避免反复来回处理
8	回复客服群/客服转单的消息，明确告知已完成（清密 + 若有解锁也说明）	形成操作闭环
9	客服再告知会员：下次提现时需重新设置提款密码	客服提前告知，避免会员再困惑

  客服转单："会员 X 忘记取款密码"
        │
        ▼
  查账户是否绑定提款密码
        ├─ 否 → 不是"忘记"，让会员走首次绑定流程
        │
        └─ 是 → 查是否有提款历史
                │
        ┌───────┴────────┐
        ▼                ▼
   有提款历史        无提款历史
        │                │
        ▼                ▼
 要求两项凭证       要求两项凭证
 ① 最后一次提款    ① 最近一次存款
   截图（游戏        截图（银行/钱包
   APP 内）          APP 内付款记录）
 ② 提款银行/       ② 提款银行/
   ewallet profile   ewallet profile
   截图（银行名+     截图（银行名+
   账号前后几位）     账号前后几位）
        │                │
        └───────┬────────┘
                ▼
          核对凭证一致?
          ├─ 否 → 驳回 + "凭证不符" + 操作日志留痕
          │       ⚠️ 不能"差一项就放行"
          │
          └─ 是 → 清空提款密码
                      │
                      ▼
              查会员是否在【用户锁定列表】中
                      │
              ┌───────┴────────┐
              ▼                ▼
           不在              在列表
              │                │
              │                ▼
              │      被锁的都解开
              │      （登录 / 投注 / 提款
              │       全部锁定项一次性解掉）
              │                │
              └───────┬────────┘
                      ▼
              回复客服群：已完成（清密 + 若有解锁也说明）
                      ▼
              客服告知会员：下次提现需重新设置

注意事项： 1. 绝不凭"群里一句话"就动手——必须走客服转单 2. 两项凭证缺一不可——单张截图可能是盗图，profile 页用于交叉核对 3. 凭证 ② 的银行名 + 账号前几位后几位必须和后台绑定的取款账户一致——这是防社工关键 4. 解锁把锁定列表里的所有锁定项一次性全部解开（登录 / 投注 / 提款），不要遗漏。为什么一次性全解：会员已经走完了"账号归属证明"流程（凭证 ① + ②），属于正常会员——应该一次性把所有问题解决，避免会员因还有其他锁未解又反复来回处理，提升用户体验 5. 所有改密/清空/解锁操作必须在操作日志留痕 6. 处理完必须回复消息确认完成，形成闭环；不回复等于没做

5.2.3 "二次验证/Data"层级机制（密码重置安全加固）¶

背景：曾发现个别远程工作人员利用密码重置操作盗用会员账号、将会员资金提款到自己账户。为防止此类事件，新增"二次验证/Data"层级——被拉入此层级的会员所有提现操作都将进入人工审核，由副组长严格验证。

涉及两个团队的分工：

团队	职责	触发时机
RESET 团队	重置提现 PIN 时，在 Signal 确认操作是否当天/近期发生 → 确认后关闭自动提现 + 拉入"二次验证/Data"层级	会员进行 PIN 更换时
副组长（WD 团队）	审核"二次验证/Data"层级会员的提现订单，判定是否放行	该层级会员提交提现订单时

RESET 团队操作流程：

  会员请求重置提现 PIN
        │
        ▼
  ┌────────────────────────────────────┐
  │ 在 Signal 搜索该会员账号            │
  │ 确认是否在当天或近期有 PIN 更换操作  │
  └──────────┬─────────────────────────┘
             │
             ▼
        确认属实且有效？
        ├─ 否 → 按常规流程处理
        │
        └─ 是 → 执行以下操作：
              │
              ▼
        ┌────────────────────────────────┐
        │ (1) 关闭该会员的自动提现功能     │
        │ (2) 拉入"二次验证/Data"层级     │
        │ (3) 添加备注：                  │
        │     "WD 需二次确认，是否为       │
        │      旧提现资料"                │
        └────────────────────────────────┘

⚠️ 同日改登录密码 + 又改取款密码：如果发现会员在当天既修改了登录密码又修改了取款密码，可以直接拉进"二次验证/Data"层级。

📝 来源：学习讨论

副组长审核流程（WD 团队）：

收到"二次验证/Data"层级会员的提现订单后：

  收到提现订单，备注为
  "WD 需二次确认，是否为旧提现资料"
        │
        ▼
  ┌────────────────────────────────────┐
  │ 核查：会员提现到的是哪个账号？       │
  └──────────┬─────────────────────────┘
             │
     ┌───────┴───────┐
     │               │
  旧 WD 账号        新 WD 账号
  （旧提现资料）     （新提现资料）
     │               │
     ▼               ▼
  ┌──────────┐   ┌──────────────────────────┐
  │ ✅ 放行    │   │ ❌ 驳回该笔提现            │
  │ · 删除备注 │   │ · 关闭提现功能             │
  │ · 正常出款 │   │ · 要求会员配合视频验证     │
  │ · 拉出     │   │   （会员之前已提供截图，   │
  │   "二次    │   │    本步直接做视频验证，    │
  │    验证    │   │    无需重复要求截图）      │
  │   /Data"  │   │           │                │
  │   层级     │   │           ▼                │
  └──────────┘   │   视频验证（见下方规则）   │
                  │           │                │
                  │   ┌───────┴───────┐        │
                  │   ▼               ▼        │
                  │ 通过           不通过/拒    │
                  │ → 正常出款     → 维持关    │
                  │ → 拉出层级     → 上报组长  │
                  │ → 改正常层级                │
                  └──────────────────────────────┘

视频验证规则（这是已提供截图后的唯一核身环节，不再要求重复截图）：

⚠️ 目的是防止截图 PS 造假——截图可以伪造，但实时拍摄的操作视频伪造门槛极高。

视频规格（硬性要求）：

必须用另一台手机录制——不是被验证的那台手机自己拍自己

必须露出手指操作手机的画面——能看到真实的人在真实地操作

严禁手机内录屏（screen recording）——内录屏可以拼接 / 反复重做，无法证明实时性

视频中需同时展示两个不同电子钱包 APP 的账户信息页面（证明这些钱包确实属于同一个人）

如会员已经使用了 2 部手机（一部展示钱包 A，一部展示钱包 B），那么必须用第 3 部手机来录制视频，确保画面的真实性

判定标准：视频画面流畅 + 手指真实操作 + 两个钱包都能看到 + 不是录屏 → 通过；任一项不满足 → 不通过。

判定速查表：

情况	操作	原因
提现到旧账号（旧 WD 资料）	✅ 删备注 + 正常出款 + 拉出层级	旧账号说明是会员本人的正常提现
提现到新账号	❌ 驳回 + 关提现 + 直接进入视频验证（不重复要截图）	之前已收过截图，新账号需视频核身
视频验证通过	✅ 正常出款 + 拉出层级 + 改正常层级	视频确认钱包确属本人
视频验证不通过/拒绝配合	❌ 维持关闭提现 + 上报组长	高度疑似盗用，升级处理

📝 来源：学习讨论

📎 关联文档：客服管理专员视角的安全风控排查流程见 → 04-客服管理专员工作指南 · §十四客服安全风控——账号盗用排查

5.3 会员改绑银行卡 / 钱包账号¶

与 §5.2 改提款密码同等敏感——会员账户的"出款目的地"修改属于资金安全核心操作。 两种典型场景验证强度不同：修正小错（错 1-2 位） vs 完全换账号。

5.3.1 两种场景区分¶

场景	触发原因	验证强度
场景 A：修正 1-2 位输错	会员当时绑定时输错位	中——能匹配出"会员意图改的方向"即可
场景 B：完全换账号	会员要换一个完全不同的银行卡 / 钱包账号	高——必须证明本人操作

边界：1-2 位差异走场景 A；3 位以上差异或整段账号不同走场景 B。

5.3.2 凭证要求¶

场景 A：修正 1-2 位输错¶

凭证基础与 5.2.1 凭证要求同——根据会员是否有过存款 / 提款历史，提供凭证 ① + ②：

会员状态	凭证 ①	凭证 ②
有过提款	最后一次提款截图——从我们的游戏 APP 内截取（金额/时间/到账账户）	改后正确账号的 profile 页截图——能看到银行名 + 完整账号
没有过提款	最近一次存款截图——从会员用来存款的银行 / 钱包 APP 内（金额/时间/对方账户）	改后正确账号的 profile 页截图——能看到银行名 + 完整账号

关键核对：凭证 ② 必须清晰显示完整的正确账号——副组长能比对出"原来后台绑的账号是输错了 1-2 位，新账号是修正版"。

场景 B：完全换账号¶

凭证	要求
① 完整 ID 证件（印尼会员一般是 KTP）	不能是部分截图 / 模糊照——必须看清姓名 + 证件号 + 头像
② 新账户的完整截图	银行 App / 钱包 App 的账户主页——显示账号 + 户名 + 余额等基础信息
③ 三方一致性	ID 证件姓名 = 后台会员户名 = 新账户截图户名（三方完全匹配）

⚠️ 场景 B 的验证强度高于密码重置——出款目的地完全更换，资金风险敞口最大。

📝 来源：学习讨论

5.3.3 处理流程¶

步骤	动作	说明
1	客服转单——明确说明"改绑银行 / 钱包" + 哪种场景	不接受"群里一句话"
2	副组长判断是场景 A 还是场景 B	决定凭证强度
3	按 5.3.2 要求凭证	两项 / 三项缺一不可
4	核对凭证一致性	场景 A：原账号 vs 新账号差几位；场景 B：ID + 户名 + 新账户截图三方一致
5	核对通过 → 后台修改绑定信息	操作日志留痕
6	核对不通过 → 退回客服	要求会员重新提交
7	回复客服群确认"已完成改绑"	形成闭环

  客服转单："会员 X 要改绑银行卡 / 钱包"
        │
        ▼
  判断场景：是 A 修 1-2 位错 还是 B 完全换账号
        │
   ┌────┴────┐
   ▼         ▼
 场景 A      场景 B
   │         │
   ▼         ▼
 凭证 ① + ②  凭证 ① + ② + ③
 ( ② 显示    （完整 ID + 新账户
   完整新账号）  完整截图 + 三方一致）
   │         │
   └────┬────┘
        ▼
  核对凭证
        │
   ┌────┴────┐
   ▼         ▼
 通过       不通过
   │         │
   ▼         ▼
 后台改绑   退回客服重交
   │
   ▼
 回复客服群：已完成改绑

5.3.4 注意事项¶

绝不凭"群里一句话"就动手——必须走客服转单
场景 A 的"输错"边界：1-2 位是合理范围；3 位以上差异基本要按场景 B 处理（按副组长经验判断）
场景 B 的 ID 证件必须完整——头像 + 姓名 + 证件号都要清晰，模糊或部分遮挡的退回
三方一致性是场景 B 的红线：ID 姓名 / 后台户名 / 新账户截图户名任一不匹配——拒绝改绑
所有改绑操作必须在操作日志留痕
处理完必须回复客服群确认完成，形成闭环；不回复等于没做

📝 来源：学习讨论

5.4 活动规则客诉速答¶

副组长不策划活动，但客服会把用户对活动规则的疑问转过来。以下是客诉快速回答表：

客诉内容	速答	排查要点
"没收到周奖励"	查周一 04:00 结算、充值门槛、7 天作废期	是否已过作废期？
"月奖励过期能补吗"	不能，系统硬性作废	30 天窗口是硬限制
"为什么要打码才能提"	所有彩金都有流水要求，行业通用反套利	查具体倍数
"红包金额变少了"	系统派发红包是随机金额，有可能多有可能少，属正常现象	向用户解释随机机制
"充值了为啥没红包资格"	次日 00:00 才刷新	确认充值时间点
"已达闯关目标没奖励"	确认有效投注额	不是所有投注都 100% 计入

📘 来源：06-VIP奖励活动配置 + 07-投注闯关活动详解 + 08-红包雨活动功能

VIP 奖励关键时间节点： - 周奖励：每周一 04:00 印尼时间结算，7 天内领取，逾期作废 - 月奖励：每月 1 日 04:00 印尼时间结算，30 天内领取，逾期作废

六、协作与通讯规范¶

6.1 群组矩阵¶

  ┌──────────────┐       ┌──────────────┐       ┌──────────────┐
  │   值班群     │ ←──→  │   客服群     │ ←──→  │  用户（App）  │
  │ （内部协作）  │       │              │       │              │
  └──────┬───────┘       └──────────────┘       └──────────────┘
         │
         ▼
  ┌──────────────┐
  │   财务群     │  ← 加扣款必报备
  └──────────────┘
         │
         ▼
  ┌──────────────┐
  │   推广群     │  ← 营销素材、活动通知
  └──────────────┘

📝 来源：学习讨论

6.2 通知矩阵¶

场景	通知客服群	通知财务群	群内公示
权限开关（无资金）	—	—	✅ 认领 + 完成
权限开关（含加扣款）	—	✅ 含金额和用户	✅
提现驳回（银行维护）	✅	—	—
提现驳回（账户无效）	✅ 含驳回原因	—	—
提现驳回（代理套利嫌疑）	✅ 话术"风控人工复核"（不暴露反套利细节）	—	✅ 锁定留痕
扣款完成	✅ 回复原发起人	✅ 必报备	—
订单回调	—	—	✅ 登记表格
每班推送完成	—	—	✅ 打卡留痕

📝 来源：学习讨论

6.3 认领话术约定¶

动作	话术	说明
认领	对原消息回复 `OK` 或 ✅ 打勾	一键快速，群内可视化
完成	回复"已处理" + 关键信息	如用户名、金额、操作类型
涉及资金	完成后同步发到财务群报备	加扣款必报备

📝 来源：学习讨论

七、交接班清单¶

7.1 接班时（你是被交接方）¶

[ ] 翻看上一班的值班表格，了解当班处理过哪些订单/扣款/回调
[ ] 查看群内未认领/未闭环的任务
[ ] 确认当前生效的兑换码是否已设置并配好推送
[ ] 检查 Firebase 定时任务是否已配置到下一个时间点
[ ] 检查自己闹钟提醒是否设好（推送时间前 1h）

7.2 交班时（你是交班方）¶

[ ] 在值班表格补齐所有当班的订单 / 回调 / 扣款记录
[ ] 汇总订单回调清单和总额发到群内
[ ] 所有未闭环的事项明确交给下一棒并获得对方确认回复
[ ] 异常情况（如系统故障、未处理完的提现）单独标注
[ ] 未来一班将用到的优惠码是否已经准备好

📝 来源：学习讨论

八、自动化建议¶

8.1 总体思路¶

副组长日常有大量 N 个平台 x M 次/天 的套路化操作，每步都是出错机会。API化/工具化可以：

环节	人工	API/工具
数据格式	手抄，每次风格不同	schema 强制一致
流程一致性	靠人记忆，新人易漏步	代码保证，每次相同
出错可追溯	翻群记录 + 问当事人	审计日志全量记录
精力消耗	枯燥反复 → 疲劳 → 更多错	机器不累

在没有后台 API 支持的前提下，仍有很多地方可以通过本地工具减少重复和人工错误。

8.1.1 实操时间成本分析（副组长第一视角）¶

以下数据来自实际上岗操作，不是估算。

推送通知是全天最大的时间黑洞。13 个平台，Firebase/Jpush 每天 5 个时间点 + 站内信 1 个时间点，每次都是纯机械的复制粘贴 + 点击按钮，零决策含量。

任务	平台数	新人耗时/次	熟手耗时/次	每天频次	每组每天总耗时（熟手）
Firebase 推送	13	~60 分钟	~30 分钟	5 次	2.5 小时
极光推送（5 次）+ 站内信（1 次，合并操作）	13	~50 分钟	~30–40 分钟	极光 5 次 / 站内信 1 次	~2–2.5 小时
兑换码创建（换码时一次性）	13	~30 分钟	~15–20 分钟	1 次	~15–20 分钟
推送相关合计					~5–6 小时/天

📝 来源：学习讨论

关键洞察：一个 12 小时白班，仅推送相关的机械操作就占了 40–50% 的时间。副组长在这些任务上的角色本质是人肉复制粘贴机，不是决策者。

自动化前后对比：

任务	现状（人工）	自动化后	副组长角色转变
Firebase 推送	每次 30 分钟 × 5 = 2.5h	✅ 已开发 Tampermonkey 自动化脚本，大幅减少复制粘贴	设文案 + 查看送达结果
极光推送	每次操作 13 个平台	✅ 已开发 Tampermonkey 自动化脚本，大幅减少复制粘贴	检查送达效果
站内信	19:00 手动发（1 次/天）	后台升级一键勾选定时发送 ~2 分钟/天	检查送达效果
兑换码	手动创建 15–20 分钟	后台自动定时生成 + 与推送联动 ~0 分钟	根据前日领取/触达数据调整参数
总计	~5–6 小时/天	~15–20 分钟/天	从执行者 → 监控者 + 分析者

📝 来源：学习讨论

为什么兑换码不需要人工：兑换码是随机生成的 4 位码，人类在"生成随机数"这件事上不比代码更可靠——恰恰相反，人工操作复制粘贴更容易出错（粘贴到错误平台、码打错、忘记更新推送文案中的旧码）。后台完全可以：每天定时自动生成兑换码 → 自动联动极光推送和站内信 → 人工只需根据每个网站前一天的领取和触达数据去调整兑换数量和金额。

释放出来的时间应该投入到： - 代收代付渠道成功率监控——这需要人脑判断渠道健康度、识别异常趋势 - 提现审核深度排查——代理反套利的下级行为模式分析需要经验和判断力 - 财务异常订单分析——人工失误的识别需要交叉比对两个系统 - 数据分析和运营优化——分析推送效果、调整策略，比执行推送更有价值

一句话总结：把人从"做机器该做的事"中解放出来，去做"只有人能做的事"。

8.2 工具清单简表¶

#	工具	痛点	是否需要API	优先级	备注
T1	优惠码文案生成器	N平台手动替换文案	否（纯前端/Sheets）	⭐⭐⭐	✅工具已就位
T2	奖励发放数据管道	导出→筛选→算→填模板	否（Python/Node）	⭐⭐⭐	✅工具已就位
T3	短信名单筛选工具	手工筛选手机号	否（Python/Excel宏）	⭐⭐	✅工具已就位
T4	推送节拍提醒器	人肉记时间	否（cron/手机提醒）	⭐⭐	✅工具已就位
T5	代理下级行为模式检测器	自动扫描下级存款/打码分布	需要	⭐⭐
T6	推送文本轮转器	固定文本手选	否（本地工具）	⭐⭐	✅工具已就位
T7	多平台推送自动化	Firebase/Jpush xN站机械复制粘贴	否（Tampermonkey）	⭐⭐⭐⭐	✅ Firebase + 极光 Tampermonkey 脚本已就位
T8	存提差监控告警	逐平台查日报+心算	需要	⭐⭐⭐⭐⭐
T9	20:00联动（巡检+返水）	同一cron完成巡检+返水	需要	⭐⭐⭐⭐⭐	T8+T9合并
T10	提现备注自动判定引擎	8条备注x3种情况x4条硬规则	需要	⭐⭐⭐⭐

实施分层：

  ┌─────────────────────────────────────────────────┐
  │           ✅ 已就位                               │
  │  T1 文案生成  T2 数据管道  T3 名单筛选            │
  │  T4 节拍提醒  T6 文本轮转                         │
  │  T7 Firebase/极光 Tampermonkey 自动化脚本         │
  └───────────────────┬─────────────────────────────┘
                      │
                      ▼
  ┌─────────────────────────────────────────────────┐
  │           需要后台配合（需 API）                   │
  │  T5 行为检测  T8 存提差监控                       │
  │  T9 20:00联动  T10 备注判定                       │
  └─────────────────────────────────────────────────┘

详细技术设计和 API 需求书见：12-自动化路线图/

8.3 各工作流自动化标注汇总¶

章节	自动化机会	对应工具
3.1 推送通知	✅ Tampermonkey 脚本已就位，大幅减少 Firebase/极光复制粘贴	T7
3.2 兑换码	文本轮转器，24h内不重复	T6
3.3 营销短信	固定筛选+固定文案，一键导出	T3
3.3 批量套件（SMS + 彩金）	全链路数据管道，节省时间最多	T2
3.5 存提差+返水	读数→比阈值→发通知，最纯粹的自动化	T8+T9
4.1 提现审核	规则引擎代替人脑记忆	T10
4.1.5 代理套利审核	自动扫描下级存款/打码分布 + 计算套利比例	T5

九、待确认问题清单¶

真正的 open 项。其他原本在此清单的问题已整合进正文对应章节，或直接通过 tools/ 小工具落地。

9.1 提款密码次数限制¶

[ ] 密码重置的失败次数限制？一般用户使用错误的提款密码 10 次进行提款尝试后，会自动触发锁定提款功能。

十、经验积累 & 踩坑¶

预留给日常工作中不断补充。每遇到一个非显然的经验或坑，就记一条。

10.1 踩过的坑¶

日期	场景	错误做法	正确做法	原因
—	—	—	—	—

10.2 提效经验¶

日期	场景	做法	效果
—	—	—	—

10.3 边界判断¶

日期	情况	判断	依据
—	—	—	—

附录 A · 快速参考卡（打印版）¶

  ┌──────────────────────────────────────────┐
  │  推送时间表                                │
  │  ━━━━━━━━━━━━━━━━━━━━                    │
  │  夜班 00:00                                │
  │  白班 11:00 / 15:00 / 19:00 / 21:00      │
  │                                          │
  │  每次推送 = Firebase(自动) + Jpush(手动)   │
  │            + 站内信(手动) + 删旧站内信      │
  │                                          │
  │  站内信必须用代码编辑器粘贴 HTML             │
  │                                          │
  │  提前 1 小时设闹钟！                       │
  └──────────────────────────────────────────┘

  ┌──────────────────────────────────────────┐
  │  提现订单备注速查                            │
  │  ━━━━━━━━━━━━━━━━━━━━                    │
  │  1 代理提款 ......... 走 4.1.5 套利审核流程 │
  │  2 用户层不允许 ..... 走完整账变排查        │
  │  3 自动出款失败 ..... 查订单真实状态+按状态 │
  │  4 超过最大金额 ..... 走完整排查流程         │
  │  5 2分钟4次 ......... 首次查余额→驳回/通过 │
  │  6 首提流水不足 ..... 直接审核通过           │
  │  7 通道金额限制 ..... 跟商户核实→换钱包     │
  │  8 代付失败 ......... 查订单状态+三方确认   │
  └──────────────────────────────────────────┘

  ┌──────────────────────────────────────────┐
  │  提现订单：先锁定！                         │
  │  ━━━━━━━━━━━━━━━━━━━━                    │
  │  代理提现 → 查下级行为模式 → P1/P2 判定      │
  │  普通自动失败 → 查订单状态                   │
  │    · 账户问题 → 按状态处理                  │
  │    · 银行维护 → 驳回+通知客服                │
  │    · 通道限制 → 跟商户核实                   │
  │    · 用户层禁自动 → 完整排查后处理           │
  └──────────────────────────────────────────┘

  ┌──────────────────────────────────────────┐
  │  扣款处理流程                               │
  │  ━━━━━━━━━━━━━━━━━━━━                    │
  │  认领 → 查余额 → 扣款 → 回复客服             │
  │        → 财务群报备（含平台/ID/金额/原因）    │
  └──────────────────────────────────────────┘

附录 B · 相关文档索引¶

行业通用知识（00-10 区段）¶

04-运营体系/03-奖励体系设计 — 奖励金额、流水要求、防滥用策略
04-运营体系/05-客服运营 — 与客服团队协作的完整流程
06-合规法务/02-KYC与AML — 提现审核的合规背景
07-财务支付/02-支付体系与通道 — 提现为何会自动失败的技术背景
10-业务知识库/00-通用管理知识/01-团队管理基础 — 副组长如何开展 1:1 和团队建设
10-业务知识库/00-通用管理知识/02-远程团队协作 — 异步沟通、工具链、时区管理
09-岗位指南与SOP/01-客服线/11-客服管理专员-工作指南 §十二 — 后台权限隔离设计（远程客服 vs 现场管理岗，理解副组长在密码重置/提现审核中的把关定位）

非凡包网平台手册（11-平台手册/非凡包网/）¶

完整索引：11-平台手册/非凡包网/README.md

#	文档	对应本指南章节
01	自动出款功能详解	4.1.2
02	防恶意注册风控机制	4.1.5
03	有效打码计算方式	4.5
04	禁止投注问题排查	4.6
05	充值订单收回款项	4.2
06	VIP 奖励活动配置	5.3
07	投注闯关活动详解	5.3
08	红包雨活动功能	5.3

自动化路线图（12-自动化路线图/）¶

README — 区段总览
01-代理提现审核API需求书 — P1 最优先 API

附录 C · 副组长工具箱使用指南¶

工具地址：https://igaming-t1.pages.dev/ 访问密码：igaming2026 技术栈：Cloudflare Pages + 纯前端（零数据外泄） 管理员密码：需联系 Bob 获取（用于编辑平台配置）

核心原则¶

数据零外泄：CSV / 手机号 / 金额全部在浏览器本地处理，页面刷新即清除
配置云同步：公式档位、平台信息等业务规则通过 CF KV 同步，一人改全员生效
零安装：浏览器打开即用，不需要安装任何软件（FCM 脚本除外）

C.1 工具总览¶

工具箱包含 14 个功能 Tab，覆盖副组长白班和夜班的全部重复性操作：

Tab 名称	图标	对应工作流	简述
兑换码	🎲	§4.1 兑换码管理	每日生成 4 位兑换码，30 天不重复，云端同步
兑换码站内信	✉️	§4.1 站内信推送	按平台 × 日期生成站内信 HTML（兑换码 + 存款推广）
SMS 回访	📱	§4.2 短信回访	3 种方向文案一键复制，含 Leet Speak 反检测
推送文案	🔔	§4.1 推送	Firebase/Jpush 推送文案（带码 + 通用活动 12 条）
新人首充	🎁	会员咨询	输入充值额实时算奖金/打码要求，一键生成印尼语话术
回访彩金助手	🗄️	§4.3 彩金发放	上传 3 份 CSV → 自动套公式 → 产出 XLSX + TXT
周拉回	🔄	§4.2 周拉回	周五准备周六发放，0.88 彩金 + 手机号 TXT
每日返水	🪙	§4.13 存提差巡检	20:00 存提差 >10% 的平台，充值额 × 2% 返水
交班汇报	📋	§4.7 值班交接	快速录入订单号，一键生成交班报告 + 云端归档
SMS 测试	🧪	SMS API 验证	单条/批量发送测试，含发送日志和状态查询
SMS 监控	📡	SMS 运维	今日发送汇总、失败 TOP、Cron 轮询状态、自动补齐
客损拉回	📊	效果追踪	次日上传回访 CSV 计算拉回率，7天/30天趋势
FCM	🔥	§4.1 推送排程	准备次日 Firebase 推送 Campaign，配合 Tampermonkey 自动填

辅助功能（右上角）：

功能	说明
WIB 时钟	实时显示印尼时间（UTC+7），附下一任务倒计时
组别切换	选择当前操作的平台组（A/B/...），只显示该组平台
语言切换	中文 / English / Indonesia 三语
管理按钮	输入管理员密码后可编辑平台配置
云同步	点击手动拉取云端最新配置

C.2 各 Tab 使用说明¶

C.2.1 兑换码管理¶

功能：为所有平台生成当日/明日 4 位数字兑换码。

核心规则： - 4 位数字，印尼友好（避免重复数字 / 顺序数字） - 同平台 30 天不重复 - 当天全平台不重复 - 可勾选"优先双连数字"（如 5588），不够时用三连（如 1888）

操作步骤： 1. 点击 「生成今日全部」 → 所有平台自动生成今日码 2. 点击 「生成明日全部」 → 预生成明日码（给美工提前作图） 3. 点击 「复制今日」 → 所有平台码复制到剪贴板 4. 点击 「复制明日（给美工）」 → 明日码复制给美工制图 5. 如需修改单个平台码：点平台卡片上的 「修改」 按钮，输入后台已设置的新码

注意事项： - 生成后有时间锁，同一天不能反复重新生成（接班时段 22:00 WIB 后解锁） - 重新生成会覆盖旧码，影响美工图片、后台配置、已发文案 —— 谨慎操作 - 码生成后云端同步，其他同事刷新页面即可看到

C.2.2 兑换码站内信¶

功能：为每个平台生成两条站内信内容（兑换码通知 + 存款推广），可直接复制粘贴到后台。

操作步骤： 1. 选择模式：「单平台」 或 「批量全部」 2. 单平台模式：选择平台 → 点「生成」 3. 批量模式：点「一键生成全部」→ 所有平台的站内信一次性生成 4. 每个平台会生成两张卡片： - 站内信 ① · 兑换码：包含平台名、兑换码、社交链接，15 套文案按日期自动轮转 - 站内信 ② · 存款推广：带颜色 HTML 模板（红色标题 + 黑色加粗正文） 5. 点 「复制（带格式）」 → 粘贴到后台富文本编辑器自动带颜色/加粗/链接 6. 点 「源码」 → 复制原始 HTML，需在后台切换"代码模式"粘贴

注意事项： - 兑换码来自「兑换码」Tab 已生成的码，如需更换先去那边改 - 15 套文案按日期 1-15 / 16-30 双周期轮转，每天自动切换 - 如果某平台缺少原始文案模板，会显示 fallback 警告

C.2.3 SMS 回访¶

功能：按回访方向生成各平台的 SMS 文案，含批量发送池。

3 种回访方向：

方向	目标用户	对应文案	主推内容
A · 未充值	注册但未充值	smsText1	首充 100% + 88K 兑换码 + 99K 红包雨 + 转盘 1000K
B · 有充值	有充值记录（客损/昨存/前存共用）	smsText2	30X 幸运彩金 + VIP 100,000K + 任务 9,999K
ZLH · 周拉回	30天内注册+10天未登+充值>=2次	smsTextZlh	每周五准备周六发，独立文案

操作步骤： 1. 选择回访方向（A / B / ZLH） 2. 页面自动展示所有平台对应文案 + 手机模拟预览 3. 点击每个平台卡片的复制按钮获取文案 4. 批量发送池（下方紫色区域）： - 选择数据日期 → 显示当日待发送列表 - 勾选要发送的项目 - 配置测试号码（验证送达） - 点「一键发送已勾选」

SMS 文案自动匹配规则（批量发送池）： - sms 来源 → 未充值文案 A - kslh / czlh / lh 来源 → 有充值文案 B - zlh 来源 → 周拉回文案

注意事项： - 文案已内置 Leet Speak 反检测写法（如 k0de、cuma2、ga..c0r），不要"修正"它们 - 发送前先到「SMS 测试」Tab 验证 API 连通性 - 手动导入 TXT 功能在折叠面板里，用于补发/修正入库

C.2.4 推送文案¶

功能：为 Firebase（Android/PWA）和 Jpush（iOS）生成推送文案。

两种模式：

模式 1 · 带兑换码推送（按平台 × 日期）： 1. 选择批次（每天 5 批，每批随机分配不同文案变体） 2. 每个平台显示 Firebase 和 Jpush 两种文案 3. 同平台跨批不重复，同批跨平台不重复 4. 点复制按钮分别获取标题 / Firebase / Jpush 文案

模式 2 · 通用活动文案（12 条，无兑换码）： - VIP 永久工资、返水 Rebate 3%、代理计划 5%、日救济金 25% - 兑换码通用、签到 128K、邀请好友 25K、充值奖励 2500K - 周 Cashback 30%、推荐好友 1000K、下载 APP 5000K、累计充值 2500K

操作步骤： 1. 切换到「推送文案」子 Tab → 选批次 2. 每个平台卡片上点「标题」「Firebase」「Jpush」分别复制 3. 高级：可手动指定文案变体（展开折叠面板）

C.2.5 新人首充奖金计算器¶

功能：会员咨询时快速查询充值对应的奖金、打码要求。

9 档规则：

档位	最低充值(K)	奖金%	打码倍数
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

操作步骤： 1. 输入充值金额（单位 K，1K = 1,000 IDR） 2. 实时显示：匹配档位、奖金金额、可玩本金、打码要求 3. 点「复制印尼语话术」→ 直接发给会员

打码公式：TO 要求 = (充值 + 奖金) x 打码倍数

C.2.6 回访彩金助手（白班核心工具）¶

功能：上传 3 份后台导出 CSV，自动筛选 / 套公式 / 去重，产出宝箱 XLSX + 手机号 TXT。

操作步骤： 1. Step 1：选择平台 2. Step 2：上传 3 份 CSV： - ① 导出 A · 用户回访（T-1 注册） - ② 导出 B · 用户统计（T-1 会员） - ③ 导出 C · 用户统计（T-2 会员） 3. Step 3（可选）：展开查看/修改公式与档位配置 4. Step 4：点「一键处理」 5. Step 5：下载产出文件

公式说明（详见 C.3 配置修改指南）： - 输入字段：profit_loss（存提差），不是 deposit - 输家（存提差 < 0）：固定彩金 0.38 - 赢家：按存提差匹配 9 档阶梯，最高 777.77 - 产出的 XLSX 列：会员ID / 宝箱奖励金额 / 打码倍数(默认1) / 充值翻倍(默认"开启")

隐私策略： - 敏感数据（CSV 含会员 ID / 手机号）→ 浏览器端解析，只在内存，刷新即清 - 公式配置 → CF KV 云同步，业务规则非敏感

C.2.7 周拉回¶

功能：每周五准备、周六发放的拉回任务。

筛选条件（分工）： - 后台已筛（导出前）：① 注册时间 30 天内 ② 最后在线 > 10 天 - 工具自动筛（上传后）：③ 充值次数 >= 2（防套利防刷子）

操作步骤： 1. 设置基准日期（默认今天）、选择平台 2. 设置赠送金额（默认 0.88） 3. 上传后台已按条件筛好的用户回访 CSV（支持多选分片文件） 4. 点「一键处理」→ 产出彩金 XLSX + 手机号 TXT 5. 辅助：展开「日期计算器」可查看 30 天筛选时间戳

C.2.8 每日返水¶

功能：20:00 WIB 存提差巡检，对存提差 > 10% 的平台执行返水发放。

公式：彩金 = 充值额 x 0.02（默认 2%）

操作步骤： 1. 选择平台 2. 确认返水比例（默认 0.02） 3. 上传当日该平台的用户统计 CSV 4. 点「一键处理」 5. 工具自动：筛充值额 > 0 → 计算彩金 → 剔除为 0 的行 → 产出宝箱 XLSX

注意事项： - 前置条件：仅对后台日报表存提差 > 10% 的平台执行，工具本身不判断 - 不与 §4.3 回访彩金去重，独立发放

C.2.9 交班汇报¶

功能：快速录入值班期间处理的订单，一键生成交班报告并归档。

操作步骤： 1. 填写交班人姓名（自动保存） 2. 选择平台 → 输入订单号 → Enter 快速添加（1 单 = 10K） 3. 批量模式：展开折叠面板 → 粘贴多行订单号 4. 点 「交班汇报」 → 自动复制报告 + 云端归档 + 清空当前列表 5. 点「历史归档」可查询历史交班记录

C.2.10 SMS 测试¶

功能：验证 SMS API 连通性，先测单条再批量。

三个区域： 1. 单条测试：输入手机号 + 短信内容 → 发送测试 → 查看结果 2. TXT 批量发送：上传号码文件 + 自定义文案 → 批量发送（适用于补发/手动发送） 3. 发送状态查询：输入 sendCode 查询送达状态 4. 发送日志：最近 20 条发送记录，含完整号码清单和逐号状态

C.2.11 SMS 监控¶

功能：今日 SMS 发送全量汇总和实时监控。

主要功能： - 今日总览（发送量 / 成功率 / 费用） - 测试号专区（验证自己手机是否收到） - 按平台分解统计 - 失败 TOP 排行（排除非 TK 号段） - Cron 轮询状态（持久化队列，每分钟自动消费补齐状态） - 一键补齐全部状态 / 手动刷新

C.2.12 客损拉回¶

功能：追踪彩金助手处理后的拉回效果。

操作步骤： 1. 选择日期（客损发生日） 2. 三个视图：当日详情 / 7 天趋势 / 30 天统计 3. 点「一键复制汇报」→ 生成给组长的拉回效果报告

数据来源：彩金助手处理时自动归档客损数据到云端。

C.2.13 FCM Console 助手¶

功能：在工具箱内准备次日 Firebase 推送 Campaign 数据，配合 Tampermonkey 脚本在 Firebase Console 自动填写。

操作步骤： 1. 设置目标日期（默认自动：22:30 WIB 后自动切到明天） 2. 页面展示所有待创建的 Campaign（5 个时间点 × N 个平台） 3. 点「下载 Tampermonkey 脚本」安装自动化脚本（详见 C.4） 4. 到 Firebase Console 操作（详见 C.4）

C.3 配置修改指南¶

重要：所有配置修改需要管理员权限。点击右上角「管理」按钮 → 输入管理员密码 → 解锁。

C.3.1 平台列表管理¶

位置：tools/t1-promo-copy/public/js/data.js → DEFAULT_PLATFORMS 数组

当前配置了 14 个平台（7777W, RP66, RPRR, RP55, YYRR, SL888, 888R, SL999, 99SL, RP99, 9SL, RK55, VC55, FW66）。

每个平台的可配置字段：

字段	含义	示例
`id`	平台唯一标识	`'7777W'`
`code`	默认兑换码（通常留空，由工具自动生成）	`''`
`social.type`	社交平台类型	`'Telegram'` 或 `'Facebook'`
`social.color`	品牌色（hex）	`'#FF00FF'`
`social.url`	社交链接 URL	`'https://t.me/vip_7777w'`
`social.label`	链接显示文字	`'Link Channel Telegram : ...'`
`domain`	平台域名（用于 SMS 文案）	`'dge753.com'`
`userCount`	证明人数（用于社会证明文案）	`18599`
`maxReward`	最高奖励额度	`'88K'` 或 `'99K'`
`pushImage`	推送图标路径	`'/api/icon/7777W'`
`backendUrl`	后台地址	`'https://demo.indback789.com/'`
`letterHtml`	站内信 HTML 模板	含 `{KODE}` 占位符
`group`	所属组别	`'A'`
`smsText1`	未充值方向 SMS 文案	Leet Speak 格式
`smsText2`	有充值方向 SMS 文案	Leet Speak 格式
`smsTextZlh`	周拉回 SMS 文案	留空表示未配置
`textColor`	文字颜色（特殊平台如 9SL 用黑色）	`'black'`

在线修改方式（推荐）： 1. 点击「管理」→ 输入密码解锁 2. 在管理面板中直接编辑各平台字段 3. 点「保存所有修改」→ 自动同步到云端 4. 其他同事刷新页面即可看到更新

代码修改方式（新增平台）： 1. 编辑 tools/t1-promo-copy/public/js/data.js 2. 在 DEFAULT_PLATFORMS 数组末尾添加新平台对象 3. 部署：cd tools/t1-promo-copy && npm run deploy

C.3.2 兑换码文案模板¶

位置：data.js → KODE_VARIANTS 数组（15 条）

15 套文案按 day 字段（1-15）映射到每月日期，16-30 日循环使用 1-15。

每条文案的可配置字段：

字段	含义
`day`	日期编号（1-15）
`styleKey`	样式键名（如 `var_urgent`）
`title`	推送标题模板（含 `{KODE}` 占位符）
`alt_title`	特定平台的替代标题
`alt_for`	使用替代标题的平台列表
`body`	正文模板（含 `{KODE}`, `{SOCIAL_PLATFORM}`, `{SOCIAL_LINK}`, `{USER_COUNT}`, `{MAX_REWARD}` 占位符）

修改文案：编辑 data.js 中对应 day 的对象，保留占位符格式。

C.3.3 存款推广模板¶

位置：data.js → DEPOSIT_PROMO_TEMPLATE 常量

这是站内信第二条的 HTML 模板，带颜色样式。修改时保留 {MAX_REWARD} 占位符和 HTML 样式标签。

C.3.4 SMS 回访方向配置¶

位置：data.js → SMS_DIRECTIONS 数组（3 条）

方向 ID	说明	对应文案字段
`A`	未充值文案	`smsText1`
`B`	有充值文案	`smsText2`
`ZLH`	周拉回文案	`smsTextZlh`

修改方向描述或对应字段：编辑 SMS_DIRECTIONS 数组。修改某平台的 SMS 文案内容：编辑该平台对象的 smsText1 / smsText2 / smsTextZlh。

C.3.5 推送活动文案配置¶

位置：data.js → PUSH_ACTIVITIES 数组（12 条）

每条活动含：

字段	含义
`id`	活动标识（如 `vip_salary`）
`label`	中文标签
`title`	推送标题
`firebase`	Firebase 推送文案（Android/PWA）
`jpush`	Jpush 推送文案（iOS，含 emoji）

修改活动文案：编辑 PUSH_ACTIVITIES 数组中对应活动的 firebase 和 jpush 字段。

C.3.6 回访彩金公式配置¶

位置：tools/data/t2-reward/formula-config.v3.json

核心参数：

参数路径	当前值	含义
`profiles.default.inputField`	`profit_loss`	输入字段 = 存提差（不是充值额）
`profiles.default.loserBonus`	`0.38`	输家固定彩金
`profiles.default.loserCondition`	`profit_loss < 0`	输家判定条件
`profiles.default.doubling`	`true`	是否启用可翻倍档位

赢家 9 档阶梯（可翻倍档）：

档位	存提差门槛	彩金
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

修改彩金公式： 1. 编辑 tools/data/t2-reward/formula-config.v3.json 2. 修改 tiersDoubling 数组中的 threshold（门槛）或 payout（彩金） 3. 如需修改输家彩金，改 loserBonus 值

产出 XLSX 模板配置：

参数路径	含义
`rewardTemplate.defaults.wagerMultiplier`	打码倍数，默认 1
`rewardTemplate.defaults.rechargeDoubling`	充值翻倍，默认 "开启"
`rewardTemplate.filterBonusZero`	是否过滤彩金为 0 的行，默认 true
`rewardTemplate.platformOverrides`	特定平台覆盖配置（预留）

C.3.7 SMS 固定彩金配置¶

位置：tools/data/t3-sms/sms-bonus-config.v1.json

平台	固定彩金	备注
7777W	0.2	已确认
RP66	0.2	已确认
RP55	0.2	已确认
YYRR	0.1	原始文档有歧义，暂定 0.1
其他平台	null	待确认，默认走 0.1

C.3.8 新人首充档位配置¶

位置：index.html 内 BONUS_TIERS 常量（第 3115 行附近）

修改档位规则：编辑 BONUS_TIERS 数组中各对象的 min（最低充值）、pct（奖金百分比）、to（打码倍数）。

C.3.9 部署生效¶

所有代码文件修改后，需要部署才能让全团队看到更新：

cd tools/t1-promo-copy
npm run deploy

部署使用 Cloudflare Wrangler，配置在 wrangler.toml： - 项目名：igaming-t1 - 输出目录：public/ - KV 绑定：T1_DATA（多端共享数据存储）

在线修改（通过管理面板修改平台信息）不需要部署，直接保存即同步到 KV。

C.4 Firebase 推送自动化脚本¶

C.4.1 概述¶

3F Firebase Console Helper 是一个 Tampermonkey 用户脚本（当前版本 v5.7.11），安装后自动在以下页面注入辅助浮层：

Firebase Console（console.firebase.google.com）：推送 Campaign 自动填写
平台后台（*.indback789.com / *.indback666.com）：极光推送辅助 + 代理审核

C.4.2 安装步骤（Chrome + Tampermonkey 完整教程）¶

第一步：安装 Tampermonkey 插件

打开 Chrome，访问 Chrome 网上应用店
搜索 Tampermonkey（油猴/篡改猴）
点击 "添加至 Chrome" → 确认安装
右上角出现 🐒 图标即安装成功

国内网络访问不了应用店的，可搜索"油猴插件离线安装 .crx"

第二步：开启 Chrome 开发者模式

地址栏输入 chrome://extensions/ 回车
页面右上角 "开发者模式" 开关 → 打开（蓝色）

第三步：允许 Tampermonkey 使用用户脚本

在扩展程序页找到 Tampermonkey → 点 "详细信息"
找到 "允许用户脚本" → 打开

⚠️ 此步不做脚本无法注入页面！

第四步：设置 Site Access 权限

在 Tampermonkey 详细信息页面
找到 Site access → 改为 「On all sites」

⚠️ 这一步也必须做，否则脚本不会在目标页面自动运行

第五步：安装 3F 脚本

用 Chrome 打开以下链接，Tampermonkey 会自动弹出安装确认页，点安装即可：

https://igaming-t1.pages.dev/3f-fcm-console-helper.user.js

也可以在工具箱「FCM」Tab 点「下载 Tampermonkey 脚本」。

脚本自动更新：@updateURL 和 @downloadURL 已配置为工具箱地址，后续更新会自动推送。

C.4.3 Firebase Console 使用流程¶

脚本在 Firebase Console 页面右上角显示一个 红色/绿色徽章（可拖动），页面右侧显示 操作浮层。

推荐操作流程： 1. 在 Firebase Console 里 Duplicate 昨天的 Campaign（继承 Target + 图片） 2. 进入 edit 页面 3. 在右侧浮层中找到对应批次 → 点 「🔥 填入」 按钮 4. 脚本自动填写标题、正文等字段 5. 手动修改日期（定时发送到目标日期） 6. 点 Publish → 回浮层点 「✅ 已发」

日期模式（浮层顶部三个按钮）： - ⏱ 自动：22:30 WIB 后自动切到明天 - 📅 今天：强制使用今天数据 - ➡️ 明天：强制使用明天数据

C.4.4 平台后台功能¶

在平台后台页面，脚本自动识别当前是哪个平台（通过 hostname 映射），提供： - 极光推送页面：辅助填写推送内容 - 代理审核页面：IP 碰撞检测辅助（默认关闭，需手动启用）

启用代理审核功能（F12 Console 执行）：

localStorage.setItem('fcm_3f_agent_enabled', '1'); location.reload();

关闭：

localStorage.removeItem('fcm_3f_agent_enabled'); location.reload();

C.4.5 注意事项¶

徽章和浮层均可拖动，位置自动保存
如果看不到徽章/浮层，检查 Tampermonkey 的 Site access 设置
脚本使用 DOM 锁防止重复注入
支持 SPA 页面导航（interval 定时检测环境变化）

C.5 常见问题¶

Q1: 打开工具箱后是空白页面？¶

检查网络是否能访问 Cloudflare（部分地区可能需要代理）
清除浏览器缓存后重试
确认访问地址是 https://igaming-t1.pages.dev/

Q2: 兑换码生成按钮灰色不可点？¶

当天已生成过兑换码，有时间锁
等待印尼时间 22:00（接班时段）后解锁
或使用「修改」按钮手动输入后台已设的码

Q3: 上传 CSV 后提示格式错误？¶

确认是从后台「导出」功能下载的原始 CSV
CSV 文件名应以平台名开头（如 SL888-用户统计xxx.csv）
确认 CSV 编码是 UTF-8
如果是分片导出的多个文件，周拉回 Tab 支持多选

Q4: 站内信复制后粘贴到后台没有颜色？¶

使用「复制（带格式）」按钮（不是「源码」按钮）
确保后台编辑器处于富文本模式（不是代码模式）
如果仍然无效，用「源码」按钮 → 后台切换到代码模式 → 粘贴

Q5: SMS 发送余额为 0？¶

联系 Bob 充值 AboSend 账户
在「SMS 测试」Tab 查看余额卡片了解当前余额

Q6: Tampermonkey 脚本安装后看不到徽章？¶

确认 Tampermonkey 的 Site access 设为 「On all sites」
在目标页面按 F12 打开控制台，搜索 [3F-Helper] 日志
如有 重复注入检测 · 跳过 说明脚本被双重加载，刷新页面即可
检查页面是否是 Firebase Console 或平台后台（脚本只在这两类页面工作）

Q7: 修改了 data.js 但团队看不到更新？¶

代码文件修改后需要部署：cd tools/t1-promo-copy && npm run deploy
通过管理面板在线修改平台信息则不需要部署，保存即同步

Q8: 数据助手处理结果和后台数据对不上？¶

确认使用正确的 CSV 类型（用户回访 vs 用户统计）
确认公式配置中的档位和彩金值与最新业务规则一致
输入字段是 profit_loss（存提差），不是 deposit（充值额）
如有疑问，在 Step 3 展开公式配置面板检查当前参数

Q9: 多个同事同时操作会冲突吗？¶

兑换码：云端同步，以最后保存为准。建议一个组指定一人生成码
配置修改：同理，最后保存的覆盖之前的
CSV 处理：纯本地运算，不会冲突
交班汇报：按交班人姓名归档，不冲突

Q10: 如何备份/恢复数据？¶

管理面板中有「导出 v3 备份」按钮，下载 JSON 备份
「迁移 v3 → v4」用于版本升级时的数据迁移
「LS 用量诊断」可查看 localStorage 占用分布