Une facturation récurrente dont on n’a pas à se battre pour sortir

Le revenu récurrent est la forme la plus attirante qu’une entreprise puisse prendre, raison pour laquelle tant d’entreprises le poursuivent jusqu’à se faire détester de leurs clients.

Il y a deux défaillances contre lesquelles il vaut la peine de concevoir, et elles tirent dans des directions opposées.

La première : renoncer trop tôt

Un renouvellement échoue. Le solde était insuffisant ce matin-là. L’abonnement est résilié, l’accès s’arrête, et un client qui avait pleinement l’intention de continuer à payer est parti.

La plupart des renouvellements échoués ne sont pas des décisions. Ce sont des mardis.

Les relances sont la solution : un prélèvement échoué est réessayé selon un calendrier publié plutôt qu’abandonné à la première tentative. Étalés sur quelques jours, la plupart de ces paiements réussissent simplement, et le client n’apprend jamais qu’il y avait un problème.

Ce n’est pas glorieux et c’est la chose au meilleur rendement de toute la facturation récurrente.

La seconde : ne pas lâcher

La tentation inverse, et bien plus dommageable : rendre la résiliation difficile.

Cacher le bouton. Exiger un appel. Seulement aux heures de bureau. Proposer trois écrans de rétention avant le vrai.

Cela fonctionne, au sens où cela achète un mois de plus. Cela produit aussi un client qui en parle à tout le monde, et qui ne reviendra jamais — et, de plus en plus, un régulateur qui s’y intéresse.

La résiliation arrête ici le prochain prélèvement, depuis le côté du client. Pas d’appel, pas de labyrinthe de rétention, pas de ticket de support.

Une entreprise qui ne retient que les clients incapables de trouver la sortie n’a pas de revenu récurrent. Elle a un compte à rebours.

Un mandat, pas une carte conservée

Le prélèvement repose sur un mandat que le client a confirmé — un accord explicite d’être débité selon un calendrier.

C’est autre chose que garder un numéro de carte au dossier en espérant qu’il fonctionne encore. Le client a accepté l’arrangement, peut le voir, et peut y mettre fin.

Des événements, pour que votre système sache

Créé, résilié, facture payée, paiement échoué — tous publiés comme événements.

Votre produit peut suspendre l’accès quand les relances finissent par échouer, et le rétablir à l’instant où une reprise réussit, sans que personne n’interroge quoi que ce soit.

Les plans à l’usage

La consommation peut être enregistrée contre un abonnement : un plan qui facture ce qui a été consommé facture ce qui a été consommé.

Ce que cela coûte

Le tarif ordinaire sur les paiements encaissés. Il n’y a aucun frais pour le calendrier lui-même.

Ce que vous pouvez vérifier

Ce sont des faits sur la plateforme en fonctionnement, pas des adjectifs. Chacun est visible dans le produit, dans la référence de l’API ou dans le grand livre.

• Le prélèvement repose sur un mandat que le client a confirmé, pas sur un numéro de carte conservé au dossier.
• Un prélèvement échoué est réessayé selon un calendrier de relance publié plutôt qu’abandonné au premier échec.
• Les événements du cycle de vie — créé, résilié, facture payée, paiement échoué — sont publiés : votre système sait sans interroger.
• La consommation peut être enregistrée contre un abonnement là où un plan est facturé à l’usage plutôt qu’au forfait.

Ce que cela coûte

Les abonnements portent le tarif ordinaire sur les paiements qu’ils encaissent. Il n’y a aucun frais distinct pour le calendrier.

Est-ce activé ?

La disponibilité dépend des autorisations en place et de ce que l’administrateur d’un déploiement donné a activé. Cela change, un article non — la réponse vivante est donc sur la page de la fonctionnalité, qui la lit dans la plateforme elle-même : Abonnements et facturation récurrente sur la page des fonctionnalités.

À lire ensuite

• Liens de paiement — Être payé en envoyant un message.
• Notifications signées — Votre logiciel l’apprend avant votre client.
• L’API de la passerelle — Trois appels et une notification.