Comment structurer HubSpot pour un SaaS B2B

Nous éditons un logiciel en abonnement. Comment structurer HubSpot pour suivre à la fois l'acquisition et la base installée ?

Le point de départ est une distinction que HubSpot ne fait pas pour vous. Une transaction mesure un événement de vente, un abonnement mesure un état contractuel. Un SaaS a besoin des deux.

Notre recommandation tient en quatre décisions.

Une transaction par événement de revenu, à savoir la souscription initiale, chaque expansion et chaque renouvellement.
L'état contractuel porté ailleurs, par les propriétés de revenu récurrent, ou par l'objet Abonnements si vous facturez dans HubSpot.
Le cycle de vie piloté par l'entreprise, pas par le contact, puisque c'est le compte qui s'abonne.
La perte suivie comme un motif, pas comme un type de transaction.

Une irréversibilité à connaître avant d'activer quoi que ce soit. Les propriétés de revenu récurrent, une fois générées dans votre compte, ne peuvent plus être retirées.

Le piège à connaître. Les propriétés d'information de revenu récurrent, une fois générées automatiquement dans votre compte, ne peuvent plus être retirées. La décision de les activer est donc définitive.

Pourquoi une transaction mesure un événement, un abonnement un état

Deux familles de propriétés de revenu récurrent existent, et les confondre coûte du temps.

La première, le revenu annuel et mensuel récurrent, est disponible en Sales Hub Professionnel et Entreprise. Elle est calculée automatiquement à partir de la durée d'engagement et des lignes de produit récurrentes, et elle n'est pas modifiable. Deux pièges. En l'absence de durée, HubSpot suppose douze mois. Et surtout, ce calcul ne tient pas compte de la propriété de montant de la transaction, ce qui explique la plupart des écarts constatés.

La seconde, les informations de revenu récurrent, est réservée à Sales ou Service Hub Entreprise. C'est elle qui porte la distinction utile, avec les valeurs nouvelle affaire, renouvellement, montée en gamme et descente en gamme. Trois contraintes, elle se remplit à la main, les propriétés fonctionnent par paires, et le reporting ne retient que les transactions en phase gagnée.

Un point de vocabulaire qui compte pour un SaaS. La perte de client n'existe pas comme type de transaction récurrente. Elle apparaît seulement comme motif d'inactivité, aux côtés du renouvellement, de la montée et de la descente en gamme.

L'objet Abonnements est une autre brique, et il ne remplace pas les précédentes. Il sert à automatiser des paiements récurrents. Trois contraintes structurantes pour un SaaS. Un abonnement ne s'associe qu'à un seul contact à la fois. Il ne s'édite plus dans les deux jours précédant une échéance. Et un paiement récurrent ne crée pas de nouvelle transaction, donc il n'alimente pas vos rapports de vente.

Sur le cycle de vie, deux définitions documentées cadrent le modèle. Une opportunité est une fiche associée à une transaction, un client est une fiche ayant au moins une transaction gagnée. Et la synchronisation va de l'entreprise principale vers ses contacts, jamais dans l'autre sens.

En pratique, structurer un portail pour une activité par abonnement

Le modèle que nous recommandons

L'entreprise porte le compte abonné, et c'est elle qui porte la phase du cycle de vie. Les contacts portent les utilisateurs et les décideurs, distingués par libellés d'association. Les transactions portent chaque événement de revenu. Et les lignes de produit portent le détail de ce qui est vendu, avec leur durée d'engagement.

Les propriétés à poser sur l'entreprise

Une date de début d'abonnement, une date de renouvellement, un nombre de licences, et un statut d'abonnement. Ces quatre propriétés donnent la lecture de la base installée sans aucun développement.

L'ordre de mise en place

Renseignez d'abord la durée d'engagement sur vos lignes de produit, sinon HubSpot supposera douze mois.
Vérifiez l'écart entre le montant de la transaction et le revenu récurrent calculé. Il est normal, et il s'explique.
N'activez le suivi de revenu récurrent qu'après avoir décidé, puisque les propriétés ne se retirent plus.

Ce qu'il ne faut pas faire

Créer un objet personnalisé Abonnement alors que vous facturez dans HubSpot. L'objet Abonnements existe et il est lié au paiement. Et si vous facturez ailleurs, préférez des propriétés sur l'entreprise à un objet dédié, tant que vous n'avez pas besoin de suivre plusieurs contrats simultanés par compte.

À surveiller sur la structuration de HubSpot pour un SaaS B2B

Une transaction mesure un événement, un abonnement mesure un état. Un SaaS a besoin des deux.
Les propriétés de revenu récurrent, une fois générées, ne se retirent plus.
Le calcul du revenu récurrent ignore la propriété de montant.
Sans durée d'engagement, HubSpot suppose douze mois.
La perte n'est pas un type de transaction récurrente, c'est un motif d'inactivité.
Un abonnement ne s'associe qu'à un seul contact à la fois.
Un paiement récurrent ne crée pas de transaction, donc n'alimente pas les rapports de vente.
Le cycle de vie se pilote par l'entreprise principale.

Articles liés à la structuration de HubSpot pour un SaaS B2B

Quand nous contacter sur la structuration de HubSpot pour un SaaS B2B

Contactez Yuzu Corp avant d'activer le suivi du revenu récurrent. C'est une décision définitive, et le modèle se cadre mieux avant que les propriétés existent.

Pour aller plus loin, découvrez notre offre d'architecture commerciale.

Auteur, sources et date de vérification

Rédigé par Antoine Coatanoan
Sales Ops chez Yuzu Corp · 2 ans sur HubSpot · Nantes & Paris
Yuzu Corp est partenaire HubSpot Diamond et membre du Claude Partner Network
Publié le 3 septembre 2026 · Vérifié sur HubSpot le 1 septembre 2026