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