---

name: customer-billing-ops description: 操作客户计费工作流，如订阅、退款、流失分类、计费门户恢复和方案分析，使用连接的计费工具如Stripe。当用户需要帮助客户、检查订阅状态或管理影响收入的计费操作时使用。 origin: ECC

客户计费运营

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

目标是帮助运营人员回答：这个客户是谁，发生了什么，最安全的修复方案是什么，以及应该发送什么后续跟进？

何时使用

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

首选工具

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

防护规则

• 永远不要在响应中暴露密钥、完整卡号或不必要的客户个人信息
• 不要盲目退款；先分类问题
• 区分以下情况：
  • 意外重复购买
  • 有意的多席位或团队购买
  • 产品故障/未满足价值
  • 失败或未完成的结账
  • 因缺少自助控制而取消
• 对于年度方案、团队方案和按比例计费状态，在采取行动前验证合同结构

工作流程

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

良好建议示例

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