customer-billing-ops
affaan-m/ECC
利用 Stripe 等集成计费工具,处理客户计费工作流,例如订阅、退款、流失分级处理、计费门户恢复以及套餐分析。
...展开全部客户计费运营
请将此技能应用于实际的客户运营场景,而非泛泛的支付API设计。
其目标是帮助操作人员解答以下问题:这位客户是谁?发生了什么?最安全的解决方法是什么?以及我们应该发送什么样的后续通知?
何时使用
- 客户反映计费异常、要求退款或无法取消订阅时
- 调查重复订阅、误扣款、续订失败或流失风险
- 审查套餐组合、活跃订阅、年付与月付的转化情况,或团队席位相关混淆
- 创建或验证计费门户流程
- 审核涉及订阅、发票、退款或支付方式的客服投诉
首选工具界面
- 优先使用 Stripe 等集成式计费工具
- 仅将电子邮件、GitHub 或问题跟踪系统作为辅助证据
- 当平台已提供所需控制功能时,优先选用托管式计费/客户门户,而非自定义账户管理代码
防护措施
- 切勿在响应中暴露密钥、完整的卡片信息或不必要的客户个人身份信息
- 不要盲目退款;应先对问题进行分类
- 区分以下情况:
- 意外重复购买
- 故意购买多席位或团队套餐
- 产品故障/未达预期价值
- 结账失败或未完成
- 因缺少自助操作功能而导致的取消
- 对于年度套餐、团队套餐和按比例计费状态,在采取行动前请核实合同类型
工作流
1. 准确识别客户
从可用的最强标识符开始:
- 客户邮箱
- Stripe 客户 ID
- 订阅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
复制





首页
