customer-billing-ops

原文涵盖的主题

• 客户计费运营
• 使用场景
• 首选工具界面
• 安全边界
• 工作流程
• 1. 清晰识别客户身份
• 2. 对问题进行分类
• 3. 优先采取最安全的可逆操作

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