Billing ops

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:

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

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 SKC 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"

---

Finance Billing Ops

Use this when the user wants to understand money, pricing, refunds, team-seat logic, or whether the product actually behaves the way the website and sales copy imply.

This is broader than customer-billing-ops. That skill is for customer remediation. This skill is for operator truth: revenue state, pricing decisions, team billing, and code-backed billing behavior.

Skill Stack

Pull these SKC-native skills into the workflow when relevant:

• customer-billing-ops for customer-specific remediation and follow-up
• research-ops when competitor pricing or current market evidence matters
• market-research when the answer should end in a pricing recommendation
• github-ops when the billing truth depends on code, backlog, or release state in sibling repos
• verification-loop when the answer depends on proving checkout, seat handling, or entitlement behavior

When to Use

• user asks for Stripe sales, refunds, MRR, or recent customer activity
• user asks whether team billing, per-seat billing, or quota stacking is real in code
• user wants competitor pricing comparisons or pricing-model benchmarks
• the question mixes revenue facts with product implementation truth

Guardrails

• distinguish live data from saved snapshots
• separate:
  • revenue fact
  • customer impact
  • code-backed product truth
  • recommendation
• do not say "per seat" unless the actual entitlement path enforces it
• do not assume duplicate subscriptions imply duplicate value

Workflow

1. Start from the freshest billing evidence

Prefer live billing data. If the data is not live, state the snapshot timestamp explicitly.

Normalize the picture:

• paid sales
• active subscriptions
• failed or incomplete checkouts
• refunds
• disputes
• duplicate subscriptions

2. Separate customer incidents from product truth

If the question is customer-specific, classify first:

• duplicate checkout
• real team intent
• broken self-serve controls
• unmet product value
• failed payment or incomplete setup

Then separate that from the broader product question:

• does team billing really exist?
• are seats actually counted?
• does checkout quantity change entitlement?
• does the site overstate current behavior?

3. Inspect code-backed billing behavior

If the answer depends on implementation truth, inspect the code path:

• checkout
• pricing page
• entitlement calculation
• seat or quota handling
• installation vs user usage logic
• billing portal or self-serve management support

4. End with a decision and product gap

Report:

• sales snapshot
• issue diagnosis
• product truth
• recommended operator action
• product or backlog gap

Output Format

SNAPSHOT
- timestamp
- revenue / subscriptions / anomalies

CUSTOMER IMPACT
- who is affected
- what happened

PRODUCT TRUTH
- what the code actually does
- what the website or sales copy claims

DECISION
- refund / preserve / convert / no-op

PRODUCT GAP
- exact follow-up item to build or fix

Pitfalls

• do not conflate failed attempts with net revenue
• do not infer team billing from marketing language alone
• do not compare competitor pricing from memory when current evidence is available
• do not jump from diagnosis straight to refund without classifying the issue

Verification

• the answer includes a live-data statement or snapshot timestamp
• product-truth claims are code-backed
• customer-impact and broader pricing/product conclusions are separated cleanly