customer-billing-ops

Use it when:: A customer says billing is broken, wants a refund or can't cancel, or you're chasing duplicate subscriptions, failed renewals or churn risk.
It does:: Finds the customer from an email or Stripe ID, puts the case in one of five buckets, then prefers restoring self-serve control over refunding.
You get:: An operator handoff: customer and billing state, the decision and why, the action taken, a short customer message and the product gap to fix.
Unlike payment API guides:: This one is for handling real customers' billing, not writing billing code.
Guardrails:: Never shows secret keys, full card details or unneeded personal data, and never refunds before classifying the case.

It acts on your billing account through whatever Stripe or billing tool the agent has connected, and can cancel subscriptions and issue refunds.

TL;DR

A support workflow for subscription billing problems, built around four questions: who is this customer, what happened, what's the safest fix and what should we send them. It prefers a connected billing tool such as Stripe, with email, GitHub or issue trackers only as supporting evidence. It starts from the strongest identifier, such as an email, customer, subscription or invoice ID, and summarizes active and canceled subscriptions, invoices and anomalies like duplicate active subscriptions. Each case goes into one bucket before any action: duplicate personal subscription, real team purchase, failed or incomplete checkout, missing self-serve controls, or product failure. Actions follow a fixed order of preference: restore self-serve management, fix the broken billing state, refund only the affected charge, document why, then send a short follow-up. Annual, team and prorated plans get their contract checked first. When the pain comes from a missing billing portal, cancellation flow or duplicate-subscription guard, it reports that as a product gap rather than a one-off ticket.

Summarizes the skill at d2ef268.

npx skills add https://github.com/affaan-m/ecc --skill customer-billing-ops

skills.sh page Source on GitHub All skills from affaan-m/ecc

Weekly Downloads week to Nov 9, 2026

439

+71% in 8 weeks

More weekly downloads than 56% of skills

Weekly values

Week to	Installs
Sep 21	257
Sep 28	160
Oct 5	137
Oct 12	230
Oct 19	412
Oct 26	399
Nov 2	468
Nov 9	439

Total Downloads on skills.sh

5,300

Fewer downloads than 91% of skills

Repo stars affaan-m/ecc

299,776

More stars than 97% of repos

Age published May 19, 2026

5 months

Newer than 66% of skills

Category	category:business Run a company outside its code and marketing: strategy, sales, finance, operations, legal, management and hiring.
Type	type:workflow A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect	effect:remote Its own steps change something outside your machine: post, send, deploy, provision, file issues, drive a website, or upload data to a service.
Needs	needs:account An account, API key or paid plan with an outside service.
Publisher	by:community Everyone else. Unverified vendor claims default to community.
Topics	payments ecommerce
Stack	stack:stripe

SKILL.md

From affaan-m/ecc at d2ef268. Checked daily, last changed Nov 6, 2026.

Frontmatter

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. Use when the user needs to help a customer, inspect subscription state, or manage revenue-impacting billing operations.
metadata:
  origin: ECC

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 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:

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"