Finance Billing Ops（财务计费运营）¶

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

它覆盖的范围比 customer-billing-ops 更广。那个技能面向客户补救措施。这个技能面向运营人员的实际情况：收益状态、定价决策、团队计费、由代码支撑的计费行为。

技能栈¶

如相关，将以下 ECC 原生技能引入工作流：

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

使用时机¶

• 当用户询问 Stripe 的收入、退款、MRR 或最近的客户活动时
• 当用户想确认团队计费、按席位计费或配额叠加是否真的存在于代码中时
• 当用户需要竞争对手价格比较或定价模型基准时
• 当问题混淆了收益事实和产品实现实际情况时

护栏¶

• 区分实时数据和已保存的快照
• 分离以下内容：
• 收益事实
• 对客户的影响
• 由代码支撑的产品实际情况
• 建议
• 除非实际的权益路径确实应用了它，否则不要说“按席位”
• 不要假设重复订阅意味着重复价值

工作流¶

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

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

规范化整体情况：

• 付费收入
• 活跃订阅
• 失败或不完整的结账
• 退款
• 争议
• 重复订阅

2. 分离客户事件和产品实际情况¶

如果问题是特定于某个客户的，先进行分类：

• 重复结账
• 实际团队意图
• 失效的自助控制
• 未满足的产品价值
• 失败的支付或不完整的设置

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

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

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

如果答案取决于实现的实际状况，检查代码路径：

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

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

报告以下内容：

• 销售快照
• 问题诊断
• 产品实际情况
• 建议的运营人员操作
• 产品或待办事项差距

输出格式¶

SNAPSHOT（スナップショット）
- タイムスタンプ
- 収益 / サブスクリプション / 異常

CUSTOMER IMPACT（顧客への影響）
- 誰が影響を受けているか
- 何が起きたか

PRODUCT TRUTH（製品の実態）
- コードが実際に何をするか
- ウェブサイトや販売コピーが何を主張しているか

DECISION（決定）
- 返金 / 保持 / 変換 / 無操作

PRODUCT GAP（製品ギャップ）
- 構築または修正すべき具体的なフォローアップ項目

陷阱¶

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

验证¶

• 答案中包含实时数据声明或快照时间戳
• 产品实际情况的主张有代码支撑
• 对客户的影响与更广泛的定价/产品结论被明确分离