Customer Billing Ops

# 顧客請求業務

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

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

## 使用時期

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

## 推奨ツールサーフェス

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

## ガードレール

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

## ワークフロー

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

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

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

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

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

### 2. 問題を分類する

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

| ケース | 典型的なアクション |
|------|----------------|
| 重複する個人サブスクリプション | 余分をキャンセル、返金を検討 |
| 実際のマルチシート/チームの意図 | シートを保持、請求モデルを明確にする |
| 支払い失敗/不完全なチェックアウト | ポータルまたは支払い方法の更新で回復 |
| セルフサーブコントロールの欠如 | ポータル、キャンセルパス、または請求書アクセスを提供 |
| 製品の失敗または信頼の喪失 | 返金、謝罪、製品の問題を記録 |

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

優先順位：

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

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

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

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