| name | customer-billing-ops |
| description | Operate customer billing workflows — subscriptions, refunds, churn triage, and plan analysis via Stripe. Use when the user needs to help a customer, inspect subscription state, or manage billing operations. |
| origin | MCC |
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:
- 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
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 MCC 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:
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"
