Finance Billing Ops（財務請求業務）
ユーザーが金銭、価格設定、返金、チームシート論理、またはウェブサイトや販売コピーが示唆する方法で製品が実際に動作しているかどうかを理解したい場合に使用します。
これはcustomer-billing-opsより広い範囲をカバーします。そのスキルは顧客の救済措置向けです。このスキルはオペレーターの実態向けです: 収益状態、価格決定、チーム請求、コードに裏付けられた請求動作。
スキルスタック
関連する場合、次のECCネイティブスキルをワークフローに引き込みます:
customer-billing-ops顧客固有の救済措置とフォローアップ用research-ops競合他社の価格設定や現在の市場エビデンスが重要な場合market-research答えが価格推奨で終わる場合github-ops請求の実態がコード、バックログ、または関連リポジトリのリリース状態に依存する場合verification-loop答えがチェックアウト、シート処理、エンタイトルメント動作の証明に依存する場合
使用するタイミング
- ユーザーがStripeの売上、返金、MRR、または最近の顧客活動を尋ねる場合
- ユーザーがチーム請求、シートごとの課金、またはクォータスタッキングがコードで実際に存在するか確認したい場合
- ユーザーが競合他社の価格比較や価格モデルのベンチマークを必要とする場合
- 質問が収益の事実と製品実装の実態を混在させる場合
ガードレール
- ライブデータと保存されたスナップショットを区別する
- 以下を分離する:
- 収益の事実
- 顧客への影響
- コードに裏付けられた製品の実態
- 推奨事項
- 実際のエンタイトルメントパスがそれを適用していない限り「シートごと」と言わない
- 重複したサブスクリプションが重複した価値を意味すると仮定しない
ワークフロー
1. 最新の請求エビデンスから開始する
ライブ請求データを優先します。データがライブでない場合は、スナップショットのタイムスタンプを明示的に述べます。
全体像を正規化する:
- 有料売上
- アクティブなサブスクリプション
- 失敗または不完全なチェックアウト
- 返金
- 紛争
- 重複したサブスクリプション
2. 顧客インシデントと製品の実態を分離する
質問が顧客固有の場合、まず分類します:
- 重複したチェックアウト
- 実際のチームの意図
- 壊れたセルフサーブコントロール
- 満たされていない製品価値
- 失敗した支払いまたは不完全なセットアップ
次に、より広い製品の質問から分離します:
- チー…
