客户计费运营 是做什么的？
将此技能用于真实的客户操作，而非通用的支付 API 设计。
目标是帮助操作员回答：这个客户是谁，发生了什么，最安全的修复是什么，以及应发送什么后续消息。
何时使用
- 客户反馈计费出错、希望退款或无法取消
- 调研重复订阅、意外收费、续费失败或流失风险
- 审查套餐组合、活跃订阅、年度与月度转换率或团队席位混淆
- 创建或验证计费门户流程
- 审计涉及订阅、发票、退款或支付方式的支持投诉
首选工具界面
- 优先使用连接的计费工具，如 Stripe
- 仅将电子邮件、GitHub 或问题跟踪器作为辅助证据
- 当平台已提供所需控制时，优先使用托管的计费/客户门户，而非自定义账户管理代码
护栏
- 绝不在响应中暴露密钥、完整卡号或不必要的客户 PII
- 不要盲目退款；首先对问题进行分类
- 区分以下情况：
- 意外的重复购买
- 有意的多席位或团队购买
- 产品故障 / 价值未达到
- 失败或不完整的结账
- 因缺少自助控制而取消
- 对于年度套餐、团队套餐和按比例分配的状态，在采取行动前验证合同形式
工作流程
1. 清晰地识别客户
从最强的可用标识符开始：
- 客户电子邮件
- Stripe 客户 ID
- 订阅 ID
- 发票 ID
- GitHub 用户名或支持电子邮件（若已知可映射回计费）
返回简洁的身份摘要：
- 客户
- 活跃订阅
- 已取消订阅
- 发票
- 明显异常，例如重复的活跃订阅
2. 对问题进行分类
在采取行动前将案例归入一个类别：
| 案例 | 典型操作 |
|---|---|
| 重复的个人订阅 | 取消多余订阅，考虑退款 |
| 真实的多席位/团队意图 | 保留席位，澄清计费模式 |
| 付款失败 / 不完整的结账 | 通过门户恢复或更新支付方式 |
| 缺少自助控制 | 提供门户、取消路径或发票访问权限 |
| 产品故障或信任破裂 | 退款、道歉、记录产品问题 |
3. 首先采取最安全的可逆操作
首选顺序：
- 恢复自助管理
- 修复重复或异常的计费状态
- 仅退款受影响的费用或重复项
- 记录原因
- 发送简短的客户后续消息
如果修复需要产品工作，请分离：
- 当前客户补救措施
- 将产品缺陷 / 工作流缺口放入待办事项
4. 检查操作端产品缺口
如果客户问题源于缺失的操作界面，请明确指出来。常见示例：
- 没有计费门户
- 没有使用量/速率限制可见性
- 没有套餐/席位说明
- 没有取消流程
- 没有重复订阅防护
将这些视为 ECC 或网站后续项，而不仅仅是支持事件。
5. 生成操作移交
以以下内容结束：
- 客户状态摘要
- 采取的操作
- 收入影响
- 要发送的后续文本
- 需要创建的产品或待办事项问题
输出格式
使用以下结构：
客户
- 姓名 / 电子邮件
- 相关账户标识符
计费状态
- 活跃订阅
- 发票或续费状态
- 异常
决策
- 问题分类
- 为什么此操作是正确的
采取的操作
- 退款 / 取消 / 门户 / 无操作
后续
- 简短的客户消息
产品缺口
- 应在产品或网站中修复的内容
良好建议示例
- “正确的修复是计费门户，而不是自定义仪表板”
- “这看起来是重复的个人结账，而不是真正的团队席位购买”
- “退还一笔重复费用，保留剩余的活跃订阅，然后如果需要，稍后将客户转换为组织计费”