Maison

Skill

Autres

customer-billing-ops

affaan-m/ECC

Gérer les processus de facturation des clients, notamment les abonnements, les remboursements, le tri des résiliations, la réactivation via le portail de facturation et l'analyse des forfaits, à l'aide d'outils de facturation connectés tels que Stripe.

...Développer tout

Heure mise à jour 12 octobre 2026

# stripe # churn # subscriptions # refunds # billing portal # customer support # invoicing

Opérations de facturation client

Utilisez cette compétence pour des opérations clients réelles, et non pour la conception d’API de paiement génériques.

L'objectif est d'aider l'opérateur à répondre aux questions suivantes : qui est ce client, que s'est-il passé, quelle est la solution la plus sûre et quel suivi devons-nous envoyer ?

Quand l'utiliser

Le client signale un problème de facturation, demande un remboursement ou ne parvient pas à résilier son abonnement
Enquête sur les abonnements en double, les prélèvements accidentels, les renouvellements échoués ou les risques de désabonnement
Examiner la composition des formules, les abonnements actifs, la conversion annuelle par rapport à la conversion mensuelle, ou la confusion concernant les licences d'équipe
Créer ou valider le parcours utilisateur d’un portail de facturation
Audit des réclamations adressées au service client concernant les abonnements, les factures, les remboursements ou les modes de paiement

Outils recommandés

Utilisez en priorité des outils de facturation connectés tels que Stripe
N’utilisez les e-mails, GitHub ou les outils de suivi des tickets qu’à titre de preuves complémentaires
Privilégier les portails de facturation/client hébergés plutôt que le code personnalisé de gestion des comptes lorsque la plateforme fournit déjà les contrôles nécessaires

Mesures de sécurité

Ne divulguez jamais de clés secrètes, de détails complets de carte bancaire ou d’informations personnelles identifiables (PII) inutiles sur le client dans la réponse
Ne procédez pas à des remboursements à l’aveuglette ; commencez par classer le problème
Faites la distinction entre :
- un achat en double accidentel
- achat délibéré de plusieurs licences ou d’un forfait d’équipe
- produit défectueux / valeur non conforme
- paiement échoué ou incomplet
- annulation due à l'absence de commandes en libre-service
Pour les abonnements annuels, les abonnements d'équipe et les abonnements au prorata, vérifiez les modalités du contrat avant d'intervenir

Processus

1. Identifiez clairement le client

Commencez par l'identifiant le plus fiable dont vous disposez :

l'adresse e-mail du client
l'identifiant client Stripe
ID d'abonnement
l'identifiant de la facture
nom d'utilisateur GitHub ou e-mail du service client s'il est connu pour être associé à la facturation

Renvoyer un résumé concis des informations d'identité :

client
abonnements actifs
abonnements résiliés
factures
anomalies évidentes telles que les abonnements actifs en double

2. Classer le problème

Classer le cas dans une catégorie avant d’agir :

Cas	Action type
Abonnement personnel en double	annuler les options supplémentaires, envisager un remboursement
Véritable intention d'utilisation multi-postes/en équipe	Conserver les places, clarifier le modèle de facturation
Échec du paiement / processus de paiement incomplet	Récupération via le portail ou mise à jour du mode de paiement
Absence de commandes en libre-service	fournir un portail, une procédure d’annulation ou un accès aux factures
Défaillance du produit ou perte de confiance	Rembourser, présenter des excuses, enregistrer le problème lié au produit

3. Prendre d’abord la mesure réversible la plus sûre

Ordre recommandé :

rétablir la gestion en libre-service
corriger les doublons ou les anomalies de facturation
rembourser uniquement les frais concernés ou les doublons
documenter la raison
envoyer un bref message de suivi au client

Si la correction nécessite une intervention sur le produit, traiter séparément :

la résolution du problème pour le client dès maintenant
bug du produit / lacune dans le workflow à ajouter au backlog

4. Vérifier les lacunes du produit du côté de l’opérateur

Si le problème rencontré par le client provient d’une interface opérateur manquante, signalez-le explicitement. Exemples courants :

pas de portail de facturation
pas de visibilité sur l’utilisation ni sur les limites de débit
pas d’explications sur les forfaits/licences
pas de procédure de résiliation
pas de protection contre les abonnements en double

Considérez ces éléments comme des points à suivre dans l'ECC ou sur le site web, et non pas simplement comme des incidents d'assistance.

5. Préparer le transfert vers l’opérateur

Terminer par :

un résumé de la situation du client
mesures prises
impact sur le chiffre d'affaires
texte de suivi à envoyer
problème lié au produit ou au backlog à créer

Format de sortie

Utilisez cette structure :

CLIENT
- nom / e-mail
- identifiants de compte pertinents

ÉTAT DE FACTURATION
- abonnements actifs
- état de la facture ou du renouvellement
- anomalies

DÉCISION
- classification du problème
- pourquoi cette action est justifiée

ACTION ENTREPRISE
- remboursement / annulation / portail / aucune action

SUIVI
- court message destiné au client

LACUNE DU PRODUIT
- ce qui doit être corrigé dans le produit ou sur le site web

Exemples de bonnes recommandations

« La bonne solution est un portail de facturation, et non pas encore un tableau de bord personnalisé »
« Cela ressemble à un double paiement personnel, et non à un véritable achat de licence d’équipe »
« Remboursez l’un des prélèvements en double, conservez l’abonnement actif restant, puis faites passer le client à la facturation d’organisation ultérieurement si nécessaire »

Voir sur GitHub

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

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

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