顧客請求業務

このスキルは、汎用的な支払いAPI設計ではなく、実際の顧客業務のために使用します。

目標は、オペレーターが以下に答えるのを助けることです：この顧客は誰か、何が起きたか、最も安全な修正は何か、どのようなフォローアップを送るべきか？

使用時期

• 顧客が請求が壊れている、返金が必要、またはキャンセルできないと言っている場合
• 重複サブスクリプション、偶発的な請求、失敗した更新、またはチャーンリスクを調査する場合
• プランミックス、アクティブなサブスクリプション、年間対月間の変換、またはチームシートの混乱をレビューする場合
• 請求ポータルフローの作成または検証
• サブスクリプション、請求書、返金、または支払い方法に関するサポートの苦情を監査する場合

推奨ツールサーフェス

• Stripeなどの接続された請求ツールを最初に使用する
• メール、GitHub、または課題トラッカーは補足証拠としてのみ使用する
• プラットフォームが必要なコントロールをすでに提供している場合、カスタムアカウント管理コードよりもホストされた請求/顧客ポータルを優先する

ガードレール

• レスポンスに秘密鍵、完全なカード詳細、または不必要な顧客PIIを公開しない
• 盲目的に返金しない。まず問題を分類する
• 以下を区別する：
  • 偶発的な重複購入
  • 意図的なマルチシートまたはチーム購入
  • 壊れた製品/未達成の価値
  • 失敗または不完全なチェックアウト
  • セルフサーブコントロールの欠如によるキャンセル
• 年間プラン、チームプラン、按分状態については、アクションを取る前に契約の形状を確認する

ワークフロー

1. 顧客を明確に特定する

利用可能な最強の識別子から始めます：

• 顧客メール
• StripeカスタマーID
• サブスクリプションID
• 請求書ID
• GitHubユーザー名または請求に紐づくことがわかっているサポートメール

簡潔なアイデンティティサマリーを返します：

• 顧客
• アクティブなサブスクリプション
• キャンセルされたサブスクリプション
• 請求書
• 重複するアクティブなサブスクリプションなどの明らかな異常

2. 問題を分類する

アクションを取る前に、ケースを1つのバケットに入れます：

3. 最初に最も安全で可逆的なアクションを取る

優先順位：

1. セルフサーブ管理を復元する
2. 重複または壊れた請求状態を修正する
3. 影響を受けた請求または重複分のみ返金する
4. 理由を文書化する
5. 短い顧客フォローアップを送る

修正が製品作業を必要とする場合、以下を分離します：

• 今すぐの顧客救済
• バックログ向けの製品バグ/ワークフローギャップ

4. オペレーター側の製品ギャップを確認する

顧客の痛みが欠けているオペレーターサーフェスから来ている場合、明示的にそれを指摘します。一般的な例：

• 請求ポータルなし
• 使用量/レート制限の可視性なし
• プラン/シートの説明なし
• キャンセルフローなし
• 重複サブスクリプションガードなし

これらをサポートインシデントではなく、ECCまたはウェブサイトのフォローアップアイテムとして扱います。

5. オペレーターへの引き渡しを生成する

以下で終わります：

• 顧客状態サマリー
• 取ったアクション
• 収益への影響
• 送るフォローアップテキスト
• 作成する製品またはバックログの課題

出力形式

この構造を使用します：

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件を返金し、残りのアクティブなサブスクリプションを保持し、その後必要に応じて顧客を組織請求に変換します」