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