customer-billing-ops
affaan-m/ECC
利用 Stripe 等連線的計費工具,執行客戶計費工作流程,例如訂閱、退款、流失案件分流、計費入口網站帳戶恢復以及方案分析。
...展開全部客戶帳單作業
請將這項技能應用於實際的客戶營運情境,而非泛用的付款 API 設計。
目標是協助操作人員釐清:這位客戶是誰、發生了什麼事、最安全的解決方式是什麼,以及我們應該發送哪些後續通知?
何時適用
- 客戶表示計費系統出錯、要求退款,或無法取消訂閱時
- 調查重複訂閱、誤收費用、續約失敗或流失風險
- 審查方案組合、有效訂閱、年付與月付轉換率,或團隊席位混淆問題
- 建立或驗證計費入口網站的流程
- 審核涉及訂閱、發票、退款或付款方式的客服投訴
首選工具介面
- 優先使用已整合的計費工具(例如 Stripe)
- 僅將電子郵件、GitHub 或問題追蹤系統作為輔助證據
- 當平台已提供所需控制功能時,應優先選用託管式計費/客戶入口網站,而非自訂的帳戶管理程式碼
防護措施
- 切勿在回應中洩露密鑰、完整的信用卡資料或不必要的客戶個人識別資訊
- 切勿盲目退款;應先對問題進行分類
- 請區分以下情況:
- 意外重複購買
- 刻意進行的多席位或團隊購買
- 產品故障/未達預期價值
- 結帳失敗或未完成
- 因缺乏自助控制功能而導致的取消
- 針對年度方案、團隊方案及按比例計費狀態,請在採取行動前確認合約類型
工作流程
1. 明確識別客戶
請從現有最可靠的識別資訊開始:
- 客戶電子郵件
- Stripe 客戶 ID
- 訂閱 ID
- 發票編號
- 若已知可追溯至帳單資訊,則為 GitHub 使用者名稱或支援電子郵件
回傳簡明的身分摘要:
- 客戶
- 有效訂閱
- 已取消的訂閱
- 發票
- 明顯的異常情況,例如重複的有效訂閱
2. 分類問題
在採取行動前,先將此案例歸類至其中一類:
| 案例 | 典型處理方式 |
|---|---|
| 重複的個人訂閱 | 取消額外服務,考慮退款 |
| 真正的多席位/團隊用途 | 保留席位,釐清計費模式 |
| 付款失敗/結帳未完成 | 透過入口網站恢復或更新付款方式 |
| 缺少自助管理功能 | 提供入口網站、取消流程或發票存取權限 |
| 產品故障或信任破裂 | 辦理退款、致歉、記錄產品問題 |
3. 優先採取最安全且可逆的措施
建議順序:
- 恢復自助管理功能
- 修正重複或異常的計費狀態
- 僅退還受影響的費用或重複收費
- 記錄原因
- 發送簡短的客戶後續追蹤通知
若解決問題需進行產品端作業,請分開處理:
- 立即對客戶進行補救
- 產品錯誤/工作流程缺口,納入待辦事項
4. 檢查操作端產品缺口
若客戶痛點源於操作介面功能缺失,請明確指出。常見範例:
- 缺乏計費入口網站
- 缺乏使用量/速率限制的可視化
- 缺乏方案/授權說明
- 缺乏取消訂閱流程
- 缺乏重複訂閱防護機制
請將這些視為 ECC 或網站後續處理事項,而非單純的支援案件。
5. 製作客服人員交接流程
結尾應包含:
- 客戶狀態摘要
- 已採取的行動
- 對營收的影響
- 後續需發送的文字
- 需建立的產品或待辦事項問題
輸出格式
請使用以下結構:
客戶
- 姓名 / 電子郵件
- 相關帳戶識別碼
帳務狀態
- 有效訂閱
- 發票或續約狀態
- 異常狀況
決策
- 問題分類
- 為何此行動是正確的
已採取的行動
- 退款 / 取消 / 入口網站 / 無操作
後續處理
- 簡短的客戶訊息
產品缺失
- 產品或網站中應修正之處
良好建議的範例
- 「正確的解決方案是建立帳單入口網站,目前還不需要自訂儀表板」
- 「這看起來像是重複的個人結帳,並非真正的團隊席位購買」
- 「退還一筆重複的費用,保留其餘的有效訂閱,日後如有需要,再將該客戶轉換為組織帳單」
---
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.
---
# 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"
所有檔案
1 個檔案安裝 customer-billing-ops
請下載並將技能檔案解壓縮至您的 .claude/skills/ 目錄中。
下載 ZIP複製儲存庫並將技能檔案複製到您的專案中。
git clone https://github.com/affaan-m/ECC/tree/main/skills/customer-billing-ops # Copy SKILL.md to your .claude/skills/ directory
複製





首頁
