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