customer-billing-ops

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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?

注意：本技能用于实际客户操作，而非通用支付API设计。

其目标是帮助运营人员解答以下问题：该客户是谁？发生了什么问题？最安全的修复方案是什么？我们需要发送什么后续跟进内容？

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

客户反馈账单异常、想要退款，或者无法取消订阅
排查重复订阅、意外扣费、续费失败或者客户流失风险
复盘套餐组合、有效订阅、年付vs月付转化率，或者团队席位使用疑问
创建或验证账单门户流程
审计涉及订阅、发票、退款或支付方式的客户支持投诉

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

优先使用Stripe等已对接的账单工具
仅将邮件、GitHub或问题跟踪器作为辅助佐证
当平台已提供所需管控能力时，优先使用托管式账单/客户门户，而非自定义账户管理代码

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

永远不要在响应中暴露密钥、完整银行卡信息，或者非必要的客户PII（个人可识别信息）
不要盲目退款，先对问题进行分类
区分以下不同场景：
- 意外重复购买
- 刻意的多席位/团队采购
- 产品故障/未兑现价值
- 结账失败或未完成
- 因缺少自助服务功能导致的取消
对于年付套餐、团队套餐和按比例计费状态，在采取行动前先核实合同约定

Workflow

工作流程

1. Identify the customer cleanly

1. 准确识别客户身份

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

从可用的最高效识别符开始查询：

客户邮箱
Stripe客户ID
订阅ID
发票ID
已知可关联到账单信息的GitHub用户名或支持邮箱

返回简洁的身份摘要：

客户信息
有效订阅
已取消订阅
发票信息
明显异常，例如重复的有效订阅

2. Classify the issue

2. 问题分类

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

3. 优先采取最安全的可撤销操作

Preferred order:

restore self-serve management
fix duplicate or broken billing state
refund only the affected charge or duplicate
document the reason
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

4. 检查运营侧的产品缺口

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.

如果客户的痛点来自于运营端缺少相关功能，明确指出。常见示例：

无账单门户
无使用量/速率限制可见性
无套餐/席位说明
无取消流程
无重复订阅防护机制

将这些作为ECC或网站后续优化项，而非仅当作支持事件处理。

5. Produce the operator handoff

5. 生成运营交接内容

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

使用如下结构：

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"

"正确的解决方案是上线账单门户，暂时不需要开发自定义仪表盘"
"这看起来是个人重复结账，而非真实的团队席位采购"
"退还一笔重复扣费，保留剩下的有效订阅，后续如有需要再将客户转换为组织账单模式"