財務・請求業務オペレーション は何をしますか？
ユーザーがお金、価格設定、返金、チームシートのロジック、あるいは製品が実際にウェブサイトやセールスコピーで謳っている通りに動作しているかを理解したい場合に使用します。
これは customer-billing-ops よりも広い範囲をカバーします。customer-billing-ops は顧客への対応のためのスキルです。このスキルは運用者の真実、すなわち収益の状態、価格設定の決定、チーム請求、コードで裏付けられた請求動作のためのものです。
スキルスタック
必要に応じて、これらのECCネイティブスキルをワークフローに取り入れてください。
customer-billing-ops：顧客固有の対応とフォローアップにresearch-ops：競合の価格設定や現在の市場エビデンスが重要な場合にmarket-research：回答が価格設定の推奨で終わるべき場合にgithub-ops：請求の真実が、関連リポジトリのコード、バックログ、リリース状態に依存する場合にverification-loop：チェックアウト、シート処理、エンタイトルメントの動作を証明する必要がある回答の場合に
使用すべきタイミング
- ユーザーがStripeの売上、返金、MRR、最近の顧客アクティビティについて尋ねる場合
- ユーザーがチーム請求、シート単位の請求、またはクォータの積み上げがコード上で実際に存在するかどうかを尋ねる場合
- ユーザーが競合の価格比較や価格設定モデルのベンチマークを求める場合
- 質問が収益の事実と製品実装の真実を混在させている場合
ガードレール
- ライブデータと保存済みスナップショットを区別する
- 以下を分離する：
- 収益の事実
- 顧客への影響
- コードで裏付けられた製品の真実
- 推奨事項
- 実際のエンタイトルメントパスがそれを強制しない限り、「シート単位」とは言わない
- 重複したサブスクリプションが重複した価値を意味すると想定しない
ワークフロー
1. 最も新しい請求エビデンスから始める
ライブの請求データを優先します。データがライブでない場合は、スナップショットのタイムスタンプを明示してください。
状況を把握します。
- 有料セールス
- アクティブなサブスクリプション
- 失敗または未完了のチェックアウト
- 返金
- 異議申し立て
- 重複したサブスクリプション
2. 顧客インシデントと製品の真実を分離する
質問が顧客固有の場合は、最初に分類します。
- 重複チェックアウト
- 実際のチームの意図
- 壊れたセルフサービスコントロール
- 満たされていない製品価値
- 支払いの失敗または不完全なセットアップ
次に、それをより広範な製品の質問から分離します。
- チーム請求は実際に存在するのか？
- シートは実際にカウントされているのか？
- チェックアウト時の数量はエンタイトルメントを変えるのか？
- サイトは現在の動作を誇張していないか？
3. コードで裏付けられた請求動作を検査する
回答が実装の真実に依存する場合は、コードパスを検査します。
- チェックアウト
- 価格設定ページ
- エンタイトルメント計算
- シートまたはクォータの処理
- インストール vs ユーザー使用のロジック
- 請求ポータルまたはセルフサービス管理サポート
4. 判断と製品ギャップで締めくくる
報告します。
- セールススナップショット
- 課題の診断
- 製品の真実
- 推奨される運用者のアクション
- 製品またはバックログのギャップ
出力フォーマット
スナップショット
- タイムスタンプ
- 収益 / サブスクリプション / 異常値
顧客への影響
- 影響を受けるのは誰か
- 何が起こったか
製品の真実
- コードが実際に行うこと
- ウェブサイトやセールスコピーが主張すること
判断
- 返金 / 維持 / コンバート / 対応不要
製品ギャップ
- 構築または修正すべき正確なフォローアップ項目
落とし穴
- 失敗した試行と純収益を混同しない
- マーケティングの文言だけでチーム請求を推測しない
- 現在のエビデンスが利用可能な場合、記憶だけで競合の価格比較をしない
- 問題を分類せずに、診断から直接返金に飛びつかない
検証
- 回答にライブデータの記述またはスナップショットのタイムスタンプが含まれていること
- 製品の真実の主張がコードで裏付けられていること
- 顧客への影響と、より広範な価格設定・製品の結論が明確に分離されていること