04 · 客服管理专员工作指南¶

适用对象：客服管理专员（现场，负责远程客服团队管理及存提款订单处理） 内容来源：远程客服管理 SOP.docx + 学习讨论 整理人：Bob ｜日期：2026-04-30 状态：初稿，持续补充中

目录¶

第一部分 · 核心业务与订单处理¶

一、岗位定位与团队架构¶

1.1 岗位定位¶

客服管理专员是组长直属的现场管理岗位，每班 2 人，主要负责远程客服团队的日常运营与订单异常处理。职责覆盖八大块工作：

存提款订单处理：充值未到账排查、提现卡单处理、Transaction ID 打码管理
通道异常监控：关注三方代收代付群通知，及时向客服线通报影响
会员 ID 查询：根据钱包/银行账号为客服反馈对应会员，协助找回账号
远程客服排班管理：维护 100 人排班、补班/缺勤、班次稳定
质检与绩效管理：质检统计、加扣分汇总、月度薪资核算、远程助理考评
新人培训协调：与远程助理协作完成新客服岗前培训
云桌面与安全运维：状态监控、谷歌 OTP 派发、Beeftext、账号风控排查
人员与行政管理：招聘面试、提拔评估、离职交接、自媒体发布、远程测试人员选拔

1.2 远程客服班次安排¶

所有时间为印尼雅加达时间（WIB, UTC+7）。

远程客服实行 24 小时全覆盖，分两种班次版本：

版本	白班	夜班	组数	人数
A 版	10:00 - 22:00	22:00 - 10:00	1 组	20 人
B 版	12:00 - 00:00	00:00 - 12:00	4 组	80 人

每组 20 人分白班和夜班（各约 10 人），确保 24 小时不间断服务。

为什么 B 版安排更多人：晚间 19:00-00:00 是用户活跃高峰，B 版白班（12:00-00:00）完整覆盖高峰时段，需要更多人手。

时间(WIB)  00  02  04  06  08  10  12  14  16  18  20  22  00
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A版(1组)   ░░░░░░░░░░░░░░░░░░░░██████████████████████████████░░
           ← A夜班 22:00-10:00 →← A白班 10:00-22:00      →

B版(4组)   ██████████████████████████░░░░░░░░░░░░░░░░░░░░░░████
           ← B夜班 00:00-12:00 →    ← B白班 12:00-00:00      →

           ████ = 白班    ░░░░ = 夜班

班次重叠时段（同时在线人数最多）： - 12:00-22:00：A 白班 + B 白班同时在线（重叠 10 小时） - 22:00-00:00：A 夜班 + B 白班同时在线（重叠 2 小时，交接缓冲） - 00:00-10:00：A 夜班 + B 夜班同时在线

1.3 远程助理职责概述¶

每位远程助理负责管理自己团队的 10 名远程客服（每组 2 位助理各管 10 人），主要职责： - 日常监督：检查团队成员工作质量、话术使用、SOP 执行情况 - 绩效排查：排查团队成员的响应时间、会话处理时长、接待量等数据 - 问题反馈：向客服管理专员反馈团队内的问题和异常情况 - 新人培训：负责新入职远程客服的培训工作（参见第九章） - 纪律管理：处理团队成员的突发缺勤、工作态度等问题

二、存款订单问题处理¶

2.1 处理流程¶

  会员发现存款未到账
        │
        ▼
  ┌─────────────────────────────────┐
  │ (1) 远程客服接待                 │
  │  · 按 SOP 要求会员提供存款证明   │
  │  · 截图需显示：交易金额、状态、  │
  │    时间、日期、参考号            │
  │  · 第一层验证：信息是否完整      │
  └──────────┬──────────────────────┘
             │ 验证通过，发到群里反馈
             ▼
  ┌─────────────────────────────────┐
  │ (2) 客服管理专员二次验证         │
  │  · 到后台找到这笔存款订单        │
  │  · 核对截图信息与后台记录：       │
  │    ① 交易时间是否一致            │
  │    ② 存款方式是否匹配            │
  │      (如后台显示 DANA 存款，     │
  │       截图必须也是 DANA)         │
  │    ③ 金额是否一致               │
  └──────────┬──────────────────────┘
             │
        ┌────┴────┐
        │         │
     匹配 ✅    不匹配 ❌
        │         │
        ▼         ▼
  ┌──────────┐  ┌──────────────────────┐
  │ (3) 提交 │  │ 反馈给远程客服        │
  │ 到三方群 │  │ 要求会员重新提供      │
  │ 查证     │  │ 正确的存款证明        │
  └────┬─────┘  └──────────────────────┘
       │
       ▼
  ┌─────────────────────────────────┐
  │ (4) 根据三方反馈结果处理         │
  │  · 三方确认到账 → 通知客服告知   │
  │    会员已处理                    │
  │  · 三方确认未收到 → 通知客服     │
  │    告知会员并协助解决             │
  └─────────────────────────────────┘

2.2 二次验证要点¶

2.2.1 信息核对（4 项全过 → 进三方群查证）¶

验证项	正常	异常
交易时间顺序	截图付款时间 ≥ 后台订单创建时间	顺序错（先付后提单）→ 拒
存款方式	截图渠道 = 后台渠道（如都是 DANA）	不一致 → 退回核实
金额	截图金额 = 后台订单金额	不符 → 退回核实
截图完整性	状态成功、有参考号	模糊 / 裁剪 / 缺失 → 退回核实

4 项全部通过 → 提交三方代收代付群查证（按 §2.1 步骤 3-4）。钱到没到以三方群回复为准。

⚠️ 顺序约束的核心逻辑：会员必须先在平台提交存款表单，系统才会生成付款码（QR Code）或转账目标账户。如果截图付款时间早于后台订单创建时间——说明会员是先付款再提交表单——那笔钱不会转到平台指定的收款账户。这个约束与时区无关，所有时区下都必须满足。

2.2.2 关于"时间差"——参考信息，非硬性判定¶

印尼有 3 个时区，凭证截图显示用户手机本地时间——WITA（巴厘 / 苏拉威西）比后台 WIB 快 1h，WIT（巴布亚）快 2h。单纯的"时间差大小"不能作为合规判断依据。

时间差仅作辅助参考：

时间差 = 截图时间 - 后台订单时间	推断
< 0 分钟（顺序错）	拒（与时区无关）
0 - 40 分钟	WIB 用户正常付款延迟
60 - 100 分钟	可能 WITA 用户（巴厘 / 苏拉威西）
120 - 160 分钟	可能 WIT 用户（巴布亚 / 马鲁古）

印尼省份 → 时区速查表¶

时区	UTC	主要省份 / 城市
WIB	+7	雅加达、西/中/东爪哇、班丹、苏门答腊全岛、加里曼丹西/中部
WITA	+8	巴厘岛、苏拉威西全岛、努沙登加拉、加里曼丹南/东部
WIT	+9	马鲁古、北马鲁古、巴布亚、西巴布亚

关键变化：原规则的"40 分钟硬性约束"已取消——跨时区下会误判巴厘 / 苏拉威西 / 巴布亚用户，且真实合规判定本来就靠三方群权威查证，不靠时间差。客服管理专员不需要识别用户时区，时间差只是看一眼参考。

📝 来源：用户跟岗反馈 + 跨时区调研（spec: docs/superpowers/specs/2026-05-06-deposit-timezone-rule.md）

三、提款订单问题处理¶

3.1 处理流程¶

  会员咨询提款问题
        │
        ▼
  ┌─────────────────────────────────┐
  │ (1) 远程客服接待并收集信息       │
  │  · 平台名称                     │
  │  · 会员 ID                      │
  │  · 提款单号                     │
  │  · 具体问题描述                  │
  │  → 发到群里反馈                  │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ (2) 客服管理专员后台查单         │
  │  · 到后台找到该提款订单          │
  │  · 查看订单状态                  │
  └──────────┬──────────────────────┘
             │
        ┌────┴──────────┐
        │               │
   出款成功 ✅      处理中/异常 ⚠️
        │               │
        ▼               ▼
  ┌──────────────┐  ┌──────────────────────┐
  │ (3a) 到三方群│  │ (3b) 根据后台状态    │
  │ 查询出款凭证 │  │ 反馈给远程客服       │
  │ (发单号给机器│  │ · 处理中 → 请等待    │
  │  人自动返回) │  │ · 失败 → 排查原因    │
  └──────┬───────┘  │ · 驳回 → 查看原因    │
         │          └──────────────────────┘
         ▼
  ┌─────────────────────────────────┐
  │ (4) 处理出款凭证                 │
  │  ⚠️ 必须打码 Transaction ID     │
  │  （不能让用户看到三方信息，      │
  │   避免用户投诉导致三方被牵连）   │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ (5) 把打码后的出款凭证           │
  │    反馈给远程客服                │
  │    告知会员已成功出款            │
  └─────────────────────────────────┘

3.2 Transaction ID 打码工具与方法¶

为什么要打码：出款凭证中的 Transaction ID（三方代付的交易流水号）一旦让用户看到，用户可能拿这个 ID 反查到具体的三方商户名，进而： - 直接联系三方投诉/索赔，绕过我方客服 - 在三方平台留下投诉记录，影响我方与三方的合作关系 - 利用三方信息进行其他诈骗行为

两种处理方式（任选其一）：

方法	工具	操作
方法 A：打码模糊	Snapaste 或类似截图工具	截取完整凭证 → 用马赛克/模糊功能涂掉 Transaction ID 行 → 保存图片发群里
方法 B：选择性截图	任意截图工具（系统自带也可）	截图时直接框选不包含 Transaction ID 的部分，只保留显示"交易成功 + 金额 + 时间"的关键信息

截图必须保留的关键信息： - ✅ 交易状态（Berhasil / Sukses / Success） - ✅ 出款金额 - ✅ 出款时间和日期 - ✅ 收款方账户后几位（让会员能识别是自己的账号） - ❌ Transaction ID / Reference Number（必须遮挡或裁剪） - ❌ 任何能反推三方商户身份的标识

⚠️ 核心原则：方法 B（选择性截图）比方法 A（打码模糊）更安全——直接不暴露的信息，比打码后的图片永远不会被恢复或穷举猜测。

📝 来源：学习讨论

3.3 特殊情况：会员绑定错误账号¶

场景：会员绑定了错误的 DANA 账号（如仅 1 位数字错误），但该错误账号恰好存在，且出款已成功到达该错误账号。

处理原则： - 三方已扣款且资金已出到错误账号 → 平台不承担责任 - 属于会员自身绑定错误导致 - 客服需向会员解释情况，并协助会员更正绑定为正确账号，避免后续再次出错

⚠️ 关键点：这种情况钱已经出了，无法追回。只能帮会员改正账号防止下次再错。

📝 来源：学习讨论

四、通道异常通知管理¶

4.1 监控渠道¶

客服管理专员需要持续关注以下群的通知： - 三方代收代付群——银行维护、通道波动、渠道异常 - 工作群——公司内部通知

4.2 通知处理流程¶

  三方群/工作群发布通知
  （如：BRI 银行维护，存款可能延迟到账）
        │
        ▼
  ┌─────────────────────────────────┐
  │ 客服管理专员判断影响范围          │
  │ · 影响哪些银行/钱包？            │
  │ · 影响存款还是提款？             │
  │ · 预计影响时间多长？             │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 及时在客服大群里发通知            │
  │ · 说明受影响的银行/钱包          │
  │ · 说明影响类型（存款延迟/提款暂停）│
  │ · 说明预计恢复时间（如有）        │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 远程客服收到通知后                │
  │ · 如有用户因此问题咨询            │
  │ · 可以及时准确告知原因            │
  │ · 提升沟通效率，减少升级          │
  └─────────────────────────────────┘

📝 来源：学习讨论

五、会员 ID 查询¶

会员 ID 查询有两种方法，优先用方法一（钱包/银行账号），方法一无法确定时再用方法二（IP 稽查）辅助。

5.1 方法一：通过绑定的钱包/银行账号查询（主要方法）¶

  远程客服要求会员提供信息
  （钱包/银行名称 + 账号）
        │
        ▼
  远程客服发到群里
  （平台名称 + 钱包/银行类型 + 账号）
        │
        ▼
  ┌─────────────────────────────────┐
  │ 客服管理专员后台查询              │
  │ · 后台 → 会员管理                │
  │   → 银行卡查询 / 钱包查询        │
  │ · 输入账号进行查询               │
  └──────────┬──────────────────────┘
             │
        ┌────┴────┐
        │         │
    命中 1 个   命中多个
        │         │
        ▼         ▼
  反馈 ID    见 5.3 多账号处理
  给客服

5.2 方法二：通过登录 IP 在 IP 稽查页面查询（辅助方法）¶

适用场景：会员无法提供绑定的银行卡/钱包信息，或方法一未能精确定位时。

⚠️ IP 可用性限制：并非所有聊天记录都包含 IP 地址。

来源渠道	IP 是否可见
网站直接访问（LiveChat）	✅ 可见
Telegram 发起的客服聊天	❌ 不可见
Messenger（Facebook）发起的客服聊天	❌ 不可见

如果会员是通过 Telegram 或 Messenger 联系客服，Salesmartly 后台的该聊天记录中不包含 IP 地址，此时无法使用方法二，需要直接询问会员的 ID 或使用方法一（钱包/银行卡查询）。

查询步骤：

  在客服后台（Salesmartly）
  找到该会员与客服的对话界面
        │
        ▼
  检查右侧客户信息面板是否显示 IP
  （Telegram/Messenger 来源无 IP）
        │
  ┌─────┴─────┐
  │           │
  有 IP      无 IP
  │           │
  ▼           ▼
  继续       改用方法一
  下一步     或直接问会员要 ID
        │
        ▼
  查看会员的登录 IP 和对应平台名称
        │
        ▼
  ┌─────────────────────────────────┐
  │ 进入游戏后台                     │
  │ · 会员管理 → IP 稽查页面         │
  │ · 输入会员登录 IP 进行查询        │
  └──────────┬──────────────────────┘
             │
        ┌────┴────────────┐
        │                 │
    命中 1 个         命中多个 ⚠️
        │                 │
        ▼                 ▼
  反馈 ID            见下方"IP 多结果处理"
  给客服

IP 稽查页面详解（参考 13-02 · IP 稽查使用说明）：

后台路径：后台 → 会员管理 → IP 稽查
搜索方式：单一 IP 输入框 + 「查询」按钮，输入待查 IP 后点击查询
列表展示 9 列（按时间倒序）：

列	含义
登录时间	该 IP 上的登录时间戳（UTC+7）
会员 ID	蓝色可点击，跳转该会员档案——这是要反馈给客服的关键字段
登录 IP	本次登录的 IP
IP 归属地	如 `United States` / `Japan Osaka`
浏览器信息	如 `Chrome 141.0` / `Safari 18.1`
操作系统	如 `Mac 15.6`
设备类型	如 `desktop` / `mobile`
手机品牌	如 `Apple`
手机型号	（部分会为空）

IP 多结果处理：

同一 IP 搜出多个会员 ID 的情况十分常见（共用 WiFi、运营商动态 IP 等），此时：

切换回方法一：要求会员提供绑定的银行/钱包账号，用账号精确匹配排除其他 ID
结合设备指纹判断：观察登录设备（操作系统/浏览器/手机型号）是否一致——同设备多账号比同 IP 多账号更可疑
若仍无法唯一确认：将多个候选 ID 和情况一并反馈给组长，由组长决定下一步

⚠️ 同一 IP 下多个会员 ID = 高风险信号：除了帮会员找回 ID，还需同步评估是否存在一人多号的情况（详见 5.4）。

📌 印尼 IP 共享提醒：Telkomsel/Indosat/XL 等运营商部分 IP 段是共享 NAT，可能让多个真实用户共用一个公网 IP。只有当 IP + 设备 + 行为模式三重吻合时才应判定一人多号（参见 13-02 §五注意事项）。

5.3 特殊情况一：同一手机号绑定多个钱包类型¶

场景：用户同一个手机号注册了 DANA、OVO、GoPay 等不同类型的电子钱包，分别绑定到了不同的会员账号上。

系统规则：同一类型的相同账号只能绑定一个会员账号（如同一个 DANA 号只能绑一个会员）
但不同类型的钱包即使手机号相同，可以绑定到不同会员账号

处理方式： 1. 根据远程客服在群里提供的钱包类型（DANA/OVO/GoPay），判断对应哪个会员 ID 2. 反馈正确的 ID 给远程客服

⚠️ 多账号警示：同一手机号的不同钱包绑定到不同会员，高度疑似一人多号。系统规则禁止一个用户注册多个游戏账号。发现此类情况应标记并上报组长，由组长/稽核决定是否进一步处理。

5.4 特殊情况二：IP 稽查发现同一 IP 下多个会员¶

场景：通过 IP 稽查查出同一 IP 下有多个不同的会员账号。

判断思路：

可能原因	风险程度	处理方式
家庭/公司共用 WiFi，不同人注册	较低	配合方法一用账号排除，正常处理
同一设备不同时间换 IP（动态 IP）	较低	同上
同一人注册多个账号（一人多号）	⚠️ 高	标记并上报组长，由稽核决定处置

⚠️ 上报标准：如果同一 IP 下的多个会员 ID 存在以下情况，需立即上报组长： - 存款/提款行为高度相似（时间、金额、渠道相近） - 绑定的钱包/银行账号有重叠或关联 - 参与同一活动且均有领取记录 - 设备信息高度一致（同操作系统 + 同浏览器版本 + 同手机型号）

参见：04-代理套利行为判定指南 + 13-02 IP 稽查使用说明

判定建议（基于平台 IP 稽查文档）： 1. 仅"同 IP 多账号"——可能是共享 WiFi/NAT，不能单独定性 2. 仅"同设备多账号"——明显异常，可疑度高 3. IP + 设备 + 行为模式三重吻合——基本可定性为一人多号，立即上报

逐级上报流程：

  客服管理专员发现可疑（IP 稽查命中多账号 + 行为可疑）
        │
        ▼
  ┌─────────────────────────────────┐
  │ (1) 第一级：上报副组长            │
  │  · 提供：IP / 多个会员 ID /      │
  │    设备信息 / 可疑行为描述        │
  │  · 由副组长进一步核查             │
  └──────────┬──────────────────────┘
             │
        ┌────┴────┐
        │         │
     无问题     有问题
        │         │
        ▼         ▼
  关闭工单   ┌─────────────────────────────────┐
             │ (2) 第二级：副组长深入排查       │
             │  · 重点排查多账号套利特征         │
             │    （存款/打码/活动领取关联）     │
             │  · 评估问题严重程度               │
             └──────────┬──────────────────────┘
                        │
                  ┌─────┴─────┐
                  │           │
              一般情况     严重情况
                  │           │
                  ▼           ▼
            ┌──────────┐  ┌──────────────────┐
            │ 进入套利  │  │ (3) 第三级：通知 │
            │ 警告处理  │  │     组长         │
            │ 流程      │  │ · 由组长决定具体 │
            │（参见 04 │  │   处置方案        │
            │ 套利判定 │  │ · 如：账号冻结/   │
            │ 指南）   │  │   余额扣除/拉黑   │
            └──────────┘  └──────────────────┘

📌 关键原则：客服管理专员不直接做账号处置决定——发现可疑只负责采集信息+上报，处置由副组长（一般情况）或组长（严重情况）决定。这与 §十二后台权限隔离设计的"刹车不给油门"原则一致。

📝 来源：学习讨论 + 13-02 IP 稽查使用说明 + 04-代理套利行为判定指南

六、自媒体内容发布¶

6.1 职责说明¶

客服管理专员负责按运营计划，在指定渠道定时发布自媒体图文内容：

内容类型	说明
兑换码定时帖子	按计划时间发布带有兑换码的图文，让会员可即时领取
活动推广内容	配合平台活动节奏发布相关宣传图文
其他运营通知	平台规则更新、维护通知等需要对外发布的内容

6.2 操作要点¶

要点	说明
发布渠道	Facebook、Telegram、WhatsApp 群/频道等社交媒体平台
发布时间	印尼时间（WIB）19:00 和 00:00，每天 2 次定时发布
图片素材	由 UI 美工组根据需求制作。例如：副组长设置好兑换码后，交给 UI 组根据兑换码创建推广图片
文案内容	一般由副组长准备好文案，发布人员在此基础上复制并做适当的 emoji 优化，尽量让每次发布有变化和新鲜感
多平台区分	管理多个平台时，发布前必须确认渠道与平台名称对应，避免内容发错平台
发布确认	发布后确认内容正常显示，如有异常立即通知组长

素材协作流程：

副组长设置兑换码/活动参数
        │
        ▼
副组长准备文案 + 通知 UI 组
        │
        ├──→ UI 美工组根据兑换码制作推广图片
        │
        └──→ 文案发给客服管理专员
                    │
                    ▼
客服管理专员：
  · 复制文案
  · 适当优化（加 emoji、调整措辞）
  · 在 19:00 和 00:00 定时发布到各渠道

📘 来源：远程客服管理 SOP.docx（能力要求第 6 项）+ 学习讨论确认

第二部分 · 远程团队日常管理¶

七、远程客服排班管理¶

7.1 排班职责¶

客服管理专员负责所有远程客服（100 人）的排班安排： - 制定排班表，确保每个班次有足够人员 - 处理调休/请假申请——根据排班表情况决定是否批准，批准后反馈给组长 - 处理突发缺勤——如员工断电、紧急情况等

7.2 排班工具与表格格式（当前现状）¶

当前工具：Google Sheet 文件 WFH SHIFT(远程排班表）.xlsx（共 15 个 Sheet）

核心表格结构：

Sheet	用途
AST SPV	主管月度排班表（37 列）
SHIFT CR1 ~ CR7	7 个班次组各自的员工排班（每张 42 列）
KPI（绩效）	绩效评分标准与扣分规则
Teks CS（话术）	客服话术库（已迁移到 01-客服话术库）
WFH（远程注意事项）	远程客服规范（已迁移到 03-远程客服管理规范）

SHIFT CR* 表的核心字段： - Jam Kerja（班次类型）：PAGI（早班）/ SHIFT（中班）/ MALAM（晚班） - 工作时间列（如 10:00-22:00）：明确每个班次的工作时段 - 日期列（每月 1-31 号）：日排班状态（早 / 中 / 晚 / OFF / IZIN 请假 / Libur Tahunan 年假） - 员工名称列：标识每个班次组的成员

⚠️ 时间口径：所有时间为印尼雅加达时间（WIB, UTC+7），表头会标注 Jam kerja sesuai dengan waktu lokal atau Waktu Indonesia Barat。

7.3 缺勤与补班规则¶

  远程助理反馈：某员工突发情况无法上班
  （如：断电、家庭紧急事务等）
        │
        ▼
  ┌─────────────────────────────────┐
  │ 客服管理专员处理                  │
  │ · 记录缺勤原因                   │
  │ · 统计缺岗时长                   │
  │ · 协调当班人员补位               │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 后续排班补回                     │
  │ · 缺岗时间必须通过加班方式补回   │
  │ · 在后续排班中安排补班           │
  └─────────────────────────────────┘

7.4 当前 Google Sheet 工具的问题¶

#	问题	影响
1	数据隔离缺失	排班表 + 质检表 + 个人档案分散在 3 个 Excel，员工信息冗余且需要手动联动
2	手动同步成本高	排班变更后，需要手动更新质检和工资表，容易遗漏
3	无自动化校验	不会自动检查"班次重复/排班冲突/同一员工被排两个班"
4	无趋势分析	月度数据沉淀但无可视化看板（趋势/对比）
5	薪资 Sheet 与质检 Sheet 跨文件	工资计算虽然有 Excel 公式（INSPECTOR APRIL Sheet），但与排班/个人档案分散在不同文件，每月需要手动跨文件搬运数据

7.5 HQ 后勤中台系统（houqin · 个人尝试中）¶

我本人正在尝试开发houqin（后勤中台）项目，希望统一替代当前分散在 Google Sheet 中的排班/质检/工资管理。

预期整合的模块（首期 Phase 1）： - 排班管理（白/晚/休/调班） - 配餐 + Billing（餐费定价 + 消费记录 + 工资扣款导出） - 平台核心：Auth / RBAC / 组织 / 审计 / 多时区 / i18n（中/英/印尼/俄） - 货币结算：所有餐费/工资/账单以 USDT 为基准币

6.5.1 客服管理专员视角的开发需求清单（已记录）¶

跟岗学习中累积的功能需求，待交付给 houqin 开发团队：

来源章节	需求	优先级
§11.1.4	一键筛选当前空闲云桌面账号（避免人工逐个查询）	P1
§15.5	一键离职申请受理（员工自助提交 → 自动通知专员）	P0
§15.5	离职单模板嵌入（"离职单-远程岗位（合同制）"模板内嵌系统）	P0
§15.5	强密码自动生成（云桌面/Salesmartly 改密时）	P1
§15.5	共用账号自动识别（系统列出该账号的同账号在职员工）	P1
§15.5	多渠道密码下发（按账号类型自动选择 Signal 渠道：私人/工作）	P1
§15.5	自动群通知（受理后自动在工作群发布离职通知）	P0

📌 详细产品规划和开发进度参见组长工作指南 → 11-组长-工作指南 · HQ 后勤中台系统。本文档只保留客服管理专员相关的使用接口，避免跨文档信息重复。

📝 来源：学习讨论 + A 组远程客服 Google Sheet 文件分析 + houqin 项目文档 + 跟岗学习

八、质检与绩效管理¶

8.1 质检工具与指标¶

通过 Salesmartly 客服管理后台进行质检（详细使用方法参见 06-Salesmartly 后台使用指南），主要关注以下指标：

指标	说明
首次响应时间	用户发起会话后，客服第一次回复的时间
平均会话处理时长	从会话开始到 session 结束的平均时间
当日接待量	当天总共接待了多少用户
话术规范度	是否使用标准话术回复（参见 01-客服话术库）
SOP 执行情况	是否按照标准流程处理问题（参见 02-远程客服工作流程 SOP）
服务态度	接待会员时态度是否得体
会员好评/差评	会话结束后会员的评价反馈

8.2 绩效评分流程与公式¶

评分维度（满分 100 分）——基于 Inspector Chat-CR_质检.xlsx 真实表格分析：

#	评分项	满分	计算方式
1	质检得分	20	每错扣 3 分（错误处理）/ 每错扣 2 分（缩写、语法）/ 起评 20 分
2	工作问题	5	工作态度问题每错扣 5 分（懈怠、冷漠、推诿、不礼貌）
3	接线量得分	10	基于接线量估分公式（接线量越多分越高）
4	首次响应时长得分	30	响应越快分越高（权重最大）
5	平均响应时长得分	30	整段会话的平均响应时长
6	会员好评加减分	±10	好评率挂钩
7	差评减分	负值	直接扣分
总分	100+	—	= 上述各项之和

评级体系（基于历史数据反推 + 实际备注用语）：

评级	含义	印尼语备注	推断分数区间
Cukup Bagus	卓越（优秀）	Cukup Bagus	≥ 72.5 分
Cukup	良好（合格）	Cukup	62.5 ~ 72.5 分
Semangat	标准（一般，仍需努力）	Semangat	12 ~ 44 分
No KPI	不合格 / 离职	No KPI	< 0 分

⚠️ 样本说明：上表分数区间基于 8 个历史样本的反推统计，置信度中等。S/A/B/C/D/E 标准评级（备注 Sheet 中提到）的精确分数区间仍需更多月度数据确认。

📊 质检异常负分逻辑： - 正常区间：质检得分 0 ~ 20（满分 20） - 轻微违规：-10 ~ 0（如多次小错累加） - 重大违规：≤ -90 分——典型场景：员工当月离职/严重违规会被一次性扣 ~92 分（实际样本印证）

📊 接线量估分公式（线性回归 R²=0.989，高置信度）：
接线量得分 = 接线量 × 0.004456 - 9.67
- 零点：接线量约 2171 通（不扣分也不加分） - 负分：低于 2171 → 线性扣分（如 1759 通对应 -2.88 分） - 下限：-10 分（接线量极少或为 0 的员工） - 满分 10：接线量约 4400+ 通时达到

⚠️ 缩写词禁忌（质检扣分项）： - 禁用 yg（yang）、tdk（tidak）、kmi（kami）等口语缩写 - 避免冗用"我们"，要用更得体的表达

评分流程：

  ┌─────────────────────────────────┐
  │ 远程助理（×10，每组 2 人）        │
  │ · 每人排查自己管辖的 10 人        │
  │ · 检查话术使用、SOP 执行、态度    │
  │ · 记录具体问题和表现              │
  │ → 反馈给客服管理专员              │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 客服管理专员                      │
  │ · 汇总 10 位助理的反馈            │
  │ · 结合 Salesmartly 数据指标       │
  │ · 套用 7 项评分公式 → 计算总分    │
  │ · 评定 S/A/B/C/D/E 等级          │
  │ · 填报组长提供的工资绩效表        │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 月末汇总                         │
  │ · 出勤天数 × 日薪 = 基础工资     │
  │ · 总分 → 应得绩效奖金            │
  │ · 总薪资 → 通过 Wallet 地址发放  │
  └─────────────────────────────────┘

8.3 工资绩效表的格式（基于真实表格）¶

当前使用的工资绩效表：Inspector Chat-CR_质检.xlsx（24 个 Sheet）

核心字段（17 项）：

序号	字段名	用途
1	员工名	与排班表/个人档案联动
2	班次	早 / 中 / 晚
3	质检得分（20 分）	见 §8.2
4	工作问题（5 分）	工作态度评分
5	会员好评	好评率（如 5.26%）
6	好评加减分（10 分）	好评率换算分数
7	差评减分	负向扣分
8	接线量	当月接线总数
9	接线量估分	接线量换算公式
10	接线量得分（10 分）	上限 10
11	首次响应时长得分（30 分）	权重最高
12	平均响应时长得分（30 分）	同等权重
13	总分	各项之和
14	应得绩效	与总分挂钩的奖金
15	出勤天	当月出勤天数（薪资基数）
16	评估	S/A/B/C/D/E
17	备注	特殊说明

Sheet 组织： - 按班次分离：CR 01、CR 02... 每个班次组独立 Sheet - 配对显示：部分 Sheet 以"员工 A - 员工 B"配对呈现（反映班次搭档关系） - 月度迭代：按月生成新版本（如 APRIL）

❓ 待跟组长确认： - S/A/B/C/D/E 评级对应的具体分数区间和绩效奖金金额 - 接线量估分的精确公式（用户统计中部分员工出现 -2.88 等负值，是否正常） - 异常负分（如质检得分 -92）的计算逻辑（是否有特殊扣分项）

8.4 远程助理的绩效评估¶

客服管理专员需要评估下属 10 位远程助理的表现，评估维度：

维度	考察内容
响应及时性	反馈问题后是否能及时回复和处理
问题处理能力	下属客服出现问题时，助理能否及时沟通并敦促改正
团队管理效果	团队整体工作质量是否在提升
问题频率趋势	日常出现的问题频率是否逐步在减少
培训成效	新人培训后能否顺利独立上岗

8.5 三表联动：排班 → 质检 → 个人档案 → 工资¶

WFH SHIFT(排班表)
    │ 员工名 + 出勤天数
    ▼
Inspector Chat-CR_质检 (绩效评分表 + 工资计算表)
    │ 评估维度（Nilai Sheet）：质检/工作问题/响应时长 → 总分 → S/A/B/C/D/E
    │ 月度工资计算（INSPECTOR APRIL Sheet）：基础工资+实际上班+接线量比例 → Total Gaji
    ▼
远程个人信息_DATA WFH (个人档案)
    │ Wallet 地址 + 转正状态
    ▼
工资发放（USDT 转账到 Wallet 地址）

8.6 月度工资计算公式（基于真实 INSPECTOR APRIL Sheet）¶

工资计算 Sheet 的位置：Inspector Chat-CR_质检.xlsx → INSPECTOR / INSPECTOR APRIL Sheet（按月迭代）

完整字段清单（中印对照，共 32 列）：

列名（印尼语）	中文	含义
Nama Kerja	小名	员工工作名
CS	客服昵称	LiveChat 显示名
Jam Kerja	上班时间	班次时段
Tanggal Kerja	入职时间	入职日期
Total	Total	月度接线量汇总
1 ~ 30	每日列	每日接线量（30 天数据）
GAJI POKOK	基础工资	固定底薪（USDT，如 360 / 400）
Total hari kerja	上班天数	当月应上班天数（如 29 天）
OFF	休假	周休天数
IZIN	请假	请假天数
Hari Kerja	实际上班	= 上班天数 - OFF - IZIN
GAJI	实际工资	= 基础工资 × (实际上班 / 上班天数)
LC	单量	LiveChat 接线量
Jumlah Chat	应当接线量	月度目标接线量（如 10150）
KPI	绩效最高	满分绩效奖金（USDT，如 320 / 340）
kerajinan	全勤	全勤奖（USDT）
KPI/Hari	每日绩效	= 绩效最高 / 上班天数
Total KPI	上班天数绩效	= 每日绩效 × 上班天数
Jumlah Chat(%)	接线量比例	= 实际单量 / 应当接线量
KPI STAFF	应得绩效	= 上班天数绩效 × 接线量比例
Extra KPI	绩效得分	额外加分项
Potong KPI	应得工资	绩效扣分项（如某 case 扣 20）
Total KPI	绩效总分	= 应得绩效 + Extra KPI - Potong KPI
Total Gaji	应得工资 / 总工资	= 实际工资 + 绩效总分
Remark	备注	特殊说明

核心计算公式：

实际上班 = 上班天数 - 休假 - 请假
实际工资 = 基础工资 × (实际上班 / 上班天数)

每日绩效 = 绩效最高 / 上班天数
上班天数绩效 = 每日绩效 × 上班天数  ≈ 绩效最高
接线量比例 = 实际单量 / 应当接线量
应得绩效 = 上班天数绩效 × 接线量比例

绩效总分 = 应得绩效 + Extra KPI - Potong KPI

【Total Gaji = 实际工资 + 绩效总分】 ← 最终月度工资（USDT）

真实样例（已脱敏）：

员工	基础工资	实际上班/上班	实际工资	绩效最高	接线量比例	应得绩效	扣分	Total Gaji
A	400	27/29	386.67	340	0.75	246.32	0	632.99
B	400	27/29	386.67	340	0.63	205.52	0	592.19
C	360	27/29	348.00	320	0.61	188.89	0	536.89
D	400	29/29	386.67	340	0.56	185.12	20	551.79

工资分布（126 人样本）： - 最低：0（全月请假/未入职等特殊情况） - 中位数：~543 USDT - 均值：~479 USDT - 最高：~657 USDT

✅ 工资计算自动化：薪资计算 Sheet 已存在并使用 Excel 公式自动计算，没有缺失环节。HQ 管理系统的目标不是"补缺失"，而是把分散在 3 个 Excel 中的排班/质检/工资数据整合到一个统一系统，避免手动同步、提供可视化看板、支持权限隔离。

📝 来源：学习讨论 + A 组远程客服 Google Sheet 文件分析（WFH SHIFT / Inspector Chat-CR_质检 INSPECTOR APRIL Sheet / 远程个人信息_DATA WFH）

九、新人培训管理¶

9.1 培训流程¶

  新远程客服入职
        │
        ▼
  ┌─────────────────────────────────┐
  │ 客服管理专员指派给对应的远程助理  │
  │ 由远程助理负责一对一培训          │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 远程助理进行培训                  │
  │ · 话术学习 → 01-客服话术库       │
  │ · 工作流程 → 02-远程客服工作流程 SOP  │
  │ · WFH 规范 → 03-远程客服管理规范  │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 远程助理反馈培训进度              │
  │ · 可独立当班 → 调整排班表        │
  │ · 需继续培训 → 延长培训期        │
  │ · 不适合岗位 → 反馈给客服管理专员    │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 客服管理专员根据反馈做调整        │
  │ · 可独立 → 正式排班              │
  │ · 需延长 → 安排更多培训时间      │
  │ · 不适合 → 考虑换岗或终止        │
  │ · 如需要可安排其他助理再次培训    │
  └─────────────────────────────────┘

9.2 培训材料索引¶

文档	用途
01-客服话术库	学习标准回复话术，掌握各场景用语
02-远程客服工作流程 SOP	学习充值/提现/账户操作的完整决策树
03-远程客服管理规范	学习 WFH 每日 10 步流程 + 15 条规范 + FAQ

📝 来源：学习讨论

十、远程测试人员管理¶

底层逻辑：远程测试人员从远程客服中选拔而来，由客服管理专员管理，承担域名、充值、游戏三类测试工作，是平台风险监控的"前哨"。

10.1 选拔标准¶

来源：从在职远程客服中选拔。

硬件 / 资源要求：

项	要求
手机设备	同时拥有安卓手机 + iOS 苹果手机（双系统）
SIM 卡	同时拥有印尼三大网络运营商 SIM 卡（如 TK 等三家）
办公能力	熟练使用 Google 表格（用于结果汇报）
业务基础	必须先做过一段时间远程客服，了解平台业务

⚠️ 双系统手机 + 三运营商 SIM 卡是硬性门槛——测试需要覆盖不同设备和网络环境。

10.2 三类测试工作总览¶

测试类型	频率	工具	主要目标
域名测试	每小时 1 次	API 测试链接 + 三大运营商手机	检测平台域名可用性，被封早发现
充值测试	每 2 小时 1 次	测试账号 + 各平台充值页	检测三方代收支付方式可用性
游戏测试	按组长通知触发	安卓 / iOS 手机	验证特定游戏功能、UI 文案、性能

10.3 域名测试 SOP¶

域名分两类： - 主域名（业务域名）：⚠️ 最重要——一旦出现问题需要在测试群即时反馈 - 推广域名 / 炮灰域名：被封是预期行为，按流程更换

每小时测试流程：

  开始本小时测试
        │
        ▼
  ┌─────────────────────────────────────┐
  │ ① 用 TK 卡（运营商 1）批量测试        │
  │  · 在手机批量打开各平台 API 测试链接 │
  │    （每个平台一个 tab 同时测试）       │
  │  · 等待结果汇总                       │
  └────────────┬────────────────────────┘
               │
        ┌──────┴──────┐
        │             │
   全部绿色✅      有红色❌
        │             │
        ▼             ▼
   切换运营商     ┌─────────────────────────────┐
   2/3 重复       │ ② 单独打开问题域名测试        │
        │        │  · 第一次访问发现问题         │
        ▼        │  · 清浏览器缓存 / 用无痕模式  │
   汇总三大       │    再次测试，排除缓存干扰    │
   运营商结果     └────────────┬────────────────┘
                              │
                       ┌──────┴──────┐
                       │             │
                  访问恢复       仍无法访问
                       │             │
                       ▼             ▼
                  本次测试完    ┌─────────────────────┐
                                │ ③ 确认域名异常       │
                                │  · 更新 Google 表格 │
                                │  · 主域名 → 测试群   │
                                │    即时反馈          │
                                └─────────────────────┘
        │
        ▼
  切换运营商 2 → 重复①②③
        │
        ▼
  切换运营商 3 → 重复①②③
        │
        ▼
  汇总三大运营商测试结果到 Google 表格

测试效率优化要点：

优化点	做法	收益
批量并行	一个运营商 SIM 一次开多 tab，同时测多个平台	几十平台测试时间从串行 → 并行
缓存排除	第一次有问题先清缓存/无痕复测，避免误报	减少假阳性、避免无谓上报
三运营商必测	TK / IM3 / XL 等覆盖 → 区分"全网封" vs "单运营商封"	精准定位封禁源（运营商屏蔽 vs DNS 污染等）
主域名优先即时反馈	主域名异常 → 不等汇总直接发测试群	主域名是灾难级，每分钟用户流失

📌 关联文档：域名封禁的处置流程参见 11-组长-工作指南 · §3.2.4 域名封禁处理操作手册

10.4 充值测试 SOP¶

10.4.1 一次性准备工作（账号注册）¶

  测试人员入岗
        │
        ▼
  在每一个平台注册一个测试账号（一次性工作）
        │
        ▼
  把所有平台的测试账号信息发给客服管理专员
        │
        ▼
  ┌─────────────────────────────────┐
  │ 客服管理专员后台标注              │
  │  · 每个测试账号在后台标记为      │
  │    「远程测试转账账号」          │
  │  · 后续可在后台监督这些账号的    │
  │    测试活动                      │
  └─────────────────────────────────┘

10.4.2 每 2 小时巡检流程¶

  本轮巡检开始
        │
        ▼
  ┌─────────────────────────────────┐
  │ 进入每个平台（用对应平台的测试账号）│
  │        │                         │
  │        ▼                         │
  │ 进入充值页                       │
  │        │                         │
  │        ▼                         │
  │ 测试该平台所有三方代收的所有支付方式│
  │  · 点击进入每种支付方式（DANA/   │
  │    OVO/QRIS/银行卡/GoPay 等）    │
  │  · 检查是否正常出现：             │
  │    - 收款二维码 ✅                │
  │    - 银行收款账号 ✅              │
  │  · 异常表现：                    │
  │    - 报错                        │
  │    - 二维码不显示                │
  │    - 转圈加载失败                │
  └──────────┬──────────────────────┘
             │
             ▼
  把每个平台 × 每种支付方式的结果
  更新到 Google 表格中

⚠️ 重要：测试时不需要真实充值付款——只需测到"显示出收款二维码/账号"这一步即可，证明该支付方式后端正常。

📌 抽查验证机制：客服管理专员可以用测试人员的账号登录平台抽查——只要测试人员真的发起过充值测试动作（即便没付款），后台就应该有对应的存款订单记录。如果某个时段抽查发现测试账号没有存款订单记录，说明该测试人员没有按要求执行测试，可作为绩效扣分依据。

10.4.3 测试账号的监督机制¶

维度	说明
账号标注	后台标记为"远程测试转账账号"，与真实会员区分
行为监督	客服管理专员可在后台查看测试账号的活动（充值次数/失败次数等），监督测试人员是否按要求工作
登录抽查	用测试人员的账号登录平台，对照"应当存款订单数"抽查——每 2 小时一次巡检 × 平台数 × 支付方式数 = 应当存款订单数。少于该数 = 漏测
使用纪律	测试账号不允许用于真实充值或个人游戏

10.5 游戏测试 SOP¶

10.5.1 触发方式¶

按组长通知触发——例如：「请测试某平台某款新上线/异常的游戏」。

10.5.2 测试设备¶

按通知要求使用： - 安卓手机 → 测试安卓端的游戏体验 - iOS 苹果手机 → 测试 iOS 端的游戏体验

10.5.3 标准检查项¶

#	检查项	通过标准	异常表现
1	进入游戏成功率	能正常打开游戏，不报错	黑屏/白屏/闪退/无响应
2	延迟与卡顿	操作流畅、无明显延迟	响应慢、画面卡顿、动画掉帧
3	按钮交互	所有游戏按钮（下注/取消/确认等）均正常工作	按钮无响应、点击无效、误触发其他动作
4	界面语言	完全印尼语（无任何中文/英文残留）	局部按钮/弹窗/错误提示出现中英文
5	图标 / UI 元素	显示完整、无错位	图片加载失败、UI 元素错位
6	音效 / 动效	正常播放	音效缺失、动画异常

❓ 待补充：更细化的游戏测试检查项可参考 [11-平台手册/19-游戏管理]，待具体游戏文档化后补充。

10.5.4 反馈机制¶

  完成测试 → 整理结果（截图 + 文字描述）
        │
        ▼
  反馈到工作群 → @ 组长
        │
        ▼
  组长决定后续动作（联系游戏厂商/调整配置/暂停游戏等）

10.6 远程测试人员的考勤与监督¶

维度	说明
每小时域名测试	每个整点 ± 一定时间窗口必须完成上报
每 2 小时充值测试	双数小时上报，覆盖每天主要时段
测试账号活动追踪	通过后台标注 + 行为监控
质量考核	漏测/迟报/误报会影响绩效（可纳入 §八质检与绩效管理）

📝 来源：跟岗学习

第三部分 · 系统与工具运维¶

十一、云桌面管理¶

客服管理专员负责远程客服云桌面环境的日常运维，涵盖五类工作：员工状态监控、验证码派发、自助/技术重启、临时账号借用、Beeftext 快捷输入工具配置。

📌 自建 RDS 方案：若公司试点/切换至自建 Windows RDS 云桌面，技术架构与账号 SOP 见 02-技术体系/23-rds-cloud-desktop（含 VPB 供应商调研、部署 checklist、入离职 SOP）。

11.1 员工状态监控¶

11.1.1 在线状态巡检¶

通过云桌面管理端实时查看远程客服的在线情况：

检查项	正常状态	异常处理
是否按时上线	班次开始后员工均已登录	联系对应远程助理确认情况
是否存在异常离线	工作时间内保持在线	核查原因——是否报备、是否属实
工作活跃度	持续接线，无长时间无操作	提醒助理督促，必要时记录并上报

11.1.2 随机抽查云桌面（管理员视角核心动作）¶

这是云桌面管理员视角的核心动作，与员工自己使用云桌面（03 §7）的视角完全不同。

抽查方式：客服管理专员可以在管理端随机打开任意一台员工云桌面（CR01~CR50+），实时查看该员工的工作流。

抽查重点：

抽查维度	观察要点	异常处理
操作流程是否规范	是否按 02-远程客服工作流程 SOP 处理问题（如先查 ID、按 SOP 决策树走）	不规范 → 通知对应远程助理跟进培训
工作效率	单会话处理时长、并行接线数、空闲间隔	偏慢/偏快异常 → 沟通了解原因
话术使用	是否使用 01-客服话术库标准话术，是否乱用缩写（yg/tdk/kmi）	缩写或非标准话术 → 提醒+扣 KPI
后台操作	是否在权限范围内操作，是否有异常查询行为（如频繁查同一会员）	异常 → 立即上报组长（参见 §14.3 排查职责）
错误识别	给会员的回复是否有错（如 ID 输错后台、错误信息发送）	立即提醒员工纠正，避免影响升级

抽查节奏建议： - 高峰时段（19:00-00:00）每小时随机抽查 5-10 台 - 平峰时段每 2 小时抽查 3-5 台 - 重点关注新人（培训期）和近期质检低分员工

❓ 待确认：云桌面管理系统的具体平台名称和管理端操作界面，待跟组长确认补充。

11.1.3 自助重启 vs CR 技术群协助¶

两级重启机制：

  远程客服反馈云桌面有问题
        │
        ▼
  ┌─────────────────────────────────┐
  │ 第一级：客服管理专员后台自助重启 │
  │  · 在云桌面管理后台对该账号      │
  │    执行重启操作                  │
  └──────────┬──────────────────────┘
             │
        ┌────┴────┐
        │         │
     已恢复    仍有问题
        │         │
        ▼         ▼
   工作恢复   ┌─────────────────────────────────┐
              │ 第二级：CR 技术群反馈            │
              │  · 在 CR 技术群描述具体问题      │
              │  · 由云桌面运营商技术处理        │
              │  · 技术执行的是更深层的重启      │
              │    （推断：宿主机层/物理层）     │
              └─────────────────────────────────┘

为什么自助重启不一定能解决（推断）：

重启级别	操作主体	影响范围	能解决的问题
后台自助重启	客服管理专员	云桌面虚拟机操作系统层软重启	OS 卡顿、应用进程卡死、内存占用过高
CR 技术群重启	云桌面运营商技术	宿主机层/物理层重启 + 网络栈 + 驱动	虚拟机网络断连、宿主资源问题、驱动异常、虚拟磁盘错误等深层故障

⚠️ 上述技术差异属于推断——客服管理专员只需要知道"自助 → 解决不了 → 升级到 CR 技术群"的两级流程即可。具体技术实现 ❓ 待跟 CR 技术群确认。

CR 技术群反馈格式（建议）：

云桌面账号：[CR编号]
故障现象：[具体描述，如：黑屏、网络断、应用闪退、特定操作卡死等]
已尝试操作：[已自助重启 N 次仍无效]
紧急程度：[高峰时段 = 紧急 / 平峰时段 = 一般]

11.1.4 临时云桌面账号借用流程¶

场景：当某远程客服的云桌面出现故障，反馈给 CR 技术群后技术说需要时间处理，可以从当前班次中找一个没人使用的云桌面账号临时借给该客服使用，避免耽误工作。

  确认故障客服需要等待技术处理
        │
        ▼
  ┌─────────────────────────────────┐
  │ 查找当前班次中空闲的云桌面账号    │
  │  · 当前班次未排班的账号          │
  │  · 当前在班人员中暂未登录的账号   │
  │  · 排休/请假员工的账号           │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 把空闲账号信息发给故障客服        │
  │ （工作 Signal）                  │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 故障客服登录借用账号继续工作      │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 技术处理完原账号问题后            │
  │ 通知客服切换回自己的账号          │
  └─────────────────────────────────┘

📌 HQ 系统功能需求（已记录）：员工系统需要新增"一键筛选当前空闲云桌面账号"功能，避免人工逐个查询的繁琐。详见 §7.5 HQ 后勤中台系统。

📝 来源：跟岗学习

11.2 验证码（OTP）派发——谷歌验证码¶

远程客服登录平台后台时，需要在账号密码之外再输入一次性的谷歌验证码（Google Authenticator OTP）。这套验证码体系由客服管理专员统一保管——账号绑定的谷歌验证器（即 secret 种子）只装在客服管理专员手上的设备/管理后台，远程客服本人不掌握。

📌 底层逻辑：谷歌验证码 = 账号的"第二把钥匙"。把第二把钥匙锁在客服管理专员那里，是为了防止远程客服私自登录后台、避免账号被偷拿即可登入——员工每次登录都必须找客服管理专员要验证码，登录行为天然受控。

派发流程：

  员工：申请登录后台，找客服管理专员要谷歌验证码
        │
        ▼
  客服管理专员：在自己保管的谷歌验证器（App / 管理端）中
           查看该账号当前 6 位动态验证码
        │
        ▼
  客服管理专员：通过 Signal / Telegram 群组或私聊
           把验证码发给员工（注意：30 秒刷新一次，及时发出）
        │
        ▼
  员工：30 秒内输入验证码完成登录
        │
        ▼
  登录成功 → 派发完毕

操作要点：

项	要求
保管方	谷歌验证器 secret 由客服管理专员唯一持有，不允许告诉员工 secret 本身
派发渠道	Signal / Telegram 群组或私聊；不通过其他不安全渠道
时效	谷歌验证码每 30 秒自动刷新；发出后让员工立即输入，超时需重发
登录入口	仅平台后台账号登录使用；区别于云桌面登录（云桌面是另一套机制，参见 §11.1）
离职/换岗	员工离职或转岗时，客服管理专员需把对应账号的谷歌验证器重置（解绑旧 secret + 重新绑定新设备），防止前员工保留访问能力

📌 与平台后台双重防护的关系：参见本文 §15.5.3「平台后台为什么不改密码（双重安全保险）」——第一层 IP 限制只能通过云桌面登录、第二层就是这里的谷歌验证码由客服管理专员保管。两层缺一不可。

11.3 常见问题处理¶

问题类型	处理方式
员工登录失败	确认账号是否正确 → 协助转发验证码 → 仍无法解决则上报组长
云桌面断连	引导员工重新连接 → 超时未恢复则升级给组长处理
账号权限异常	记录问题并反馈给组长，等待权限修复
多人共用账号冲突	要求员工退出他人账号再重新登录自己的账号（参见 03-远程客服管理规范 §1.3）

📘 来源：远程客服管理 SOP.docx（能力要求第 8 项）

11.4 Beeftext 快捷输入工具配置与备份¶

底层逻辑：远程客服使用的云桌面都是 Windows 系统，配套的快捷输入工具是 Beeftext（开源免费工具）。Beeftext 让客服可以配置短代码 → 长文本的自动替换（例如输入 ;w1 自动展开为完整的欢迎语）。

11.4.1 上岗前的标准配置流程¶

  新员工入职 / 重装环境
        │
        ▼
  ┌─────────────────────────────────┐
  │ ① 安装 Beeftext                  │
  │  · 从 beeftext.org 下载安装包    │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ ② 根据话术库配置快捷输入         │
  │  · 参照 [01-客服话术库] 的编号   │
  │    （w1/t1/d1/wd1/gs1...）       │
  │  · 在 Beeftext 中创建对应的     │
  │    短代码 → 长文本规则           │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ ③ 导出 JSON 配置文件             │
  │  · Beeftext 主界面 → 导出        │
  │  · 保存为 `.json` 文件           │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ ④ 上传到团队共用 Google 云盘     │
  │  · 文件命名建议：              │
  │    `beeftext-[员工名]-[日期].json` │
  │  · 后续话术库更新需要同步更新    │
  └─────────────────────────────────┘

11.4.2 故障恢复流程（云桌面重装后快速复原）¶

  云桌面出现问题需要重装 / Beeftext 重装
        │
        ▼
  重新安装 Beeftext
        │
        ▼
  ┌─────────────────────────────────┐
  │ 从团队 Google 云盘下载该员工    │
  │ 的备份 JSON 配置文件            │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ Beeftext 主界面 → 导入           │
  │ 选择刚下载的 JSON                │
  └──────────┬──────────────────────┘
             │
             ▼
  ✅ 所有快捷输入立即恢复，节省重新配置时间

11.4.3 客服管理专员的管理职责¶

维度	职责
入职检查	新员工配置完成后，检查 JSON 是否已上传到团队云盘
话术更新同步	话术库有更新时，提醒在职员工更新 Beeftext 配置 + 重新导出备份
云盘维护	定期清理离职员工的备份文件
培训交付	在新人培训环节确保员工掌握 Beeftext 配置和导出操作

📌 关联文档：客服话术库（短代码源）参见 01-客服话术库

📝 来源：跟岗学习

11.5 Signal 账号注册管理¶

底层逻辑：团队内部沟通主力软件是 Signal。印尼本地远程客服注册 Signal 受 KYC 等限制不便利，所以由客服管理专员通过员工的云桌面代为注册，统一使用 hero-sms.com 平台提供的国际手机号接收验证码。

11.5.1 触发场景¶

场景	处理
新员工入职	首次为新员工注册 Signal 账号
老员工账号问题	重新注册（手机号失效 / 账号被封 / 设备切换无法恢复等）

11.5.2 操作流程（端到端）¶

⚠️ 操作环境分离原则：hero-sms.com 是敏感的管理凭据，只在管理员自己的电脑上登录——绝不能在员工的远程桌面（云桌面）上登录或操作 hero-sms.com，避免员工看到平台账号、余额、收件区等敏感信息。员工云桌面上只做"为该员工配置 Signal"这一步。

环境              操作

</div>

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

【管理员自己电脑】
[1] 打开 hero-sms.com，登录管理岗账号
    ├─ 检查余额
    ├─ 余额充足 → 选号 + 申请接收 Signal 验证码
    └─ 余额不足 → 反馈组长充值，等充值完再操作
        │
        ▼
[2] 复制选好的手机号；保留 hero-sms.com 收件区窗口待用
        │
        ▼
─────────────────────────────────────────────────
【员工远程桌面（云桌面 CR0X）】
[3] 登录员工的云桌面
        │
        ▼
[4] 在云桌面打开 Signal 应用，开始注册
    ├─ 接受 Terms & Privacy
    ├─ 输入步骤 [2] 的完整国际手机号
    │     - 必须含国家代码（如 +62 印尼 / +7 俄罗斯 / +1 美国）
    │     - 去掉前导 0
    │     - 国家代码以 hero-sms.com 选号时所属国家为准
    └─ 提交 Signal → SMS 验证码会发到 hero-sms.com（管理员自己电脑接收）
        │
        ▼
─────────────────────────────────────────────────
【管理员自己电脑】
[5] 在 hero-sms.com 收件区收到验证码 → 复制
    └─ 收不到 SMS 时：回员工云桌面 Signal 点 "Call me" 切语音验证
       （语音也回到 hero-sms 接听）
        │
        ▼
─────────────────────────────────────────────────
【员工远程桌面（云桌面 CR0X）】
[6] 切回云桌面 Signal，输入验证码完成注册
        │
        ▼
[7] 设置个人资料
    ├─ First Name（**必填**，可用工号或岗位标识，如 "CS-A12"）
    ├─ Last Name（可选）
    └─ 头像（可选）
        │
        ▼
[8] 设置 Signal PIN（**必设**）
    ├─ 4-20 位数字或字母数字
    ├─ 用于设备切换 / 账号恢复
    └─ ⚠️ PIN **记录在管理员自己电脑**的密码本/密码管理器，不要写在云桌面里
        │
        ▼
[9] 拉入对应工作群
    └─ 按员工岗位和市场需要拉群（不同市场涉及不同群组，按当时实际配置）
        │
        ▼
[10] 退出员工云桌面 + 通知员工 Signal 已就绪
        │
        ▼
─────────────────────────────────────────────────
【管理员自己电脑】
[11] 持续维护：定期检查 hero-sms.com 余额
     └─ 余额低 → 反馈组长充值

11.5.3 hero-sms.com 平台账号管理¶

项	内容
平台职责	提供国际手机号接收 Signal 验证码 + 周期性自动扣费续费手机号（保活）
账号使用权	客服管理专员直接登录使用，无需向上申请
登录环境	⚠️ 只在管理员自己的电脑登录 —— 绝不在员工云桌面登录 hero-sms.com（敏感凭据隔离）
充值	余额不足由客服管理专员反馈给组长，组长安排充值
手机号保活	平台自动扣费续费——余额不足会导致手机号失效 → 该员工 Signal 账号失联

11.5.4 注意事项¶

⚠️ 环境分离（最重要）：hero-sms.com 只在管理员自己电脑登录，员工云桌面只做 Signal 注册操作。两者之间只通过手机号 + 验证码这两条信息单向传递——不要在员工云桌面打开 hero-sms.com 页面、不要在云桌面登录 hero-sms.com 账号。
PIN 也只在管理员自己电脑保管：用密码管理器记录每位员工的 Signal PIN，不要在云桌面写到任何文件 / 备忘录里——员工本人也不应知道 PIN
手机号必须保活：hero-sms.com 自动按周期扣费续费手机号；如果余额耗尽，手机号失效 → 该员工 Signal 账号会失联（无法接收新设备验证、可能被踢出 Signal 网络）
不要把 hero-sms.com 注册的手机号当作员工真实手机号：这只是接收 Signal 验证码的虚拟号，不要用于其他业务流程
国家代码即号码所属国：Signal 看的是手机号的国家代码，与员工实际所在地无关——hero-sms.com 选什么国家的号，注册时就用什么国家代码

11.5.5 待跟组长确认 ❓¶

hero-sms.com 余额监控的频率（每天 / 每周 / 每月一次？）
余额告警阈值（剩余多少时反馈组长充值？）

📝 来源：用户跟岗反馈 + Signal 官方注册文档调研（Signal Support · Register a phone number / Signal PIN）

十二、后台权限隔离设计¶

底层逻辑：远程客服的物理工作环境不可控（家庭网络、无监控、可能有家人/室友旁观、设备可能私用），即便是相同的业务功能，远程岗也必须比现场岗"少一截"权限。这不是不信任，而是保护远程客服在发生资金事故时天然被排除嫌疑链。

12.1 权限差异总览¶

平台后台共有 4 大模块，远程客服与现场客服管理岗的权限对比如下：

模块	远程客服可见	客服管理专员可见	差异说明
会员管理（13-会员与风控）	✅ 14 个子页面	✅ 14 个子页面（同等）	同等权限，会员资料查询业务必需
财务管理（14-财务与支付）	⚠️ 3 个子页面	✅ 6 个子页面（多 3 个）	核心权限隔离——见 §12.2
活动记录（17-活动记录）	✅ 18 个子页面	✅ 18 个子页面（同等）	同等权限，活动咨询业务必需
营销工具（16-营销工具）	⚠️ 2 个子页面	✅ 3 个子页面（多 1 个）	兑换码生成权管控——见 §12.3

12.2 财务管理：6 个页面的权限切分（核心）¶

页面	远程客服	客服管理专员	核心功能	包含的敏感数据
02-三方待入款	✅	✅	三方电子钱包（DANA/OVO等）充值待确认订单	会员 ID、订单号、充值金额、第三方通道、支付方式、申请时间
04-入款记录	✅	✅	全量充值订单归档，30 分钟内可撤回误确认	含完整会员钱包账号/银行卡号（用户付款用的账号）、订单号、充值通道、推广通道、金额
07-提现锁定	✅	✅	提现订单第一道审核池，可锁定/取消锁定	会员 ID、订单号、提现类型（BANK/DANA）、提现金额、手续费、充值/提现次数、锁定人
03-银行卡待入款	❌	✅	印尼本地银行卡（BCA/BRI/BNI）充值待确认	会员转账银行卡号 + 平台收款卡号 + 附言订单号匹配信息
05-提现出款	❌	✅	锁定后订单的执行层，单笔代付出款/批量驳回	会员提现绑定的银行卡号/钱包账号、出款通道选择、驳回权
06-提现记录	❌	✅	全量提现归档 + "三方已出款"兜底确认	会员提现账号、手续费、流水费、第三方通道详细、操作人审计、驳回原因

12.3 营销工具：3 个页面的权限切分¶

页面	远程客服	客服管理专员	核心功能	敏感数据
04-站内信-全体用户	✅	✅	给所有会员发系统消息	低：仅文本内容
05-站内信-指定用户	✅	✅	给特定会员发系统消息（如卡单补偿通知）	低：仅文本内容
01-兑换码	❌	✅	生成可领取彩金的兑换码 + 配置打码倍数	极高：可凭空生成的奖金权

12.4 三个限制项的威胁建模¶

(1) 限制「提现出款 / 提现记录」¶

维度	内容
威胁路径	① 看到会员完整提现绑定账号 → 拿账号+订单号去三方群冒充会员套款（伪装会员申诉提现失败要求三方再付一次） ② 操作人字段+完整出款流水 → 内外勾结操控放款顺序 / 选择性拖延某些会员的提现 ③ 截图外发用于洗钱链路画像或客诉骗赔
阻断点	阻断"出款侧账号信息+操作权"——远程岗只剩「提现锁定」这个只能拦截、不能放行的单向操作，看不到具体出款账号
业务理由	放款决策权属于财务岗+客服管理岗，远程客服的工作只需要"发现可疑→锁定→升级"，不需要看放款明细和会员账号

(2) 限制「银行卡待入款」¶

维度	内容
威胁路径	① 该页面含会员转账银行卡号 + 平台收款卡号 + 附言订单号 → 拿订单号到三方群冒充财务伪造已付款凭证套款 ② 平台收款卡号外泄 → 黑产钓鱼伪装客服收款 ③ 卡号信息倒卖到撞库黑产做假充值/洗钱
阻断点	阻断"平台收单基础设施 + 用户银行卡号"信息暴露面。三方待入款只暴露三方网关回调结果，不暴露具体银行卡号字段
业务理由	银行卡入款多为大额 VIP 通道，由现场岗+财务岗专人核对凭证

(3) 限制「兑换码」⚠️ 风险最高¶

维度	内容
威胁路径	兑换码 = 可凭空生成的奖金权——给自己/家人/同伙账号生成兑换码 → 兑现真金白银 → 0 成本盗取平台资金
阻断点	彻底切断"远程岗 → 资金创造权"的链路。站内信只能传达消息，不能产生资金
业务理由	发福利属于营销岗+管理岗决策动作，需走审批留痕

12.5 远程客服为什么能保留 3 个财务页面¶

设计哲学：给远程岗"刹车"，不给"油门"——能拦截可疑提现，但不能放行任何资金。

页面	业务必要性	为什么安全
三方待入款	处理用户充值不到账客诉	数据是三方网关脱敏回执，无平台银行卡号
入款记录	核对历史充值争议	只读历史，无操作权，无放款决策面
提现锁定	发现风控嫌疑立即冻结	单向风控动作（拦截 > 放行），失误成本是延迟而非资金损失

12.6 与岗位职责的协同¶

由于权限隔离，很多业务环节远程客服必须在群里反馈，由现场岗位执行实际操作：

业务场景	远程客服可做	必须现场岗位执行
充值未到账排查	收集会员凭证、初步验证	客服管理专员到「03-银行卡待入款」/「05-提现出款」核查
提现卡单处理	收集会员信息、锁定可疑提现	客服管理专员在「05-提现出款」执行驳回 + 三方群查证
密码/PIN 重置	接收会员请求 + 群内反馈	副组长执行重置 + 拉入二次验证层级
银行卡/钱包变更	收集证明材料 + 群内反馈	现场会员资料更正岗执行变更
发兑换码彩金	群内反馈需求	客服管理专员/副组长生成兑换码

12.7 客服管理专员的延伸职责¶

权限隔离只是第一道防线，客服管理专员还需配合落实纵深防御：

防线	措施	责任人
操作审计	关注后台操作日志，定期抽查远程客服的查询/导出行为	客服管理专员
异常告警	单日查询会员数异常、连续打开同一会员资料、非工作时段操作 → 上报组长	客服管理专员
网络环境	远程客服必须用公司分配的云桌面（CR），禁止私人电脑	详见 §十一云桌面管理
截图防护	远程客服严禁截图后台内容外发（违规罚款 $50/次）	详见 §14.4 防范措施
会员数据脱敏	给会员的截图必须打码所有 PII（手机号/卡号/三方账号）	详见 03-岗前培训 §3.3

📚 培训要点：让远程客服理解"被限制不是不信任，而是保护你不背锅"——一旦发生资金事故，没有权限的人天然被排除嫌疑链。

📝 来源：学习讨论 + 平台手册 14-财务与支付 + 16-营销工具

十三、交接班文档（STK）核实¶

13.1 STK 文档说明¶

STK（Serah Terima Kerja，印尼语"工作交接"）是每个班次必须核实的交接文档，记录上一班的工作状态、通道异常、待跟进事项等关键信息。

远程客服每日上班第 4 步即为"查看 STK 文档并签名"（参见 03-远程客服管理规范 §1.4）。

13.2 客服管理专员核实职责¶

远程客服负责查看并签名，客服管理专员需要额外核实以下内容：

核实项	说明
内容完整性	上一班的通道异常通知、待处理订单、特殊事项是否均已记录
平台最新变动	活动调整、规则更新、通道上下线等是否已同步写入
客服签名状态	确认当班所有远程客服已阅读并完成签名确认
待跟进事项	上一班遗留的问题是否有明确的跟进人和处理方向

核实时机：每班次开始后尽早完成核实，发现漏填或异常事项立即联系上一班补充。

❓ 待确认：STK 文档的具体格式（文件/群消息/表单）、存档位置、签名方式，待跟组长确认补充。

📝 来源：学习讨论 + 03-远程客服管理规范 §1.4

第四部分 · 安全与人员管理¶

十四、客服安全风控——账号盗用排查¶

14.1 风险场景¶

远程客服拥有查看会员信息和协助修改密码的权限，存在以下安全风险：

盗用手法：个别客服利用帮会员重置登录密码或提款密码的机会，登录会员账号 → 将提款绑定的银行卡/钱包更换为自己的 → 发起提款 → 盗取会员资金。

14.2 已有防线（副组长侧）¶

副组长在密码重置流程中已设置「二次验证/Data 层级」安全机制： - 密码重置后，会员自动进入二次验证层级 - 该层级下提现不走自动出款，必须人工审核 - 副组长审核时会检查提现账号是否为旧资料（正常）还是新资料（可疑）

提现审核验证流程：

  会员发起提现
        │
        ▼
  ┌─────────────────────────────────┐
  │ 副组长核对提现信息                │
  │ · 提现账户的户名是否与会员注册    │
  │   信息一致？                     │
  │ · 提现账号是否与之前绑定的一致？  │
  └──────────┬──────────────────────┘
             │
        ┌────┴────┐
        │         │
   一致 ✅    不一致 ❌
        │         │
        ▼         ▼
   正常出款   ┌──────────────────────────┐
              │ (1) 先关闭提现权限         │
              │ (2) 直接进入视频验证       │
              │     （会员之前已提供截图，  │
              │      本步不重复要截图）    │
              └──────────┬───────────────┘
                         │
                         ▼
  ┌──────────────────────────────────────┐
  │ 视频验证（详见下方视频规格）            │
  │ · 必须用另一部手机录                   │
  │ · 必须露出手指真实操作画面             │
  │ · 严禁手机内录屏                       │
  │ · 视频中展示两个不同钱包 APP 的账户    │
  │ · 已用 2 部手机时必须用第 3 部录       │
  └──────────┬───────────────────────────┘
             │
       ┌─────┴─────┐
       ▼           ▼
   通过 ✅     不通过/拒 ❌
   → 正常出款   → 维持关提现
                → 上报组长

⚠️ 视频验证规格（硬性要求）： - 目的是防止截图 PS 造假——截图可以伪造，但实时拍摄的操作视频伪造门槛极高 - 必须用另一部手机录制——不是被验证的那台手机自己拍自己 - 必须露出手指操作手机的画面——能看到真实的人在真实地操作 - 严禁手机内录屏（screen recording）——内录屏可拼接 / 反复重做，无法证明实时性 - 视频中需同时展示两个不同电子钱包 APP 的账户信息页面，证明这些钱包确实属于同一个人 - 如果会员已经使用了 2 部手机（一部展示钱包 A，一部展示钱包 B），那么必须用第 3 部手机来录制视频 - 判定标准：视频画面流畅 + 手指真实操作 + 两个钱包都能看到 + 不是录屏 → 通过；任一项不满足 → 不通过

详见 → 01-副组长-工作指南 · 5.2.3 二次验证/Data 层级机制

14.3 客服管理专员的排查职责¶

副组长的二次验证是事后防线，客服管理专员需要在事前和事中进行排查：

  发现可疑信号（任一触发）
  · 会员投诉账号被盗/资金异常
  · 副组长驳回可疑提现后反馈
  · 质检发现某客服异常操作
        │
        ▼
  ┌─────────────────────────────────┐
  │ (1) 定位涉事客服                 │
  │  · 到 Salesmartly 后台查找       │
  │    该会员的会话记录               │
  │  · 确认是哪个客服处理的           │
  │    密码重置/资料变更请求          │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ (2) 排查聊天记录                 │
  │  · 客服是否按 SOP 执行密码重置   │
  │  · 是否要求了会员提供身份证明     │
  │  · 是否存在异常操作（如主动引导   │
  │    会员修改绑定信息）             │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ (3) 核查后台操作记录              │
  │  · 检查会员账号的资料变更时间线   │
  │  · 密码重置 → 绑定信息变更 →     │
  │    提现发起 的时间间隔是否异常短  │
  │  · 新绑定的钱包/银行卡是否与     │
  │    该客服或其他可疑账号关联       │
  └──────────┬──────────────────────┘
             │
        ┌────┴────┐
        │         │
     确认盗用    排除嫌疑
        │         │
        ▼         ▼
  ┌──────────┐  ┌──────────────┐
  │ (4a)     │  │ (4b)         │
  │ 上报组长 │  │ 记录排查结果 │
  │ 按规处理 │  │ 存档备查     │
  │ · 停职   │  └──────────────┘
  │ · 冻结   │
  │ · 追回   │
  └──────────┘

14.4 防范措施¶

防范层级	措施	负责人
制度层	培训时明确告知：擅自修改会员资料 = 罚款 $50/次，盗用账号 = 停职 + 追责	远程助理（培训）
流程层	所有密码重置必须经 leader 确认，远程客服无权独立执行	客服管理专员
技术层	密码重置后自动进入二次验证层级，提现需人工审核	副组长（审核）
监控层	定期抽查密码重置相关会话记录，排查异常模式	客服管理专员
追溯层	所有资料变更操作均有后台日志，可追溯到具体操作人和时间	组长

⚠️ 关键原则：远程客服只能收集会员提供的信息并反馈到群里，所有密码重置和资料变更的实际操作必须由现场有权限的人员（客服管理专员/副组长）执行。远程客服本身没有直接修改会员数据的权限。

📝 来源：学习讨论

十五、人员变动管理（招聘 / 内部提拔 / 离职）¶

15.1 招聘职责¶

客服管理专员承担远程客服团队的人员补充工作： - 外部招聘：根据团队当前缺口（离职/扩编），安排面试候选人 - 内部提拔：识别优秀的远程客服，推荐提拔为远程助理，支持梯队建设

15.2 外部面试流程¶

  识别招聘需求（团队缺员）
        │
        ▼
  获取候选人简历/联系方式
  （来源：组长转介/内部推荐）
        │
        ▼
  安排面试时间，进行面谈（按下方标准问题清单）
        │
        ▼
  评估候选人，综合打分
        │
        ▼
  合格 → 报告组长，安排入职培训（详见第九章）
  不合格 → 记录原因，继续招募

14.2.1 面试标准问题清单（Customer Service Interview / Screening Questions）¶

以下为远程客服面试的 10 道标准筛查问题，按顺序逐一提问：

#	问题	考察目的
1	Please introduce yourself.（请自我介绍）	表达能力、沟通流畅度
2	Where are you currently located?（目前在哪里？）	确认地理位置，评估网络环境
3	What is your current living situation? (own house / rented / dormitory)（住房情况：自有/租房/宿舍）	工作环境稳定性
	· How is your internet connection? Any stability issues?（网络状况如何？稳定吗？）	远程工作基础条件
	· What device do you use for work (laptop/PC)? What are the specifications?（工作设备和配置？）	设备是否满足要求
	· Typing test (please complete): https://10fastfingers.com/typing-test/indonesian（打字速度测试）	打字速度直接影响客服效率
	· Are you familiar with AutoText or keyboard shortcuts?（是否熟悉快捷输入？）	工作效率潜力
4	Does your area experience frequent power outages?（你的地区经常停电吗？）	远程工作连续性风险
5	What is your work experience? Have you worked as a Customer Service (CS) before?（工作经验？是否做过客服？）	经验匹配度
6	Please explain your understanding of the Customer Service role.（你对客服工作的理解是什么？）	岗位认知、服务意识
7	Explanation of salary, leave policy, and KPI structure.（讲解薪资、休假和 KPI 体系）	确认候选人接受条件
8	Work setup explanation:（工作方式说明）	确认候选人了解工作形式
	· Work From Home (WFH)（远程办公）	—
	· Using cloud desktop / remote tools (similar to TeamViewer)（使用云桌面/远程工具）	—
9	Are you able to handle 250+ live chat inquiries per day?（你能处理每天 250+ 条实时对话吗？）	工作量承受能力
10	How much RAM does your laptop/PC have?（电脑内存多大？）	云桌面运行最低要求

⚠️ 第 3 题中的打字测试是硬性筛查项——远程客服需要快速打字回复会员，打字速度慢的候选人不适合此岗位。

⚠️ 第 9 题的 250+ 对话量——这是日常工作的真实负荷，必须确认候选人能接受高强度的多任务处理。

15.3 内部提拔远程助理的参考标准¶

评估维度	考察内容
工作质量	话术规范、SOP 执行准确、错误率低
责任心	出勤稳定、主动发现和反馈问题
沟通能力	与会员和团队沟通顺畅、有分寸
学习能力	能快速掌握新规则和流程变化
团队协作	愿意帮助新人、带动团队氛围

提拔建议需报组长审批，审批通过后安排新助理培训和职责交接。

参见：岗位必备能力第 10 项——"能识别优秀远程客服并提拔为远程助理，支持团队梯队建设"。

❓ 待确认：提拔审批的具体流程及所需表单，待跟组长确认补充。

15.4 行政申请模板¶

员工离职、人员变动等行政事项需按规定填写行政申请模板，确保流程规范。

参见：岗位必备能力第 9 项——"理解离职单、清单单及申请模板，确保行政流程规范"。

❓ 待确认：具体表单模板位置及填报方式，待跟组长确认补充。

📘 来源：远程客服管理 SOP.docx（能力要求第 9、10 项）

15.5 离职流程（远程客服合同制员工）¶

底层逻辑：远程客服离职涉及多个账号系统的密码变更、共用账号的协调、敏感信息隔离，必须按标准流程操作，避免离职人员保留任何后续访问能力。

14.5.1 完整离职流程¶

  远程客服提出离职申请
  （说明情况，确定离职日期）
        │
        ▼
  ┌─────────────────────────────────┐
  │ ① 客服管理专员填写离职单         │
  │  · 模板：离职单-远程岗位（合同制） │
  │  · 模板需向组长获取              │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ ② 离职单发送给组长审批           │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ ③ 在工作群通知团队               │
  │  · 公告该员工已离职              │
  │  · 提醒：不允许再分享任何账号    │
  │    信息等敏感信息                │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ ④ 三个后台账号处理（见 17.5.2） │
  │  · 云桌面后台：改密码            │
  │  · Salesmartly 后台：改密码      │
  │  · 平台后台：不改密码（详见原因）│
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ ⑤ 同账号在职员工通知            │
  │  （按账号类型走不同 Signal 渠道）│
  └─────────────────────────────────┘

14.5.2 三个后台账号的差异化处理（核心）¶

账号系统	是否改密码	同账号在职员工通知渠道	原因
云桌面后台	✅ 必须改	私人 Signal（个人手机/家用设备）	改密码后该员工暂时无法登录云桌面，工作 Signal 是装在云桌面里的，所以无法通过工作 Signal 通知——必须用员工的个人 Signal
Salesmartly 后台	✅ 必须改	工作 Signal（云桌面内）	工作 Signal 可登录使用，正常渠道通知即可
平台后台	❌ 不改	—	双重安全保险：① 限制只能通过云桌面 IP 登录；② 每个账号都有谷歌验证码，由客服管理专员保管。离职人员单独有密码也无法登录

⚠️ 关键点：私人 Signal vs 工作 Signal - 私人 Signal：员工个人手机/设备上安装的 Signal（用于云桌面相关通知） - 工作 Signal：装在云桌面里的 Signal（用于日常工作通讯，包括 Salesmartly 通知） - 改云桌面密码会导致工作 Signal 暂时不可用 → 必须用私人 Signal 通知

14.5.3 平台后台为什么不改密码（双重安全保险）¶

保险层	机制	防御效果
第一层：IP 限制	平台后台限制只能通过云桌面 IP 登录	离职人员从家庭/任何外部 IP 登录都会被拒绝
第二层：谷歌验证码	每个账号配置 Google Authenticator 二次验证；验证码由客服管理专员保管，不交给员工本人	即便密码泄露，没有验证码也无法登录

结论：离职人员没有办法绕过这两层保险——所以平台后台不需要改密码，避免不必要的同账号在职员工通知工作。

14.5.4 共用账号的处理矩阵¶

  改密码后（云桌面 / Salesmartly）
        │
        ▼
  ┌─────────────────────────────────┐
  │ 查询：该账号还有哪些在职员工在用？│
  │  · 云桌面账号通常多人共用        │
  │  · Salesmartly 账号也常有共用    │
  └──────────┬──────────────────────┘
             │
             ▼
  ┌─────────────────────────────────┐
  │ 按账号类型选择通知渠道           │
  │                                 │
  │ 云桌面密码 → 私人 Signal 发     │
  │ Salesmartly 密码 → 工作 Signal 发│
  └─────────────────────────────────┘

14.5.5 HQ 系统功能需求（已记录）¶

除了云桌面后台和 Salesmartly 后台需要人工到具体平台改密码外，整个离职流程都可以集成到 HQ 后勤中台系统（§7.5 houqin）：

功能	描述	优先级
一键离职申请	员工自助提交离职申请 → 自动通知客服管理专员	P0
一键受理	专员一键受理 → 自动生成离职单（嵌入"离职单-远程岗位（合同制）"模板）	P0
自动群通知	受理后自动在工作群发布离职通知	P0
强密码自动生成	系统为云桌面/Salesmartly 自动生成新强密码	P1
共用账号自动识别	系统自动识别同账号在职员工，列出待通知名单	P1
多渠道密码下发	按账号类型自动选择 Signal 渠道（私人/工作）	P1

📝 行动项：把上述需求整理后交付给 HQ 系统开发团队（houqin 项目）。

📝 来源：跟岗学习

第五部分 · 能力清单与学习参考¶

十六、岗位必备能力要求（13 项）¶

以下内容来自《远程客服管理 SOP》正式文档。

序号	SOP 事项	标准/要求	重点说明
1	理解客服基础流程	必须理解客服线所有基础流程	包括接线方式、回复流程、话术以及基本运营模式
2	具备逻辑与客观思维	能独立且客观地建立和优化话术逻辑	有助于提高服务质量、沟通效率与判断准确性
3	掌握客服后台功能	必须熟练使用后台各项功能	包括自媒体、FB Messenger、Telegram 机器人、报表、创建新用户、自动化流程修改与排查等
4	制定远程客服排班表	能独立安排远程客服班次	排班需合理、清晰、可执行，并保障服务连续性
5	统计客服线数量	能统计并掌握客服线数量	便于资源管理与运营控制
6	分享自媒体图片与文案	能按需求分享对应内容	如兑换码定时帖子等
7	理解查存提款掉单逻辑	了解相关业务逻辑和处理方式	便于协助处理业务异常问题
8	熟悉云桌面操作	必须熟练使用云桌面	包括登录、监控、问题排查与日常使用
9	掌握行政申请模板	理解离职单、清单单及申请模板	确保行政流程规范
10	发现并培养优秀员工	能识别优秀远程客服并提拔为远程助理	支持团队梯队建设
11	通道异常监控	关注三方群通知	理解渠道风险，及时通报客服线
12	会员 ID 查询技能	掌握 4 种查询方法	识别多账号风险并上报
13	远程测试管理	了解测试人员选拔、测试分类	监督测试结果汇总与考勤

📘 来源：远程客服管理 SOP.docx

十七、日常工作清单（17 项）¶

序号	日常工作内容	执行标准	工作目的
1	分享自媒体图片与文案	按运营计划定时发布兑换码帖子等内容，注意区分多平台名称（详见第六章）	确保运营宣传同步进行
2	面试候选人	根据团队当前缺口安排面试，按标准评估候选人（详见第十五章）	支持人员补充与梯队建设
3	排查客服线质量与数量	通过 Salesmartly 后台检查在线客服人数及服务质量指标，确认各班次人力到位	保证客服线正常稳定
4	排查并处理云桌面问题	及时处理员工反馈的登录失败、断连等云桌面异常（详见第十一章）	保障远程工作环境稳定
5	关注并派发云桌面验证码	员工登录云桌面时收到的验证码（OTP）如无法自行获取，由客服管理专员接收后转发（详见第十一章）	避免员工因验证码问题无法登录工作
6	统计并记录质检数量	每日统计远程助理提交的质检记录条数，汇入 Salesmartly 数据（详见第八章）	作为质量管理和月度汇总依据
7	处理存提款订单问题	处理远程客服上报的充值未到账、提现卡单等异常（详见第二章、第三章）	确保订单异常及时闭环
8	使用云桌面监控员工状态	通过云桌面管理端实时查看远程客服在线情况，发现异常离线及时联系（详见第十一章）	监督工作纪律与效率
9	核实交接班文档（STK）	检查 STK 文档内容完整性，确认所有当班客服已阅读并签名（详见第十三章）	防止信息遗漏和工作断层
10	关注远程助理活跃度	持续观察 5 位远程助理的响应速度和问题反馈质量（详见第八章 §8.3）	保障辅助岗位发挥管理作用
11	整理、排查、安排排班表	持续维护 100 人排班表，处理调休/缺勤/补班请求（详见第七章）	保持班次秩序稳定
12	监控三方代收代付群及工作群通知	持续关注三方群的通道异常、银行维护通知，及时转发至客服大群（详见第四章）	确保远程客服了解通道动态，减少会员投诉
13	处理会员 ID 查询请求	根据远程客服上报的钱包/银行账号，在后台查询并反馈对应会员 ID，注意多账号警示（详见第五章）	协助会员快速找回账号
14	汇总助理反馈并填报工资绩效表	收集 5 位远程助理的当日质检和加扣分反馈，结合 Salesmartly 数据，填报组长提供的工资绩效表（详见第八章 §8.2）	作为月度薪资考核的每日数据积累
15	排查账号异常与多账号检测	根据质检反馈与会员举报，进行 IP 稽查与关联账号排查	防止账号盗用与套利
16	远程测试人员日常管理	监督测试人员的域名、充值、游戏测试完成情况	保障平台风险预警机制
17	自媒体运营发布	按计划在 FB/Instagram/TikTok 发布兑换码、宣传、更新	确保营销宣传同步

📘 来源：远程客服管理 SOP.docx

十八、月常工作清单（7 项）¶

序号	月常工作内容	执行标准	工作目的
1	远程客服月度绩效加扣分汇总	汇总 100 名远程客服全月加扣分记录，按组别整理后提交组长（详见第八章）	作为月度薪资核算依据
2	质检数量月度汇总	汇总整月 Salesmartly 质检数据，分析各组质量趋势（详见第八章）	作为月度质量分析与管理依据
3	派发工资单	按时整理当月工资数据，通过指定渠道发放工资单给各远程客服	确保薪资流程规范透明
4	月度远程助理绩效考评	按第八章 §8.3 的五个维度评估 5 位远程助理当月表现，结果提交组长	支持梯队建设与激励管理
5	月度行政事项汇总	整理本月人员变动（新入职/离职/提拔为助理）、请假记录归档、行政申请表单处理（详见第十五章）	确保人事行政流程合规存档
6	人员变动行政汇总	整理本月新入职、离职、提拔员工档案与合同	确保人事档案完整、合同合规
7	远程测试人员月度总结	汇总测试工作量、发现的风险问题、月度评分	作为测试岗绩效核算依据

📘 来源：远程客服管理 SOP.docx

十九、重点管理事项（5 项）¶

序号	重点事项	说明
1	全流程理解能力	管理岗位必须真正理解客服运作，而不仅仅是表面监督
2	后台与云桌面能力	这是远程客服管理最核心的能力基础
3	排班与质检管理	直接决定团队稳定性和服务质量
4	人才培养责任	管理层需承担发现、培养、提拔优秀员工的责任
5	文档与行政规范	所有表单、交接、记录、工资资料都必须严格管理

📘 来源：远程客服管理 SOP.docx

二十、待深入学习清单¶

经过与其他文档的交叉验证 + 实际表格分析 + 工具调研，原 10 项待学习事项中已有 9 项被覆盖，仅剩 1 项需要进一步跟组长确认。

20.1 已被其他文档覆盖的事项¶

编号	事项	覆盖文档	引用位置
~~1~~	~~存款订单后台查询的具体操作路径和界面~~	03-远程客服-岗前培训指南	§6.4 存款未到账（含 `CRM → Financial Management → Deposit records → 输入 ID → Query` 完整路径 + 凭证验证表）
~~2~~	~~Transaction ID 打码工具和操作~~	本文档	§3.2 Transaction ID 打码工具与方法（Snapaste 打码 vs 选择性截图）
~~3~~	~~三方群查证的具体流程（不同商户的查询方式）~~	02-远程客服工作流程 SOP + 01-副组长-工作指南	02 §条件2「待支付」按 Merchant 名称到对应 Telegram 群查证（如 cover pay 群）；03 §4.10 提现 30 分钟未回调对应商户排查流程
~~4~~	~~Salesmartly 质检后台的具体操作和指标查看~~	06-Salesmartly 后台使用指南	客服视角 + 管理员视角双覆盖（界面、KPI、质检抽查、报表导出）
~~5~~	~~远程客服排班的具体格式和工具~~	本文档 + 03 §8	§7.2 排班工具与表格格式（WFH SHIFT.xlsx 真实结构）+ §7.5 HQ 后勤中台系统
~~6~~	~~工资绩效表的具体格式和填报方式~~	本文档	§8.3 工资绩效表的格式（17 字段+计算公式 / 来自 Inspector Chat-CR_质检.xlsx 真实分析）
~~7~~	~~云桌面（CR）操作 + 管理员监控视角~~	03-远程客服-岗前培训指南 + 本文档	03 §7 客服视角（CR/OTP/DAKA）+ 本文档 §11.1.2 随机抽查云桌面
~~8~~	~~面试流程和评估标准~~	本文档	§15.2 外部面试流程 + §15.2.1 面试标准问题清单
~~10~~	~~多账号检测后的标准处理流程~~	03 + 01-副组长-工作指南 + 04-代理套利行为判定指南 + 06-稽核组长工作指南	03 §6.8 余额消失 IP 稽查流程；03 §4.1 提现审核多账号检测；04 套利判定标准；06 稽核组长视角

20.2 部分覆盖、需要补充的事项¶

编号	事项	已覆盖部分	仍需补充
9	与组长的日常沟通和汇报机制	03 §1.1 四个工作群（IDR-MD-Bahas Kerja / IDR-MD-Utama CS / Cek DP/WD / STK/WFH）	客服管理专员 ↔ 组长之间的具体汇报频率、汇报内容模板、升级路径

20.3 仍需跟组长确认的细节¶

编号	事项	备注
~~7.2 补~~	~~评级分数区间~~	✅ 已通过历史数据反推（Cukup Bagus≥72.5 / Cukup 62.5~72.5 / Semangat 12~44 / No KPI<0），见 §8.2
~~7.3 补~~	~~接线量估分公式~~	✅ 已反推：`估分 = 接线量 × 0.004456 - 9.67`（R²=0.989）
~~7.3 补~~	~~异常负分计算逻辑~~	✅ 已确认：当月离职/严重违规一次性扣 ~92 分
~~HQ 系统~~	~~HQ 管理系统需求文档~~	✅ 已立项开发中（项目代号 houqin，详见 11-组长-工作指南）
14 补	云桌面管理系统的具体平台名称和管理端界面	§十一中仍标记为 ❓

跨文档协同原则：避免内容重复——本文档（客服管理专员视角）只描述管理决策和判断标准，而具体操作步骤优先在 03-远程客服-岗前培训指南中维护。如发现两份文档对同一操作描述不一致，以 05 为准（最贴近一线操作）。

交叉引用¶

01-客服话术库 — 客服标准回复话术（培训必读）
02-远程客服工作流程 SOP — 充值/提现/账户操作详细 SOP 决策树
03-远程客服管理规范 — 远程客服 WFH 每日流程 + 15 条规范 + FAQ
11-组长-工作指南 — 组长对客服管理专员的管理总览
01-副组长-工作指南 — 存提款相关的副组长操作流程参考
04-代理套利行为判定指南 — 多账号/套利行为的判定标准
14-财务与支付 — 财务管理 6 个子页面的功能详解（权限差异参考）
16-营销工具 — 营销工具 3 个子页面的功能详解（权限差异参考）
13-会员与风控 — 会员管理 14 个子页面（远程客服与管理岗同等权限）

📘 来源：远程客服管理 SOP.docx + 学习讨论 + 平台手册（14/16/13）