客戶帳務運維 是做什麼的？
請將此技能用於實際的客戶操作，而非一般的支付 API 設計。
目標是協助操作者回答：這位客戶是誰、發生了什麼事、最安全的修復方式為何，以及我們應該傳送什麼後續通知？
使用時機
- 客戶表示帳務功能異常、要求退款或無法取消
- 調查重複訂閱、意外收費、續約失敗或客戶流失風險
- 審查方案組合、有效訂閱、年繳與月繳轉換或團隊席位混淆
- 建立或驗證帳務入口流程
- 稽核涉及訂閱、發票、退款或付款方式的支援投訴
偏好的工具介面
- 優先使用已串接的帳務工具，如 Stripe
- 電子郵件、GitHub 或問題追蹤器僅作為佐證資料
- 當平台已提供所需控制項時，優先使用託管的帳務/客戶入口，而非自訂的帳戶管理程式碼
安全護欄
- 絕不回覆中揭露密鑰、完整卡號或非必要的客戶個人識別資訊
- 不盲目退款；先分類問題
- 區分以下情境：
- 意外重複購買
- 有意的多席位或團隊購買
- 產品故障 / 未達預期價值
- 付款失敗或不完整的結帳流程
- 因缺少自助服務控制而取消訂閱
- 對於年繳方案、團隊方案及按比例計算的狀態，請先確認合約結構再採取行動
工作流程
1. 明確識別客戶
從可用的最強識別碼開始：
- 客戶電子郵件
- Stripe 客戶 ID
- 訂閱 ID
- 發票 ID
- GitHub 使用者名稱或支援電子郵件（若已知可對應到帳務）
回傳簡潔的身份摘要：
- 客戶
- 有效訂閱
- 已取消訂閱
- 發票
- 明顯異常，例如重複的有效訂閱
2. 分類問題
在採取行動前，先將案例歸納到一個類別：
| 案例 | 典型行動 |
|---|---|
| 重複的個人訂閱 | 取消多餘訂閱，考慮退款 |
| 真正的多席位/團隊意圖 | 保留席位，釐清帳務模式 |
| 付款失敗 / 不完整的結帳 | 透過入口恢復或更新付款方式 |
| 缺少自助服務控制 | 提供入口、取消路徑或發票存取權 |
| 產品故障或信任受損 | 退款、道歉、記錄產品問題 |
3. 先採取最安全的可逆操作
優先順序：
- 恢復自助服務管理
- 修復重複或異常的帳務狀態
- 僅退還受影響的費用或重複項目
- 記錄原因
- 傳送簡短的客戶後續通知
如果修復需要產品開發工作，請分開處理：
- 立即的客戶補償
- 待辦事項中的產品錯誤 / 工作流程缺口
4. 檢查操作端產品缺口
如果客戶的困擾來自缺少操作者介面，請明確指出。常見範例：
- 沒有帳務入口
- 沒有用量/速率限制檢視
- 沒有方案/席位說明
- 沒有取消流程
- 沒有重複訂閱防護
將這些視為工程變更控管或網站後續追蹤項目，而非僅是支援事件。
5. 產出操作者交接文件
結尾需包含：
- 客戶狀態摘要
- 已採取的動作
- 營收影響
- 要傳送的後續追蹤文字
- 需建立的產品或待辦事項
輸出格式
使用此結構：
客戶
- 姓名 / 電子郵件
- 相關帳戶識別碼
帳務狀態
- 有效訂閱
- 發票或續約狀態
- 異常狀況
決策
- 問題分類
- 為何此動作是正確的
已採動作
- 退款 / 取消 / 入口 / 無操作
後續追蹤
- 簡短的客戶訊息
產品缺口
- 產品或網站應修正的項目
良好建議範例
- 「正確的修復方式是帳務入口，而非自訂儀表板」
- 「這看起來是重複的個人結帳，而非真正的團隊席位購買」
- 「退還一筆重複費用，保留其餘有效訂閱，之後如有需要再將客戶轉換為組織帳務」