| name | finance-billing-ops |
| description | 证据优先的收入、定价、退款、团队计费和计费模型真实性工作流。当用户想要销售快照、定价比较、重复收费诊断或代码支持的计费事实而非通用支付建议时使用。 |
| origin | ECC |
财务计费运维
当用户想要了解资金、定价、退款、团队席位逻辑，或产品是否真的像网站和销售文案暗示的那样运作时使用。
这比 customer-billing-ops 更广泛。该技能用于客户补救。此技能用于运营者事实：收入状态、定价决策、团队计费和代码支持的计费行为。
技能栈
在相关时将这些 ECC 原生技能拉入工作流：
customer-billing-ops 用于客户特定的补救和跟进research-ops 当竞争对手定价或当前市场证据重要时market-research 当答案应以定价建议结束时github-ops 当计费事实依赖于兄弟仓库中的代码、backlog 或发布状态时verification-loop 当答案依赖于证明结账、席位处理或权限行为时
何时使用
- 用户询问 Stripe 销售、退款、MRR 或最近的客户活动
- 用户询问团队计费、按席位计费或配额堆叠是否在代码中真实存在
- 用户想要竞争对手定价比较或定价模型基准
- 问题混合了收入事实与产品实现事实
防护措施
- 区分实时数据和保存的快照
- 分离：
- 不要说"按席位"，除非实际权限路径执行了它
- 不要假设重复订阅意味着重复价值
工作流
1. 从最新的计费证据开始
优先使用实时计费数据。如果数据不是实时的，明确说明快照时间戳。
归一化全貌：
- 付费销售
- 活跃订阅
- 失败或未完成的结账
- 退款
- 争议
- 重复订阅
2. 将客户事件与产品事实分离
如果问题是客户特定的，首先分类：
- 重复结账
- 真实的团队意图
- 损坏的自助服务控制
- 未满足的产品价值
- 支付失败或设置不完整
然后将其与更广泛的产品问题分离：
- 团队计费真的存在吗？
- 席位实际被计算了吗？
- 结账数量是否改变权限？
- 网站是否夸大了当前行为？
3. 检查代码支持的计费行为
如果答案依赖于实现事实，检查代码路径：
- 结账
- 定价页面
- 权限计算
- 席位或配额处理
- 安装与用户使用逻辑
- 计费门户或自助服务管理支持
4. 以决策和产品缺口结束
报告：
- 销售快照
- 问题诊断
- 产品事实
- 建议的运营者行动
- 产品或 backlog 缺口
输出格式
快照
- 时间戳
- 收入 / 订阅 / 异常
客户影响
- 谁受到影响
- 发生了什么
产品事实
- 代码实际做了什么
- 网站或销售文案声称了什么
决策
- 退款 / 保留 / 转换 / 无操作
产品缺口
- 需要构建或修复的具体后续项目
常见陷阱
- 不要将失败尝试与净收入混为一谈
- 不要仅从营销语言推断团队计费
- 在有当前证据可用时不要从记忆中比较竞争对手定价
- 不要从诊断直接跳到退款而不先分类问题
验证
- 答案包含实时数据声明或快照时间戳
- 产品事实声明有代码支持
- 客户影响和更广泛的定价/产品结论清晰分离
