finance-billing-ops

Topics in the source

• Finance Billing Ops（財務請求業務）
• スキルスタック
• 使用するタイミング
• ガードレール
• ワークフロー
• 1. 最新の請求エビデンスから開始する
• 2. 顧客インシデントと製品の実態を分離する
• 3. コードに裏付けられた請求動作を検査する

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

This is an excerpt. Refer to the complete source and its current requirements.