customer-billing-ops

客户计费运营

将此技能用于真实的客户运营，而非通用的支付 API 设计。

目标是帮助运营人员回答：这个客户是谁，发生了什么，最安全的修复是什么，我们应该发送什么后续跟进。

何时使用

• 客户说计费出了问题、想要退款或无法取消
• 调查重复订阅、意外收费、续费失败或流失风险
• 审查套餐组合、活跃订阅、年付 vs 月付转化或团队席位混乱
• 创建或验证计费门户流程
• 审计涉及订阅、发票、退款或支付方式的支持投诉

首选工具接口

• 优先使用已连接的计费工具如 Stripe
• 仅将电子邮件、GitHub 或问题追踪器作为辅助证据
• 当平台已提供所需控制时，优先使用托管的计费/客户门户而非自定义账户管理代码

防护栏

• 绝不在响应中暴露密钥、完整卡号或不必要的客户个人身份信息
• 不要盲目退款；先分类问题
• 区分以下情况：
  • 意外的重复购买
  • 故意的多席位或团队购买
  • 产品故障 / 价值未达预期
  • 失败或不完整的结账
  • 因缺少自助控制而取消
• 对于年付计划、团队计划和按比例计费状态，在采取行动前验证合同结构

工作流

1. 干净地识别客户

从可用的最强标识符开始：

• 客户电子邮件
• Stripe 客户 ID
• 订阅 ID
• 发票 ID
• GitHub 用户名或支持电子邮件（如已知可映射到计费）

返回简洁的身份摘要：

• 客户
• 活跃订阅
• 已取消订阅
• 发票
• 明显的异常（如重复的活跃订阅）

2. 分类问题

在行动之前将案例归入一个类别：

案例	典型操作
重复的个人订阅	取消多余的，考虑退款
真实的多席位/团队意图	保留席位，澄清计费模型
支付失败 / 不完整结账	通过门户恢复或更新支付方式
缺少自助控制	提供门户、取消路径或发票访问
产品故障或信任破裂	退款、道歉、记录产品问题

3. 首先采取最安全的可逆操作

首选顺序：

1. 恢复自助管理
2. 修复重复或损坏的计费状态
3. 仅退受影响的收费或重复部分
4. 记录原因
5. 发送简短的客户跟进

如果修复需要产品工作，分开处理：

• 现在的客户补救
• 产品缺陷 / 工作流缺口纳入待办事项

4. 检查运营侧产品缺口

如果客户痛点来自缺失的运营界面，明确指出。常见示例：

• 无计费门户
• 无使用量/速率限制可见性
• 无套餐/席位说明
• 无取消流程
• 无重复订阅防护

将这些视为 ECC 或网站的跟进事项，而非仅是支持事件。

5. 生成运营交接

以以下内容结束：

• 客户状态摘要
• 已采取的操作
• 收入影响
• 要发送的跟进文本
• 要创建的产品或待办事项

输出格式

使用此结构：

客户
- 姓名 / 邮箱
- 相关账户标识符

计费状态
- 活跃订阅
- 发票或续费状态
- 异常

决策
- 问题分类
- 为什么此操作是正确的

已采取的操作
- 退款 / 取消 / 门户 / 无操作

后续跟进
- 简短的客户消息

产品缺口
- 产品或网站中应修复的内容

好建议的示例

• "正确的修复是计费门户，而不是自定义仪表板"
• "这看起来像重复的个人结账，而非真实的团队席位购买"
• "退一个重复收费，保留剩余的活跃订阅，之后如需要再将客户转为组织计费"