Un paiement récurrent qui échoue représente entre 5 et 10 pour cent des transactions mensuelles sur la plupart des comptes Stripe d’abonnements, avec des pics à 15 pour cent sur certains mois. La majorité de ces échecs relève d’une carte expirée, d’un plafond temporaire ou d’un changement bancaire que le client n’a pas reporté sur son moyen de paiement enregistré. Sans action coordonnée, ces incidents se traduisent en pertes définitives : un abonné qui voit son service interrompu sans message clair part chez un concurrent dans la semaine qui suit. GoHighLevel permet de bâtir un workflow de relance entièrement automatisé qui détecte l’échec en temps réel, prévient le client par les bons canaux, lui offre une voie simple pour mettre à jour son moyen de paiement, et déclenche les actions internes nécessaires en cas de non-réponse. Cet article détaille la construction de ce workflow étape par étape, les points de vigilance qui font la différence entre une relance qui récupère 60 pour cent des paiements et une relance qui laisse partir les clients sans bruit.
Identifier le déclencheur Payment Failed et structurer la première relance
Le point de départ du workflow est le déclencheur natif Payment Failed disponible dans la bibliothèque de triggers GHL. Ce trigger se déclenche dès que Stripe ou la passerelle utilisée renvoie une erreur de prélèvement sur un abonnement ou un plan de paiement, peu importe la cause technique sous-jacente. Vous le sélectionnez depuis Workflows puis Create Workflow, puis Add Trigger, puis Payment Failed. La configuration permet de filtrer par produit ou par plan de paiement spécifique, ce qui est utile si vous gérez plusieurs offres avec des seuils de tolérance différents.
La première action du workflow doit être un envoi de message dans les minutes qui suivent l’échec, idéalement par email avec un objet explicite type votre paiement n’a pas pu être traité plutôt qu’un objet alarmiste. Le contenu de l’email doit indiquer clairement le montant concerné, la date de la tentative, la raison déclarée par la banque si l’API la remonte, et un bouton unique pour mettre à jour le moyen de paiement. Ce bouton renvoie vers une page Update Payment Method générée nativement par GHL, qui permet au client de saisir une nouvelle carte sans avoir à se reconnecter à son espace ni à fournir d’identifiants supplémentaires. Cette friction réduite est le principal levier de récupération immédiate. La logique de structuration des workflows transactionnels rejoint celle décrite dans notre guide sur les workflows GoHighLevel pour le suivi des leads qui détaille comment articuler triggers, actions et conditions dans un séquencement clair.
Construire la séquence multi-canal sur sept jours
La récupération d’un paiement échoué se joue sur les sept à dix jours qui suivent l’incident, après quoi la probabilité de récupération chute drastiquement. La séquence type combine email et SMS dans un calendrier précis. Jour zéro, l’email immédiat de notification dont le contenu a été décrit plus haut. Jour deux, un email de relance avec un ton légèrement plus engageant et un rappel des conséquences d’une interruption de service. Jour quatre, un SMS court avec le lien direct vers la page de mise à jour, parce que le SMS est ouvert dans les minutes qui suivent et capte les clients qui n’ouvrent pas leurs emails commerciaux. Jour six, un dernier email avec une formulation plus directe et un délai annoncé avant suspension du service.
Entre chaque action, le workflow doit inclure une condition If/Else qui vérifie si le paiement a été régularisé entre-temps. GHL propose un check natif Payment Successful sur le même contact et la même facture, qui retourne vrai dès que la banque a accepté un nouveau prélèvement. Si la condition est vraie, le workflow sort de la branche relance et déclenche un email de remerciement positif qui consolide la relation. Si la condition est fausse, le workflow continue vers l’action suivante. Cette logique de sortie conditionnelle évite les situations frustrantes où un client qui a déjà régularisé reçoit encore deux relances inutiles, ce qui dégrade la perception de la marque. Pour le détail de la mécanique If/Else et des conditions disponibles, le guide sur les actions et conditions des workflows GoHighLevel rappelle l’ensemble des opérateurs utilisables.
Personnaliser le ton et les variables dynamiques pour préserver la relation
Le ton des messages de relance pèse autant que leur cadence. Un message qui culpabilise le client ou qui dramatise l’incident génère un churn supérieur à un message qui adopte un ton informationnel neutre. La règle simple est de présenter l’échec comme un incident technique courant, de rappeler que la cause est dans la majorité des cas une carte expirée sans intervention du client, et de proposer la solution en une action unique. Les variables dynamiques GHL permettent de personnaliser chaque message avec le prénom du contact, le nom du produit concerné, le montant exact et la date de prochaine tentative automatique. Cette personnalisation rend les emails moins génériques et augmente leur taux d’ouverture.
Dans le cadre de la méthodologie PROPULSE que nous appliquons chez Propuls’Lead, les séquences de relance de paiement font l’objet d’un AB test systématique sur le ton et le rythme. Nous testons par exemple une version avec relance jour deux puis jour quatre puis jour six, contre une version avec relance jour un puis jour trois puis jour cinq. Sur certains comptes, la version compressée récupère 8 à 12 points de pourcentage supplémentaires, sur d’autres elle dégrade l’expérience et fait fuir les clients agacés. Aucune règle universelle ne s’applique, le test sur votre propre base est la seule manière de calibrer le bon équilibre. Cette discipline d’expérimentation chez Propuls’Lead permet aussi d’identifier les segments de clientèle qui réagissent mieux à un canal plutôt qu’un autre, ce qui ouvre la voie à des séquences différenciées selon la durée d’abonnement ou la valeur du contrat.
Gérer les escalades internes et la suspension du service
Au-delà de sept jours sans régularisation, le workflow doit déclencher des actions internes en plus des messages au client. Première action, l’assignation d’une tâche au commercial ou au support attitré du compte avec un script d’appel court à passer dans la journée. Cette intervention humaine récupère une fraction supplémentaire des comptes qui ne réagissent à aucun message automatique, parce qu’un coup de fil court résout souvent un blocage que l’écran ne parvient pas à débloquer. La création de cette tâche se fait via l’action Create Task de GHL, avec assignation automatique selon la propriétaire du contact, et la mécanique générale est couverte dans l’article sur les tâches internes et l’assignation dans GoHighLevel qui détaille le paramétrage des notifications associées.
Deuxième action, la suspension automatique du service si votre offre le permet techniquement, avec un message clair qui invite à régulariser pour récupérer l’accès. La suspension ne doit jamais être brutale ni définitive à ce stade, elle doit être présentée comme une pause technique réversible en un clic dès que le paiement passe. Troisième action, l’archivage du contact dans un segment Paiement en échec longue durée qui alimente un rapport hebdomadaire de pilotage. Ce segment permet de mesurer la performance globale du workflow de relance et de détecter les baisses de récupération avant qu’elles n’impactent significativement le chiffre d’affaires récurrent. Pour situer ces flux comptables dans une vue d’ensemble, les rapports de paiement GoHighLevel consolident les transactions récupérées et perdues sur la période, ce qui donne la mesure réelle de l’impact économique des relances automatisées.
Mesurer la performance du workflow et l’améliorer dans la durée
Un workflow de relance n’est jamais figé, il s’améliore mois après mois en fonction des métriques observées. Les trois indicateurs à suivre sont le taux de récupération global sur sept jours, le taux de récupération par canal pour identifier celui qui performe le mieux, et le délai médian entre l’échec initial et la régularisation. Ces métriques se construisent à partir des données natives GHL en croisant les événements Payment Failed et Payment Successful sur la même facture, soit via les rapports intégrés soit via un export vers un tableau de bord externe pour les comptes qui pilotent finement leur revenu récurrent. La cohérence comptable des transactions récupérées s’apprécie aussi via les factures émises depuis GoHighLevel qui doivent refléter les régularisations sans créer de doublons.
Un benchmark utile observé chez Propuls’Lead : un workflow bien calibré récupère entre 50 et 65 pour cent des paiements échoués dans les sept jours, avec une part importante captée par le premier email et le SMS de jour quatre. Si vos chiffres sont inférieurs à 40 pour cent, c’est probablement que la séquence est trop espacée, que le ton est trop alarmiste ou que le lien de mise à jour du moyen de paiement n’est pas suffisamment mis en avant. Si vos chiffres dépassent 70 pour cent, c’est un signe que votre base est très engagée et que votre offre est perçue comme essentielle, ce qui est un excellent indicateur de santé business. Dans tous les cas, mettre en place ce workflow dès les premiers abonnements actifs est un des leviers à plus fort retour sur investissement parmi les automatisations GHL, parce qu’il transforme du churn passif en revenu préservé avec un effort de configuration limité à quelques heures de travail initial.