customer-billing-ops

客户计费操作

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

目标是帮助操作员回答：这个客户是谁，发生了什么，最安全的修复方案是什么，以及我们应该发送什么后续消息？

何时使用

• 客户表示计费出现问题，想要退款，或无法取消
• 调查重复订阅、意外收费、续费失败或流失风险
• 审查套餐组合、活跃订阅、年付与月付转换或团队席位混淆
• 创建或验证计费门户流程
• 审计涉及订阅、发票、退款或支付方式的客服投诉

首选工具

• 优先使用已连接的计费工具，如 Stripe
• 仅将电子邮件、GitHub 或问题跟踪器作为辅助证据
• 当平台已提供所需控制时，优先使用托管的计费/客户门户，而非自定义账户管理代码

安全护栏

• 切勿在回复中暴露密钥、完整卡号或不必要的客户个人身份信息
• 不要盲目退款；首先对问题进行分类
• 区分以下情况：
  • 意外的重复购买
  • 有意的多席位或团队购买
  • 产品故障/未实现价值
  • 失败或不完整的结账
  • 因缺少自助服务控制而取消
• 对于年付套餐、团队套餐和按比例计费的情况，在采取行动前验证合同形式

工作流程

1. 清晰识别客户

从可用的最强标识符开始：

• 客户电子邮件
• Stripe 客户 ID
• 订阅 ID
• 发票 ID
• GitHub 用户名或支持电子邮件（如果已知可映射到计费）

返回简洁的身份摘要：

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

2. 对问题进行分类

在采取行动前，将案例归入一个类别：

案例	典型操作
重复的个人订阅	取消多余的，考虑退款
真实的多席位/团队意图	保留席位，澄清计费模式
支付失败/不完整结账	通过门户恢复或更新支付方式
缺少自助服务控制	提供门户、取消路径或发票访问
产品故障或信任破裂	退款、道歉、记录产品问题

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

优先顺序：

1. 恢复自助管理
2. 修复重复或错误的计费状态
3. 仅退款受影响的费用或重复项
4. 记录原因
5. 发送简短的客户后续消息

如果修复需要产品工作，请区分：

• 当前客户补救
• 产品缺陷/工作流缺口，放入待办事项

4. 检查操作端产品缺口

如果客户问题源于缺少操作界面，请明确指出。常见示例：

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

将这些视为 ECC 或网站后续事项，而不仅仅是支持事件。

5. 生成操作员交接信息

以以下内容结束：

• 客户状态摘要
• 已采取的操作
• 收入影响
• 要发送的后续文本
• 要创建的产品或待办事项

输出格式

使用以下结构：

客户
- 姓名/电子邮件
- 相关账户标识符

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

决策
- 问题分类
- 为什么此操作是正确的

已采取的操作
- 退款/取消/门户/无操作

后续
- 简短的客户消息

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

良好建议示例

• "正确的修复是计费门户，而不是自定义仪表板"
• "这看起来是重复的个人结账，而不是真正的团队席位购买"
• "退款一个重复费用，保留剩余的活跃订阅，然后根据需要稍后将客户转换为组织计费"