---

name: finance-billing-ops description: 以证据为先的收入、定价、退款、团队计费和计费模型真相工作流（ECC）。当用户需要销售快照、定价对比、重复收费诊断或代码支撑的计费真相而非通用支付建议时使用。 origin: ECC

财务计费运营

当用户想要了解资金、定价、退款、团队席位逻辑，或产品是否真的按照网站和销售文案所暗示的方式运行时使用此技能。

这比 customer-billing-ops 范围更广。那个技能用于客户补救。此技能用于运营真相：收入状态、定价决策、团队计费和代码支撑的计费行为。

技能栈

在相关时将这些 ECC 原生技能纳入工作流：

• customer-billing-ops 用于客户特定的补救和跟进
• research-ops 当竞争对手定价或当前市场证据重要时
• market-research 当答案应以定价建议结束时
• github-ops 当计费真相取决于相关仓库中的代码、待办事项或发布状态时
• verification-loop 当答案取决于证明结账、席位处理或权限行为时

适用场景

• 用户询问 Stripe 销售额、退款、MRR 或近期客户活动
• 用户询问团队计费、按席位计费或配额叠加是否在代码中真实存在
• 用户想要竞争对手定价对比或定价模型基准
• 问题混合了收入事实和产品实现真相

防护规则

• 区分实时数据和保存的快照
• 分离：
  • 收入事实
  • 客户影响
  • 代码支撑的产品真相
  • 建议
• 除非实际的权限路径强制执行，否则不要说"按席位"
• 不要假设重复订阅意味着重复价值

工作流

1. 从最新的计费证据开始

优先使用实时计费数据。如果数据不是实时的，明确说明快照时间戳。

规范化全貌：

• 已付款销售
• 活跃订阅
• 失败或未完成的结账
• 退款
• 争议
• 重复订阅

2. 将客户事件与产品真相分离

如果问题是客户特定的，先分类：

• 重复结账
• 真实的团队意图
• 损坏的自助控制
• 未满足的产品价值
• 支付失败或设置未完成

然后将其与更广泛的产品问题分离：

• 团队计费真的存在吗？
• 席位真的被计数了吗？
• 结账数量是否改变权限？
• 网站是否夸大了当前行为？

3. 检查代码支撑的计费行为

如果答案取决于实现真相，检查代码路径：

• 结账
• 定价页面
• 权限计算
• 席位或配额处理
• 安装量 vs 用户使用逻辑
• 计费门户或自助管理支持

4. 以决策和产品差距结束

报告：

• 销售快照
• 问题诊断
• 产品真相
• 建议的运营操作
• 产品或待办事项差距

输出格式

快照
- 时间戳
- 收入 / 订阅 / 异常

客户影响
- 谁受到影响
- 发生了什么

产品真相
- 代码实际做了什么
- 网站或销售文案声称什么

决策
- 退款 / 保留 / 转换 / 无操作

产品差距
- 需要构建或修复的确切后续项目

常见陷阱

• 不要将失败的尝试与净收入混淆
• 不要仅从营销语言推断团队计费
• 当有当前证据可用时，不要凭记忆比较竞争对手定价
• 不要在未分类问题的情况下直接从诊断跳到退款

验证

• 答案包含实时数据声明或快照时间戳
• 产品真相声明有代码支撑
• 客户影响和更广泛的定价/产品结论被清晰分离