finance-billing-ops

Topics in the source

• 财务计费运营
• 技能栈
• 使用时机
• 护栏
• 工作流程
• 1. 从最新的计费证据开始
• 2. 将客户事件与产品真相分开
• 3. 检查基于代码的计费行为

当用户想要了解资金、定价、退款、团队席位逻辑，或产品是否真的如网站和销售文案所暗示的那样运作时，使用此技能。 此技能比 customer-billing-ops 更广泛。该技能用于客户补救。此技能用于运营者真相：收入状态、定价决策、团队计费以及基于代码的计费行为。 在相关时，将这些 ECC 原生技能引入工作流程： customer-billing-ops 用于特定客户的补救和跟进 research-ops 当竞争对手定价或当前市场证据重要时 market-research 当答案应以定价建议结束时 github-ops 当计费真相取决于兄弟仓库中的代码、待办事项或发布状态时 verification-loop 当答案取决于验证结账、席位处理或权限行为时 用户询问 Stripe 销售额、退款、MRR 或近期客户活动 用户询问团队计费、按席位计费或配额叠加在代码中是否真实存在 用户想要竞争对手定价比较或定价模型基准 问题混合了收入事实与产品实现真相 区分实时数据与保存的快照 区分： 收入事实 客户影响 基于代码的产品真相 建议 除非实际的权限路径强制执行，否则不要说“按席位” 不要假设重复订阅意味着重复价值 优先使用实时计费数据。如果数据不是实时的，请明确说明快照时间戳。 规范化视图： 已付款销售 活跃订阅 失败或不完整的结账 退款 争议 重复订阅 如果问题是针对特定客户的，请先分类： 重复结账 真实的团队意图 自助服务控制失效 未满足的产品价值 付款失败或设置不完整 然后将其与更广泛的产品问题分开： 团队计费真的存在吗？ 席位是否实际被计数？ 结账数量是否会改变权限？ 网站是否夸大了当前行为？ 如果答案取决于实现真相，请检查代码路径： 结账 定价页面 权限计算 席位或配额处理 安装与用户使用逻辑 计费门户或自助管理支持 报告： 销售快照 问题诊断 产品真相 建议的运营者行动 产品或待办事项差距 不要将失败的尝试与净收入混为一谈 不要仅从营销语言推断团队计费 在有当前证据可用时，不要凭记忆比较竞争对手定价 不要在没有对问题进行分类的情况下，直接从诊断跳到退款 答案包含实时数据声明或快照时间戳 产品真相声明有代码支持 客户影响与更广泛的定价/产品结论被清晰区分