财务计费运营 是做什么的？
当用户想要了解资金、定价、退款、团队席位逻辑，或者产品实际行为是否与网站和销售文案所述一致时，请使用此技能。
这比customer-billing-ops范围更广。那个技能用于客户补救。此技能用于运营真相：收入状态、定价决策、团队计费和基于代码的计费行为。
技能栈
在相关时，将这些ECC原生技能纳入工作流：
customer-billing-ops：用于客户特定的补救和后续跟进research-ops：当竞争定价或当前市场证据重要时使用market-research：当答案应以定价建议结尾时使用github-ops：当计费真相取决于同级仓库中的代码、待办事项或发布状态时使用verification-loop：当答案取决于证明结账、席位处理或权限行为时使用
使用时机
- 用户询问Stripe销售、退款、MRR或近期客户活动
- 用户询问团队计费、按席位计费或配额堆积在代码中是否真实存在
- 用户想要竞争定价比较或定价模型基准
- 问题混合了收入事实和产品实现真相
防护措施
- 区分实时数据与保存的快照
- 分离以下内容：
- 收入事实
- 客户影响
- 基于代码的产品真相
- 建议
- 除非实际的权限路径强制执行，否则不要说“按席位”
- 不要假设重复订阅意味着重复价值
工作流
1. 从最新的计费证据开始
优先使用实时计费数据。如果数据不是实时的，请明确说明快照时间戳。
标准化视图：
- 已付销售
- 活跃订阅
- 失败或不完整的结账
- 退款
- 争议
- 重复订阅
2. 将客户事件与产品真相分开
如果问题是客户特定的，首先分类：
- 重复结账
- 真实团队意图
- 自助控制故障
- 未满足的产品价值
- 支付失败或设置不完整
然后将其与更广泛的产品问题分离：
- 团队计费真的存在吗？
- 席位是否实际被统计？
- 结账数量是否改变权限？
- 网站是否夸大了当前行为？
3. 检查基于代码的计费行为
如果答案取决于实现真相，请检查代码路径：
- 结账
- 定价页面
- 权利计算
- 席位或配额处理
- 安装与用户使用逻辑
- 计费门户或自助管理支持
4. 以决策和产品差距结束
报告：
- 销售快照
- 问题诊断
- 产品真相
- 推荐的运营操作
- 产品或待办事项差距
输出格式
快照
- 时间戳
- 收入/订阅/异常
客户影响
- 谁受影响
- 发生了什么
产品真相
- 代码实际做什么
- 网站或销售文案声称什么
决策
- 退款/保留/转换/无操作
产品差距
- 需要构建或修复的确切后续项目
陷阱
- 不要将失败的尝试与净收入混为一谈
- 不要仅凭营销语言推断团队计费
- 当有当前证据可用时，不要凭记忆比较竞争定价
- 不要在没有对问题进行分类的情况下，从诊断直接跳到退款
验证
- 答案包含实时数据声明或快照时间戳
- 产品真相声明有代码支持
- 客户影响与更广泛的定价/产品结论被清晰地分开