Les documents automatisés ne valent que ce que valent les champs CRM qui les alimentent. Je travaille régulièrement avec des administrateurs HubSpot qui souhaitent des propositions et des contrats qui « fonctionnent tout simplement ». Dans presque tous les cas, le blocage ne vient pas du modèle. Il vient de propriétés incohérentes, de champs en double, et d'un désaccord sur la valeur de référence.

Voici la liste de contrôle que j'utilise quand je veux que les données HubSpot s'intègrent proprement dans les devis, propositions et contrats générés par Portant. L'objectif est simple : un champ canonique par information, nommé de façon compréhensible pour les commerciaux, et validé afin qu'une donnée erronée ne puisse pas atteindre silencieusement un PDF client.

Commencer par ce que le document doit exprimer

Avant de toucher aux paramètres HubSpot, je liste les informations qui doivent figurer sur un accord signé ou une proposition formelle. Raison sociale, adresse de facturation, signataire, conditions commerciales, dates de démarrage et lignes de produits sont les suspects habituels. J'ignore le jargon interne jusqu'à ce que la liste orientée client soit claire.

Je mappe ensuite chaque information à un objet HubSpot existant. Company contient les données d'entité et de facturation. Contact contient les personnes et leurs rôles. Deal contient la structure commerciale et l'étape. Les lignes de produits contiennent le calcul au niveau des références. Les objets personnalisés s'appliquent là où les relations sont réelles, et non là où le deal ne disposait plus de suffisamment de place.

Lorsque cette correspondance est rigoureuse, Portant peut injecter des valeurs en temps réel dans les propositions et les contrats sans que les commerciaux aient à copier des cellules depuis des feuilles de calcul. Si la correspondance est floue, l'automatisation ne fait qu'amplifier les erreurs.

Des noms et des groupes que les commerciaux utilisent réellement

Je regroupe les propriétés dans HubSpot afin qu'un commercial en phase de préparation documentaire voie un seul bloc intitulé « Éléments essentiels du contrat » ou « Données pour la proposition », et non cinquante champs éparpillés. Les noms sont formulés en langage courant : « Raison sociale » est bien préférable à « co_legal_nm ». Le texte d'aide tient en une phrase : d'où vient la valeur et qui la corrige en cas d'erreur.

J'évite les champs quasi identiques. Rien ne perturbe plus une équipe que d'avoir « Valeur annuelle du contrat » sur le deal et « Copie ACV » dans une colonne de tableur que personne ne gère. Si deux champs peuvent se contredire, je supprime l'un des deux ou j'en fais un champ calculé en lecture seule.

Pour les listes de sélection et les menus déroulants, je limite les options et les rends mutuellement exclusives. Le texte libre convient pour la nuance, mais pas pour les éléments qui alimentent des tableaux de tarification ou des clauses de juridiction. Ceux-là appartiennent à des vocabulaires contrôlés afin que les modèles puissent brancher de façon prévisible.

Les champs obligatoires doivent correspondre à de véritables points de contrôle. Si un contrat ne peut pas partir sans règle de bon de commande, rendez cela visible avant « contrat envoyé », et non après que la finance a rejeté le PDF. J'utilise des propriétés obligatoires sur le deal ou la société à l'étape où l'équipe s'engage sur ces conditions.

Lorsque HubSpot le permet, j'ajoute des garde-fous simples : formats numériques pour les montants, validation des adresses e-mail sur les signataires, longueurs minimales là où des valeurs vides ont déjà causé des incidents. L'objectif n'est pas la bureaucratie. L'objectif est d'empêcher la mauvaise valeur unique qui se transforme en cauchemar de négociation.

Lorsque l'automatisation documentaire s'appuie sur ces champs, les approbations sont plus rapides parce que les relecteurs font confiance aux données. C'est le bénéfice concret d'une conception rigoureuse des propriétés.

Propriétés personnalisées ou surcharge des champs standard

HubSpot fournit des propriétés standard pour de bonnes raisons. Je les utilise quand la sémantique correspond. J'ajoute des propriétés personnalisées lorsqu'il existe un concept métier distinct, comme « Date d'entrée en vigueur du MSA » ou « Délai de préavis de renouvellement automatique », qui ne devrait jamais être glissé dans un champ de notes générique.

Je surveille également « l'abus du champ de notes », où des conditions critiques ne vivent que dans les notes du deal. Les notes n'ont pas leur place dans les documents clients sans traduction humaine, ce qui réintroduit le copier-coller. Si une information doit figurer sur papier, elle doit être dans une propriété structurée.

Pour les équipes qui utilisent des workflows pour générer des fichiers lors d'un changement d'étape, les champs structurés sont ce qui rend les sections conditionnelles fiables. « Si la durée de renouvellement est égale à 12 mois, inclure le bloc de clause A » ne fonctionne que si la durée de renouvellement est un vrai champ.

Des rapports qui prouvent la bonne santé des données

Je construis un petit ensemble de listes et de rapports qui répondent à une seule question : pouvons-nous générer un document propre pour chaque deal à cette étape ? Le rapport filtre sur les propriétés obligatoires manquantes, les valeurs de liste de sélection invalides, et les deals avec des lignes de produits qui ne concordent pas avec le montant du deal.

Les RevOps examinent cette liste chaque semaine dans un premier temps, puis chaque mois lorsque les taux d'erreur se stabilisent. Les responsables commerciaux y ont également accès, car la solution passe souvent par de la formation, et non par une nouvelle intégration.

Des propriétés saines rendent aussi les indicateurs d'engagement significatifs. Lorsque les enregistrements de documents dans HubSpot reflètent le bon compte et le bon contact, vous pouvez faire confiance à qui a ouvert quoi et quand.

Passation aux propriétaires de modèles

Une fois les propriétés stabilisées, je rédige un « dictionnaire de champs » d'une page à l'intention de la personne responsable des modèles Google Docs ou Word. Chaque balise est associée à une propriété HubSpot, à l'objet sur lequel elle se trouve et à un exemple de valeur. Les éditeurs de modèles ne devraient jamais avoir à deviner si « ville de facturation » provient de la société ou du contact.

Dans Portant, ces balises récupèrent les données HubSpot en temps réel afin que les fichiers générés restent synchronisés lors des mises à jour des enregistrements. La démarche que je préconise est la suivante : rigueur CRM d'abord, peaufinage des modèles ensuite, automatisation en troisième lieu.

Questions fréquentes

À partir de combien de propriétés personnalisées y en a-t-il trop ?

Si les commerciaux ne peuvent pas trouver les champs dont ils ont besoin sans recourir à la recherche, la vue par défaut en contient trop. Vous pouvez conserver un nombre total plus élevé à condition que les vues intelligentes, les formulaires et les playbooks présentent le bon sous-ensemble selon le rôle. Je préfère moins de champs avec une utilisation plus stricte à un encombrement de champs optionnels sans fin.

Les lignes de produits doivent-elles être la source de vérité pour la tarification ?

Pour tout ce qui est basé sur des références produit, oui. Le montant du deal doit correspondre aux lignes de produits, sinon il faut un processus d'exception documenté. Les modèles de documents doivent lire à partir des lignes de produits lorsque les tableaux sont détaillés, et à partir des champs au niveau du deal lorsque vous vendez un bundle packagé avec un total unique.

Et si l'équipe commerciale insiste sur le texte libre pour les conditions ?

Capturez des indicateurs structurés pour ce qui a une importance juridique et financière, et utilisez un champ de texte long pour les éléments narratifs si nécessaire. Ensuite, expliquez à l'équipe quels éléments peuvent faire l'objet d'une fusion de données par rapport à ceux qui nécessitent une révision juridique. Le texte non structuré ne devrait jamais être le seul endroit où figurent la durée de renouvellement ou les plafonds de responsabilité.