mturac Finance 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（製品ギャップ）
- 構築または修正すべき具体的なフォローアップ項目
落とし穴
- 失敗した試みを純収益と混同しない
- マーケティング言語だけからチーム請求を推測しない
- 現在のエビデンスが利用可能な場合、記憶から競合他社の価格を比較しない
- 問題を分類せずに診断から返金へ直接ジャンプしない
検証
- 答えにはライブデータの声明またはスナップショットタイムスタンプが含まれている
- 製品実態の主張はコードに裏付けられている
- 顧客への影響と、より広い価格/製品の結論が明確に分離されている