customer-billing-ops
用 Stripe 等工具處理訂閱、退款和流失的客戶帳務問題
中文翻譯
--- name: customer-billing-ops description: 透過 Stripe 等已連接的帳務工具，處理訂閱、退款、流失分流、帳務入口網站救援和方案分析這類客戶帳務工作流程。當使用者需要幫助客戶、檢查訂閱狀態，或處理會影響營收的帳務操作時使用。 metadata: origin: ECC --- # 客戶帳務營運 這個 skill 用在真實的客戶營運，不是通用的支付 API 設計。 目標是幫操作者回答：這個客戶是誰、發生了什麼事、最安全的修法是什麼、後續該寄什麼訊息。 ## 何時使用 - 客戶說帳務有問題、想要退款，或無法取消 - 調查重複訂閱、誤扣款、續約失敗或流失風險 - 檢視方案組合、有效訂閱、年繳 vs 月繳的轉換，或團隊席次的混淆 - 建立或驗證帳務入口網站的流程 - 稽核跟訂閱、發票、退款或付款方式有關的客服抱怨 ## 偏好的工具介面 - 優先使用 Stripe 這類已連接的帳務工具 - email、GitHub 或 issue tracker 只當作輔助證據 - 平台已經提供所需控制功能時，優先用平台代管的帳務/客戶入口網站，不要自己寫帳號管理的程式碼 ## 護欄 - 絕對不要在回應中暴露 secret key、完整卡號或不必要的客戶個資 - 不要盲目退款；先把問題分類 - 要區分： - 誤買的重複購買 - 刻意的多席次或團隊購買 - 產品壞掉 / 價值沒達到 - 結帳失敗或沒完成 - 因為缺少自助控制功能而取消 - 年繳方案、團隊方案和按比例計費的狀態，動手之前要先確認合約的形式 ## 工作流程 ### 1. 乾淨地辨識客戶 從手邊最強的識別資訊開始： - 客戶 email - Stripe customer ID - subscription ID - invoice ID - GitHub 使用者名稱或客服 email（如果已知能對應回帳務資料） 回傳一份簡短的身分摘要： - 客戶 - 有效訂閱 - 已取消的訂閱 - 發票 - 明顯的異常，例如重複的有效訂閱 ### 2. 把問題分類 動手前先把案例放進一個類別： | 案例 | 典型動作 | |------|----------------| | 重複的個人訂閱 | 取消多的，考慮退款 | | 真的有多席次/團隊需求 | 保留席次，釐清帳務模式 | | 付款失敗 / 結帳未完成 | 透過入口網站救援，或更新付款方式 | | 缺少自助控制功能 | 提供入口網站、取消的路徑或發票存取 | | 產品故障或信任受損 | 退款、道歉、記錄產品問題 | ### 3. 先做最安全、可回復的動作 偏好的順序： 1. 恢復自助管理 2. 修好重複或壞掉的帳務狀態 3. 只退受影響的那筆扣款或重複的那筆 4. 記錄原因 5. 寄一封簡短的客戶後續訊息 如果修復需要產品面的工作，要分開處理： - 現在要做的客戶補救 - 要放進 backlog 的產品 bug / 工作流程缺口 ### 4. 檢查操作者端的產品缺口 如果客戶的痛點來自缺少操作者介面，要明確點出來。常見的例子： - 沒有帳務入口網站 - 看不到用量/rate limit - 沒有方案/席次的說明 - 沒有取消的流程 - 沒有防止重複訂閱的機制 把這些當成 ECC 或網站的後續事項，不要只當成客服事件。 ### 5. 產出操作者交接 結尾要包含： - 客戶狀態摘要 - 已採取的動作 - 營收影響 - 要寄出的後續訊息文字 - 要建立的產品或 backlog issue ## 輸出格式 使用這個結構： ```text 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 ``` ## 好的建議範例 - 「正確的修法是做帳務入口網站，現在還不用做自訂的 dashboard」 - 「這看起來是重複的個人結帳，不是真的團隊席次購買」 - 「退掉一筆重複的扣款，保留剩下的有效訂閱，之後有需要再把客戶轉成組織帳務」
英文原文
--- name: customer-billing-ops description: Operate customer billing workflows such as subscriptions, refunds, churn triage, billing-portal recovery, and plan analysis using connected billing tools like Stripe. Use when the user needs to help a customer, inspect subscription state, or manage revenue-impacting billing operations. metadata: origin: ECC --- # Customer Billing Ops Use this skill for real customer operations, not generic payment API design. The goal is to help the operator answer: who is this customer, what happened, what is the safest fix, and what follow-up should we send? ## When to Use - Customer says billing is broken, they want a refund, or they cannot cancel - Investigating duplicate subscriptions, accidental charges, failed renewals, or churn risk - Reviewing plan mix, active subscriptions, yearly vs monthly conversion, or team-seat confusion - Creating or validating a billing portal flow - Auditing support complaints that touch subscriptions, invoices, refunds, or payment methods ## Preferred Tool Surface - Use connected billing tools such as Stripe first - Use email, GitHub, or issue trackers only as supporting evidence - Prefer hosted billing/customer portals over custom account-management code when the platform already provides the needed controls ## Guardrails - Never expose secret keys, full card details, or unnecessary customer PII in the response - Do not refund blindly; first classify the issue - Distinguish among: - accidental duplicate purchase - deliberate multi-seat or team purchase - broken product / unmet value - failed or incomplete checkout - cancellation due to missing self-serve controls - For annual plans, team plans, and prorated states, verify the contract shape before taking action ## Workflow ### 1. Identify the customer cleanly Start from the strongest identifier available: - customer email - Stripe customer ID - subscription ID - invoice ID - GitHub username or support email if it is known to map back to billing Return a concise identity summary: - customer - active subscriptions - canceled subscriptions - invoices - obvious anomalies such as duplicate active subscriptions ### 2. Classify the issue Put the case into one bucket before acting: | Case | Typical action | |------|----------------| | Duplicate personal subscription | cancel extras, consider refund | | Real multi-seat/team intent | preserve seats, clarify billing model | | Failed payment / incomplete checkout | recover via portal or update payment method | | Missing self-serve controls | provide portal, cancellation path, or invoice access | | Product failure or trust break | refund, apologize, log product issue | ### 3. Take the safest reversible action first Preferred order: 1. restore self-serve management 2. fix duplicate or broken billing state 3. refund only the affected charge or duplicate 4. document the reason 5. send a short customer follow-up If the fix requires product work, separate: - customer remediation now - product bug / workflow gap for backlog ### 4. Check operator-side product gaps If the customer pain comes from a missing operator surface, call it out explicitly. Common examples: - no billing portal - no usage/rate-limit visibility - no plan/seat explanation - no cancellation flow - no duplicate-subscription guard Treat those as ECC or website follow-up items, not just support incidents. ### 5. Produce the operator handoff End with: - customer state summary - action taken - revenue impact - follow-up text to send - product or backlog issue to create ## Output Format Use this structure: ```text 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 ``` ## Examples of Good Recommendations - "The right fix is a billing portal, not a custom dashboard yet" - "This looks like duplicate personal checkout, not a real team-seat purchase" - "Refund one duplicate charge, keep the remaining active subscription, then convert the customer to org billing later if needed"