customer-billing-ops

# 顧客請求業務 このスキルは、汎用的な支払いAPI設計ではなく、実際の顧客業務のために使用します。 目標は、オペレーターが以下に答えるのを助けることです：この顧客は誰か、何が起きたか、最も安全な修正は何か、どのようなフォローアップを送るべきか？ ## 使用時期 - 顧客が請求が壊れている、返金が必要、またはキャンセルできないと言っている場合 - 重複サブスクリプション、偶発的な請求、失敗した更新、またはチャーンリスクを調査する場合 - プランミックス、アクティブなサブスクリプション、年間対月間の変換、またはチームシートの混乱をレビューする場合 - 請求ポータルフローの作成または検証 - サブスクリプション、請求書、返金、または支払い方法に関するサポートの苦情を監査する場合 ## 推奨ツールサーフェス - Stripeなどの接続された請求ツールを最初に使用する - メール、GitHub、または課題トラッカーは補足証拠としてのみ使用する - プラットフォームが必要なコントロールをすでに提供している場合、カスタムアカウント管理コードよりもホストされた請求/顧客ポータルを優先する ## ガードレール - レスポンスに秘密鍵、完全なカード詳細、または不必要な顧客PIIを公開しない - 盲目的に返金しない。まず問題を分類する - 以下を区別する： - 偶発的な重複購入 - 意図的なマルチシートまたはチーム購入 - 壊れた製品/未達成の価値 - 失敗または不完全なチェックアウト - セルフサーブコントロールの欠如によるキャンセル - 年間プラン、チームプラン、按分状態については、アクションを取る前に契約の形状を確認する ## ワークフロー ### 1. 顧客を明確に特定する 利用可能な最強の識別子から始めます： - 顧客メール - StripeカスタマーID - サブスクリプションID - 請求書ID - GitHubユーザー名または請求に紐づくことがわかっているサポートメール 簡潔なアイデンティティサマリーを返します： - 顧客 - アクティブなサブスクリプション - キャンセルされたサブスクリプション - 請求書 - 重複するアクティブなサブスクリプションなどの明らかな異常 ### 2. 問題を分類する アクションを取る前に、ケースを1つのバケットに入れます： | ケース | 典型的なアクション | |------|----------------| | 重複する個人サブスクリプション | 余分をキャンセル、返金を検討 | | 実際のマルチシート/チームの意図 | シートを保持、請求モデルを明確にする | | 支払い失敗/不完全なチェックアウト | ポータルまたは支払い方法の更新で回復 | | セルフサーブコントロールの欠如 | ポータル、キャンセルパス、または請求書アクセスを提供 | | 製品の失敗または信頼の喪失 | 返金、謝罪、製品の問題を記録 | ### 3. 最初に最も安全で可逆的なアクションを取る 優先順位： 1. セルフサーブ管理を復元する 2. 重複または壊れた請求状態を修正する 3. 影響を受けた請求または重複分のみ返金する 4. 理由を文書化する 5. 短い顧客フォローアップを送る 修正が製品作業を必要とする場合、以下を分離します： - 今すぐの顧客救済 - バックログ向けの製品バグ/ワークフローギャップ ### 4. オペレーター側の製品ギャップを確認する 顧客の痛みが欠けているオペレーターサーフェスから来ている場合、明示的にそれを指摘します。一般的な例： - 請求ポータルなし - 使用量/レート制限の可視性なし - プラン/シートの説明なし - キャンセルフローなし - 重複サブスクリプションガードなし これらをサポートインシデントではなく、ECCまたはウェブサイトのフォローアップアイテムとして扱います。 ### 5. オペレーターへの引き渡しを生成する 以下で終わります： - 顧客状態サマリー - 取ったアクション - 収益への影響 - 送るフォローアップテキスト - 作成する製品またはバックログの課題 ## 出力形式 この構造を使用します： ```text CUSTOMER - name / email - relevant account identifiers BILLING STATE - active subscriptions - invoice or renewal state - anomalies DECISION - issue classification - why this action is correct ACTION TAKEN - refund / cancel / portal / no-op FOLLOW-UP - short customer message PRODUCT GAP - what should be fixed in the product or website ``` ## 良い推奨事項の例 - 「正しい修正は、カスタムダッシュボードではなく請求ポータルです」 - 「これは実際のチームシート購入ではなく、重複する個人チェックアウトのように見えます」 - 「重複請求の1件を返金し、残りのアクティブなサブスクリプションを保持し、その後必要に応じて顧客を組織請求に変換します」