Customer Billing Ops 是一个用于真实客户运营的计费操作技能，目标不是设计通用支付 API，而是帮助运营人员回答：这位客户是谁、发生了什么、最安全的修复方式是什么、应发送什么后续跟进。
一、适用场景 当客户表示计费出现问题、希望退款或无法取消订阅时；调查重复订阅、误扣费、续费失败或流失风险时；审查套餐组合、活跃订阅、年付与月付转化或团队席位混淆时；创建或验证计费门户流程时；审计涉及订阅、发票、退款或支付方式的支持投诉时，可使用该技能。
二、首选工具面 优先使用已连接的计费工具，例如 Stripe；邮件、GitHub 或问题追踪器仅作为辅助证据。当平台已提供所需控制能力时，优先使用托管的计费/客户门户，而非自定义账户管理代码。
三、防护规则 不得在回复中暴露密钥、完整卡号或不必要的客户隐私信息。不要盲目退款，必须先对问题进行分类，区分：意外重复购买、有意的多席位或团队购买、产品故障/未达价值、结账失败或不完整、因缺少自助控制而取消。对于年付计划、团队计划和按比例计费状态，在采取行动前需核实合同形态。
四、工作流程
- 清晰识别客户：从最强标识符入手，如客户邮箱、Stripe 客户 ID、订阅 ID、发票 ID，或已知可映射回计费的 GitHub 用户名/支持邮箱。返回简洁的身份摘要，包括客户、活跃订阅、已取消订阅、发票，以及明显异常（如重复活跃订阅）。
- 分类问题：在行动前将案例归入一个类别。重复个人订阅对应取消多余项、考虑退款；真实多席位/团队意图对应保留席位、澄清计费模型；支付失败/结账不完整对应通过门户恢复或更新支付方式；缺少自助控制对应提供门户、取消路径或发票访问；产品故障或信任破裂对应退款、致歉、记录产品问题。
- 优先采取最安全的可逆操作：推荐顺序为恢复自助管理、修复重复或损坏的计费状态、仅退受影响或重复的费用、记录原因、发送简短的客户跟进。若修复需要产品工作，需将客户即时补救与产品缺陷/工作流缺口分开处理。
- 检查运营侧产品缺口：若客户痛点源于缺少运营界面，需明确指出，常见例子包括无计费门户、无用量/速率限制可见性、无套餐/席位说明、无取消流程、无重复订阅防护。这些应视为 ECC 或网站后续事项，而不仅是支持事件。
- 产出运营交接：以客户状态摘要、已采取行动、收入影响、待发送的跟进文本、需创建的产品或待办问题作为结尾。
五、输出格式 使用以下结构：CUSTOMER（姓名/邮箱、相关账户标识符）；BILLING STATE（活跃订阅、发票或续费状态、异常）；DECISION（问题分类、为何此行动正确）；ACTION TAKEN（退款/取消/门户/无操作）；FOLLOW-UP（简短客户消息）；PRODUCT GAP（产品或网站应修复的内容）。
六、良好建议示例 “正确的修复方式是计费门户，而不是先做自定义仪表盘”；“这看起来是重复的个人结账，而不是真实的团队席位购买”；“退还一笔重复费用，保留剩余活跃订阅，之后如有需要再将客户转为组织计费”。
七、限制 该技能依赖已连接的计费工具（如 Stripe）作为主要操作面；具体支持的平台、价格、收费方式、可用功能范围等资料暂未提供。