finance-billing-ops
以證據為先查營收、定價、退款與有程式碼支撐的計費實況
中文翻譯
--- name: finance-billing-ops description: 以證據為先的營收、定價、退款、團隊計費與計費模型真相工作流，用於 ECC。在使用者想要銷售快照、定價比較、重複扣款診斷，或有程式碼支撐的計費實況，而不是通用的支付建議時使用。 metadata: origin: ECC --- # Finance Billing Ops 當使用者想了解金錢、定價、退款、團隊席位邏輯，或產品的實際行為是否真的像網站與銷售文案所暗示的那樣時使用。 這比 `customer-billing-ops` 的範圍更廣。那個 skill 是用來處理客戶補救。這個 skill 是用來取得操作者所需的真相：營收狀態、定價決策、團隊計費，以及有程式碼支撐的計費行為。 ## Skill 組合 相關時，把這些 ECC 原生 skill 拉進工作流： - `customer-billing-ops`：針對特定客戶的補救與後續跟進 - `research-ops`：競爭對手定價或當前市場證據很重要時 - `market-research`：答案應該以定價建議收尾時 - `github-ops`：計費真相取決於兄弟 repo 的程式碼、backlog 或發布狀態時 - `verification-loop`：答案取決於證明 checkout、席位處理或 entitlement 行為時 ## 何時使用 - 使用者問 Stripe 的銷售、退款、MRR，或最近的客戶活動 - 使用者問團隊計費、按席位計費或配額疊加，在程式碼裡是不是真的存在 - 使用者想要競爭對手的定價比較或定價模型的 benchmark - 問題把營收事實和產品實作的真相混在一起 ## 護欄 - 區分即時資料和已儲存的快照 - 分開： - 營收事實 - 客戶影響 - 有程式碼支撐的產品真相 - 建議 - 除非實際的 entitlement 路徑真的強制執行，否則不要說「按席位」 - 不要假設重複訂閱就代表重複的價值 ## 工作流 ### 1. 從最新的計費證據開始 優先使用即時的計費資料。如果資料不是即時的，要明確寫出快照的時間戳。 把整體狀況正規化： - 已付款的銷售 - 有效的訂閱 - 失敗或未完成的 checkout - 退款 - 爭議 - 重複的訂閱 ### 2. 把客戶事件和產品真相分開 如果問題是針對特定客戶，先分類： - 重複 checkout - 真實的團隊意圖 - 壞掉的自助控制 - 未達成的產品價值 - 失敗的付款或未完成的設定 然後把它和更廣泛的產品問題分開： - 團隊計費真的存在嗎？ - 席位真的有被計算嗎？ - checkout 的數量會改變 entitlement 嗎？ - 網站有誇大目前的行為嗎？ ### 3. 檢查有程式碼支撐的計費行為 如果答案取決於實作的真相，就檢查程式碼路徑： - checkout - 定價頁 - entitlement 計算 - 席位或配額處理 - installation 與 user 使用量的邏輯對比 - 計費入口或自助管理的支援 ### 4. 以決策和產品缺口收尾 回報： - 銷售快照 - 問題診斷 - 產品真相 - 建議的操作者行動 - 產品或 backlog 的缺口 ## 輸出格式 ```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 ``` ## 常見陷阱 - 不要把失敗的嘗試和淨營收混為一談 - 不要只憑行銷用語就推斷有團隊計費 - 有當前證據時，不要憑記憶比較競爭對手的定價 - 不要從診斷直接跳到退款，而沒有先分類問題 ## 驗證 - 答案包含即時資料的聲明或快照時間戳 - 產品真相的主張要有程式碼支撐 - 客戶影響和更廣泛的定價/產品結論要清楚分開
英文原文
--- name: finance-billing-ops description: Evidence-first revenue, pricing, refunds, team-billing, and billing-model truth workflow for ECC. Use when the user wants a sales snapshot, pricing comparison, duplicate-charge diagnosis, or code-backed billing reality instead of generic payments advice. metadata: origin: ECC --- # 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. ## 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 ## 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 ## 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 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 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 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 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 ``` ## 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