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