Back to Details

finance-billing-ops

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Finance Billing Ops

财务账单运营

Use this when the user wants to understand money, pricing, refunds, team-seat logic, or whether the product actually behaves the way the website and sales copy imply.
This is broader than 
customer-billing-ops
. That skill is for customer remediation. This skill is for operator truth: revenue state, pricing decisions, team billing, and code-backed billing behavior.
当用户需要了解资金、定价、退款、团队席位逻辑，或者产品实际表现是否与网站和销售文案描述一致时，可以使用此工作流。
本工作流覆盖范围比
customer-billing-ops
更广：该技能用于客户问题修复，而本技能用于运营端事实核查：营收状态、定价决策、团队账单，以及基于代码的账单实际行为。

Skill Stack

技能栈

Pull these ECC-native skills into the workflow when relevant:
  • customer-billing-ops
    for customer-specific remediation and follow-up
  • research-ops
    when competitor pricing or current market evidence matters
  • market-research
    when the answer should end in a pricing recommendation
  • github-ops
    when the billing truth depends on code, backlog, or release state in sibling repos
  • verification-loop
    when the answer depends on proving checkout, seat handling, or entitlement behavior
在相关场景下可将以下ECC原生技能纳入工作流：
  • customer-billing-ops
    用于特定客户的问题修复与跟进
  • research-ops
    当需要竞品定价或当前市场证据时使用
  • market-research
    当最终需要输出定价建议时使用
  • github-ops
    当账单事实依赖于关联仓库中的代码、待办事项或发布状态时使用
  • verification-loop
    当需要验证结账、席位处理或权益行为时使用

When to Use

适用场景

  • user asks for Stripe sales, refunds, MRR, or recent customer activity
  • user asks whether team billing, per-seat billing, or quota stacking is real in code
  • user wants competitor pricing comparisons or pricing-model benchmarks
  • the question mixes revenue facts with product implementation truth
  • 用户询问Stripe销售、退款、MRR或近期客户活动
  • 用户询问团队账单、按席位计费或配额叠加是否在代码中真实生效
  • 用户需要竞品定价对比或计费模型基准
  • 问题同时涉及营收事实与产品实现实际情况

Guardrails

防护规则

  • distinguish live data from saved snapshots
  • separate:
    • revenue fact
    • customer impact
    • code-backed product truth
    • recommendation
  • do not say "per seat" unless the actual entitlement path enforces it
  • do not assume duplicate subscriptions imply duplicate value
  • 区分实时数据与已保存的快照
  • 区分以下内容：
    • 营收事实
    • 客户影响
    • 基于代码的产品实际情况
    • 建议
  • 除非实际权益路径确实执行了按席位计费规则，否则不要提及「按席位计费」
  • 不要假设重复订阅意味着重复价值

Workflow

工作流

1. Start from the freshest billing evidence

1. 从最新的账单证据开始

Prefer live billing data. If the data is not live, state the snapshot timestamp explicitly.
Normalize the picture:
  • paid sales
  • active subscriptions
  • failed or incomplete checkouts
  • refunds
  • disputes
  • duplicate subscriptions
优先使用实时账单数据。如果数据不是实时的，请明确说明快照时间戳。
梳理数据全貌：
  • 付费销售额
  • 有效订阅
  • 失败或未完成的结账
  • 退款
  • 争议
  • 重复订阅

2. Separate customer incidents from product truth

2. 区分客户事件与产品实际情况

If the question is customer-specific, classify first:
  • duplicate checkout
  • real team intent
  • broken self-serve controls
  • unmet product value
  • failed payment or incomplete setup
Then separate that from the broader product question:
  • does team billing really exist?
  • are seats actually counted?
  • does checkout quantity change entitlement?
  • does the site overstate current behavior?
如果问题是特定客户相关的，先进行分类：
  • 重复结账
  • 真实的团队采购意图
  • 自助服务控件故障
  • 产品价值未达预期
  • 支付失败或设置未完成
然后将其与更广泛的产品问题区分开：
  • 团队账单功能是否真实存在？
  • 席位是否真实统计？
  • 结账数量是否会变更权益？
  • 网站是否夸大了当前的实际功能？

3. Inspect code-backed billing behavior

3. 核查基于代码的账单行为

If the answer depends on implementation truth, inspect the code path:
  • checkout
  • pricing page
  • entitlement calculation
  • seat or quota handling
  • installation vs user usage logic
  • billing portal or self-serve management support
如果答案依赖于实现的实际情况，请核查代码路径：
  • 结账流程
  • 定价页面
  • 权益计算
  • 席位或配额处理
  • 安装与用户使用逻辑
  • 账单门户或自助管理支持

4. End with a decision and product gap

4. 最终输出决策与产品缺口

Report:
  • sales snapshot
  • issue diagnosis
  • product truth
  • recommended operator action
  • product or backlog gap
报告以下内容：
  • 销售快照
  • 问题诊断
  • 产品实际情况
  • 建议的运营操作
  • 产品或待办事项缺口

Output Format

输出格式

text
SNAPSHOT
- timestamp
- revenue / subscriptions / anomalies

CUSTOMER IMPACT
- who is affected
- what happened

PRODUCT TRUTH
- what the code actually does
- what the website or sales copy claims

DECISION
- refund / preserve / convert / no-op

PRODUCT GAP
- exact follow-up item to build or fix
text
SNAPSHOT
- timestamp
- revenue / subscriptions / anomalies

CUSTOMER IMPACT
- who is affected
- what happened

PRODUCT TRUTH
- what the code actually does
- what the website or sales copy claims

DECISION
- refund / preserve / convert / no-op

PRODUCT GAP
- exact follow-up item to build or fix

Pitfalls

常见误区

  • do not conflate failed attempts with net revenue
  • do not infer team billing from marketing language alone
  • do not compare competitor pricing from memory when current evidence is available
  • do not jump from diagnosis straight to refund without classifying the issue
  • 不要将失败的尝试与净收入混为一谈
  • 不要仅从营销文案推断团队账单功能存在
  • 当有当前证据可用时，不要凭记忆对比竞品定价
  • 不要在没有对问题进行分类的情况下，直接从诊断跳到退款操作

Verification

验证标准

  • the answer includes a live-data statement or snapshot timestamp
  • product-truth claims are code-backed
  • customer-impact and broader pricing/product conclusions are separated cleanly
  • 答案包含实时数据说明或快照时间戳
  • 产品实际情况的声明是基于代码验证的
  • 客户影响与更广泛的定价/产品结论明确分开