客户计费业务¶

本技能用于实际的客户业务，而非通用的支付 API 设计。

目标是帮助操作员回答以下问题：这位客户是谁、发生了什么、最安全的修复方式是什么、应该发送什么样的跟进信息？

何时使用¶

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

推荐工具界面¶

• 优先使用已连接的计费工具（如 Stripe）
• 仅将邮件、GitHub 或问题跟踪器作为补充证据
• 如果平台已提供所需控制，优先使用托管的计费/客户门户，而不是自定义账户管理代码

护栏¶

• 不要在响应中暴露密钥、完整卡号或不必要的客户 PII
• 不要盲目退款，先对问题进行分类
• 区分以下情况：
• 意外的重复购买
• 有意的多席位或团队购买
• 产品损坏/价值未兑现
• 失败或不完整的结账
• 因缺少自助控制而取消
• 对于年付套餐、团队套餐和按比例计费状态，在采取行动前确认合同形态

工作流¶

1. 明确识别客户¶

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

• 客户邮箱
• Stripe 客户 ID
• 订阅 ID
• 发票 ID
• GitHub 用户名或已知与计费关联的支持邮箱

返回简洁的身份摘要：

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

2. 对问题进行分类¶

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

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

优先级：

1. 恢复自助管理
2. 修复重复或损坏的计费状态
3. 仅退款受影响的发票或重复部分
4. 记录原因
5. 发送简短的客户跟进

如果修复需要产品工作，请分离以下内容：

• 立即的客户补救
• 面向待办事项的产品缺陷/流程缺口

4. 检查操作员侧的产品缺口¶

如果客户痛点来自缺失的操作员界面，请明确指出。常见示例：

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

将这些作为 ECC 或网站的跟进项处理，而不是支持事件。

5. 生成操作员交接¶

以以下内容结束：

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

输出格式¶

使用以下结构：

CUSTOMER
- name / email
- relevant account identifiers

BILLING STATE
- active subscriptions
- invoice or renewal state
- anomalies

DECISION
- issue classification
- why this action is correct

ACTION TAKEN
- refund / cancel / portal / no-op

FOLLOW-UP
- short customer message

PRODUCT GAP
- what should be fixed in the product or website

良好建议示例¶

• “正确的修复方式是计费门户，而不是自定义仪表盘”
• “这看起来像是重复的个人结账，而不是实际的团队席位购买”
• “退款一张重复发票，保留其余活跃订阅，之后如有需要再将客户转换为组织计费”