Back to Details

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:
CaseTypical action
Duplicate personal subscriptioncancel extras, consider refund
Real multi-seat/team intentpreserve seats, clarify billing model
Failed payment / incomplete checkoutrecover via portal or update payment method
Missing self-serve controlsprovide portal, cancellation path, or invoice access
Product failure or trust breakrefund, apologize, log product issue
采取行动前先将案件归入以下某一类别：
场景典型操作
个人订阅重复取消额外订阅，可考虑退款
真实的多席位/团队采购意图保留席位，明确账单模式
支付失败/结账未完成通过门户恢复流程或更新支付方式
缺少自助服务功能提供门户入口、取消路径或发票访问权限
产品故障或信任受损退款、致歉、记录产品问题

3. Take the safest reversible action first

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

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
优先顺序：
  1. 恢复自助管理能力
  2. 修复重复或异常的账单状态
  3. 仅对受影响的扣费或重复扣费项退款
  4. 记录操作原因
  5. 发送简短的客户跟进信息
如果修复需要产品开发工作，分开处理：
  • 即时的客户补救措施
  • 待加入待办列表的产品漏洞/工作流缺口

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