07 · 组长工作指南¶
适用对象：运营组长 内容来源：学习笔记 + 新站搭建准备工作表格 作者：Bob ｜ 日期：2026-04-26 状态：初稿，持续更新中
目录¶
- 一、组长角色定位
- 1.1 管理范围
- 1.2 工作重心对比
- 二、日常管理工作
- 第二章·一 人员与决策（5 节）
- 第二章·二 运营支撑（4 节）
- 第二章·三 内容运营（2 节）
- 三、新站搭建工作流程
- 3.1 搭建工作总览
- 3.2 域名类（9 项）
- 3.3 配置类（11 项）
- 3.3.2 支付通道金额及层级配置
- 3.3.3 Firebase APK 推送配置完整流程
- 3.4 做图类（7 项）
- 3.5 账号类（4 项）
- 3.6 测试类（4 项）
- 3.7 搭建流程总览图（含并行关系）
- 3.8 搭建任务分工总览
- 四、活动效果监控与调整
- 4.1 新站活动监控
- 4.2 周拉回效果测试
- 五、HQ 后勤中台系统（houqin）
- 六、待确认清单
一、组长角色定位¶
组长的工作偏向人员管理，而非具体的执行操作。日常工作主要是解决平台运营中出现的各种问题——更多是人员和具体业务上的问题，而非平台系统性问题（系统性问题一般在建站初期就解决了）。
1.1 管理范围¶
┌──────────┐
│ 经理 │
└────┬─────┘
│
┌────────────┼────────────┐
│ │
┌─────▼─────┐ ┌─────▼──────┐
│ 组长 │ │ 稽核组长 │
│（运营方向） │ │（风控方向） │
└─────┬─────┘ └─────┬──────┘
│ │
┌──────┼──────┐ ▼
│ │ 远程稽核团队
┌────▼────┐ ┌─────▼──────────┐
│ 副组长 │ │ 客服管理人员 │
│（值班） │ │（现场，兼任客服）│
└────┬────┘ └─────┬──────────┘
│ │
▼ ▼
值班团队 远程客服团队
组长和稽核组长是并行关系，分别负责不同方向（运营 vs 风控），不是上下级隶属关系。两者都向经理汇报。
问题升级链路：远程人员问题 → 现场负责人先处理 → 处理不了/需要决策 → 提交组长/稽核组长 → 仍无法解决 → 提交经理审核决策
1.2 工作重心对比¶
| 维度 | 副组长 | 稽核组长 | 组长 |
|---|---|---|---|
| 工作性质 | 执行操作 | 风控审核 | 人员管理 + 问题解决 |
| 日常重点 | 推送/回访/提现审核 | 套利排查/质检 | 协调团队/处理疑难/监控效果/运营支出 |
| 固定任务 | 5 次推送/存提差巡检 | 代理审核/异常排查 | 新站搭建（阶段性）+ 活动监控 + 日常支付 |
| 决策权 | 按标准执行（不调整流程） | 套利判定 + 风险标记 | 组长单独可决策：流程调整 / 参数修改 / 人员调配 / 资金支出（多签钱包内） 需经理批准：人员离职 / 薪资调整 / 制度修改 / 跨部门重大资源调度 |
📝 来源：学习讨论
二、日常管理工作¶
组长的日常工作不像副组长那样有固定的节拍时间表，更多是响应式和监控式的：
第二章·一 人员与决策（5 节）¶
2.1 组长的工作定位¶
组长本身主要负责决策性和审核性的工作，具体执行工作通过培训下属来完成：
| 组长做的 | 下属做的 |
|---|---|
| 决策和审核 | 具体执行操作 |
| 培训副组长和其他人员 | 按标准流程执行 |
| 处理现场人员的问题 | 远程人员问题先由现场负责人处理 |
| 处理无法解决的升级问题 | 日常问题自行处理 |
| 无法解决的提交经理 | — |
2.2 人员管理¶
下属团队： - 副组长——值班执行团队 - 客服管理人员——现场，本身也是客服，同时管理远程客服团队 - ⚠️ 稽核组长不归组长管——两者是并行关系，各自向经理汇报
2.2.1 班次人员配置¶
每个班次现场 6 人（1 人排休基本不影响运转），按职能分为 3 组：
| 岗位 | 人数 | 主要职责 | 工作指南 |
|---|---|---|---|
| 副组长 | 2 | 推送/回访/提现审核/存提差巡检/代收代付渠道管理 等值班执行工作 | 01-副组长-工作指南 |
| 会员资料更正 | 2 | 会员登录密码重置、提款密码（PIN）重置、银行卡号更换、账号解锁等资料变更操作 | 01-副组长-工作指南 · 5.密码重置 |
| 客服管理专员 | 2 | ① 充值未到账排查处理 ② 提现卡单排查处理 ③ 远程客服团队的日常管理（排班/质检/监控/培训） | 04-客服管理专员工作指南 |
组长管辖的每班 6 人配置
┌──────────────────────────────────────────────────────┐
│ 组长（管理层） │
│ 决策/审核/培训/协调/运营支出 │
└───────────────┬────────────────────────────────────-─┘
│
┌────────────┼────────────────────┐
│ │ │
┌──▼──┐ ┌───▼────┐ ┌─────────▼──────────┐
│副组长│ │会员资料 │ │存提款订单 + 远程管理 │
│ ×2 │ │更正 ×2 │ │ ×2 │
└──┬──┘ └───┬────┘ └─────────┬──────────┘
│ │ │
▼ ▼ ├─→ 充值未到账排查
推送/回访 密码重置 ├─→ 提现卡单处理
提现审核 PIN 重置 └─→ 远程客服管理
存提差巡检 换银行卡 （排班/质检/监控）
渠道管理 账号解锁 │
▼
远程客服团队（WFH）
远程客服团队架构（客服管理专员管辖）：
- 远程助理 ×10（5 组各 2 人）：每人管理 10 名远程客服，负责团队质检、新人培训、问题反馈
- 远程客服 ×100（5 组各 20 人），24 小时全覆盖，分白班/夜班（印尼雅加达时间 WIB）：
- A 版（1 组 20 人）：白班 10:00-22:00 / 夜班 22:00-10:00
- B 版（4 组 80 人）：白班 12:00-00:00 / 夜班 00:00-12:00
- B 版安排更多人手，因为晚间 19:00-00:00 是用户活跃高峰
详见 → 04-客服管理专员工作指南
📝 来源：学习讨论
2.2.2 与客服管理人员的协调机制¶
以下机制经跨文档（04-客服管理专员-工作指南、02-远程客服-管理规范、03-远程客服-岗前培训指南 等）交叉验证整理，仍存数值/周期细节用 ❓ 标注，待跟组长确认补充。
协调机制总览（汇报流向图）¶
┌──────────────┐
│ 远程客服 │
│ （100 人） │
└──────┬───────┘
│ 工作问题
▼
┌─────────────────────┐
│ 远程助理（10 人） │ ← 第一接触人
│ 每 2 人 / 20 名远程 │
└──────┬──────────────┘
│ 助理处理不了
▼
┌─────────────────────────┐
│ 客服管理专员（现场） │
│ 每班 2 人 │
└──────┬──────────────────┘
│ 处理不了或需审核
▼
┌──────────────┐
│ 组长 │
└──────┬───────┘
│ 仍无法解决
▼
┌──────────────┐
│ 经理 │
└──────────────┘
维度 1 · 日常汇报¶
客服管理专员向组长进行日常 + 周常两层汇报：
- 日常汇报（每班交接时）：
- 远程客服排班状态异常（缺勤、临时调班）
- 当班质检重大问题（连续违规、严重投诉）
- 超出处理范围的会员投诉案例
- 周常汇报（每周一汇总）：
- 周度排班执行率
- 周度质检均值（按班次/个人统计）
- 当周新入职 / 离职 / 提拔人员变动
- 待审批的人事申请清单
- 汇报渠道：组长群（Signal / Telegram）+ 月底书面汇总表
❓ 待跟组长确认：周汇报具体频次（建议周一 / 周四固定时段）+ 质检数据聚合方式（分班次 vs 整体）
维度 2 · 问题升级¶
四级升级链条（不能跳级）：远程客服 → 远程助理 → 客服管理专员 → 组长 → 经理。
三级分类标准：
| 层级 | 类型 |
|---|---|
| 第一层（客服管理专员处理） | 排班调整、单次质检异常、员工请假申请、常规工具故障 |
| 第二层（组长审核） | 纪律处罚决策、人事变动建议、质检重大问题原因分析、排班冲突调解 |
| 第三层（经理审批） | 人员离职审批、薪资调整、岗位变更、制度修改 |
维度 3 · 排班协调¶
协调原则：客服管理专员自主排班，组长默认不干涉。排好后主动同步告知组长即可——组长是知情角色，仅在异常时介入。
- 客服管理专员自主权（完全自主，排好后同步告知组长）：
- 制定 100 人远程客服的排班表
- 处理日常调休 / 请假申请
- 缺勤补班安排
- 排班表月度更新
- 特殊情况下组长才介入：
- 突发大规模缺勤（如 ≥5 人同日缺勤）需组长协调支援
- 人事变动涉及的排班调整（新入职 / 提拔 / 离职涉及岗位）
- 跨组协调（如远程客服与稽核组之间）
维度 4 · 质检结果¶
完整闭环（日 → 周 → 月）：
| 周期 | 客服管理专员动作 | 组长动作 |
|---|---|---|
| 日常质检 | 每日 Salesmartly 查看 + 远程助理每班反馈异常客服 | — |
| 周度汇总 | 每周一 09:00 整合上周数据（按班次/个人统计），输出《周质检反馈表》 | 接收汇总表，发现异常关注 |
| 异常处理 | 质检异常（≥3 个错、差评率 ≥5%）→ 转发助理 → 1 对 1 指正 → 次周跟进 | 严重案例上报 |
| 月度工资挂钩 | 月度工资绩效表按公式计算，扣分项由质检异常累积 | 审批 |
详细操作 SOP 见 04-客服管理专员-工作指南 §八 质检与绩效管理。
❓ 待跟组长确认：S / A / B / C / D / E 评级与 KPI 金额的具体绑定关系
维度 5 · 人事管理¶
| 流程 | 客服管理专员动作 | 组长决策点 |
|---|---|---|
| 招聘 | 识别缺口 → 初筛面试 → 提交候选人 | 最终审批 + 确认入职时间和分班 |
| 内部提拔 | 识别候选人 → 5 项评估打分 → 提出建议 | 审批后安排新助理培训和职责交接 |
| 离职 | 接收离职申请 → 填离职单 → 提交 | 送审批 → 客服管理专员执行三个后台处理（云桌面改密 / Salesmartly 改密 / 工作群通知） |
详细操作 SOP 见 04-客服管理专员-工作指南 §十五 人员变动管理。
❓ 待跟组长确认：组长批复周期（建议 24 小时内）+ 提拔评估表是否需助理共评
维度 6 · 培训协调¶
完整职责分工：
| 角色 | 职责 |
|---|---|
| 客服管理专员 | 入职首日：收集个人信息、分配云桌面账号、配置 Beeftext、指派对应远程助理 培训周期：3-5 天适应期（新人与助理 1 对 1 对标） 后续跟进：每日抽查质检、周度评估是否可独立当班 |
| 远程助理 | 讲解话术库、SOP、工作规范 实时纠错 5-7 天后反馈"可独立"或"需延长" |
| 组长 | 培训资源协调（如新材料引入） 跟进新员工 1 个月后的转正评估 |
培训材料（已整理归档）：
📝 来源：跨文档（04 / 02 / 03 / 05）交叉验证 + 学习讨论
2.3 平台问题处理¶
- 日常平台运营中出现的各种问题
- 注意：一般是人员和具体业务上的问题，系统性问题在建站初期已解决
2.4 活动效果监控¶
- 新站刚开始时设置的各类活动，需要持续监控效果
- 周拉回等测试性活动，根据效果数据决定是否需要调整参数
- 详见 四、活动效果监控与调整
2.5 排班与人事¶
- 排班管理：负责现场人员、UI 人员、远程报表人员的排班表和请假需求
- 月底薪资整理：每月底整理 A+C 组的内推费和加班费，提交给人事部审核后由财务发放
📝 来源：学习讨论
第二章·二 运营支撑（4 节）¶
2.6 日常运营开支管理¶
组长负责每天的日常运营开支支付，主要以 USDT 通过多签钱包进行支付。每笔支出实时报到财务群。
常见开支类型：
| 开支类型 | 说明 |
|---|---|
| 每日短信费用 | SMS 回访/拉回的渠道费用 |
| 员工离职工资 | 离职员工的工资结算 |
| 员工工作开支报销 | 日常工作产生的费用报销 |
| 客服线套餐费用 | Salesmartly 等客服平台的座席使用费 |
| 其他运营支出 | 其他日常运营相关费用 |
多签钱包支付流程：
经理存入一定金额到多签钱包
│
▼
┌──────────────────────────────┐
│ 组长发起出款 │
│ （主要签名权重在组长） │
└──────────┬───────────────────┘
│
▼
┌──────────────────────────────┐
│ 副组长（有权限的）进行签名 │
│ （双签确认后款项付出） │
└──────────┬───────────────────┘
│
▼
┌──────────────────────────────┐
│ 钱包余额消耗到一定程度 │
│ → 组长向经理申请补充 │
└──────────────────────────────┘
安全机制：多签钱包需要两个签名（组长发起 + 副组长确认）才能付出，单人无法独立操作，防止资金被挪用。
📝 来源：学习讨论
2.7 远程测试管理¶
远程测试群监控和游戏/网站测试本质上都是组长安排远程测试人员按要求进行测试，统一管理。
2.7.0 测试触发条件（组长决策）¶
新增/调整远程测试的触发场景——组长基于以下情况决策是否启动测试：
| 触发类型 | 场景 | 决策标准 |
|---|---|---|
| 新通道上线 | 新代收/代付通道接入 | 必须测试（通道稳定性 + 真实存提款） |
| 域名变更 | 主域名/PWA/APK 域名更换 | 必须测试（用户访问 + 跳转链路） |
| 用户大批量投诉 | 同一类型问题 ≥10 条/小时 | 即时启动专项测试 |
| 新游戏厂商接入 | 厂商 SDK 集成完成 | 必须测试（投注/结算/异常） |
| 活动重大变更 | 奖金规则/层级配置调整 | 必须测试（计算正确性） |
详见 01-副组长-工作指南 §4.1.5 套利场景判定基础 的测试方法论。
📝 来源：跨证 副组长指南 §4.1
2.7.1 测试的目的与原理¶
为什么要测试：平台面向印尼市场的真实用户，任何功能异常（支付不通、游戏打不开、页面无法访问）都会直接导致用户流失和资金损失。远程测试通过模拟真实用户操作，在问题影响用户之前发现并解决。
测试的核心目的：
| 目的 | 说明 |
|---|---|
| 保障用户体验 | 确保网站/游戏/支付全链路正常，用户充值、游戏、提现无障碍 |
| 验证支付通道可用性 | 代收代付渠道经常变动，需要定期测试确认充值和提现通道畅通 |
| 验证游戏厂商接口 | 游戏厂商的 API 可能出现故障或变更，及时发现避免用户投诉 |
| 新站上线验收 | 新站搭建完成后，必须经过完整测试才能正式上线（参见三、新站搭建 · 3.6 测试类） |
| 域名可用性监控 | 炮灰域名/PWA 域名/业务域名随时可能被封，需要持续验证访问是否正常 |
2.7.2 测试类型与内容¶
| 测试类型 | 测试内容 | 触发时机 | 备注 |
|---|---|---|---|
| 支付渠道测试 | 充值（代收）+ 提现（代付）全流程 | 新通道上线、渠道切换、日常巡检 | 需要订单回调配合，参见副组长 4.4 订单回调处理 |
| 游戏厂商测试 | 指定游戏厂商的游戏能否正常打开、下注、结算 | 新游戏上线、厂商接口变更、用户投诉 | ❓ 具体测试频率和判定标准待与组长确认 |
| 网站访问测试 | 各类域名（业务域名/PWA/炮灰/APK）是否正常打开 | 日常巡检、域名变更后、被封恢复后 | 参见 3.2.1 域名体系详解 |
| 活动内容检查 | 活动规则、图片、链接、领取流程是否正确 | 新活动上线、活动参数调整后 | — |
| 模拟回调数据 | 通过三方渠道机器人 /testpay 订单号 模拟充值回调 |
支付渠道测试时 | ❓ 更多场景待确认 |
2.7.3 组长的管理职责¶
组长本身不做具体测试操作，而是负责：
组长安排测试任务
│
▼
远程测试人员按要求执行
（充值/提现/游戏/网站访问等）
│
▼
测试结果反馈到远程测试群
│
▼
┌─────────────────────────────┐
│ 组长监控测试群 │
│ · 查看测试结果 │
│ · 识别异常问题 │
│ 常见：支付渠道不通 │
│ 网站/游戏打不开 │
│ 活动内容错误 │
└──────────┬──────────────────┘
│ 发现问题
▼
┌─────────────────────────────┐
│ 协调相关人员处理 │
│ · 支付问题 → 联系三方商户 │
│ · 域名被封 → 后台换域名 │
│ · 游戏异常 → 联系游戏厂商 │
│ · 配置错误 → 安排修正 │
└─────────────────────────────┘
2.7.4 问题排查思路¶
发现测试异常时，按以下思路排查：
📝 来源：资料整理（基于学习讨论 + 副组长工作指南 + 新站搭建测试类），后续需跟组长确认具体测试安排细则并补充修正
2.8 集团运营报表¶
不限于「下班前」——拿到需要填写的数据就填写报表。手续费数据、客损拉回人数等数据何时到手，就何时填报。
2.8.1 报表填写职责¶
组长需要填写/确认的数据项（❓ 具体报表格式和完整字段待确认）：
| 数据项 | 来源 | 关注重点 |
|---|---|---|
| 手续费 | 代收代付三方商户结算 | 金额是否合理，与历史平均值对比是否异常偏高/偏低 |
| 客损拉回人数 | 副组长每日批量任务汇报 | 拉回效果趋势，是否需要调整拉回策略 |
| 存提差数据 | 各平台后台日报表 | 比例是否在正常范围（参见副组长 3.5 存提差巡检） |
| 其他运营指标 | ❓ 待确认 | ❓ 具体看哪些指标、判断哪些数据待后续与组长确认 |
2.8.2 报表检查职责¶
组长不仅自己填数据，还需要检查报表填报人员的数据质量：
报表填报人员提交数据
│
▼
┌─────────────────────────────────┐
│ 组长检查要点 │
│ │
│ ① 数据是否正确填写 │
│ · 是否漏填、错填 │
│ · 数值格式是否正确 │
│ │
│ ② 数据异常检测 │
│ · 存提差比例是否偏离历史平均 │
│ · 手续费是否突然升高/降低 │
│ · 充值/提现量是否有异常波动 │
│ │
│ ③ 公式/计算是否被误改 │
│ · Google Sheet 公式是否完好 │
│ · 汇总数据与明细是否一致 │
└──────────┬──────────────────────┘
│ 发现异常
▼
┌─────────────────────────────────┐
│ 排查流程 │
│ · 存提差异常 → 检查具体平台数据 │
│ 是否有大额提现/异常充值 │
│ · 手续费异常 → 检查渠道费率变动 │
│ 或交易笔数异常 │
│ · 数据对不上 → 排查是否有漏录 │
│ 或重复录入 │
└─────────────────────────────────┘
2.8.3 当前报表体系的问题¶
目前所有运营报表通过 Google Sheet 由填报人员手工填写，存在以下问题：
| # | 问题 | 风险 |
|---|---|---|
| 1 | 数据隔离缺失 | 填报人员能看到整个表格所有数据，缺乏权限隔离 |
| 2 | 误操作风险 | 填报人员可能误改公式或其他人的数据，影响最终汇总计算 |
| 3 | 缺乏可视化 | 数据都是纯数字，没有图表趋势展示，新组长分析数据学习成本高 |
| 4 | 异常排查困难 | 数据量大时，人工逐行检查效率低，难以快速定位异常数据 |
2.8.4 数据看板系统（开发中 · iConsole）¶
为解决上述问题，目前正在自研一套运营数据看板系统，项目代号 iConsole。核心思路两条：①把多张 Excel/Google Sheet 的死数据搬进系统，用图表/Dashboard 可视化呈现；②录入与查看权限分离——录入人员看不到完整敏感数据，每个岗位只能看到自己权限范围内的数据。
项目基线¶
| 项 | 内容 |
|---|---|
| 项目代号 | iConsole |
| 代码仓库 | ~/Coding/iconsole/（独立仓，与 igaming 主仓平级） |
| 后端技术栈 | FastAPI（Python 3.12）+ PostgreSQL 16 + Redis 7 |
| 前端技术栈 | Next.js 14（App Router）+ React 19 + Tailwind CSS v4 + Recharts |
| BI 工具 | Apache Superset（独立栈） |
| 部署 | Docker Compose 单机 · 已上 dhv6 服务器（iconsole.zycenter.one） |
| 测试覆盖 | 后端 574 个测试 + 前端 e2e 49 个测试 |
① 数据录入端（给填报人员使用）¶
- 角色：
ops_inputter（运营录入）/ad_inputter（广告录入）/cashflow_inputter（金流录入） - 状态机：
draft → submitted → reviewing → approved → locked，录入人只能write/submit，不能审批/导出 - 数据隔离：录入人只看自己负责的资源（如
ops_inputter只能写site_ops，看不到广告/金流的数据） - 作用域 3 维：
market_id（如 'IDN' / ''）+group_code（如 ''）+platform_ids（NULL 全平台 / INT[] 指定） - 页面：
/entry/today（今日录入工作台 · 4 状态卡片）//entry/[platform]/[domain]（80+ 字段表单）
② 管理看板端（给组长/管理层使用）¶
- 角色：
boss_viewer（老板看板，全域 read）/auditor（稽核，全域 read + export） - 看板架构：4 Tab × 42 张卡片
- 资金面板（13 张）/ 投放 ROI（13 张）/ 用户 Funnel（8 张）/ 促销支出（8 张）
- 可视化：移动端响应式 · 趋势图 + sparkline + 同环比 · 汇率 IDR ↔ USDT 实时切换
- 数据源：PostgreSQL fact 表直查（8 fact 表 + 4 个
vw_board_*物化视图）
③ 权限分离（RBAC）核心设计¶
| 维度 | 已落地内容 |
|---|---|
| 角色 | 10 个预设角色：superadmin / boss_viewer / ops_inputter / ops_approver / ad_inputter / ad_approver / cashflow_inputter / cashflow_approver / currency_admin / auditor |
| 资源 | 11 个：site_ops / ad_daily / cashflow / channel_promo / currency_rate / admin_users / admin_roles / admin_permissions / …… |
| 行为 | 6 个：read / write / submit / approve / lock / export |
| 作用域 | 3 维：市场（market_id）+ 组（group_code）+ 平台（platform_ids） |
| 数据库强制隔离 | 32 条 PostgreSQL RLS 策略（8 个 fact 表 × 4 policy）+ SECURITY DEFINER + search_path 锁——绕过应用层也拿不到数据 |
| 审计 | INSERT-only audit_log 表（DBA 也不能修改历史记录） |
这套设计实现了用户最初提的核心诉求："录入人员不应该看到敏感的完整数据，每个岗位只能看到权限范围内的数据"。在数据库层用 RLS 强制隔离，应用层用
check_perm + apply_scope_filter过滤，前端再按角色渲染——三层防护。
里程碑状态¶
| 里程碑 | 状态 | 关键交付 |
|---|---|---|
| M1 数据底座 | ✅ | 11 dim 表 + 8 fact 表 + 32 RLS 策略 + 4 物化视图 + 79 测试 |
| M2 录入端 | ✅ | FastAPI + Next.js 前端 + JWT + 审核工作流 + admin 后台 |
| M3 老板看板 | ✅ | 42 卡片移动端 + Mock 数据 + 汇率切换 + dhv6 生产部署 |
| P1 真实数据底座 | ✅ | dim_ad_account 817 行 + fact_ad_daily + 字段字典 |
| P2 entry v2 | 🚧 进行中 | 4 迁移 + 13 后端端点 + 前端 4 路由 + e2e 7 测试（待部署） |
| S1 RBAC 完整化 | 🚧 进行中 | 10 预设角色 + 权限 schema 补全 + admin SPA 三页 |
| P6 数据导入工具 | ⏳ 计划中 | 上传 xlsx → 灌 fact_ad_daily |
| AI 分析 | ⏳ 预留 | InsightProvider 抽象已留接口（等 ANTHROPIC_API_KEY 接入） |
给组长岗位的关联说明¶
- 当前阶段：iConsole 已完成 M1-M3 + P1，已能跑通端到端流程，但真实业务数据导入还在做（P6）——暂时还得继续用 Google Sheet
- 过渡策略：现阶段组长仍按 §2.8.1 / §2.8.2 在 Google Sheet 上工作；iConsole P6 完工后，组长会转为在 iConsole 看板端查询，填报人员转为在录入端工作
- 需要组长配合的事：把目前正在用的 Google Sheet 报表模板（字段、公式、口径）整理出来交给开发，是补完系统的关键前提
- ❓ 待确认：完整的报表字段清单、公式设计、各平台数据口径——计划在 P6 启动时同步收集
📝 来源：iConsole 项目代码深度分析（2026-05-04 · feat/s1-rbac-completion 分支） + 学习讨论
2.8.5 组长报表收集时间线¶
| 周期 | 组长收什么 | 来自谁 | 时间点 |
|---|---|---|---|
| 每日 | 当日推送数据、扣款明细 | 副组长（B 线值班） | 当班结束前 |
| 每日 | 远程客服质检异常 | 客服管理专员 | 每班交接 |
| 每周一 09:00 | 周质检反馈表 | 客服管理专员 | 周一上午 |
| 每月 1 日 | 月度工资绩效表（含远程客服） | 客服管理专员 | 月初 |
| 每月 1 日 | 月度运营报表（充提流水/活动费用/通道费） | 副组长 + 财务对接人 | 月初 |
📝 来源：跨证 01-副组长-工作指南 §二 每日工作时间线 + 04-客服管理专员-工作指南 §17/§18 日常/月常清单
2.9 代收代付三方群下发确认¶
- 在代收代付三方群里进行下发确认 ❓ 具体确认什么内容和流程待确认
📝 来源：学习讨论
第二章·三 内容运营（2 节）¶
2.10 客服话术整理与培训¶
组长负责整理客服热线回复的统一话术，确保所有客服（现场+远程）在面对用户时使用统一的标准回复。
话术体系文档（已整理归档到 10-客服中心 目录）：
| 文档 | 内容 | 适用对象 |
|---|---|---|
| 01-客服话术库 | 30+ 分类、200+ 条标准回复话术（印尼语），含快捷编号 | 全体客服 |
| 02-远程客服工作流程 SOP | 16 条工作纪律 + 充值/提现/账户操作完整决策树 | 远程客服 |
| 03-远程客服管理规范 | 远程客服 10 步工作流程 + WFH 规范 + FAQ | 远程客服 |
组长的管理职责： - 话术更新：根据业务变化（新活动上线、规则调整、新平台）及时更新话术库 - 培训：新客服入职时安排学习上述三份文档，考核通过后上岗 - 质检：抽查客服回复质量，不符合标准的进行纠错和再培训 - KPI 关联：回复质量（话术规范度、响应速度、解决率）纳入客服 KPI 考核
📝 来源：学习讨论 + 话术库.xlsx
2.11 UI 素材文案¶
- UI 展示图 Excel 里排版样式有不同的尺寸要求
- 活动推广文案由组长自己撰写（不是从模板复制）
- 后台运营配置里的所有大小图标由组长负责
- 尺寸规格详见 12-UI展示图索引
📝 来源：学习讨论
三、新站搭建工作流程¶
这是组长最重要的阶段性固定工作。搭建完成后就不再重复，但每开一个新站都要完整走一遍。
3.1 搭建工作总览¶
新站搭建共 37 项工作，分为 5 大类：
| 类别 | 工作数量 | 说明 |
|---|---|---|
| 域名类 | 9 | 域名购买、绑定、解析、加速 |
| 配置类 | 11 | 推送/支付/游戏/客服/活动/Firebase 等后台配置 |
| 做图类 | 7 | ICON/LOGO/Banner/活动图/客服图/下载页等视觉素材 |
| 账号类 | 4 | 客服/稽核/自媒体等账号创建和配置 |
| 测试类 | 4 | 游戏/存取款/网址/活动内容的全面测试 |
3.2 域名类（9 项）¶
| # | 搭建内容 | Konten Pembangunan | 负责人 | 说明 |
|---|---|---|---|---|
| 1 | 购买主域名，确定模版，开后台 | Beli domain utama, tentukan template, buka backend | Martin | 由管理层（经理/老板）决定，组长配合执行 |
| 2 | 通知 SEO 做排名 | Beri tahu SEO untuk optimasi peringkat | Martin | 域名确定后尽早通知 SEO 团队 |
| 3 | 联系技术人员购买配套域名 | Hubungi teknisi untuk membeli domain pendukung | Martin | 配套域名用于辅助功能 |
| 4 | 联系技术人员购买炮灰域名 | Hubungi teknisi untuk membeli domain "umpan" (decoy) | Martin | 炮灰域名用于防封 |
| 5 | 配套域名绑定 | Pengikatan domain pendukung | HB | |
| 6 | PWA 域名绑定 | Pengikatan domain PWA | HB | PWA 安装需要独立域名 |
| 7 | 炮灰域名绑定 | Pengikatan domain "umpan" (decoy) | HB | |
| 8 | 炮灰域名解析 | Pengaturan DNS domain "umpan" (decoy) | HB | DNS 解析设置 |
| 9 | 防封域名 + APK 域名线路加速 | Domain anti-blokir + percepatan jalur domain APK | HB | 线路加速确保 APK 下载速度 |
📘 来源：新站搭建准备工作表格
3.2.1 域名体系详解¶
以下内容帮助组长深入理解域名体系的设计逻辑，方便给副组长等执行人员讲解"为什么这样做"。
非凡包网后台的域名分三大管理模块：
| 模块 | 后台路径 | 本质角色 | 面向谁 |
|---|---|---|---|
| 网站域名 | 域名管理 → 网站域名 | 真实业务落地页 | 所有终端用户 |
| PWA 防封域名 | 域名管理 → PWA 防封域名 | 桌面 App 的替身入口 | PWA 安装用户 |
| 跳转域名（炮灰域名） | 域名管理 → 跳转域名 | 一次性挡枪跳板 | 广告/短信触达的新用户 |
📘 来源：09-域名类型功能
网站域名的五种类型标签——不只是分类，每种在业务中有不同角色：
| 类型 | 一句话角色 | 为什么需要独立 |
|---|---|---|
| 普通 | 万能兜底入口（首页/导航/跳转中转） | 不需要特殊系统行为的通用场景 |
| 代理分享 | 代理自主裂变的专属链接 | 系统自动标记推广来源，代理后台直接调用，与官方推广互不污染归因 |
| 推广链接 | 官方主动触达（短信/推送/广告） | 区分"公司花钱拉"vs"代理自发推"，便于 ROI 分开核算 |
| APK 域名 | APP 内部线路通道（每站 3 条容灾） | 暴露=被攻击=全站 APP 瘫痪；需技术二次处理，严禁对外暴露 |
| 检测域名 | 运维健康探针（/api/check） |
不打开主站就能诊断服务器状态，不干扰业务流量 |
📘 来源：09-域名类型功能
三大模块详细对比：
| 维度 | 网站域名 | PWA 防封域名 | 跳转域名（炮灰） |
|---|---|---|---|
| 被封影响 | 灾难级——全站不可访问 | 中等——换域名即恢复，用户无需重装 | 低——换个炮灰继续投 |
| 域名成本 | 高价值、长期持有 | 中等、可替换 | 廉价、短期、消耗品 |
| 技术机制 | NS 激活 + CF 防御 | NS 激活 + 关联网站域名 | NS 激活 + 子域名解析 + 302 跳转 |
| 参数透传 | 不涉及 | 不涉及 | 支持（utm/click_id 等归因参数） |
3.2.2 用户访问的完整链路¶
理解不同用户是怎么通过不同的域名到达平台的。
┌─────────────────── 新用户获客路径 ───────────────────┐
│ │
│ 广告/短信/社媒推广 │
│ │ │
│ ▼ │
│ 炮灰域名 dd.xyz.cc ← 挡在最前面，承担封禁风险 │
│ │ 302 跳转（参数透传 ?utm_source=xx） │
│ ▼ │
│ 业务域名 bc666a.top ← 类型=推广链接/普通 │
│ │ │
│ ▼ │
│ 用户注册/充值/安装 PWA │
│ │
├─────────────────── 老用户回访路径 ───────────────────┤
│ │
│ 手机桌面 PWA 图标 │
│ │ │
│ ▼ │
│ PWA 防封域名 pwa.abc.com ← 独立域名层，被封可热替换 │
│ │ 关联 │
│ ▼ │
│ 业务域名 bc666a.top ← 用户无感知切换 │
│ │
├─────────────────── 代理分享路径 ─────────────────────┤
│ │
│ 代理后台 → 复制代理分享域名链接 │
│ │ │
│ ▼ │
│ agent-share.top（类型=代理分享）→ 自动带代理邀请码 │
│ │ │
│ ▼ │
│ 用户注册，归因到该代理 │
│ │
├─────────────────── APK 用户路径 ─────────────────────┤
│ │
│ 安卓 APP 内部代码 │
│ │ │
│ ▼ │
│ APK 域名 ×3（代码硬编码）← 严禁对外暴露，3条容灾 │
│ │ │
│ ▼ │
│ APP 正常加载业务数据 │
└──────────────────────────────────────────────────────┘
3.2.3 三层洋葱防封架构¶
设计哲学：三层洋葱结构——炮灰在最外层挨打，PWA 在中间做弹性入口，业务域名在核心永远不直接暴露。每一层被封只需替换该层，不影响内层。
┌─── 最外层：炮灰域名 ───┐
│ 挡枪消耗品，被封就换 │
│ ┌─── 中间层：PWA ───┐ │
│ │ 弹性入口，热替换 │ │
│ │ ┌── 核心层 ──┐ │ │
│ │ │ 业务域名 │ │ │
│ │ │ 从不暴露 │ │ │
│ │ └────────────┘ │ │
│ └──────────────────┘ │
└────────────────────────┘
封禁风险排序：炮灰（最高）> PWA（中）> 业务域名（最低）
被封后的应急响应：
| 被封层级 | 影响 | 响应时间 | 操作 |
|---|---|---|---|
| 炮灰被封 | 新用户推广链接失效 | 5 分钟 | 后台换新炮灰 + 同步解析 |
| PWA 被封 | 老用户 PWA 打开白屏 | 10 分钟 | 后台换新 PWA 域名 + 关联原业务域名，用户自动恢复 |
| 业务域名被封 | 全站不可访问 | 灾难级 | 整站迁移（极少发生，因为从不直接暴露） |
| APK 域名被封 | APP 瘫痪 | 需重新打包发版 | 所以严禁暴露 |
场景故事帮助理解：
场景 1：炮灰被封——短信投放用
dd.xyz.cc，某天被运营商封禁。后台换一个新炮灰ee.abc.cc指向同一个业务域名，群里更新链接模板，5 分钟恢复投放。真实域名零影响，老用户完全无感。场景 2：PWA 被封——老用户桌面 PWA 图标打开白屏。后台把 PWA 防封域名换成新的，仍然关联同一个业务域名。用户下次打开 PWA 自动拉到新线路，无需卸载重装——壳坏了换壳，芯不变。
3.2.4 域名封禁处理操作手册¶
📘 来源：网站官方域名封禁处理流程 v2.docx（2026-05-02 更新）
以下是三种域名被封时的具体操作步骤。
A. 网站官方域名封禁处理¶
场景：网站主域名被封（如 7777w77.com 封禁）
操作步骤：
发现官方域名被封
│
▼
后台 →「网站域名」→ 找到被封域名（如 7777w77.com）
│
▼
① 关闭「域名被封检测」开关
原理：已确定被封，不需要让系统持续提醒
│
▼
② 同步检查「域名加速」是否开启
→ 如果开启，必须同步关闭
原理：域名加速只有 15 个名额，
被封域名占用名额浪费，
要把名额留给有需要的域名
│
▼
③ 在备注栏标注屏蔽日期
格式：「SEO 专用 3.10 屏蔽了」
│
▼
④ ⚠️ 检查域名类型！
如果是「代理域名」被封禁
→ 必须**立刻**将类型改为「普通」
│
▼
⑤ 状态**不用关闭**
原理：客户能打开的还是可以让客户继续打开，
关闭状态会导致已访问客户也无法访问
│
▼
⑥ 如需增加新域名
→ Signal 联系域名管理人员 @tom 添加
⚠️ 三个关键原则： 1. 关闭域名加速——15 个名额很宝贵，被封域名要让出来 2. 代理域名被封必须立刻改普通类型——否则可能影响代理体系 3. 状态不要关闭——能打开的客户继续让他打开，避免误伤还能访问的用户
B. PWA 域名封禁处理¶
⚠️ PWA 域名风险有两种，要先区分（详见 3.2.9.1 三种风险事件的精准区分）：
- 运营商屏蔽：印尼电信运营商屏蔽 → 该运营商网络的用户访问不了，已安装的 PWA 还能用（换运营商可正常打开）
- 谷歌爆红：Google Chrome 标为危险 → 整页红色警告，已安装 PWA 的老用户也受影响（PWA 基于 Chrome 内核），无法进入前台
本节流程通用于两种场景的事后应急。爆红场景的事前主动分散策略见 §3.2.9 渠道-炮灰-PWA 风险分散策略。
场景：PWA 防封域名被封（如 7777w.gum719.com 被电信屏蔽，或被 Chrome 爆红）
操作步骤：
发现 PWA 域名被封
│
▼
① 后台 →「PWA 防封域名」→ 找到被封域名
→ 关闭「域名被封检测」
→ 备注屏蔽信息，如「H5转化（1220被电信屏蔽）」
│
▼
② Signal 联系 @tom：
· 购买新乱码域名（如 werewurh.com）
· 或从已购买的 PWA 备用域名中选一条
│
▼
③ 拿到新域名后，加上平台前缀
例：7777w.werewurh.com
│
▼
④ 后台操作：
· 先绑定新域名（域名绑定方式）
· 添加 PWA 域名 → 填写新域名
· 选择「防封指向」域名
· 确认后等待 NS1、NS2 显示
│
▼
⑤ NS 显示后 → Signal 联系 @tom 做解析
│
▼
⑥ 解析激活后：
· 打开「域名被封检测」
· 将新 PWA 域名添加到「极光推送」
│
▼
⑦ 更换原绑定的炮灰域名（详见 B.1 子流程）
│
▼
⑧ 被封的 PWA 域名开启「救援弹窗」（详见 B.2 子流程）
B.1 炮灰域名换绑子流程¶
后台 →「投放跳转域名」
│
▼
选择绑定在被封 PWA 域名的炮灰域名（可能多条）
│
▼
点击「解析」按钮
│
▼
删除两条原记录
│
▼
添加新域名记录：
· 子域名：输入 `@`
· 跳转链接：`https://` + 新的 PWA 域名
（例：https://7777w.werewurh.com）
│
▼
点击「同步」
│
▼
✅ 完成：原老域名下载的 PWA 客户**无感切换**到新域名
B.2 救援弹窗设置子流程（针对老客户）¶
⚠️ 核心问题：老客户使用 PWA 添加了桌面书签，原 PWA 域名被封后，桌面书签会白屏无法游戏。后台完成域名更换后，新客户自然到新域名，但老客户需要救援弹窗提醒更新。
后台 → 找到**被封的旧 PWA 域名**配置项
│
▼
开启「救援弹窗」开关
│
▼
设置弹窗为「强制弹窗」
│
▼
在弹窗目标输入框
填入**新绑定的 PWA 域名**
（例：7777w.werewurh.com）
│
▼
复制下方 B.2.1 标准救援文案并粘贴
│
▼
保存配置
│
▼
✅ 老客户打开旧 PWA 桌面书签时
→ 出现救援弹窗
→ 点击「更新」
→ 自动跳转到新 PWA 域名
→ 重新添加桌面书签后继续游戏
✅ 不受影响的客户群体：通过 PWA 域名下载了原生 APK 或马甲包的客户，不依赖 PWA 桌面书签，所以救援弹窗对他们不生效——但他们也不需要救援，因为 APK 已经在本地。
B.2.1 救援文案模板¶
标准救援文案（直接复制粘贴使用，不需要修改任何内容）：
Unduh aplikasi terbaru!
Klik tombol unduh, lalu tekan tombol di kanan atas untuk membuka halaman unduhan utama menggunakan Google Chrome, dan unduh aplikasi terbaru!
中文翻译参考（仅供理解，实际使用印尼语版）：
下载最新应用！点击下载按钮，然后按右上角的按钮，使用 Google Chrome 打开主下载页面，下载最新应用！
📌 使用说明：所有平台都用这一份文案，不需要替换平台名或域名。文案的核心是引导老用户用 Chrome 打开主下载页重新下载，或重新添加新的桌面书签即可
B.3 PWA 域名封禁操作要点速查¶
| 步骤 | 操作 | 位置 |
|---|---|---|
| 关闭检测+备注 | 关闭域名被封检测，标注日期和原因 | 后台 → PWA 防封域名 |
| 获取新域名 | Signal @tom 购买乱码域名或从备用选 | Signal |
| 加前缀绑定 | 新域名加平台前缀后在后台绑定 | 后台 → PWA 防封域名 |
| 等待 NS + 解析 | 等 NS1/NS2 显示后联系 @tom 解析 | Signal |
| 激活后配置 | 开启封禁检测 + 添加极光推送 | 后台 |
| 更新炮灰指向 | 投放跳转域名 → 解析 → 删旧记录 → 加新记录（@ + https://新PWA） → 同步 | 后台 → 投放跳转域名 |
| 救援弹窗 | 旧 PWA 域名开启救援弹窗，指向新 PWA 域名 | 后台 → 旧 PWA 域名配置 |
C. 炮灰域名封禁处理¶
场景：投放跳转用的炮灰域名被封
操作步骤：
发现炮灰域名被封
│
▼
① Signal 联系 @tom
询问能否做 301 跳转
（利用未被封的域名做跳转）
│
▼
② 通知**投放部门**：
该域名已封禁，需更换推广链接
│
▼
③ ⚠️ **不要在后台删除被封的炮灰域名**
（保留记录用于追溯）
│
▼
④ 提供**新的炮灰域名**
继续绑定到原 PWA 域名
│
▼
⑤ 把新炮灰域名提供给投放部门
继续去做投放
📝 状态说明：炮灰域名封禁目前尚未发生过，以上为预设的处理方式（基于平台技术能力推演）。
⚠️ 重要登记纪律：所有域名的使用途径需要在表格内明确登记，方便后续忘记时查询（哪个炮灰绑哪个 PWA、哪个 PWA 关联哪些业务域名等）。
D. 域名管理通用注意事项¶
这部分是在三种封禁处理之上的全局管理纪律，避免被动应对带来的资金浪费和数据混乱。
| # | 注意事项 | 说明 |
|---|---|---|
| 1 | 被封域名同步给 @tom | 第一时间通知 tom，登记到统一的封禁记录表 |
| 2 | 缓存时间 vs 域名续费 | PWA 域名缓存周期约 300 天。如果域名买了 1 年但第 300 天被封，还剩 65 天到期但缓存还有 300 天 → 这种情况被封也必须续费一年，否则缓存期内老用户会因域名过期再次失效 |
| 3 | 炮灰域名买 1 年 | 炮灰域名一般用不到 2 年，不能循环使用（被封过的域名重新使用风险高），到期不续，买新的更划算 |
| 4 | 站内域名买 2 年 | 以下类型必须买 2 年：APK 域名、PWA 域名、代理域名、前台域名、导航站入口域名、防封指向域名（这些域名不能频繁换，需要长期稳定） |
| 5 | ⚠️ 渠道链接参数不可变更（铁律） | 渠道链接（炮灰链接 / 防封链接）一旦生成投放出去，链接后面的参数部分（utm_source / click_id 等归因参数）不能改变——改参数会破坏归因链路 + 影响投放数据回传。所有"分散 / 重解析"操作只能改域名本身或解析跳转目标，不能动参数。详见 §3.2.9 渠道-炮灰-PWA 风险分散策略 |
域名续费决策表¶
| 域名类型 | 默认购买年限 | 被封后续费策略 | 原因 |
|---|---|---|---|
| APK 域名 | 2 年 | 续 2 年 | 内嵌在 APP 代码中，换域名要重新打包发版 |
| PWA 域名 | 2 年 | 续 1 年（看缓存周期） | 被封后老客户走救援弹窗迁移，新客户走新域名 |
| 代理域名 | 2 年 | 续 1 年 | 被封后改类型为"普通"继续用 |
| 前台域名 | 2 年 | 续 1 年 | 业务核心域名，重要 |
| 导航站入口 | 2 年 | 续 1 年 | 用户引导链路，长期稳定 |
| 防封指向域名 | 2 年 | 续 1 年 | PWA 防封的目标域名 |
| 炮灰域名 | 1 年 | 不续费 | 一次性消耗品，被封即弃 |
域名封禁处理速查表¶
| 域名类型 | 风险触发方 | 用户感知 | 第一步 | 获取替代 | 后台配置 | 特殊步骤 | 后续 |
|---|---|---|---|---|---|---|---|
| 网站官方域名 | 印尼监管 / 运营商 | 全站不可访问 | 关闭封禁检测 + 关闭域名加速 + 备注日期 | Signal @tom 添加新域名 | 代理类型改普通 | 状态不用关闭 | — |
| PWA 防封域名（运营商屏蔽） | 印尼电信运营商 | 该运营商用户访问不了，已装 PWA 还能用 | 关闭封禁检测 + 备注日期 | Signal @tom 买乱码域名或用备用 | 加前缀绑定 → 等 NS → 解析 → 极光推送 | 更新炮灰指向 + 救援弹窗 | 开启封禁检测 |
| PWA 防封域名（谷歌爆红） | Google Chrome | 整页红色警告，已装 PWA 老用户也受影响 | 同上 + 立即启动 §3.2.9.4 / §3.2.9.5 分散策略 | 同上 | 同上 | 同上 + 改炮灰解析分流新会员 | 开启封禁检测 |
| 炮灰域名（FB 标记） | FB 媒体平台 | 用户无感，FB 端不让投 | Signal @tom 看能否 301 跳转 | 提供新炮灰域名给 FB | 不删除被封域名 | 通知投放部门改链接；旧炮灰可转给 TT/Kwai 复用 | 登记到表格 |
场景 3：参数透传归因——广告投放
dd.xyz.cc?utm_source=fb&click_id=123，302 跳转后变成bc666a.top?utm_source=fb&click_id=123，归因链路不断。炮灰挡枪的同时，ROI 数据完整回传。
📝 来源：网站官方域名封禁处理流程 v2.docx + 学习讨论 + 经理工作笔记（D-5 渠道链接参数铁律 + 速查表中 PWA 爆红行 / 炮灰 FB 标记行） 📘 来源：09-域名类型功能 📘 来源：10-投放跳转炮灰域名
3.2.5 DNS 域名解析原理¶
组长需要理解域名解析的基本原理，才能排查域名不通、解析不生效等问题。
域名解析的本质：把人类看得懂的域名（www.example.com）翻译成机器看得懂的 IP 地址（93.184.216.34）。
解析过程：
用户在浏览器输入 www.example.com
│
▼
[1] 检查本地 DNS 缓存
│ 没有缓存
▼
[2] 问本地 DNS 服务器（运营商/ISP 提供）
│ 没有记录
▼
[3] 问根 DNS 服务器（全球 13 组）
│ 返回：.com 的顶级 DNS 地址
▼
[4] 问 .com 顶级 DNS 服务器
│ 返回：example.com 的 NS 记录
│ （即"谁来管这个域名的解析"）
▼
[5] 问权威 DNS 服务器（由 NS 记录指定）
│ 返回：A 记录 → 93.184.216.34
▼
[6] 浏览器拿到 IP → 建立连接 → 加载页面
三种核心 DNS 记录对比：
| 记录类型 | 作用 | 类比 | 示例 |
|---|---|---|---|
| A 记录 | 域名 → IP 地址 | 终点站 | example.com → 93.184.216.34 |
| CNAME | 域名 → 另一个域名 | 中转站 | www.example.com → example.com |
| NS 记录 | 指定由谁来管解析 | 调度中心 | example.com NS → ns1.cloudflare.com |
简单记法：A 记录是终点站（给 IP），CNAME 是中转站（指向另一个域名），NS 决定谁来做调度。
3.2.6 Cloudflare 托管（NS 修改）¶
为什么要把域名托管到 Cloudflare（CF）： - 免费 SSL 证书（HTTPS） - DDoS 防御 - CDN 加速（全球 300+ 节点） - 隐藏源站真实 IP
操作步骤：
域名托管到 Cloudflare 的完整流程
│
▼
┌────────────────────────────────┐
│ (1) 注册 Cloudflare 账号并登录 │
│ https://www.cloudflare.com │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ (2) 点击 Add a Site │
│ 输入你的域名 → 选 Free 计划 │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ (3) CF 自动扫描现有 DNS 记录 │
│ 人工核查是否完整 │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ (4) CF 给出两条 NS 地址： │
│ ns1.cloudflare.com │
│ ns2.cloudflare.com │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ (5) 登录域名注册商后台 │
│ 找 Name Servers 设置 │
│ 删除原 NS → 填入 CF 的 NS │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ (6) 回到 CF 点 Check Nameservers│
│ 等待生效（几分钟~24小时） │
│ 出现绿色勾 = 托管成功 │
└────────────────────────────────┘
非凡包网后台的域名绑定也是类似流程：添加域名后系统生成 NS1/NS2 → 去域名商后台改 NS → 3-5 分钟激活。
📘 来源：09-域名类型功能
3.2.7 CDN 加速原理¶
问题：用户在印尼，服务器在其他国家，直连延迟高。 解决：CDN（内容分发网络）在全球部署缓存节点，用户访问就近节点。
传统访问（无 CDN）：
用户(印尼) ─── 跨国网络 ───→ 源站(其他国家) 延迟高❌
CDN 加速（有 CF）：
用户(印尼) ──→ CF 雅加达节点 ──→ 源站(其他国家)
│
命中缓存直接返回 ✅
不用每次都回源
CF Proxy 模式（橙色云 vs 灰色云）：
| 🟠 橙色云（Proxied） | ⚪ 灰色云（DNS-only） | |
|---|---|---|
| 流量经过 CF | 是 | 否（直连源站） |
| 隐藏源站 IP | ✅ 是 | ❌ 否（IP 暴露） |
| CDN 缓存加速 | ✅ 有 | ❌ 无 |
| DDoS 防护 | ✅ 有 | ❌ 无 |
| 适用场景 | Web 流量（推荐） | 邮件/FTP 等非 HTTP |
建议：所有面向用户的域名都开橙色云（Proxied），获得加速+防护+隐藏 IP 三重效果。
3.2.8 炮灰域名操作详解¶
后台路径：域名管理 → 跳转域名
操作流程：
添加炮灰域名
│
▼
┌──────────────────────────┐
│ (1) 添加跳转主域 │
│ 输入炮灰域名 │
└──────────┬───────────────┘
│
▼
┌──────────────────────────┐
│ (2) 激活 NS │
│ 去域名商改 NS 指向后台 │
└──────────┬───────────────┘
│
▼
┌──────────────────────────┐
│ (3) 点"解析"（绿色按钮） │
│ 配置子域名映射： │
│ 子域名 → 目标 URL │
│ （支持参数透传） │
└──────────┬───────────────┘
│
▼
┌──────────────────────────┐
│ (4) 点"同步"（橙色按钮） │
│ 下发配置到 CDN 节点 │
└──────────────────────────┘
参数透传示例：
dd.炮灰.cc?utm=abc → 302 跳转到 → 真实域名.com?utm=abc
推广追踪参数不丢失。
📘 来源：10-投放跳转炮灰域名
3.2.9 渠道-炮灰-PWA 风险分散策略（运营管理层）¶
这部分是组长在域名层面的运营管理决策——不是技术配置，而是基于业务量、渠道特性、风险类型，主动设计炮灰与 PWA 的多对多映射，把风险分散开。
与 §3.2.4 域名封禁处理（事后被动应急）相对，本节是事前主动布局——通过合理的炮灰-PWA 配比 + 渠道差异化分配，让单点风险只影响局部。
3.2.9.1 三种风险事件的精准区分¶
域名相关的风险事件有 3 种，触发方、影响面、用户感知都不同——必须先区分清楚才能选对应策略：
| 风险类型 | 触发方 | 影响范围 | 用户感知 | 应对入口 |
|---|---|---|---|---|
| 炮灰域名标记 | FB 媒体平台 | 该炮灰不能再用于 FB 投放（其他媒体如 TT / Kwai 仍可复用） | 用户无感，只是 FB 端不让投了 | §3.2.4 C + §3.2.9.6 |
| PWA 域名屏蔽 | 印尼电信运营商 | 该运营商用户访问不了，换运营商可正常打开；已安装 PWA 仍能用 | 部分用户报反馈"打不开" | §3.2.4 B |
| PWA 域名爆红 | Google Chrome 浏览器 | 整页红色危险警告——已安装 PWA 的老用户也受影响（PWA 基于 Chrome 内核），无法进入前台 | 老用户 + 新用户都受影响 | §3.2.9.3 ~ §3.2.9.5 |
⚠️ PWA 爆红 ≠ 运营商屏蔽：前者是浏览器层级的危险警告，会传染到所有已安装 PWA 的用户；后者只是网络访问层问题，已安装的 PWA 仍能用。爆红比屏蔽严重得多。
3.2.9.2 默认配比：5 炮灰 ↔ 1 PWA（PWA 渠道固定标准）¶
平台域名管理的标准配比：
炮灰域名 1 ┐
炮灰域名 2 │
炮灰域名 3 ├── 跳转到 ──→ PWA 域名 1
炮灰域名 4 │
炮灰域名 5 ┘
为什么 5:1： - 炮灰被封比 PWA 被封频率高得多——多炮灰共用 1 个 PWA 既保证投放灵活性，又不浪费 PWA - 5 条是固定配比（PWA 渠道场景下）——APK 渠道不同（见 §3.2.9.6）
3.2.9.3 PWA 爆红的连带影响（为什么需要分散策略）¶
PWA 爆红有一个特殊的连带影响：
- PWA 本身基于 Google Chrome 浏览器内核安装的桌面应用
- 一旦 PWA 域名被 Chrome 标记为"危险"，所有已安装该 PWA 的用户——不只是新点炮灰链接的用户——打开手机桌面 PWA 图标时也会爆红
- 结果：老用户也无法进入前台，已经在跑的会员量直接被切断
这就是为什么爆红比炮灰被标记严重得多——所以管理层面要主动做风险分散（§3.2.9.4 / §3.2.9.5）。
3.2.9.4 大渠道分流策略（多对多映射）¶
适用场景：长期合作的大渠道（已知能起量），不能把鸡蛋放在一个 PWA 篮子里。
策略：从多条 PWA中各挑 1 条炮灰给同一渠道用，让该渠道的量分流到不同 PWA 上。
示例：
炮灰域名 1 ┐ 炮灰域名 6 ┐
炮灰域名 2 │ 炮灰域名 7 │
炮灰域名 3 ├── PWA 1 炮灰域名 8 ├── PWA 2
炮灰域名 4 │ 炮灰域名 9 │
炮灰域名 5 ┘ 炮灰域名 10 ┘
把 炮灰 1 + 炮灰 6 同时给某大渠道跑
↓
该渠道的量被分到 PWA 1 + PWA 2 两条线
↓
任一条 PWA 爆红 → 只影响该渠道一半的量
3.2.9.5 起量后炮灰动态分流（改炮灰解析）¶
问题背景：渠道在 FB 起量后，广告链接已经投放出去——
- ⚠️ 渠道链接生成后参数部分不能改变（参数变更会破坏归因 + 影响投放回传），所以炮灰域名本身也不能换
- 但风险还是要分散，怎么办？
解决方案：改炮灰的解析跳转目标——炮灰域名不变（投放链接稳定），但把它解析到新的 PWA。
示例（炮灰 1 起量后重解析到 PWA 2）：
重解析前：
炮灰域名 1（已起量）┐
炮灰域名 2（已起量）│
炮灰域名 3（已起量）├── PWA 1
炮灰域名 4 │
炮灰域名 5 ┘
炮灰域名 6 ┐
炮灰域名 7 │
炮灰域名 8 ├── PWA 2
炮灰域名 9 │
炮灰域名 10 ┘
重解析后（炮灰 1 改解析到 PWA 2）：
炮灰域名 2（已起量）┐
炮灰域名 3（已起量）│
炮灰域名 4 ├── PWA 1
炮灰域名 5 ┘
炮灰域名 1（已起量）┐
炮灰域名 6 │
炮灰域名 7 │
炮灰域名 8 ├── PWA 2
炮灰域名 9 │
炮灰域名 10 ┘
效果：炮灰 1 已经投出的链接保持不变（旧链接入口稳定），但炮灰 1 注册的新会员会落到 PWA 2，分散风险。
❓ 待跟组长确认：起量的判定标准（每天注册数 / 充值额 / 投放消耗 等具体阈值）
3.2.9.6 APK 渠道差异化配比 + 炮灰跨媒体复用¶
APK 渠道（w2a / kwai 等）的特殊性：
- 用户安装的是 APK 不是 PWA
- PWA 爆红 / 屏蔽不影响已安装 APK 的用户
- 因此可以放宽炮灰-PWA 配比
APK 渠道配比：10 炮灰 ↔ 1 PWA（固定，比 PWA 渠道宽松）
炮灰域名 1（w2a）┐
炮灰域名 2（w2a）│
炮灰域名 3（w2a）│
炮灰域名 4（w2a）│
炮灰域名 5（w2a）├── PWA 1
炮灰域名 6（w2a）│
炮灰域名 7（w2a）│
炮灰域名 8（kwai）│
炮灰域名 9（kwai）│
炮灰域名 10（kwai）┘
炮灰跨媒体复用：
- 标记炮灰的目前只有 FB 媒体
- 炮灰被 FB 标记后不要直接弃用，换给 TT / Kwai 等其他媒体继续跑，减少浪费
⚠️ 复用风险提示：目前没发现新媒体也标记炮灰的案例，但不能 100% 保证未来不会出现。如发现某条炮灰在多个媒体被标记，要及时反馈组长。
3.2.9.7 关键约束（铁律）¶
这是绝对铁律——所有域名调整必须围绕这条约束设计：
⚠️ 渠道链接（炮灰链接 / 防封链接）一旦生成投放出去，链接后面的参数部分（utm_source / click_id 等归因参数）不能改变。
改参数会： - 破坏渠道归因链路 - 影响投放数据回传 - 让已起量的链接 ROI 数据断裂
因此所有"分散 / 重解析"操作只能改域名本身或解析跳转目标，不能动参数。
3.2.9.8 决策速查表¶
| 场景 | 处理动作 | 配比 / 关键 |
|---|---|---|
| 新渠道刚起步（PWA 渠道） | 默认配比 | 5 炮灰 ↔ 1 PWA |
| 长期合作大渠道 | 跨 PWA 各挑炮灰给该渠道 | 量分流到多条 PWA |
| 渠道在 FB 起量了 | 改炮灰的解析跳转到新 PWA（链接不动） | 新会员分流 |
| APK 渠道（w2a / kwai） | 放宽配比 | 10 炮灰 ↔ 1 PWA |
| 炮灰被 FB 标记 | 换新炮灰给 FB；旧炮灰转给 TT / Kwai | 减少浪费 |
| 任何调整 | 绝不改链接参数 | 只改域名本身或解析目标 |
📘 来源：经理工作笔记 + 学习讨论
3.3 配置类（11 项）¶
| # | 搭建内容 | Konten Pembangunan | 负责人 | 说明 |
|---|---|---|---|---|
| 10 | 极光推送开通、后台绑定 API | Aktifkan Jiguang push & ikat API di backend | Martin | JPush 推送通道 |
| 11 | 极光推送 PWA 配置 | Konfigurasi push Jiguang (JPush) untuk PWA | Martin | PWA 端推送 |
| 12 | 三方通道对接 | Integrasi saluran pihak ketiga | Martin | 代收代付渠道接入 |
| 13 | 支付通道金额及层级配置 | Konfigurasi nominal & level saluran pembayaran | HB | 不同层级用户的支付通道和限额 |
| 14 | 游戏排序开关 + 热门游戏图标 | Sakelar urutan game + ikon game populer | nuoya | 前台游戏展示顺序 |
| 15 | 客服线后台集成、自动化流程、客服接线配置 | Integrasi backend layanan pelanggan, alur otomatisasi, konfigurasi penerimaan CS | nuoya | Salesmartly 等客服系统 |
| 16 | 官网 iOS 马甲包 | Paket kamuflase iOS untuk situs resmi | Martin | iOS 端的安装包 |
| 17 | PDD 活动检查、PDD 手机号上传 | Pemeriksaan aktivitas PDD, unggah nomor ponsel PDD | Martin | 拼多多活动配置 |
| 18 | 智能 APK 模版配置 | Konfigurasi template APK cerdas | Martin | Android 端安装包模版 |
| 19 | 后台所有文案配置 | Konfigurasi semua teks/copy di backend | nuoya | 包括活动文案、提示文案等 |
| 20 | 开通新 Firebase | Aktifkan Firebase baru | yuhai | FCM 推送通道 |
| 21 | 站点配置里的平台站点名称、描述、icon、logo 上传 | Konfigurasi situs: nama, deskripsi, ikon, logo | nuoya | 平台基础信息 |
📘 来源：新站搭建准备工作表格
3.3.1 极光推送（JPush/EngageLab）注册与改价流程¶
📘 来源：组长工作笔记
极光推送是 PWA 端的消息推送通道，新站搭建时需要注册并完成改价。
第一步：注册账号
- 打开极光官网：https://www.engagelab.com/
- 使用邮箱 + 密码注册（⚠️ 不要直接用谷歌邮箱「一键注册」，必须用邮箱+密码的方式）
- 注册完成后登录
第二步：创建应用
- 登录后创建新应用
- 应用名称格式：一般为市场缩写 + 科技/公司
- 选择 消息服务 → WebPush → 创建应用
- 应用信息设置：
- 名称：站点主域名（例如
YYBB） - 服务器选择：新加坡
第三步：绑定后台
将极光生成的 应用 Key 填写到运营后台：
运营后台 → PWA 极光推广设置 → 填入应用 Key
第四步：联系极光商务改价
- 联系极光商务：Signal @winna8989
- 提供资料：
- 极光生成的应用 ID
- 极光生成的应用 Key
- 要求：极光推送改价
- 话术：告知是包网，马丁推荐，改价跟马丁套餐一致
- 等待商务完成改价
第五步：升级套餐
改价完毕后，在极光后台生成套餐并完成升级。
完整流程图：
注册 engagelab.com（邮箱+密码）
│
▼
创建应用 → 选 WebPush → 服务器选新加坡
│
▼
获得 应用 ID + 应用 Key
│
├──→ 填入运营后台「PWA 极光推广设置」
│
└──→ Signal @winna8989 发送 ID+Key
→ 要求改价（马丁推荐套餐）
│
▼
等待改价完成 → 生成套餐升级
3.3.2 支付通道金额及层级配置（编辑第三方充值信息）¶
📘 来源：组长工作笔记 + 平台后台截图
操作路径：后台 → 财务管理 → 三方充值配置 → 选择某个代收渠道 → 点击「编辑」
功能定位：每个第三方代收渠道的支付方式都需要单独配置——决定哪些层级用户可见、最小/最大充值金额、费率、赠送规则、快捷金额档位。新站搭建时需要为每个支付方式（DANA / OVO / GoPay / QRIS / 银行卡 等）都做一遍。
编辑界面字段详解¶
| 字段 | 含义 | 填写规则 / 示例 |
|---|---|---|
| 第三方 | 三方支付商（下拉选择） | 如 CoverPay(Transfer) |
| 支付方式 | 该三方下的具体支付通道（下拉选择） | 如 DANA / OVO / GoPay / QRIS |
| 金流费率 | 三方收取的费率百分比 | 1.1 表示 1.1% / 1% 就填 1，没有就填 0 |
| 单笔手续费 | 每笔固定手续费（IDRK） | 0 表示无固定费 / 没有就填 0 |
| 金额范围 | 用户单笔充值的最小值 ~ 最大值（IDRK） | 如 10 - 10000（即 10K~10M IDR）单位 IDRK，1 IDRK = 1000 印尼盾 |
| 赠送比例 | 充值赠送百分比 | 0 表示不赠送 / 1% 就填 1，最大不能超过 20，不赠送就填 0 |
| 赠送码量倍数 | 赠送金额要求打码倍数 | 1 倍 / 最小 1 倍（防止白送钱） |
| 可见会员层级 | 哪些层级用户能看到这个支付方式 | 多选标签（详见下方层级说明） |
| 排序 | 前台展示顺序 | 数字越小越靠前（从小到大） |
| 备注 | 内部备注（不展示给用户） | 通常填支付方式名（如 DANA） |
| 状态 | 启用 / 停用 | 启用 = 用户可见、停用 = 隐藏 |
| 前台显示名称 | 用户在前台看到的标签 | 如 DANA / 10K = Rp10,000.00 / CP（多个标签可叠加） |
可见会员层级（核心权限隔离）¶
后台支持的会员层级标签：
| 层级标签 | 含义 | 操作要点 |
|---|---|---|
| 默认 | 默认层级（普通会员） | 通道按层级开关默认对此层级开放 |
| 30 日留存客户 | 注册满 30 天且有留存的会员 | — |
| 15 日留存客户 | 注册 15 ~ 30 天的留存会员 | — |
| 7 日留存客户 | 注册 7 ~ 15 天的留存会员 | — |
| 新用户 1 | 新注册第 1 个层级（细分） | — |
| 新用户 | 新注册用户 | — |
| 套利观察层 / BH | 被发现套利的会员——主要包括套利邀请奖励、拼多多奖励的会员 | 拉到此层后不允许自动出款，提现走人工审核（防止继续套利） |
| 二次验证 / Data | 触发风控的会员——修改登录密码、修改提款密码、或两者同时修改的会员 | 拉到此层后不允许自动出款，提现走人工审核（详见 01-副组长-工作指南 §5.2.3） |
配置策略建议：
❓ 待跟组长确认补充。
快捷金额列表¶
界面下方有「快捷金额列表」配置——用户在前台看到的预设充值档位。
| 字段 | 含义 | 示例 |
|---|---|---|
| 金额 | 后台金额数值（单位 IDRK） | 20 / 30 / 50 / 100 / 300 / 500 / 1000 / 5000 / 10000 |
| 前台显示名称 | 用户看到的金额标签 | 20K / 30K / 50K / ... / 10000K |
| 操作 | 删除该档 / 添加新档 | — |
典型档位配置：20 / 30 / 50 / 100 / 300 / 500 / 1000 / 5000 / 10000（9 档），覆盖小额到大额全场景。
📌 档位设计原则： - 小额引流（20~100）：给新用户低门槛尝试 - 中额主力（300~1000）：主流活跃用户的常用区间 - 大额 VIP（5000+）：留给高价值用户，注意不要超过该通道的「金额范围」上限 - 必须包含整数倍数（如 50 / 100 / 500），符合用户习惯
配置完成后的验证¶
保存配置
│
▼
前台测试（用对应层级的测试账号登录）
│
▼
① 该支付方式是否在该层级用户的充值页可见？
② 快捷金额档位是否正确显示？
③ 显示名称（如 "DANA / 10K = Rp10,000.00 / CP"）是否符合预期？
│
▼
发起一笔小额充值（如 20K）测试
│
▼
✅ 验证：充值成功 → 前台到账 → 后台「入款记录」可查
常见配置失误（重点排查）¶
| 失误类型 | 表现 | 后果 |
|---|---|---|
| 金额范围设错 | 最小值大于快捷金额最低档（如 范围 50-10000，快捷里有 20K） | 用户点 20K 报错"金额低于最小值" |
| 赠送比例填错 | 把 5% 填成 5（实际是 5%）/ 把 1% 填成 0.01（实际无赠送） | 要么平台亏死，要么用户拿不到优惠 |
| 赠送码量倍数填 0 | 用户领奖金不需要打码 | 白送钱——用户领完直接提现，平台损失 |
| 层级全选错误 | BH / Data 层也开了大额通道 | 风险用户可能利用大额通道做套利 |
| 状态未启用 | 配置完忘记开启用 | 用户在前台完全看不到这个通道 |
📝 来源：组长工作笔记 + 后台界面分析
3.3.3 Firebase APK 推送配置完整流程¶
📘 来源：Noah 整理（FIREBASE APK 推送.docx，含 23 张实际后台截图）
3.3.3.1 功能定位¶
Firebase APK 推送属于安卓客户下载应用程序后的消息提示功能——用户安装了我们的 APK 应用后，平台可以通过 Firebase 控制台向所有已安装用户主动下发推送消息（标题、文案、图片、跳转链接），消息将显示在手机顶部通知栏。
这是配置完成后客户手机上看到的推送消息样式（显示在手机顶部通知栏）。
3.3.3.2 第一步：注册 / 登录 Firebase¶
- 控制台地址：https://console.firebase.google.com/u/0/
- 在 Google 浏览器已经登录邮箱的情况下不需要重新注册，直接打开上述链接即可。
- 如果尚未登录 Google 账号，需先注册或登录一个 Google 账号（任何 gmail.com 邮箱即可）。
3.3.3.3 第二步：创建项目¶
进入 Firebase 控制台后，选择"创建项目"。
按页面引导依次完成以下配置：
| 步骤 | 操作 |
|---|---|
| 1 | 输入项目名称——这里的名称就是该 Firebase 项目的名称（建议用平台站点的标识，便于后续多平台区分） |
| 2 | 勾选 ✅ 条款，点击"继续" |
| 3 | 再点击"继续" |
| 4 | 再点击"继续" |
| 5 | 选择推送国家（例如美国市场就选"美国"） |
| 6 | 勾选 ✅ 条款 |
| 7 | 等待配置完成 |
3.3.3.4 第三步：注册安卓应用¶
项目创建完成后，在新窗口中找到 ➕ 按钮并点击，选择安卓图标进入注册应用流程。
需要填写的信息：
| 字段 | 说明 |
|---|---|
| 安卓包名 | 该包名将会用于智能封装 APK 配置 + 投流——务必记录保存，后续封装/投流环节会用到 |
| 应用别名 | 输入目前要推送的站点名称——此名称将作为客户下载应用后看到的应用名（例如显示在手机桌面图标下方的文字） |
填写完毕后点击"注册应用"，按页面引导下一步。
⚠️ JSON 配置文件备份：注册过程中下载的 google-services.json 配置文件需妥善保管，APK 智能封装时必须使用。
3.3.3.5 第四步：进入推送控制台（Messaging）¶
回到 Firebase 项目主页：
- 进入左侧菜单 DevOps（构建/互动）
- 选择 Messaging（消息推送）
- 进入推送方式选择页面后，点击 "制作首个宣传活动"
- 选择 "Firebase 通知消息"，然后点击"创建"
3.3.3.6 第五步：配置通知消息（含图片链接）¶
在通知消息编辑页面，依次填写：
- 标题：推送显示的标题文案
- 正文：推送的详细文案内容
- 通知图片：需要先把图片上传到图床获取直链
图链接配置方式（使用 imghippo 图床）：
| 步骤 | 操作 |
|---|---|
| 1 | 打开 https://www.imghippo.com/，登录账号后点击选择图片上传 |
| 2 | 上传后点击 Direct Link，复制图链接 |
| 3 | 把复制好的链接返回 Firebase，在"通知图片"字段粘贴上去——粘贴后会显示图片预览 |
| 4 | 配置好后点击"下一步" |
3.3.3.7 第六步：选择应用与时间，发布¶
| 步骤 | 操作 |
|---|---|
| 1 | 选择应用（即第三步注册的安卓应用，对应站点的应用） |
| 2 | 选择时间（推送下发时间） |
| 3 | 直接点击"审核" |
| 4 | 核对好了之后点击"发布"——推送即下发成功 |
3.3.3.8 状态确认¶
发布完成后，活动状态显示 "投放中" 即表示推送已经成功下发，已安装 APK 的客户手机上将陆续收到该条通知。
操作要点速查¶
| 关键点 | 说明 |
|---|---|
| 谷歌邮箱 | 已登录即可，无需重复注册 |
| 推送国家 | 按客户所在市场选择（如印尼市场选印尼、美国市场选美国） |
| 安卓包名 | 必须备份——后续 APK 智能封装、投流都要用 |
| 应用别名 | = 客户下载应用后看到的图标名称 |
| google-services.json | 注册时下载，妥善保管，封装 APK 用 |
| 图片图床 | 使用 imghippo（拿 Direct Link 直链） |
| 状态判断 | "投放中" = 推送成功；其他状态需排查 |
📘 来源：Noah 整理 ·《FIREBASE APK 推送.docx》· 含 23 张实际操作截图全程演示
3.4 做图类（7 项）¶
所有图片的尺寸规格、大小限制、文案模板详见 12 · UI 展示图索引 & 活动推广文案库，做图前务必对照该文档确认规格。
| # | 搭建内容 | 负责人 | 尺寸/规格参考 | 说明 |
|---|---|---|---|---|
| 22 | ICON、LOGO 设计 | nuoya | ICON 196×196 ≤512KB / LOGO 240×60 ≤200KB | 提需求给设计团队，规格详见 §2.1 |
| 23 | 活动横幅上传 | nuoya | 656×176 ≤500KB | 规格+文案模板 §2.2 + §3.1~3.14 |
| 24 | 活动内页上传 | nuoya | 各活动尺寸不同（540×240 ~ 540×900） | 各活动内置横幅规格 §2.6 |
| 25 | Banner 图片上传 | nuoya | 大 656×220 / 小 336×100 / 个人中心 656×160 | Banner 全规格 §2.3 |
| 26 | 客服线图标、浮标上传 | nuoya | 1:1 圆图（不限大小） | 客服配置 §2.4 |
| 27 | 下载页/APK/弹窗/分享图/PWA 启动页 | nuoya | 启动页 736×1308 ≤2MB / 分享图 1280×670 / 弹窗 320×250 等 | 推广渠道素材 §2.7 + 分享 §2.5 |
| 28 | 导航页配置 | nuoya | 750×250（5 张轮番图） | §2.7 |
📘 来源：新站搭建准备工作表格 📘 来源：12-UI展示图索引（完整尺寸规格 + 活动推广文案双语模板）
3.5 账号类（4 项）¶
| # | 搭建内容 | Konten Pembangunan | 负责人 | 说明 |
|---|---|---|---|---|
| 29 | 客服组长后台配置、客服/远程客服后台配置 | Konfigurasi backend ketua tim CS, backend CS / CS jarak jauh | ❓ 待指定 | 客服团队账号 |
| 30 | 稽核出款后台配置 | Konfigurasi backend audit penarikan | ❓ 待指定 | 稽核团队+出款操作账号 |
| 31 | 自媒体频道创建、刷粉 | Buat kanal media mandiri, tambah followers | nuoya | Telegram/社媒渠道建设 |
| 32 | 客服线坐席配置 | Konfigurasi agen layanan pelanggan | nuoya | Salesmartly 坐席分配 |
📘 来源：新站搭建准备工作表格
3.6 测试类（4 项）¶
| # | 搭建内容 | Konten Pembangunan | 负责人 | 说明 |
|---|---|---|---|---|
| 33 | 游戏测试 | Pengujian game | nuoya | 确认游戏能正常打开和运行 |
| 34 | 真实存取款测试 | Uji deposit & penarikan nyata | yuhai | 测试完整的充值和提现流程 |
| 35 | 网址测试 | Uji URL/website | nuoya | 所有域名能正常访问 |
| 36 | 各个活动内容检查 | Pemeriksaan konten tiap aktivitas | nuoya | 每个活动的规则、图片、链接是否正确 |
📘 来源：新站搭建准备工作表格
3.7 搭建流程总览图（含并行关系）¶
以下是实际执行顺序，很多工作可以并行进行以缩短总周期。
═══════════════════════════════════════════════════════
新站搭建实际执行顺序（37 项）
═══════════════════════════════════════════════════════
管理层决定：购买主域名 + 确定模版 + 开后台
│
▼
域名确认后，以下三条线同时启动（并行）：
│
┌─────┼──────────────────────────────┐
│ │ │
▼ ▼ ▼
线路 A 线路 B 线路 C
域名+配置 做图素材 自媒体+账号
│ │ │
▼ ▼ ▼
通知SEO 通知美工 UI 团队 申请自媒体账号：
│ 准备所有素材 · Telegram 账号
▼ （ICON/LOGO/Banner/ · Facebook 账号
购买配套 活动横幅/内页/ · WhatsApp 账号
+炮灰域名 客服图标/下载页等） │
│ │ ▼
▼ │（等待素材期间） 创建频道/群组：
域名绑定 │ · Telegram 频道
（配套+PWA │ · WhatsApp 频道
+炮灰） │ │
│ │ ▼
▼ │ 配置 Telegram 机器人
DNS解析 │ （通过 MiniApp 配置，
+线路加速 │ 后续在 Salesmartly
│ │ 集成自动化流程）
▼ │ │
后台配置 │ ▼
（极光/三方 │ 后台录入自媒体账号
/支付/游戏 │ 到平台相应配置项
/Firebase │ │
/文案等） │ │
│ │ │
└─────┬─────┘ │
│ 素材到位后 │
▼ │
上传所有素材 │
（Banner/活动图/ │
客服图标/下载页等） │
│ │
└──────────┬───────────────────┘
│ 全部完成后
▼
═══════════════════════
测试阶段（4 项）
═══════════════════════
│
├─ 游戏测试
├─ 真实存取款测试
├─ 网址测试
└─ 各个活动内容检查
│
▼
新站上线 🚀
📝 来源：学习讨论
关键并行点：域名确认后，不需要等所有域名绑定完才开始其他工作。通知美工做素材、申请自媒体账号、创建 Telegram 频道和机器人这些都可以同步进行，充分利用等待时间。
Telegram 机器人 + Salesmartly 集成：机器人通过 MiniApp 配置好后，在 Salesmartly 客服管理平台中配置自动化流程。相关操作可参考 01-副组长-工作指南 · 4.12.2 Salesmartly 客服自动化流程配置。
3.8 搭建任务分工总览¶
以下分工数据来自 22-新站搭建准备工作表格，各表格中已标注具体负责人。
| 负责人 | 任务数 | P/S/O | 主要职责范围 |
|---|---|---|---|
| Martin | 8 项 | P | 域名采购（主域名+配套+炮灰）、通知 SEO、极光推送配置、三方通道对接、iOS 马甲包、PDD 活动、APK 模版 |
| HB | 5 项 | P | 域名绑定/解析（配套+PWA+炮灰）、线路加速、支付通道金额及层级配置 |
| nuoya | 16 项 | P | 游戏配置、全部素材制作与上传（ICON/LOGO/Banner/活动图/客服图标/下载页/导航页）、客服线配置、后台文案、站点配置、自媒体频道、测试（游戏+网址+活动检查） |
| yuhai | 2 项 | P | Firebase 开通、真实存取款测试 |
| ❓ 待指定 | 2 项 | P | 客服组长/远程客服后台配置、稽核出款后台配置 |
| 组长 | 全部 | S | 总体协调、节点检查、风险把关 |
| 副组长 | 部分 | S | 测试类、活动配置类支持 |
说明：P = Primary（主导）/ S = Support（支持）/ O = Outsource（外包）。当前所有任务均为内部 P 主导，未来可能将部分图片设计类外包（O）。
查缺补漏说明：
原始准备工作表格为 34 项，组长工作指南整理后为 37 项（因域名类拆分更细，增加了"通知 SEO 做排名"和"站点配置"等项）。两份文档的差异对照：
| 维度 | 原准备工作表格（22-新站搭建） | 组长工作指南（本文第三章） |
|---|---|---|
| 域名类 | 8 项 | 9 项（增加"通知 SEO"） |
| 配置类 | 11 项 | 11 项（一致） |
| 做图类 | 7 项 | 7 项（一致，补充了尺寸规格） |
| 账号类 | 4 项 | 4 项（一致） |
| 测试类 | 4 项 | 4 项（一致） |
| 负责人 | ✅ 有 | ✅ 已同步 |
| 原理说明 | 无 | ✅ 有（域名体系/DNS/CDN/防封架构等） |
| 并行流程图 | 无 | ✅ 有（3.7 节） |
📘 来源：22-新站搭建准备工作
四、活动效果监控与调整¶
4.1 新站活动监控¶
新站刚开始时设置的各类活动，需要持续监控效果，不能设完就不管了。
监控重点： - 各活动的参与率和领取率 - 活动对存提差比例的影响 - 用户留存效果 - 是否出现套利异常
4.2 周拉回效果测试¶
做周拉回等测试性活动时，需要： - 持续跟踪拉回效果数据 - 根据数据决定是否需要调整参数（如拉回金额、筛选条件等） - 效果不好要及时调整策略，不要持续投入无效的拉回方案
📝 来源：学习讨论
五、HQ 后勤中台系统（houqin · 个人尝试中）¶
我本人正在尝试开发一套后勤中台系统，希望统一管理排班、配餐、餐费扣款等后勤业务，未来可能扩展到考勤、办公用品、宿舍、班车等模块。本节介绍组长视角下可参考的内容。
5.1 项目定位¶
| 项 | 内容 |
|---|---|
| 项目代号 | houqin（后勤） |
| 代码仓库 | ~/Coding/HRsystem/ |
| 技术栈 | Go + Gin + PostgreSQL + Redis（后端）/ Vue 3 + TS + Naive UI（前端）/ Docker Compose 部署 |
| i18n | 中文为 base，支持 zh / en / id（印尼语）/ ru |
| 结算币 | 所有餐费、工资、账单以 USDT 为基准币（支持 CNY/AMD/IDR/RUB/USD 实时汇率换算） |
5.2 想解决什么问题¶
希望替代当前分散在多个 Excel + Signal / Telegram 群组的后勤管理方式：
- 客服排班分散在 WFH SHIFT.xlsx（15 个 Sheet）
- 质检和工资分散在 Inspector Chat-CR_质检.xlsx（24 个 Sheet）
- 个人档案在 远程个人信息_DATA WFH.xlsx（8 个 Sheet）
- 餐费靠人工统计 + Signal / Telegram 群组通知
📌 核心价值主张：把跨班信息流从 Excel + Signal / Telegram 群组搬到系统里，让员工、组长、HR、厨师各司其职零错漏。
5.3 首期范围（Phase 1）¶
| 模块 | 状态 | 说明 |
|---|---|---|
| 排班模块 | ✅ 已规划 | 白班 / 晚班 / 休假 / 调班，含调休/请假审批流 |
| 配餐模块 | ✅ 已规划 | 厨师管菜单 + 员工三选一（吃/不吃/打包）+ 转班联动 |
| Billing 模块 | ✅ 已规划 | 餐费定价 + 消费记录 + 月账单 + 工资扣款导出 |
| 平台核心 | ✅ 已规划 | Auth / RBAC / 组织 / 审计 / 事件总线 / 通知 / 多时区 / i18n |
| ❌ 办公用品申报 | Phase 2 | 已预留 schema 和事件通道 |
| ❌ 考勤打卡 | Phase 2 | 暂用云桌面 DAKA |
| ❌ 宿舍 / 班车 / 制服 | Phase 2/3 | — |
| ❌ 薪资 API 自动扣款 | Phase 2 | Phase 1 导出 Excel 人工对接 |
5.4 用户角色（与本指南管理体系对应）¶
| HQ 系统角色 | 对应本指南岗位 | 端 |
|---|---|---|
| 员工（Employee） | 远程客服 + 现场客服 + 副组长等执行岗 | Telegram Mini App（主）+ Web H5（辅） |
| 组长（Team Lead） | 本指南目标读者——管理 8-15 人班组 | Web 管理页 + Telegram Mini App |
| HR / 行政 | 人事部 + 行政岗 | Web 管理后台（PC 主） |
| 厨师（Cook） | 厨房工作人员 | 简化端（年纪偏大群体） |
5.5 组长在 HQ 系统中的核心动作¶
- 批量确认本组订餐——白天办公室坐着就能批量处理
- 临时调班——员工请假时代为调整班次
- 代改员工餐单——例如员工请假当天的餐单
- 查看本组排班和考勤汇总
5.6 开发进度¶
| 里程碑 | 时间 | 状态 |
|---|---|---|
| W0 | 设计完成（2026-04-22 ~ 2026-04-23） | ✅ |
| W1 | 基建 + Auth + RBAC + Org schema | 🔄 |
| W2 | Audit + Event Bus + 组织 CRUD | ⏳ |
| W3 | 餐饮模块 I | ⏳ |
| W4 | 餐饮 II + 排班 | ⏳ |
| W5 | Billing + FX + Web 前端 I | ⏳ |
| W6 | Web II + MiniApp | ⏳ |
| W7 | 通知 + 可观测 + 安全回归 | ⏳ |
| W8 | 灰度上线 | ⏳ |
5.7 项目内文档索引¶
详细产品规划、技术决策、开发计划见 ~/Coding/HRsystem/ 目录下的：
- README.md — 快速开始
- CLAUDE.md — 项目规范入口（开发必读）
- docs/10-prd.md — 产品需求 PRD（v1.2）
- docs/11-dev-plan.md — 开发计划
- docs/04-p0-fixes.md — P0 修复规范
- docs/adr/ — 架构决策记录（14 份 ADR）
📝 来源：houqin 项目 README + PRD v1.2
5.8 里程碑规划（待 HQ 团队确认）¶
| 阶段 | 状态 | MVP 功能 |
|---|---|---|
| 首期上线 | ❓ 待 HQ 团队确认上线时间 | 排班模块 / 质检模块 / 工资计算模块（核心三件套） |
| 二期 | ⏳ 计划中 | 培训进度跟踪 / 招聘流程线上化 / 离职单流程 |
| 三期 | ⏳ 待规划 | 数据看板（与 iConsole 联动）/ 跨部门工单 |
❓ 待 HQ 团队确认：具体上线时间、MVP 模块的 ETA、与现有 Google Sheet 工作流的过渡方案
六、待确认清单 ❓¶
| 编号 | 待确认事项 | 来源 |
|---|---|---|
| ~~1~~ | ~~组长管理的完整岗位列表（除副组长和客服管理外还有哪些？）~~ | ✅ 已在 §1.1 + §2.2 详细列出 |
| ~~2~~ | ~~新站搭建执行顺序和依赖关系~~ | ✅ 已在 3.7 节解决 |
| ~~3~~ | ~~新站搭建中组长亲自操作 vs 分配给下属的分工~~ | ✅ 已在 3.8 节整合负责人分工 |
| 4 | 活动效果监控的具体指标和数据来源 | 4.1 节 |
| 5 | 周拉回参数调整的决策标准（效果低于多少就调？） | 4.2 节 |
| 6 | 组长日常处理的"疑难 case"有哪些典型类型？ | 2.1 节 |
| ~~7~~ | ~~组长与经理之间的汇报和升级机制~~ | ✅ 已在 §2.2.2 维度二补充三级分类 |
| 8 | 指定游戏厂商测试的具体内容、频率、判定标准 | 2.7 节 |
| 9 | 模拟回调数据的更多场景和操作方式 | 2.7 节 |
| 10 | 集团运营报表的完整字段清单、公式设计、手续费合理范围 | 2.8 节 |
| 11 | 代收代付三方群下发确认的具体内容和流程 | 2.9 节 |
| ~~12~~ | ~~客服话术文档的存放位置、更新频率、审核流程~~ | ✅ 已整理到 10-客服中心 目录 |
| 13 | 目前使用的 Google Sheet 报表模板（需拿到后完善数据看板系统设计） | 2.8 节 |
| 14 | 新站搭建账号类中客服/稽核后台配置的负责人 | 3.5 节 |
附录 · 术语对照表¶
| 缩写 | 全称 | 含义 |
|---|---|---|
| STK | Shift Talk / 交接班文档 | 班次交接的标准文档 |
| WFH | Work From Home | 在家办公（指远程客服） |
| OTP | One-Time Password | 一次性验证码（指谷歌 Authenticator） |
| CRM | Customer Relationship Management | 客户关系管理后台 |
| CR | Cloud Remote Desktop | 云桌面（远程客服工作终端） |
| RTP | Return To Player | 玩家返还率（游戏指标） |
| VIP | Very Important Player | 高价值会员 |
| KPI | Key Performance Indicator | 关键绩效指标 |
| SOP | Standard Operating Procedure | 标准操作流程 |
| HQ | Headquarters / 后勤系统 | 用户自研后勤中台系统代号 |
| MVP | Minimum Viable Product | 最小可行产品 |
| PDD | Pinduoduo / 拼多多奖励 | 拼多多式邀请奖励活动 |
| PWA | Progressive Web App | 渐进式 Web 应用（防封域名层） |
| APK | Android Package | 安卓应用安装包 |
| DNS | Domain Name System | 域名解析系统 |
| CDN | Content Delivery Network | 内容分发网络 |
| SEO | Search Engine Optimization | 搜索引擎优化 |
| FCM | Firebase Cloud Messaging | 谷歌推送服务 |
📝 来源：组长工作指南全文术语提取 + 业务知识库背景
交叉引用¶
- 01-副组长-工作指南 — 组长管理的副组长岗位完整工作流程
- 06-稽核组长工作指南 — 组长管理的稽核团队工作流程
- 04-代理套利行为判定指南 — 套利审核的详细判定标准
- 22-新站搭建准备工作 — 原始搭建 Checklist 数据底稿（负责人分工来源）
- 09-域名类型功能 — 域名体系详解参考
- 12-UI展示图索引 — 素材尺寸规格与活动文案模板
- 10-客服中心 — 客服话术库 + 工作流程 SOP + 远程客服管理规范 + 远程客服管理专员工作指南
- 04-远程客服管理专员工作指南 · §18 后台权限隔离设计 — 远程客服 vs 现场管理岗的后台权限差异及安全逻辑