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