Customer Billing Operations

Credit: This skill comes from ECC. We thank and credit the original author.

Use this skill for real customer billing work. Do not use it to design a general payment API.

The goal is to answer four questions:

1. Who is the customer?
2. What happened?
3. What is the safest fix?
4. What message should the customer get?

When to Use This Skill

Use this skill when:

• A customer says billing is broken.
• A customer asks for a refund.
• A customer cannot cancel.
• You find two active plans for one person.
• A payment or renewal failed.
• A checkout did not finish.
• A customer may leave because of a billing issue.
• You need to review plans, seats, or monthly and yearly billing.
• You need to create or test a billing portal.
• You need to check a complaint about a bill, refund, plan, or payment method.

Tools to Use

• Check the connected billing tool first, such as Stripe.
• Use email, GitHub, or issue tools only for added proof.
• Prefer the billing tool's own customer portal when it can do the job.
• Do not add custom account code when a safe hosted portal already works.
• Do not make outside calls that are not needed for the billing case.

Safety Rules

• Never show secret keys or full card data.
• Share only the customer data needed for the case.
• Never ask for a full card number or security code.
• Do not refund or cancel until you know which account and charge are correct.
• Do not make a money change without clear user approval.
• If approval is missing, give a proposed action only.
• State the exact amount, currency, charge, and plan before a refund or cancel action.
• Check the refund policy and local rules when they apply.
• Do not promise that a bank will post a refund at once.
• Keep a record of why each billing change was made.

Tell these cases apart:

• An extra personal plan bought by mistake
• A planned team or multi-seat purchase
• A product that failed to give the paid value
• A failed or unfinished checkout
• A cancel request caused by missing self-serve tools
• A charge that may be fraud
• A chargeback or open payment dispute
• A refund that was already sent
• A plan change with a partial charge or credit

For yearly plans, team plans, trials, coupons, tax, credits, and partial charges, check the full plan terms before acting.

Workflow

1. Find the Right Customer

Start with the best ID you have:

• Customer email
• Billing customer ID
• Subscription ID
• Invoice ID
• Payment or charge ID
• A support email or GitHub name known to match the billing account

Match at least two facts when you can. For example, match the email and invoice ID.

If two records may belong to the same person, do not merge them or change them yet. Show the conflict and ask for proof.

Return a short account summary:

• Customer name and masked email
• Active plans
• Ended or canceled plans
• Trial state
• Recent invoices and payments
• Refunds or disputes
• Clear odd states, such as two active personal plans

2. Class the Problem

Put the case in one main group before acting:

3. Check the Money and Dates

Before any change, confirm:

• Plan name
• Monthly or yearly term
• Seat count
• Trial dates
• Renewal date
• Cancel date and cancel-at-period-end state
• Invoice status
• Amount and currency
• Tax, coupon, credit, and partial charge
• Past refunds
• Open disputes
• Whether the customer still has access

Use the billing tool as the main source of truth. If email or support notes do not match it, state the mismatch.

4. Choose the Safest Fix

Use this order:

1. Restore safe self-serve access.
2. Fix a failed or duplicate billing state.
3. Refund only the charge or part that was harmed.
4. Keep the valid plan active unless the customer asked to end it.
5. Record the reason and IDs.
6. Draft a short customer message.

Choose a fix that can be undone when possible.

If the fix also needs product work, split it into:

• Help for the customer now
• A product task for later

5. Handle Key Edge Cases

• Duplicate plans: Check that they are not team seats or two different products.
• Partial refunds: Say how the amount was found.
• Yearly plans: Check the refund rules and used time.
• Cancel requests: State if access ends now or at the term end.
• Failed payment: Do not ask for card data. Use a secure billing portal.
• Refund already sent: Do not send it twice. Share the refund state and expected bank delay.
• Chargeback: Check the dispute before any refund.
• Fraud claim: Follow the fraud path. Do not treat it as a normal refund.
• No matching customer: Make no change. Ask for one safe ID, such as an invoice ID.
• More than one currency: Never mix amounts. List each currency on its own.
• Tool error: Stop. Report what was confirmed and what is still unknown.
• Test account: Make sure it is not live before using it as proof.
• Deleted account: Check for old invoices and active plans before saying billing has ended.

6. Find Product Gaps

Call out a product gap when the billing pain came from a missing tool or weak flow.

Common gaps include:

• No billing portal
• No view of usage or limits
• No clear plan or seat details
• No cancel path
• No guard against duplicate plans
• No clear refund state
• No clear notice for a failed renewal

Track these as ECC, product, or website tasks. Do not hide them inside the support case.

7. Hand Off the Case

End with:

• Customer state
• Facts checked
• Problem class
• Action taken or proposed
• Money impact
• Customer message
• Product task
• Any open risk or missing proof

Output Format

Use this format:

CUSTOMER
- name / masked email
- key account IDs

BILLING STATE
- active and ended subscriptions
- invoice, payment, refund, or renewal state
- amount and currency
- odd or conflicting facts

DECISION
- problem class
- why this is the safest choice

ACTION
- action taken, proposed action, or no action
- exact plan, charge, amount, and date
- approval state

REVENUE IMPACT
- refund, credit, saved plan, lost plan, or none

FOLLOW-UP
- short customer message

PRODUCT GAP
- product or website fix
- owner or next step, if known

OPEN ITEMS
- missing proof, tool errors, or risks

Concrete Example

A customer says, "I was charged twice. Please cancel one."

First, find the customer by email and invoice ID. The billing tool shows two active personal monthly plans for the same product. Both plans have one seat. They began five minutes apart. There is no team account.

The result should look like this:

CUSTOMER
- Sam / s***@example.com
- customer ID: cus_123
- subscriptions: sub_main and sub_extra

BILLING STATE
- two active personal monthly plans
- both plans have one seat
- both started on May 10
- two paid invoices for $20 USD each
- no past refund or open dispute

DECISION
- extra personal subscription
- the close start times and matching plans show a likely double checkout

ACTION
- proposed: cancel sub_extra
- proposed: refund its $20 USD charge
- keep sub_main active
- waiting for user approval before making changes

REVENUE IMPACT
- $20 USD refund
- one valid $20 USD monthly plan stays active

FOLLOW-UP
- We found a second plan that looks like a double checkout. We will cancel that extra plan and refund its $20 charge. Your main plan will stay active.

PRODUCT GAP
- add a check that warns users before they buy the same personal plan twice

OPEN ITEMS
- none

Good Advice

• "The safest fix is the hosted billing portal."
• "This looks like a double personal checkout, not a team seat purchase."
• "Refund the extra charge, keep the valid plan active, and explain what changed."
• "No billing change should be made until the customer record is clear."