Gérer expansion et perte de clients

Comment suivre dans HubSpot une montée en gamme, une descente en gamme et un client qui s'en va ?

Ces trois mouvements ne se modélisent pas de la même manière, et c'est là que beaucoup se trompent.

Une montée en gamme est une transaction. Il y a un revenu supplémentaire, donc un événement de vente à mesurer.
Une descente en gamme est aussi une transaction, avec un montant négatif ou un montant nul selon votre convention, et un motif renseigné.
Une perte de client n'est pas une transaction. C'est un changement d'état du compte.

Un fait qui confirme ce découpage. Les propriétés de revenu récurrent proposent nouvelle affaire, renouvellement, montée en gamme et descente en gamme comme types, tandis que la perte n'apparaît que comme motif d'inactivité. HubSpot fait donc la même distinction.

Le piège à connaître. La phase du cycle de vie ne recule pas, et un retour arrière efface la date d'atteinte de la phase la plus avancée sans effacer les propriétés calculées. Modéliser une perte de client par un recul du cycle de vie abîme donc votre historique.

Pourquoi une perte de client n'est pas une transaction

Pourquoi la perte ne peut pas être une transaction. Une transaction porte un montant et une date de clôture, et elle alimente les prévisions. Un départ de client ne produit aucun revenu. Le modéliser comme une transaction perdue mélangerait deux choses très différentes, à savoir une affaire que vous n'avez pas gagnée et un client que vous avez perdu. Vos taux de conversion en seraient faussés.

Où porter l'état d'un compte perdu. Sur l'entreprise, par une propriété de statut d'abonnement et une date de fin. Et si vous utilisez les propriétés de revenu récurrent, par le motif d'inactivité, qui propose la perte aux côtés du renouvellement et des deux mouvements de gamme.

La contrainte du cycle de vie est ici décisive, et elle est structurante. La phase du cycle de vie ne recule pas. Elle ne peut être avancée que par les outils HubSpot, et pour redescendre il faut d'abord vider la valeur. Pire, un retour arrière abîme l'historique, puisque la date d'atteinte de la phase la plus avancée est effacée alors que les nouvelles propriétés calculées ne le sont pas.

Conséquence pratique, et c'est notre recommandation. Ne modélisez pas la perte par un recul du cycle de vie. Un ancien client reste client au sens du cycle de vie, et son état d'abonnement se lit ailleurs. C'est contre-intuitif et c'est le seul montage qui ne casse pas vos rapports de conversion.

Un rappel sur les propriétés de revenu récurrent. Elles se remplissent à la main, fonctionnent par paires, portent des valeurs mensuelles, et le reporting associé ne retient que les transactions gagnées. Sans discipline de saisie, elles restent vides.

Enfin, un point de reporting utile. Une transaction rouverte ne reçoit pas de score de transaction, et les propriétés calculées de phase tiennent compte des fiches fermées puis rouvertes.

En pratique, mesurer expansion et attrition sans fausser ses taux

Le modèle que nous recommandons

Sur l'entreprise, une propriété de statut d'abonnement avec les valeurs actif, en préavis et terminé, plus une date de fin. C'est là que se lit l'état.

Sur la transaction, une valeur de type de transaction pour chaque mouvement de revenu, à savoir nouvelle affaire, renouvellement, montée en gamme et descente en gamme. C'est là que se lit le mouvement.

Comment mesurer l'expansion

Un rapport de transactions gagnées, ventilé par type de transaction, sur une période. Vous obtenez la part de revenu venue de la base installée par rapport à l'acquisition, qui est l'indicateur le plus regardé d'un SaaS.

Comment mesurer l'attrition

Un rapport d'entreprises dont le statut d'abonnement est passé à terminé sur la période. Rappelez-vous que ce n'est pas un rapport de transactions, et c'est précisément le point.

Le radar à mettre en place

Une vue d'entreprises dont la date de renouvellement tombe dans les quatre-vingt-dix jours, croisée avec une absence d'activité récente. Attention en la construisant, la date de dernière activité suit la date déclarée de l'activité et non la date de saisie.

Ce qu'il ne faut pas faire

Créer une transaction perdue à chaque départ de client, pour que la perte apparaisse dans un rapport de vente. Vous polluerez votre taux de conversion avec des affaires qui n'ont jamais existé.

À surveiller sur le suivi de l'expansion et de l'attrition

La perte n'est pas une transaction, c'est un changement d'état du compte.
HubSpot fait la même distinction, la perte n'existe que comme motif d'inactivité.
Le cycle de vie ne recule pas, et un retour arrière abîme l'historique de dates.
Ne modélisez pas la perte par un recul du cycle de vie.
Les propriétés de revenu récurrent se remplissent à la main, par paires, en valeurs mensuelles.
Le reporting de revenu ne retient que les transactions gagnées.
La date de dernière activité suit la date déclarée, pas la date de saisie.
Une transaction rouverte ne reçoit pas de score de transaction.

Quand nous contacter sur le suivi de l'expansion et de l'attrition

Contactez Yuzu Corp pour cadrer votre mesure d'attrition. Le choix de ne pas modéliser la perte comme une transaction est contre-intuitif, et il mérite d'être expliqué à vos équipes avant d'être appliqué.

Pour aller plus loin, découvrez notre offre relation client.

Auteur, sources et date de vérification

Rédigé par Quentin Préchoux
Fondateur de Yuzu Corp · 8 ans sur HubSpot · Nantes & Paris
Yuzu Corp est partenaire HubSpot Diamond et membre du Claude Partner Network
Publié le 5 septembre 2026 · Vérifié sur HubSpot le 1 septembre 2026