Finance Billing Ops（財務請求オペレーション）
ユーザーがお金、価格設定、返金、チームシートロジック、または製品が実際にウェブサイトやセールスコピーが主張するように動作しているかどうかを理解したい場合にこれを使用します。
これはcustomer-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（製品ギャップ）
- 正確なフォローアップアイテム（構築または修正すべきもの）
落とし穴
- 失敗した試行を純収益と混同しない
- マーケティング文言だけでチーム請求を推測しない
- 現在のエビデンスが利用可能な場合、記憶から競合他社の価格を比較しない
- 診断から問題を分類せずに直接返金に飛びつかない
検証
- 回答にはライブデータの記述またはスナップショットタイムスタンプが含まれている
- 製品真実の主張はコードに基づいている
- 顧客への影響と、より広範な価格設定・製品の結論が明確に分離されている