カスタマー請求業務 は何をしますか？
このスキルは、一般的な決済API設計ではなく、実際の顧客業務のために使用します。
目的は、運用担当者が「この顧客は誰か、何が起こったか、最も安全な修正方法は何か、どのようなフォローアップを送るべきか」を答えられるようにすることです。
使用するタイミング
- 顧客が請求が壊れている、返金を希望する、または解約できないと申し出た場合
- 重複サブスクリプション、誤請求、更新失敗、解約リスクを調査する場合
- プランミックス、アクティブなサブスクリプション、年払いと月払いの変換、チームシートの混乱を確認する場合
- 請求ポータルのフローを作成または検証する場合
- サブスクリプション、請求書、返金、または支払い方法に関連するサポート苦情を監査する場合
推奨ツール
- まずStripeなどの接続された請求ツールを使用する
- メール、GitHub、または課題トラッカーは補足的な証拠としてのみ使用する
- プラットフォームが既に必要なコントロールを提供している場合は、カスタムアカウント管理コードよりもホスト型の請求/顧客ポータルを優先する
ガードレール
- 応答に秘密鍵、完全なカード詳細、または不要な顧客PIIを決して公開しない
- 盲目的に返金せず、まず問題を分類する
- 以下を区別する：
- 偶発的な重複購入
- 意図的なマルチシートまたはチーム購入
- 製品の欠陥または価値の不足
- 失敗または不完全なチェックアウト
- セルフサービス管理機能の欠如による解約
- 年払いプラン、チームプラン、および按分状態については、アクションを起こす前に契約内容を確認する
ワークフロー
1. 顧客を明確に特定する
利用可能な最も強力な識別子から開始する：
- 顧客のメールアドレス
- Stripeの顧客ID
- サブスクリプションID
- 請求書ID
- 請求にマッピングできることがわかっているGitHubユーザー名またはサポートメール
簡潔な身元情報を返す：
- 顧客
- アクティブなサブスクリプション
- 解約済みサブスクリプション
- 請求書
- 重複するアクティブサブスクリプションなどの明らかな異常
2. 問題を分類する
アクションを起こす前に、ケースを1つのカテゴリに分類する：
| ケース | 典型的なアクション |
|---|---|
| 個人サブスクリプションの重複 | 追加分を解約、返金を検討 |
| 本当のマルチシート/チーム意図 | シートを維持、請求モデルを明確化 |
| 支払い失敗/不完全なチェックアウト | ポータル経由で復旧、または支払い方法を更新 |
| セルフサービス管理機能の欠如 | ポータル、解約パス、または請求書へのアクセスを提供 |
| 製品の欠陥または信頼の喪失 | 返金、謝罪、製品問題を記録 |
3. 最初に最も安全で可逆性の高いアクションを実行する
優先順位：
- セルフサービス管理を復元する
- 重複または壊れた請求状態を修正する
- 影響を受けた請求または重複のみを返金する
- 理由を文書化する
- 短い顧客フォローアップを送信する
修正に製品作業が必要な場合は、以下を分離する：
- 今すぐの顧客是正
- バックログ用の製品バグ/ワークフローギャップ
4. 運用担当者側の製品ギャップを確認する
顧客の苦痛が運用担当者向けの機能不足に起因する場合、それを明示的に指摘する。一般的な例：
- 請求ポータルがない
- 使用量/レート制限の可視性がない
- プラン/シートの説明がない
- 解約フローがない
- 重複サブスクリプション防止策がない
これらを単なるサポートインシデントとしてではなく、ECCまたはWebサイトのフォローアップ項目として扱う。
5. 運用担当者へのハンドオフを作成する
以下で締めくくる：
- 顧客の状態の要約
- 実行したアクション
- 収益への影響
- 送信するフォローアップテキスト
- 作成する製品またはバックログの課題
出力形式
以下の構造を使用する：
顧客
- 名前 / メール
- 関連するアカウント識別子
請求状態
- アクティブなサブスクリプション
- 請求書または更新状態
- 異常
判断
- 問題の分類
- このアクションが正しい理由
実行したアクション
- 返金 / 解約 / ポータル / 何もしない
フォローアップ
- 短い顧客メッセージ
製品ギャップ
- 製品またはWebサイトで修正すべき点
適切な推奨の例
- 「正しい修正方法は請求ポータルであり、まだカスタムダッシュボードではありません」
- 「これは実際のチームシート購入ではなく、個人の重複チェックアウトのように見えます」
- 「1つの重複請求を返金し、残りのアクティブサブスクリプションを維持して、後で必要に応じて顧客を組織請求に変換します」