菲律宾 · 副组长（运营值班岗）SOP¶
文档信息
作者：Bob | 日期：2026-07-24 | 状态：可上岗版 v1 适用对象：菲律宾站运营副组长（当班值班执行主管） 地基（唯一真相源）：组织架构、职责边界、阈值、升级链、工具栈、术语一律以 00-菲律宾运营岗位-地基与术语表 为准；本文只写「副组长自己怎么干、为什么这么干」。
目录¶
一、岗位定位与一句话职责¶
一句话（引用地基 §1）
副组长 = 当班执行主管 —— 定点任务（推送 / SMS 拉回 / 彩金 / 巡检）、督导当班一线、异常排查上报。
副组长本质是 「营销执行 + 风控二审 + 协作调度」 三合一角色：
flowchart TD
DL["运营副组长 · 当班值班主管"]
DL --> M["营销执行 约45%<br/>产出层<br/>推送 / SMS 拉回 / 彩金发放"]
DL --> R["风控二审 约30%<br/>决策层<br/>提款二次审核 / 大额出款 / 套利大额扣款决策"]
DL --> C["协作调度 约25%<br/>流程层<br/>三方巡检 / 异常排查 / 交接留痕"]- 产出层：每日 4 类短信拉回、推送触达 —— 直接触达和激励用户。
- 决策层：提款二次审核、大额（> ₱5,000）出款、稽核发现后的套利大额扣款决策、需审核的密码/账号变更。
- 流程层：三方渠道巡检、运营/注册数据异常排查上报组长、跨团队协调并全程留痕。
岗位命门：为什么副组长这个岗最怕出错
决策层的每一笔都是真金白银 —— 大额出款判断失误 = 直接资损，放过套利 = 平台净亏损被会员薅走。所以副组长所有涉钱动作都必须「先认领、再核实、后留痕」，这不是流程繁琐，是给你自己留证据、给平台守住钱。
副组长不是谁（边界，详见地基 §3）：
| 不是 | 原因 |
|---|---|
| 活动策划者 | 活动策划与终审归组长；副组长只做配置执行 |
| 提款初审员 | 常规提款初审归稽核；副组长是稽核之上的二次审核（稽核拿不准时拍板）+ 出款抽查，不做逐单初审 |
| 一线客服 | 用户咨询走远程客服；副组长只处理客服/稽核转过来的需审核事项 |
二、汇报关系与职责边界¶
汇报关系（引用地基 §1）：副组长向当班运营组长汇报；督导现场稽核（值班派活）与远程稽核（值班督导）。
flowchart TD
Mgr["经理 L2"] --> OL["运营组长 · 日/夜班各一"]
OL --> DL["副组长 · 运营值班岗"]
OL --> CSM["远程客服管理"]
OL --> AUM["远程稽核管理"]
DL -->|值班督导/派活| FA["现场稽核 ×4"]
DL -->|值班督导| RA["远程稽核 · 一线"]
CSM --> ASST["远程助理"]
AUM -.制定标准/质检.-> RA职责边界速记（完整总表见地基 §3「五岗职责归属总表」）：
| 关键职能 | 副组长角色 |
|---|---|
| 当班值班执行（推送/SMS 拉回/彩金/存提差巡检） | 主办 |
| 三方渠道成功率 + 卡单实时巡查处理 | 主办（现场稽核协助） |
| 运营数据异常（存提差/RTP）+ 注册数据异常（突降/暴增）排查 → 反馈组长 | 主办 |
| 客损/存提差/次日宝箱/注册未充 —— 每日 4 类短信拉回 | 主办 |
| 套利扣款 | 大额时决策扣款（常规现场稽核直接扣、稽核发现、远程稽核管理定标准） |
| 三方资金异常补款（冲正退回 / 重复支付） | 主办（核实后现金直充补会员 + 通知客服 + Signal 报备） |
| 会员密码重置 / 换提款账号（需审核的） | 审核执行（常规走机器人+客服自助） |
| 提款订单初审 | 稽核线主办；稽核不确认时副组长二次审核拍板 |
| 稽核出款质量抽查 | 主办（反向把关出款有没有问题） |
| 出款执行 | 现场稽核常规；大额 > ₱5,000 可副组长出款 |
| 活动策划 · 终审 | 组长主办，副组长配置执行 |
铁律边界（地基）
远程客服只做订单咨询、不碰提款处理。 提款初审归稽核线；副组长是稽核之上的二次审核层 —— 稽核不确认/拿不准的订单由副组长二次审核拍板，并抽查稽核已出款订单质量。副组长在提款链条里的角色：二次审核拍板、出款抽查、大额出款、套利大额扣款决策。
三、班次与值班时间轴¶
班次（现场团队在贝尔格莱德办公 · 地基 §2）：
| 班次 | 贝尔格莱德（办公地） | 东八区（平台/马尼拉） | 谁 |
|---|---|---|---|
| 日班 | 10:00–22:00 | 16:00–次日 04:00 | 运营组长 A + 一套值班班子（含副组长、现场稽核） |
| 夜班 | 22:00–次日 10:00 | 04:00–16:00 | 运营组长 B + 一套值班班子（含副组长、现场稽核） |
按贝尔格莱德时间暂时这样分配
组长 / 副组长 / 现场稽核在贝尔格莱德现场办公，按上表作息。东八区 = 贝尔格莱德 +6（夏令时 CEST；冬令时 CET 为 +7，届时整体挪 1 小时）。玩家主峰 22:00–02:00 PHT 正好落在日班（东八区 16–04）内 —— 日班盯主峰、夜班守低谷。时段暂定，可按需调整。
时间轴用东八区（平台）时间，贝尔格莱德减 6
下面时间轴与 §五 清单的钟点都是东八区（菲 PHT）平台运营节拍——平台何时忙不随办公地变。换成贝尔格莱德挂钟 = 减 6 小时（东八区 22:00 主峰 = 贝 16:00）。三个推送点 12:00 / 19:00 / 00:00（东八区）不变，只是按新班次窗口归班：12:00 归夜班，19:00 与 00:00 归日班。
3.1 日班时间轴（东八区 16:00–次日 04:00 · 贝尔格莱德 10:00–22:00）¶
gantt
title 日班值班时间轴（东八区 16:00–次日 04:00）
dateFormat YYYY-MM-DD HH:mm
axisFormat %H:%M
section 接班（贝10:00起）
交接班+查群留意事项 :a1, 2026-07-28 16:00, 10m
查打卡/Smartly/云桌面 :a2, 2026-07-28 16:10, 10m
三方渠道+后台通道+余额检查 :a3, 2026-07-28 16:20, 10m
section 傍晚推送
第二轮拉回+自媒体+站内推送 :b1, 2026-07-28 19:00, 30m
存提差巡检+条件返水 :b2, 2026-07-28 20:00, 40m
section 主峰守护 22-02
远程稽核云桌面检查 :c1, 2026-07-28 22:00, 15m
自媒体推送 :c2, 2026-07-29 00:00, 15m
高峰期最优充值渠道守护 :c3, 2026-07-29 00:15, 105m
section 收尾（贝22:00前）
处理前一日客损拉回 :d1, 2026-07-29 02:00, 60m
下班前收尾+积压审核+移交 :d2, 2026-07-29 03:20, 40m贯穿全天（日班）：每小时三方代付余额巡检；每半小时充值成功率巡检；抽查云桌面/Smartly 在线；督导远程/现场稽核；随到随办 B 线（大额出款协助、套利大额扣款决策、需审核事项）。
⏰ 闹钟点（贝尔格莱德时间，照抄进手机）
贝 13:00（东八区 19:00 · 拉回+推送）、贝 14:00（东八区 20:00 · 存提差，提前 10 分预警）、贝 18:00（东八区 00:00 · 推送）、贝 20:00（东八区 02:00 · 客损拉回）、贝 21:20（东八区 03:20 · 收尾）；每小时整点（三方余额）、每半小时（充值成功率）。
3.2 夜班时间轴（东八区 04:00–16:00 · 贝尔格莱德 22:00–次日 10:00）¶
gantt
title 夜班值班时间轴（东八区 04:00–16:00）
dateFormat HH:mm
axisFormat %H:%M
section 接班（贝22:00起）
交接班+查打卡/云桌面/Smartly :a1, 04:00, 20m
三方渠道+后台通道+余额检查 :a2, 04:20, 10m
section 清晨核对
SMS 群核对短信模板/禁词 :b1, 09:30, 20m
section 日间拉回与推送
第一轮短信拉回 :c1, 11:30, 30m
自媒体+站内推送 :c2, 12:00, 15m
推送后检查+埋雷号核对 :c3, 12:15, 15m
section 交班（贝10:00前）
收尾+补齐值班表+未闭环移交 :d1, 15:30, 30m贯穿全天（夜班）：每小时三方余额巡检；每半小时充值成功率巡检；督导云桌面上线情况；随到随办 B 线。
⏰ 闹钟点（贝尔格莱德时间）
贝 03:30（东八区 09:30 · 短信模板核对）、贝 05:30（东八区 11:30 · 第一轮拉回）、贝 06:00（东八区 12:00 · 推送）；每小时整点（三方余额）、每半小时（充值成功率）。
四、核心工作流（重头戏）¶
B 线通用四步框架
认领 → 执行 → 回复 → 报备。 任何会员权限/扣款/回调类动作，先在群里认领（回复 OK 或 ✅）再动手。
为什么先认领
值班群里多人同时在线，同一笔扣款/回调如果两个人都以为对方没做而各做一次，就是双倍扣款/双倍回调 = 直接资损。认领 = 一句话锁定「这单我来」，是防重复的第一道闸。
4.1 每日 4 类短信拉回数据管道¶
目的：把「充了钱却不玩」的用户拉回来投注
客损 = 注册并充值了、但当天没投注的用户。 他们钱已经进来了，就差临门一脚。发条短信提醒（+ 部分给点彩金），把沉默用户激活成投注用户 —— 这是运营侧最直接的产出，投入一条短信钱、换回一个活跃玩家。
要做什么：从澎湃后台拉数据 → 按 4 类分流筛选 → 每路产出手机号清单 → 用 collab 协作台短信拉回工具（走 API / Bluebird 网关）发送 → 次日看投注记录核对效果。常规直接拉数据发；数据量大时先从澎湃导出 Excel、上传协作台工具再发。
菲律宾 4 类（地基 §4.2）：客损、存提差、次日宝箱、注册未充值。4 类都是纯短信拉回（菲律宾暂不做「导入彩金到宝箱」那套）；菲律宾也不做周拉回。
flowchart TD
A["澎湃后台拉数据"] --> K["客损拉回<br/>注册并充值当天未投注"]
A --> C["存提差拉回<br/>输多或赢多后未活跃"]
A --> B["次日宝箱拉回<br/>昨日活跃"]
A --> R["注册未充值提醒<br/>注册未充值"]
K --> TXT["产出手机号清单"]
C --> TXT
B --> TXT
R --> TXT
TXT --> TEST["插测试号+汇总总量+文案禁词预检"]
TEST --> APPR["组长审批渠道报价"]
APPR --> S["协作台短信拉回工具<br/>走 API / Bluebird 发送<br/>大数据量先导Excel上传"]
S --> CHK["核对测试号是否全部收到"]
CHK --> V["次日看投注记录<br/>有投注=已拉回"]逐步操作：
- 拉数据：澎湃后台 → 营销工具 → 用户回访 / 用户统计页 → 按目标日期导出（注册未充值取昨日注册；次日宝箱取昨日活跃；客损取有充值+0 投注；存提差取存提差异常人群）。
- 筛选分流：在导出表内按各类条件筛选（例：注册未充值 = 存款 0 + 投注 0 + 备注空；客损 = 有充值 + 0 投注 + 备注空）。
- 产出手机号清单：复制手机号 → 按统一命名规则存文件（发送日日期 + 类型代号 + 平台名）。文件格式按 Bluebird / collab 拉回工具要求提供。
- 统一发送：每个清单混入几个测试号（埋雷号，不扎堆首尾）→ 汇总总量 → 把文案发 SMS 渠道查禁词（禁词表随运营商变，每次都做）→ 报组长审批 → 用 collab 协作台短信拉回工具走 API（Bluebird 网关）发送；数据量大的清单先从澎湃导出 Excel 上传工具再发。
- 核对效果：核对埋雷号是否全部收到 —— 有未收到立即联系渠道排查；次日看投注记录，有投注即视为拉回成功。
为什么要埋雷号 + 次日看投注
埋雷号有两个作用：
- ① 验丢包：短信发出去你看不到用户端有没有真收到，混几个自己的号进去 —— 收到了 = 通道正常、没收到 = 通道被拦，第一时间发现丢包，不然白花钱还以为发成功了。
- ② 防泄客：持续盯这些号会不会收到别的平台 / 别家公司的广告短信 —— 一旦收到，说明短信渠道很可能把我们的客户名单泄露或转卖给了别家，立即警惕并反馈渠道排查。
次日看投注：拉回的唯一成功标准不是「短信发出去」，而是「用户回来投注了」。只有对着次日投注记录，才知道这批拉回值不值、文案好不好。
短信通道（地基 §4.5）
菲律宾走 Bluebird 网关，通过 collab 协作台短信拉回工具的 API 接口发送（不是印尼那套网关、也不是纯手动）。数据基本直接从澎湃后台拉；只有数据量大时才需从澎湃导出 Excel 上传工具再发。
4.2 推送触达全链路¶
目的：把优惠精准推到用户手机上
推送是「主动触达」—— 用户不一定天天开 App，但推送、社群、站内信能把当天优惠直接怼到他面前。链路每一步（做图、建码、排程）都是为了保证到点那一刻，用户看到的图、文案、兑换码三者对得上、且是当天有效的。错一个环节，用户点进来发现码过期，反而砸招牌。
链路：协作台生成兑换码+金额（TM 一键设置）→ AI 生成图片、重命名发群 → 取兑换码文案工具文案 → 排程 → 到点发送。
flowchart LR
subgraph 准备["阶段一 准备（换新码时做一次）"]
P1["协作台兑换码工具<br/>自动生成码+金额"]
P2["TM 工具一键设置到后台"]
P3["AI 生成兑换码图片<br/>不走 UI 团队"]
P4["图片按平台名重命名+发群"]
P5["文案取自兑换码文案工具<br/>duihuanma.pages.dev"]
P1 --> P2 --> P3 --> P4 --> P5
end
subgraph 排程["阶段二 排程"]
Q1["逐平台配下一个节拍点<br/>复制旧任务改文案/图/时间"]
Q2["复核 平台名-图-文案-码 一致"]
Q1 --> Q2
end
subgraph 执行["阶段三 到点发送"]
E1["澎湃后台客户端通知<br/>底层走 Firebase"]
E2["自媒体/社群推送"]
E3["站内信<br/>发新前删旧"]
end
准备 --> 排程 --> 执行
执行 --> LOG["值班群打卡 已发 HH:MM 推送"]要点：
- 兑换码用协作台工具生成：协作台兑换码工具自动生成兑换码 + 金额，再用 TM 工具一键设置到后台，不用手工建码。
-
兑换码金额（地基 §4.6）：新台子先设 ₱12 固定；满一周后改为 ₱8–10 随机。
随机规则改哪里
要让金额随机，在协作台兑换码工具里改规则，不是在后台一个个改。
-
兑换码图片用 AI 生成：菲律宾这边不走 UI 团队，直接用 AI 生成兑换码营销图，下载后按平台名重命名再发群。
- 文案用兑换码文案工具：兑换码推送文案取自专用工具 https://duihuanma.pages.dev/（菲律宾专用，跟印尼不同）；排程/执行时文案与当前兑换码必须对得上，别用过期码。
- 删旧站内信：每次发新站内信前先删旧，避免堆积。
- 推送渠道：澎湃后台「客户端通知」（本质就是调用 Firebase 推送 —— 副组长只在澎湃后台操作，不用单独管 Firebase、也不做极光推送）+ 自媒体/社群 + 站内信。
- 推送频次：每天 4 次推送触达。 ??? info "待确认：具体节拍点" 每天 4 次的具体整点待补；现有 34 号 SOP 落点参考为 12:00、19:00（站内信在 19:00）。
- 推送优先级（现有 34 号 SOP）：当天有优惠优先推当天优惠；当天没有推其他前台优惠；偶尔穿插赢钱取款截图；第二轮优先发几天没推过的优惠。
高频踩坑（每次都自查）
- 图片张冠李戴 → 配完对照平台名复查一遍。
- 文案里的码没同步 → 以兑换码文案工具（duihuanma.pages.dev）为准。
- 漏配某平台 → 对照平台清单逐一打勾。
4.3 提款审核 / 二次审核 / 出款抽查流¶
副组长是稽核之上的二次审核层
提款初审归稽核线，客服只做咨询、不碰提款处理。副组长的介入点：① 稽核不确认/拿不准的订单 → 副组长二次审核拍板（放行或驳回）；② 抽查稽核已出款订单是否有问题；③ 大额 > ₱5,000 可执行出款；④ 协调客服咨询与稽核审核的流转；⑤ 值班督导审核积压。
目的：为什么要设二次审核 + 出款抽查这道关
- 大额 / 首提风险最高（大额易被套利者盯上、首提可能薅完就跑），稽核要像查代理一样仔细。
- 但稽核也会拿不准、也会看走眼 —— 稽核不确认的订单往上交给副组长二次审核拍板，给稽核兜底；副组长再抽查已出款订单反向监督出款质量。一层初审 + 一层复核 + 一层抽查 = 三重保险，把「错误出款 = 资损」的概率压到最低。
限额与阈值（地基 §4.1）：
- 单笔提款 ₱100–50,000；不收手续费、提多少到多少；不限提款次数/额度。
- 大额提款审核触发：①被改为人工出款的会员；②单笔 > ₱5,000 的会员 → 远程稽核仔细核查（≈代理审核）。
- 首次提款审核：首提无限额；未达打码要求时进首提审核。新台子首提条件宽松、一般不必太严；老台子、或打码量差特别多时才需严查。
sequenceDiagram
participant U as 会员
participant CS as 远程客服 L0
participant RA as 远程稽核 初审
participant DL as 副组长 二次审核
participant FA as 现场稽核 出款
U->>CS: 提款进度咨询
CS->>CS: 仅订单咨询 不碰提款处理
Note over RA: 系统/稽核发起审核
RA->>RA: 初审(常规/大额>5000/首提未达打码 仔细核查)
alt 稽核不确认 / 拿不准
RA->>DL: 上呈二次审核
DL->>DL: 副组长二次审核拍板(放行/驳回)
end
RA->>FA: 审核通过 转出款
FA->>FA: 出款(大额>5000现场忙可副组长协助出款)
DL->>FA: 抽查已出款订单是否有问题
DL->>DL: 值班督导 检查审核积压
Note over DL: 收尾前检查稽核是否有太多积压款项副组长动作清单：
- 二次审核拍板：稽核初审拿不准/不确认的订单 → 上呈副组长，副组长二次审核后拍板放行或驳回（大额、首提、人工出款会员的疑难单尤其如此）。
- 抽查稽核出款：对稽核已出款的订单做抽查，核对金额 / 收款账户 / 审核是否到位 —— 发现问题立即纠正并反馈稽核（这是反向监督出款质量）。
- 大额出款协助：稽核出款群出现大额订单、现场稽核来不及 → 协助出款（大额 > ₱5,000），出款前先在群内认领。
- 值班督导：日班 东八区 22:00 与收尾前（03:20）检查远程稽核审核积压、主峰期（22:00–02:00）盯出款积压；夜班关注菲日间积压。
- 提款咨询流转：客服转来的提款咨询（进度/规则）→ 回应或引导，属咨询不属处理。
- 疑似套利驳回话术：统一说「风控人工复核」，不暴露反套利细节（见 §4.4）。
待补：二次验证 / Data 层级（菲律宾暂无，后续可加）
「二次验证 / Data」层级 = 把高危会员提现全部转人工审核 + 视频核身。菲律宾暂时没有这个层级；后续可加，届时这类会员的大额/提现由副组长等人工把关。
4.4 套利扣款流（副组长在大额决策节点）¶
菲律宾流程：现场稽核直接扣，大额才上副组长
稽核发现套利 → 现场稽核拉进「套利层级」、常规直接扣款 → 金额较大时交副组长决策扣款 → 客服群通知客服 → Signal 财务群报备。 判定标准由远程稽核管理制定。副组长只在金额较大时介入决策扣款，常规套利扣款由现场稽核直接处理。
目的：追回被套利薅走的钱 + 让客服能答复用户
套利 = 用户钻活动漏洞把邀请/拼多多奖励刷成利润提走，是平台的净亏损；扣款就是把奖励相关的钱（含用它赚的盈利）追回，用户自己充值的钱和原有余额一分不扣（既止损，又不误伤真实玩家，故须逐笔查账变、不能按当前余额一刀切）。
- 为什么扣完要通知客服：用户被扣款后大概率来问客服，客服群提前通知，客服才知道是怎么回事、怎么答复。
- 为什么大额才上副组长：常规小额现场稽核直接扣即可；金额一大，扣错就是大资损或误伤真实玩家，需副组长查账变 + 交叉验证后再决策。
flowchart TD
A["稽核发现套利"] --> B["现场稽核拉进套利层级<br/>限制提现等权限"]
B --> C{金额较大?}
C -->|否 常规| D["现场稽核直接扣款"]
C -->|是 大额| E["交副组长决策扣款"]
E --> F["副组长查账变记录<br/>+ 交叉验证复核稽核判断"]
F --> G["副组长后台执行扣款<br/>会员管理-会员列表-UID-账号数据-修改余额"]
D --> H["客服群通知客服<br/>用户来咨询时知道怎么答复"]
G --> H
H --> I["Signal 财务群报备<br/>平台/用户ID/金额/原因"]扣款金额计算原则：
| 需要扣除 | 需要保留 |
|---|---|
| 邀请奖励金额 | 用户自己充值的金额 |
| 拼多多奖励金额 | 获得奖励之前的账户余额 |
| 通过上述奖励产生的盈利 | — |
一句话记住
奖励相关的钱（含盈利）全扣，用户自己的钱全留。 需查账变记录逐笔核实，不能按当前余额一刀切。
加减款类型区分：
| 类型 | 是否计入充值统计 | 用途 |
|---|---|---|
| 人工加减款 | ✅ 计入存款 | 补充值、财务调整 |
| 彩金加减款 | ❌ 不计入存款 | 活动补偿、漏发彩金（日常用这个） |
- 操作必填备注（含工单号/客诉号）—— 审计护身符；单次/单日上限在后台账号配置，超限系统拒绝。
- 扣款 ≠ 收回款项：扣款针对违规、无时限（会员管理路径）；收回款项针对刚误确认的一笔充值，仅订单确认后 30 分钟内有效（财务管理 → 入款记录 → 收回款项，过期按钮消失）。
- 拼多多/邀请奖励门槛以菲律宾 P222 权威口径为准（phb-activities），不套用印尼 IDR 门槛。
4.5 三方渠道成功率 + 卡单巡查处理流¶
目的：保证会员随时充得进、平台随时付得出
充值通道是平台的「进钱管道」，代付通道是「出钱管道」。管道一堵，会员充不进（流失）或提不出（投诉炸群）。副组长这两条巡检线就是在会员发现问题之前，先发现并切换掉出问题的通道。
菲律宾余额逻辑跟印尼相反 —— 别搞反了
菲律宾系统会自动跳过余额低的代付渠道，所以余额低的不用你管。你要盯的是反方向：单个渠道余额别超过 200 万 ₱，堆太多要提醒财务换 U 下发掉。
两条并行守护线：① 每小时代付余额巡检（盯高余额）；② 每半小时充值成功率巡检（盯 GCash 成功率）。
flowchart TD
subgraph 余额["每小时 · 代付余额巡检"]
B1["Telegram 群机器人查各渠道代付余额"] --> B2{某渠道余额 > 200万₱?}
B2 -->|是| B3["提醒财务换 U 下发<br/>把多余额度消化掉"]
B2 -->|否| B4{有余额低的渠道?}
B4 -->|是 余额低| B5["不用管<br/>系统自动跳过 不派该渠道代付"]
B4 -->|否 正常| B6["维持配置 继续监控"]
end
subgraph 成功率["每半小时 · GCash 充值成功率巡检"]
S1["逐平台查近10分钟成功率"] --> S2{成功率?}
S2 -->|≥75% 正常| S3["维持 继续监控"]
S2 -->|<75% 关注| S4["盯紧 观察是否继续下滑"]
S2 -->|<70% 排查| S5["找三方排查<br/>是全线都低还是单商户问题?"]
S5 --> S6{哪种?}
S6 -->|单商户| S7["通知该商户优化通道<br/>观察10-15分钟"]
S6 -->|全线低| S8["立即上报组长<br/>可能是系统性问题"]
S7 --> S9{恢复?}
S9 -->|是| S3
S9 -->|否| S10["切换代收渠道<br/>问题商户降权 保持代收代付一致"]
S10 --> S11["群内报备+记录本次切换"]
end核心原则与要点：
- 看群第一：现已设置机器人自动排查提醒，代付余额、成功率异常会推到相关群 —— 副组长要及时看各群信息，别等自己巡检才发现。
- 成功率分档处理（地基 §4.6）：GCash < 75% 开始关注；< 70% 找三方排查，先判断是「全线都低（系统性）」还是「某个商户出问题」，全线低立即上报组长。
- 先通知商户优化、再切渠道（通知成本最低）；切渠道时代收排序 = 代付排序同步调整。
- 临时调整必有回归动作：设提醒到点复评，别把临时配置忘成永久。
- 三方代付银行维护通知：收到银行系统维护/网络波动通知，后台把 bank 代付类型暂时关闭，恢复后再开。
- 高峰期最优充值渠道（仅新用户）：主峰 22:00–02:00 不计成本开体验最优通道给新用户，仅新用户可见，散场后关闭。
- 所有渠道变更截图存档 + 群内报备。
4.6 三方资金异常补款流（现金直充）¶
目的：三方出问题导致会员的钱没到位，用现金直充补回、一分不差
两种常见三方资金异常：① 出款成功后被银行/钱包冲正退回；② 会员重复支付同一订单。本质都是「会员该有的钱因三方问题没到账」—— 核实无误后让三方把钱补回商户，我们再用现金直充补给会员，全程通知客服 + Signal 财务群报备，做到账目可追、会员不吃亏。
铁律：先核实三方真的收到/退回钱，再补款
补款是往会员账户送钱，必须先跟三方核实钱真的冲正退回 / 真的多收了一笔，且三方已把钱补回我们商户，才补给会员。凭会员一面之词直接补 = 被骗款资损。
场景 A —— 出款后冲正退回
flowchart TD
A["三方给会员出款 原本成功"] --> B["银行/钱包冲正<br/>钱退回三方"]
B --> C["三方通知我们<br/>并把钱补回商户"]
C --> D["副组长核实<br/>确认钱已退回并补回商户"]
D --> E["用现金直充把钱补回给会员"]
E --> F["客服群通知客服"]
F --> G["Signal 财务群报备<br/>平台/用户ID/金额/原因"]场景 B —— 会员重复支付（同一订单 / 同一二维码付两笔）
flowchart TD
A["会员同一订单/同二维码付了两笔"] --> B["会员找客服反映"]
B --> C["副组长去三方渠道核实<br/>是否真收到多笔存款"]
C --> D{确认多收?}
D -->|否 未多收| E["向客服说明 不补款"]
D -->|是 确认多收| F["让三方把多收的钱补到商户"]
F --> G["用现金直充把这笔钱补到会员账号"]
G --> H["客服群通知客服"]
H --> I["Signal 财务群报备"]共同要点：
- 补款统一用「现金直充」（不是普通加减款/彩金），确保计入正确账目。
- 顺序不能反：先三方核实 + 钱补回商户 → 再现金直充给会员。
- 补完必客服群通知客服（会员来问时客服知情）+ Signal 财务群报备（平台 / 用户 ID / 金额 / 原因）。
- 操作填备注（工单号 / 客诉号），留痕四件套照旧。
4.7 运营数据异常排查流（→ 反馈组长）¶
目的：异常数据背后往往是套利或事故，早发现早止损
存提差、RTP、注册数一旦异常，背后可能是套利团伙、渠道故障、被封域名、机器薅羊毛。副组长是当班第一个看到数据的人 —— 先做初步定位、带证据反馈组长，比等到日报复盘才发现，能少损失一大截。
副组长发现异常时，先排查、后带证据反馈组长（地基 §3）。
存提差是「双向异常」—— 偏高偏低都要查，方向不同
存提差比例正常参考约 15%： - 偏低（< 15%）：平台付出偏多 → 查是活动日彩金送太多，还是有异常会员赢太多。 - 偏高（远超 15%）：平台收入异常 → 查是有会员输很多（疑似被套/异常），还是游戏 RTP 出问题。
flowchart TD
A["巡检发现异常<br/>存提差偏离15%/RTP异常/注册突降或暴增"] --> B["初步定位"]
B --> C{哪类异常?}
C -->|存提差偏低 <15%| D["平台付出偏多<br/>查活动日彩金送太多? 异常会员赢太多?"]
C -->|存提差偏高 远超15%| E["平台收入异常<br/>查有会员输很多? 游戏RTP出问题?"]
C -->|RTP 异常| F["查活动日配置/游戏回报率<br/>对照活动配置"]
C -->|注册突降| G["查注册通道/域名是否被封<br/>连通性测试"]
C -->|注册暴增| H["查是否投流异常/薅羊毛/机器注册<br/>看注册集中度"]
D --> I["整理证据 平台/时段/数值/初判"]
E --> I
F --> I
G --> I
H --> I
I --> J["反馈组长<br/>群相关topic"]
J --> K{组长判定}
K -->|运营调整| L["按组长指示执行渠道/配置调整"]
K -->|资损/安全嫌疑| M["升级 组长+经理"]- 存提差偏低（<15%）：先看是不是活动日彩金派发多（正常波动），排除后再查是否有异常会员赢太多（拉当天用户统计锁定）。
- 存提差偏高（远超 15%）：查是否有会员输很多（可能被套利/异常），或游戏 RTP 是否异常。
- RTP 异常：活动日回报率异常需排查活动配置。
- 注册突降：优先查注册通道/域名是否被封（配合客服连通性测试）。
- 注册暴增：警惕投流异常、薅羊毛、机器注册 —— 看注册时间/来源集中度。
- 反馈原则：带证据（平台/时段/数值/初判）反馈组长；涉及资损或安全立即升级组长 + 经理。
4.8 会员密码重置 / 换提款账号（需审核的）审核执行流¶
常规走机器人自助，副组长只接「需审核的」
机器人 @phb_super6「PHB查单小能手」 支持自助改密 / 查单 / 换账号 / 获取回单 / 禁提款·解禁。副组长只处理机器人办不了、或有盗号风险需人工审核的。
为什么改密/换号必须严审 —— 这是盗号提款的主入口
最危险的资损不是套利，是盗号：坏人改掉密码或换掉提款账号，把别人的钱提走。所以「所有权验证是第一关，凭群里一句话绝不动手」不是麻烦，是防止你亲手把会员的钱送给骗子。
flowchart TD
A["会员请求 改密/清提款密码/换提款账号"] --> B{"机器人 phb_super6 可自助?"}
B -->|是 常规| C["引导会员/客服走机器人自助<br/>副组长不介入"]
B -->|否 需审核| D["客服转单 说明场景"]
D --> E["第一关 验证所有权"]
E --> F{"验证类型"}
F -->|忘登录密码| G["有充值需最近一次存款证明<br/>通过后改随机密码 发客服群"]
F -->|忘提款密码| H["按有无提款历史要两项凭证<br/>核对一致后清空提款密码"]
F -->|换提款账号| I["场景A修1-2位错/场景B完全换号<br/>B需完整证件+新账户+三方户名一致"]
G --> J["回复客服群闭环"]
H --> J
I --> J审核要点：
- 核心原则：所有权验证是第一关，凭「群里一句话」绝不动手，必须走客服转单。
- 忘登录密码：从未充值 → 直接改随机密码；有过充值 → 要最近一次存款证明。处理是改为随机密码（不是清空），让会员登录后自改；「用户 ID + 新密码」只发客服群。
- 忘提款密码：提款密码只能清空不能改（系统硬约束）；按有无提款历史要两项凭证（提款/存款截图 + 账户 profile 页），两项缺一不可，核对一致后清空；若在锁定列表则一次性全解开。
- 换提款账号：场景 A（错 1-2 位）验证中等；场景 B（完全换号）需完整证件 + 新账户完整截图。
换号核身红线（地基 §4.1）
证件姓名 = 后台户名 = 新账户户名，三方必须一致。 证件用菲律宾政府部门核发的有效 ID 均可（如 UMID / 驾照 / 护照 / PhilID 等）。
-
所有改密/清空/解锁操作操作日志留痕，处理完回复客服群确认闭环（不回复等于没做）。
待补：二次验证 / Data 层级（菲律宾暂无，后续可加）
菲律宾暂无「二次验证层级」—— 即频繁改密/疑似盗号 → 提现全走人工 + 视频核身；后续可加，届时补进本流程（在验证所有权后增设「疑似盗号 → 拉入二次验证层级」分支）。
4.9 交接班流程（白 ↔ 夜）¶
目的：让下一班无缝接手，不漏单、不重复
值班是 24 小时接力，交接没做好 = 未闭环的大额出款/扣款掉在两班之间没人管，或接班的人重复做了一遍。交接班表 + 群内认领核对，就是这根接力棒。
flowchart LR
subgraph 交班["交班方（下班）"]
O1["补齐当班值班表<br/>订单/出款/扣款/回调记录"]
O2["汇总回调清单和总额发群"]
O3["未闭环事项明确移交并获对方确认"]
O4["异常单独标注 系统故障/未处理完提现"]
O5["下一班要用的兑换码已备好"]
O1 --> O2 --> O3 --> O4 --> O5
end
subgraph 接班["接班方（上班）"]
I1["翻上一班值班表 了解处理过的单"]
I2["查群内未认领/未闭环任务"]
I3["确认当前兑换码已设并配好推送"]
I4["检查推送排程是否配到下一节拍点"]
I5["设好推送提前1h闹钟"]
I1 --> I2 --> I3 --> I4 --> I5
end
交班 ==>|东八区 16:00 / 04:00 交接| 接班交接硬性项（缺一不可）
三方渠道当前排序与临时调整（含回归提醒）、稽核审核积压情况、高峰期充值通道开关状态、未闭环的大额出款/套利扣款。
五、定点任务清单（日/夜班）¶
时点为东八区（平台）；换成贝尔格莱德挂钟 = 减 6 小时。
日班（东八区 16:00–次日 04:00 · 贝尔格莱德 10:00–22:00）¶
| 东八区时点 | 任务 |
|---|---|
| 16:00 | 交接班；查 No Limit 群等群是否有需注意事项并记录 |
| 16:10 | 查远程客服/稽核打卡；查 Salesmartly 与云桌面登录 |
| 16:20 | 三方通道是否正常、后台通道配置、短信余额、三方余额、财务群/出入款群信息检查 |
| 19:00 | 第二轮短信拉回 + 自媒体 + 站内信推送 |
| 20:00 | 存提差巡检 + 条件返水（需组长确认） |
| 22:00 | 远程稽核云桌面检查 |
| 22:00–02:00 | 玩家主峰：00:00 自媒体推送；00:15 起 高峰期最优充值渠道守护 |
| 02:00 | 处理前一日客损拉回 |
| 03:20 | 下班前收尾：客服打卡/云桌面/Salesmartly；远程稽核审核积压检查；补齐值班表、未闭环移交 |
| 全天 | 每小时三方余额巡检；每半小时充值成功率巡检；客服连通性测试；抽查 Salesmartly 在线与客服质检；稽核疑难单二次审核 + 抽查稽核出款；大额出款协助；套利大额扣款决策；回调测试；限额会员站内信+短信提醒 |
夜班（东八区 04:00–16:00 · 贝尔格莱德 22:00–次日 10:00）¶
| 东八区时点 | 任务 |
|---|---|
| 04:00 | 上班先查远程客服/质检打卡、云桌面、Salesmartly；三方通道/后台/余额检查 |
| 09:30 | SMS 群核对短信模板/禁词 |
| 11:30 | 第一轮短信拉回 |
| 12:00 | 自媒体推送 + 站内信推送 |
| 12:15 | 推送后检查（文案对否、拉回效果、埋雷号是否正常收短信、是否有其他广告介入） |
| 15:30 | 交班准备：下班前收尾检查、补齐值班表、未闭环移交 |
| 全天 | 每小时三方余额巡检；每半小时充值成功率巡检；督导云桌面上线；稽核出款群回应大额/异常订单 |
六、工具与后台操作¶
| 用途 | 工具 | 副组长在哪点什么 |
|---|---|---|
| 客服接线 | Salesmartly（Smartly） | 抽查客服在线与质检、监督回复；不直接接线用户 |
| 运营后台 | 澎湃（phcms） | 导数据、加减款/扣款、渠道排序、看日报表/成功率 |
| 短信拉回 | collab 协作台短信拉回工具（API / Bluebird） | 常规直接拉澎湃数据走 API 发送；数据量大时先从澎湃导 Excel 上传工具再发 |
| 兑换码 | 协作台兑换码工具 + TM 工具 | 自动生成码+金额、一键设置到后台；随机规则在工具里改 |
| 客服机器人 | @phb_super6「PHB查单小能手」 | 常规改密/查单/换账号/获取回单/禁提款·解禁走机器人，副组长只接需审核的 |
| 稽核查询 | collab 协作台 TM 脚本工具（现场稽核+副组长）；远程稽核用澎湃后台 | 用 TM 脚本高效查代理审核/下级行为 |
| 兑换码文案 | 兑换码文案工具 duihuanma.pages.dev | 取兑换码推送文案（菲律宾专用，替代印尼 Google 文案库） |
| 数据报表 | Google Sheet + collab 协作台数据分析 | 运营报表、数据核对 |
| 推送 | 澎湃后台「客户端通知」（底层 Firebase）+ 自媒体/社群 + 站内信 | 澎湃后台配客户端通知、社群推送、站内信代码编辑器粘贴 HTML（发新删旧）；不用极光、不单独管 Firebase |
关键后台路径速查（澎湃）
- 导出昨日注册/会员数据：营销工具 → 用户回访 / 用户统计 → 选日期导出
- 扣款/加减款：会员管理 → 会员列表 → 点 UID → 账号数据 → 修改余额（必填备注）
- 收回款项（误确认充值，30 分钟内）：财务管理 → 入款记录 → 收回款项
- 日报表/存提差比例：报表管理 → 日报表 → 查询
- 渠道排序：代收/代付渠道配置
兑换码工具箱、彩金公式、去重比对等自动化工具在
tools/目录（副组长工具箱）；菲律宾对应工具是否已部署以本站为准。
七、质检与绩效¶
副组长被考核什么
- 执行准确率：推送不错图/不发过期码、拉回数据不漏不重、扣款金额算准、大额出款不误放。
- 留痕完整：每笔资金动作四类留痕（后台备注 / 群内通告 / 值班表 / Signal 财务群报备）缺一即扣分。
- 响应时效：B 线认领与闭环及时，稽核审核积压不失控。
- 异常上报：数据异常、资损、安全事件是否按升级链及时上报。
质检体系（地基 §4.4）：
- 客服质检：以
QA GUIDE.xlsx（QI ERROR MASTER GUIDE） 为权威错误清单（38 项、12 大类、扣分 -1~-8、严重度 Minor/Major/Critical），由远程助理抽检执行 → 远程客服管理汇总审批。副组长督导当班客服质检执行，不做汇总审批。 - 稽核质检：参照客服框架，由远程稽核管理负责。
- 绩效评级：沿用菲律宾现有 18 号（客服 130+）/ 17 号（稽核绩效） 档位；月度评级由组长审批。
待确认：副组长自身绩效档
地基未单列副组长绩效档，需向组长/经理确认。
八、升级链与边界¶
升级链（地基 §4.3）：
| 层级 | 谁 | 处理 |
|---|---|---|
| L0 | 远程客服（一线） | 常规咨询、机器人/自助能解决 |
| L1 | 副组长（值班）/ 远程助理 | 需审核事项、当班异常、客服疑难兜底 |
| L2 | 组长 | 决策权外、资损/安全、运营数据异常 |
| L3 | 经理 | 制度/薪资/大额资金/合规 |
| L4 | 老板 | 最终拍板 |
副组长升级红线（这几种立即上报，不要自己扛）
- 资损 / 账号盗用 / 系统故障 → 立即上报组长 + 经理（不等、不跳级例外）。
- 会员威胁（投诉 PAGCOR / 媒体 / 差评）→ 群里相关 topic 及时反馈。
- 大额提款 + 渠道大面积异常 → 立即通知组长协调，副组长不自行决策补资。
- 活动策略、资金多签发起、绩效审批 → 均不在副组长权限，分别归组长/经理。（提款二次审核在副组长权限内，但提款初审归稽核线。）
九、红线¶
三条不可逾越的红线¶
flowchart TD
R["副组长三红线"]
R --> R1["① 防重复<br/>群里任务认领后再做<br/>权限/扣款/回调重复=资损"]
R --> R2["② 防套利<br/>套利扣款按稽核判定交叉验证<br/>提款异常查真实订单状态"]
R --> R3["③ 防断链<br/>每个动作留痕<br/>后台备注/群通告/值班表/财务报备"]为什么是这三条
- 防重复：副组长动的全是真金白银，重复执行 = 直接资损；「群内认领」是核心防线。
- 防套利：套利金额 = 平台净亏损；扣款执行前按稽核判定 + 交叉验证复核。
- 防断链：每个决策事后可能被追溯（资损调查/合规审计/用户投诉），没留痕 = 无法自证清白 —— 四类留痕缺一不可。
十、常见问题与踩坑¶
10.1 活动规则客诉速答（客服转来的规则疑问）¶
| 客诉 | 速答方向 | 排查要点 |
|---|---|---|
| 没收到 VIP 周/月奖励 | 查结算时点、充值门槛、领取作废期 | 是否已过作废期 |
| 为什么要打码才能提 | 所有彩金都有流水要求，行业通用反套利 | 查具体倍数 |
| 红包金额变少了 | 系统派发是随机金额，属正常 | 向用户解释随机机制 |
| 已达闯关目标没奖励 | 确认有效投注额（非所有投注 100% 计入） | 查有效打码口径 |
| 提款多久到 | 按公开 SLA 回复，走「赢钱即提」承诺口径 | 不虚报、不暴露内部流程 |
P222 活动门槛话术以 phb-activities 权威源为准，不套用印尼 IDR 数据。
10.2 每次都要自查的踩坑清单¶
| 坑 | 教训 |
|---|---|
| 推送图张冠李戴 | 配完对照平台名复查一遍 |
| 文案里兑换码没同步更新 | 以兑换码文案工具（duihuanma.pages.dev）为准 |
| 临时调渠道排序忘了回归 | 临时调整必设提醒到点复评 |
| 差一项凭证就放行 | 所有权凭证缺一不可，不放行 |
| 站内信堆积 | 发新前先删旧 |
| 埋雷号不核对 | 发完必核对测试号是否全收到 |
| 把菲律宾余额逻辑当印尼 | 余额低不用管（系统自动跳过），余额 > 200 万 ₱ 才要提醒财务换 U |
10.3 待补案例（上岗后逐步积累）¶
- 代理提款审核的边界判断（下级是否正常、邀请奖励正常 vs 异常、拼多多套利判断）—— 依赖案例积累（判定标准归远程稽核管理）。
- 二次验证 / Data 层级：菲律宾暂无，后续可加（届时补触发条件 + 视频核身规则 + 流程分支）。
十一、术语表¶
核心术语（客损、拉回、存提差、RTP、一人多号、大额/首提、现场/远程稽核、值班班子、TM 脚本工具）统一见地基：
两个最容易搞错的术语
- 客损 = 注册并充值了、但当天未投注（本项目特有，≠ 行业「玩家亏损」）。
- 拉回 = 发短信提醒后次日看是否产生投注记录，有 = 已拉回。
十二、互动自测（学完自查）¶
下面是本篇的互动练习——答完即时反馈。答对撒花、错了看解析，闪卡帮你记住阈值。
检查你的理解¶
:::quiz{id=keson} 本项目说的「客损」指下列哪种用户？
- [ ] 玩了游戏但输了钱的用户
- [x] 注册并充值了、但当天没有投注的用户
- [ ] 提款失败的用户
解析：本项目「客损」= 充值了却没投注（本项目特有口径，≠ 行业「玩家亏损」）。拉回目标是激活首注，不是返水。 :::
:::quiz{id=review} 关于提款审核，副组长的角色是？
- [ ] 提款订单的一线初审员
- [x] 稽核之上的二次审核（稽核拿不准时拍板）+ 抽查稽核出款
- [ ] 不碰任何审核，只发短信拉回
解析：提款初审归稽核线；副组长是二次审核层——稽核不确认时拍板 + 抽查已出款订单质量。客服只做订单咨询、不碰提款处理。 :::
:::quiz{id=balance multi=true} 关于三方代付余额，下列哪些说法对？（多选）
- [x] 单渠道余额堆到 200 万 ₱ 以上要提醒财务换 U 下发
- [x] 余额低的渠道不用管，系统会自动跳过不派它代付
- [ ] 余额低的渠道要马上通知财务补资
解析：菲律宾跟印尼相反——低余额系统自动跳过、不用管；要盯的是高余额（>200 万 ₱）提醒财务换 U。别搞反。 :::
情景演练：提款咨询怎么回¶
:::scenario{id=withdraw}
{
"start": "n1",
"nodes": {
"n1": {
"text": "客服转来：会员投诉「提现 2 小时还没到账」。你先做什么？",
"choices": [
{ "label": "回复「你的银行还没处理，请等 1-2 小时」", "next": "bad", "feedback": "❌ P222 走 InstaPay 实时到账（<5min），不能甩锅『你的银行/银行回单』。", "good": false },
{ "label": "确认属咨询→引导稽核查订单状态，不代替审核", "next": "n2", "feedback": "✅ 副组长只协调流转，不碰提款审核决策。", "good": true }
]
},
"bad": { "text": "会员更火了，还截图发群。补救：改口按 InstaPay 实时口径 + Pasensya 安抚。", "terminal": true },
"n2": {
"text": "稽核查到是大额（>₱5000）且首提，稽核拿不准。轮到你？",
"choices": [
{ "label": "二次审核拍板（放行/驳回）", "next": "good", "feedback": "✅ 稽核拿不准 → 副组长二次审核。", "good": true },
{ "label": "直接让现场稽核出款", "next": "good2", "feedback": "⚠️ 大额+首提拿不准应先二次审核，别跳过。", "good": false }
]
},
"good": { "text": "处理正确：二次审核拍板 + 留痕 + 回群闭环。", "terminal": true },
"good2": { "text": "可通过，但规范上大额+首提拿不准应二次审核后再出款。", "terminal": true }
}
}
记忆卡（阈值，每天翻一翻防忘）¶
:::flashcards{id=thresholds} - 单笔提款限额 :: ₱100 – 50,000（不收手续费、提多少到多少） - 大额人工审核阈值 :: 提款 > ₱5,000 - 存提差正常参考 :: ~15%（双向异常：偏低查彩金/会员赢多，偏高查会员输多/RTP） - GCash 成功率 :: <75% 关注 / <70% 找三方排查 - 单渠道代付余额上限 :: 200 万 ₱（超了提醒财务换 U） - 玩家主峰 :: 22:00–02:00 PHT :::
:::gate{id=done score=0.8 title=学完本篇} 把上面三道题答对、情景走一遍、闪卡过一轮，你就掌握了副组长最核心的判断。点「标记完成」记入你的学习进度。 :::
维护：本 SOP 以地基为单一真相源；规则/阈值变更先改地基再同步本文。文中所有折叠的「待确认」项需在上岗后逐条向组长/经理核实补齐，补齐后去掉标注。互动自测题随规则变更同步更新。