客户计费运营

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

目标是帮助运营人员回答：客户是谁、发生了什么、最安全的修复方案是什么、以及后续应发送什么跟进内容。

使用场景

• 客户反馈计费异常、要求退款或无法取消订阅
• 调查重复订阅、意外扣费、续费失败或流失风险
• 审查套餐组合、活跃订阅、年付与月付转换、或团队席位混淆
• 创建或验证计费门户流程
• 审计涉及订阅、发票、退款或支付方式的支持投诉

首选工具界面

• 优先使用 Stripe 等关联计费工具
• 仅将邮件、GitHub 或问题追踪器作为辅助证据
• 当平台已提供必要控制功能时，优先使用托管计费/客户门户而非自定义账户管理代码

安全边界

• 切勿在回复中暴露密钥、完整卡号或不必要的客户个人身份信息
• 不要盲目退款；首先对问题进行归类
• 区分以下情况：
  • 意外重复购买
  • 有意的多席位或团队购买
  • 产品故障/价值未兑现
  • 结账失败或不完整
  • 因缺少自助控制功能导致的取消
• 对于年付方案、团队方案及按比例计费状态，在操作前需核实合同结构

工作流程

1. 清晰识别客户身份

从最可靠的标识符入手：

• 客户邮箱
• Stripe 客户 ID
• 订阅 ID
• 发票 ID
• 已知可关联到计费的 GitHub 用户名或支持邮箱

返回简洁的身份摘要：

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

2. 对问题进行分类

在操作前将案例归入一个类别：

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

推荐顺序：

1. 恢复自助管理功能
2. 修复重复或异常的计费状态
3. 仅对受影响的扣费或重复项进行退款
4. 记录原因
5. 发送简短的客户跟进信息

若修复需要产品工作，需区分：

• 当前客户补救措施
• 待办事项中的产品缺陷/工作流缺口

4. 检查运营端产品缺口

若客户痛点源于缺少运营界面，需明确指出。常见示例：

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

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

5. 生成运营交接文档

最终需包含：

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

输出格式

使用以下结构：

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

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

决策
- 问题分类
- 为何此操作正确

已执行操作
- 退款 / 取消 / 门户 / 无操作

后续跟进
- 简短客户消息

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

优质建议示例

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