財務計費運営

ユーザーが資金、価格設定、払い戻し、チームシート ロジック、または製品が Web サイトと営業文案で示唆されているように実際に機能しているかどうかを理解したいときにこのスキルを使用します。

このスキルは customer-billing-ops よりも広範です。そのスキルは顧客の救済用です。このスキルは運営者の真実用です：収入状態、価格決定、チーム計費、およびコードベースの計費動作。

スキル スタック

必要に応じて、これらの ECC ネイティブ スキルをワークフローに取り入れます：

• customer-billing-ops 特定顧客の救済とフォローアップ用
• research-ops 競合他社の価格設定または現在の市場証拠が重要な場合
• market-research 答えが価格設定の提案で終わるべき場合
• github-ops 計費の真実がシスタリポジトリのコード、課題、またはリリース ステータスに依存する場合
• verification-loop 答えがチェックアウトの検証、シート処理、または権限動作に依存する場合

使用時機

• ユーザーが Stripe の売上高、払い戻し、MRR、または最近の顧客アクティビティについて質問する
• ユーザーがチーム計費、シート単位の計費、またはクォータ スタッキングがコードに実際に存在するかどうかを質問する
• ユーザーが競合他社の価格設定比較または価格設定モデルのベンチマークを望んでいる
• 問題が収入の事実と製品実装の真実を混ぜている

ガードレール

• リアルタイム データと保存されたスナップショットを区別する
• 以下を区別する：
  • 収入の事実
  • 顧客への影響
  • コードベースの製品真実
  • 推奨事項
• 実際の権限パスが強制していない限り、「シート単位」と言わない
• 反復課金が反復価値を意味すると仮定しない

ワークフロー

1. 最新の計費証拠から始める

リアルタイム計費データを優先します。データがリアルタイムでない場合は、スナップショットのタイムスタンプを明示的に述べます。

標準化されたビュー：

• 支払済み売上高
• アクティブな購読
• 失敗または不完全なチェックアウト
• 払い戻し
• 異議
• 反復課金

2. 顧客イベントと製品真実を分離する

問題が特定の顧客に関するものである場合は、まず分類します：

• 反復課金
• 真のチーム意図
• セルフサービス制御の障害
• 未実現の製品価値
• 支払い失敗または不完全な設定

次に、より広い製品の問題から分離します：

• チーム計費は本当に存在するか？
• シートは実際にカウントされているか？
• チェックアウト数は権限を変更するか？
• Web サイトは現在の動作を誇張しているか？

3. コードベースの計費動作を確認する

答えが実装の真実に依存する場合は、コード パスを確認します：

• チェックアウト
• 価格ページ
• 権限計算
• シートまたはクォータ処理
• インストールとユーザー使用ロジック
• 計費ポータルまたはセルフサービス管理サポート

4. 決定と製品ギャップで終了する

レポート：

• 売上スナップショット
• 問題診断
• 製品真実
• 推奨される運営アクション
• 製品または課題ギャップ

出力形式

スナップショット
- タイムスタンプ
- 収入 / 購読 / 異常

顧客への影響
- 誰が影響を受けているか
- 何が起きたか

製品真実
- コードが実際に実行する内容
- Web サイトまたは営業文案が主張する内容

決定
- 払い戻し / 保持 / コンバージョン / アクションなし

製品ギャップ
- 構築または修正が必要な特定のフォローアップ項目

よくある落とし穴

• 失敗した試行を純売上と混同しない
• マーケティング言語からだけチーム計費を推測しない
• 現在の証拠が利用可能なときに競合他社の価格設定を記憶から比較しない
• 問題を分類せずに診断から払い戻しに直接ジャンプしない

検証

• 答えにリアルタイム データ宣言またはスナップショット タイムスタンプが含まれている
• 製品真実の主張にはコード サポートがある
• 顧客への影響は、より広い価格設定/製品の結論から明確に区別されている