Enregistrements de documents dans HubSpot

Portant écrit chaque document qu'il génère dans HubSpot sous la forme de son propre enregistrement dans un objet Document (un objet d'application HubSpot fourni par l'application Portant), associé au deal, au contact, à l'entreprise, au ticket ou à l'objet personnalisé depuis lequel le workflow a été exécuté.

L'objectif n'est pas de pouvoir créer des rapports sur les documents. C'est que vos documents sont votre processus métier. Un document est un devis, un contrat, une facture, une proposition ou un énoncé des travaux. Dès lors que chacun d'eux constitue un enregistrement doté d'un statut et d'une date, des questions auxquelles vous ne pouviez pas répondre auparavant deviennent des rapports HubSpot ordinaires : combien de contrats ont été signés le mois dernier, combien de devis ont été envoyés par commercial, quels deals ont reçu trois devis sans avoir abouti à une signature, quelles demandes de signature n'ont même jamais été ouvertes.

Auparavant, les propriétés Portant sur un deal ou un contact ne conservaient que le document le plus récent, écrasé à chaque exécution. Un deal comportant un devis, un devis révisé et un contrat signé n'affichait qu'un seul jeu de valeurs. Les enregistrements de documents conservent les trois.

Dans ce guide :

Nommez vos workflows d'après le type de document
Ce que vous pouvez mesurer
Automatisations recommandées
Automatisation côté document ou côté deal
Renouvellements et expiration de contrats
Référence : contenu de chaque enregistrement
Quand les enregistrements sont créés et mis à jour
Exigences et limites
Si les enregistrements n'apparaissent pas

Nommez vos workflows d'après le type de document

Faites cela en premier, car tout ce qui suit en dépend.

Chaque enregistrement Document conserve le workflow qui l'a généré. Ce nom de workflow est ce qui vous permet de distinguer un devis d'un contrat dans un rapport : il constitue donc en pratique votre type de document. Si vos workflows s'appellent "Workflow 1" et "Copie du test de proposition", vos rapports seront inutilisables, quelle que soit la qualité de vos données.

Nommez les workflows d'après le document qu'ils produisent : Quote (Devis), Order Form (Bon de commande), MSA, NDA, Statement of Work (Énoncé des travaux), Invoice (Facture), Renewal (Renouvellement). Ainsi, "combien de contrats avons-nous signés en juillet" devient un filtre sur un seul champ.

Si vous générez plusieurs types de documents à partir d'un seul workflow, divisez-le, ou faites en sorte que le nom du document généré indique le type afin de pouvoir regrouper les résultats sur cette base.

Le nom du workflow apparaît dans l'enregistrement sous le champ Workflow, qui est le champ utilisé pour le regroupement :

Ce que vous pouvez mesurer

Volume par type de document

Regroupez les enregistrements Document par workflow et par date de création pour voir ce que votre activité a réellement produit : devis envoyés par mois, contrats signés par trimestre, factures émises par semaine. Ajoutez le propriétaire de l'enregistrement pour obtenir la même vue par commercial, ce qui transforme "l'équipe envoie-t-elle des propositions" en un chiffre plutôt qu'en une impression.

Taux de conversion devis vers signature

Deux comptages côte à côte, devis créés et contrats signés sur la même période, vous donnent un taux de conclusion basé sur les documents, indépendant du soin avec lequel chacun maintient les étapes du deal. Suivez-le par commercial ou par modèle pour identifier quels devis aboutissent réellement à une conversion.

La durée réelle du processus de signature

Chaque enregistrement indique la date de création du document et passe au statut Signed (Signé) lorsque le dernier signataire a complété le processus. L'écart entre ces deux moments correspond à votre délai réel de signature, là où les deals stagnent généralement en silence. Comparez-le entre les types de documents : un NDA qui prend onze jours représente un problème différent d'un MSA qui prend onze jours.

Deals avec plusieurs devis et aucune signature

C'est le rapport que la plupart des équipes n'ont pas. Recherchez les enregistrements sources associés à plusieurs enregistrements Document issus de votre workflow de devis et à aucun contrat signé. Chacun d'eux correspond à un deal en cours de renégociation, faisant l'objet d'une remise ou bloqué, et le nombre de devis constitue un bon indicateur du niveau de friction qu'il génère. Il s'agit à la fois d'une file d'attente pour révision des remises et d'un signal de coaching.

Deals dont l'étape ne correspond pas aux documents

Étant donné que les documents et les deals sont désormais des enregistrements distincts, vous pouvez les comparer l'un à l'autre :

Les deals marqués comme conclus (Closed Won) sans contrat signé, ce qui représente un écart en matière de comptabilisation des revenus et d'audit.
Les deals se trouvant à l'étape de proposition ou de négociation sans qu'aucune proposition n'ait jamais été générée, ce qui correspond à un pipeline inexistant.

Ces deux situations sont invisibles si la seule trace d'un document est une propriété qui est écrasée à chaque fois. Ici, le deal est marqué Closed Won (Conclu) tandis que son devis le plus récent est toujours au statut Pending (En attente) :

Si le signataire a seulement ouvert la demande

Chaque enregistrement suit le nombre de fois où la demande de signature a été ouverte et la date de sa dernière consultation. Cela permet de diviser un problème vague en deux problèmes distincts, chacun avec ses propres solutions :

Envoyé, jamais ouvert. Adresse incorrecte, ou le message est allé dans les spams. Quelqu'un doit renvoyer le document ou appeler, et relancer indéfiniment la même boîte de réception ne servira à rien.
Ouvert cinq fois, toujours pas signé. Le destinataire l'a lu et quelque chose le bloque. C'est une objection, et cela justifie un appel téléphonique aujourd'hui.

Quels modèles sont réellement utilisés

Le volume regroupé par workflow indique quels modèles sont rentables et lesquels sont inactifs depuis un an. Retirez les modèles inactifs ; la liste raccourcie que votre équipe fait défiler devient plus courte.

Automatisations utiles à mettre en place

Les enregistrements de documents peuvent être inscrits dans des workflows HubSpot et utilisés comme condition de branchement au même titre que n'importe quel autre enregistrement, ce qui permet à l'activité documentaire de piloter de véritables processus plutôt que de simples rapports. Scénarios à configurer :

Contrat signé, démarrage de la livraison. Le statut passe à Signed (Signé), ce qui déclenche une notification au propriétaire, un déplacement de l'étape de l'opportunité, la création des tâches d'onboarding et le transfert à l'équipe de livraison. Le PDF signé est déjà présent dans l'enregistrement.
Une génération a échoué. Le statut passe à Error (Erreur), ce qui alerte le responsable des opérations documentaires. Sans cette automatisation, un échec reste silencieux : le commercial suppose que le client a reçu le devis, tandis que le client l'attend.
Envoyé mais non ouvert après deux jours. Le statut est Signature Requested (Signature demandée) et le nombre de vues est toujours nul, ce qui crée une tâche d'appel. C'est l'automatisation à plus fort rendement de cette liste, car elle détecte les problèmes de délivrabilité qui passent sinon pour un désintérêt du client.
Lu à plusieurs reprises et toujours non signé. Le nombre de vues est supérieur à trois sans signature, ce qui génère une tâche pour que le commercial appelle et identifie l'objection.
Relance de la signature en attente. Le statut est Signature Requested ou Partially Signed (Partiellement signé) depuis plus longtemps que la norme, ce qui déclenche une escalade planifiée plutôt qu'une relance au bon souvenir de chacun.
Notification lors de l'envoi d'un document à forte valeur. Consultez la section suivante, car la valeur se trouve dans l'opportunité plutôt que dans le document.
Renouvellement à venir. Consultez la section sur les renouvellements de contrats ci-dessous.

Automatisation côté document ou côté opportunité

Choisissez le contexte en fonction des champs dont vous avez besoin.

Exécutez le workflow sur l'objet Document lorsque vous avez besoin d'une granularité par document : ce devis précis, son statut, son nombre de vues, la date d'envoi. C'est le cas pour la plupart des scénarios ci-dessus. Un workflow côté document inscrit les enregistrements Portant Document et crée des branches sur Document Status (Statut du document), de sorte que le scénario de contrat signé ci-dessus repose sur une seule condition d'inscription :

Exécutez-le sur l'opportunité lorsque la règle dépend de champs de l'opportunité tels que le montant, le pipeline ou l'étape, et utilisez la propriété de statut de document Portant sur l'opportunité comme déclencheur. « Notifier le responsable lorsqu'un devis supérieur à 50 000 est envoyé » est une règle côté opportunité, car l'enregistrement Document porte le statut et les liens du document, mais pas sa valeur monétaire.

Si vous souhaitez que la valeur propre au document soit reportable, renseignez-la dans une propriété via HubSpot capture fields, ou conservez le montant dans l'opportunité et laissez l'association le transmettre.

Renouvellements et expiration des contrats

Les renouvellements représentent l'enjeu le plus important de cette page et nécessitent un champ absent de l'enregistrement Document : une date de fin. Les enregistrements indiquent la date de création d'un document, et non la date d'expiration de l'accord. Deux façons d'obtenir cette information :

La déduire. Si un type de document a une durée standard, définissez une date de renouvellement à partir de la date de création augmentée de cette durée, via un workflow HubSpot ou une propriété calculée, puis déclenchez les tâches de renouvellement à partir de cette date.
La capturer. Si la durée est négociée pour chaque opportunité, demandez au signataire de la renseigner et écrivez-la en retour via HubSpot capture fields.

Ne confondez pas cela avec l'expiration du lien de signature, qui contrôle la durée de validité d'un lien de signature non encore utilisé. Cela concerne l'obtention de la signature sur le document ; il s'agit ici de la durée propre à l'accord une fois qu'il a été signé.

Une fois cette date en place, vous disposez d'un pipeline de renouvellement issu des documents déjà générés : contrats expirant dans les 90 prochains jours, accords à renouvellement automatique approchant de leur fenêtre de préavis, et clients dont le seul accord signé a expiré depuis plusieurs mois.

C'est également ce qui fait de cet objet une solution légère et opérationnelle de gestion du cycle de vie des contrats. Chaque accord est un enregistrement doté d'un statut, d'un PDF signé, d'un historique de signature et d'une date de renouvellement, tous consultables dans le CRM que votre équipe utilise déjà, sans outil CLM distinct. Il ne prendra pas en charge les bibliothèques de clauses ni la négociation de texte, mais pour savoir ce que vous avez signé, avec qui, et ce qui arrive à renouvellement, c'est suffisant.

Un autre usage mérite d'être mentionné : comme chaque enregistrement conserve ses propres horodatages, liens et historique de signature, vous disposez d'une piste d'audit par accord. C'est exactement ce dont vous avez besoin lorsque les achats demandent la copie signée, ou lorsqu'un client conteste la version sur laquelle il s'est engagé.

Référence : contenu de chaque enregistrement

Chaque document s'ouvre en tant qu'enregistrement distinct, avec les propriétés Portant dans le panneau de gauche et l'enregistrement source sous Deals (Opportunités).

Le libellé de propriété est celui que vous sélectionnerez dans les générateurs de rapports et les filtres de workflow, et c'est celui qui apparaît sur la fiche. Le nom interne désigne la même propriété à laquelle l'API, les exports et les intégrations de HubSpot font référence. Ces deux valeurs diffèrent, c'est pourquoi elles sont toutes deux répertoriées ici : les champs de signature s'affichent notamment sous la forme "Signable Document" à l'écran et signature_request dans l'API.

Libellé de propriété	Contenu	Nom interne
Document Name	Nom du document (par défaut "Portant Document")	`a1323181_document_name`
Workflow	Le workflow qui l'a généré, votre type de document	`a1323181_workflow_name`
Document Status	Statut du document	`a1323181_document_status`
Document Created Time	Date de création du document	`a1323181_document_created`
Document Link	Lien vers le document (Google Docs ou OneDrive)	`a1323181_document_link`
PDF Link	Lien vers le PDF	`a1323181_pdf_link`
PDF Files	Le PDF généré, joint en tant que fichier	`a1323181_pdf_files`
Signable Document Link	Lien vers la demande de signature	`a1323181_signature_request_link`
Signable Document View Count	Nombre de fois que le signataire l'a ouvert	`a1323181_signature_request_view_count`
Signable Document Last Viewed Date	Date à laquelle le signataire l'a ouvert pour la dernière fois	`a1323181_signature_request_last_view_date`

En faisant défiler le panneau de propriétés, vous affichez les champs de signature et le workflow qui a produit le document.

Les valeurs de statut sont les mêmes que celles utilisées par la propriété Document Status de Portant sur les transactions et les contacts : Pending, Error, Draft, Approved, Signature Requested, Partially Signed, Signed, Sent et Completed.

Il n'existe pas de propriété relative au type de document, au montant ou à la date d'expiration. Le type provient du nom du workflow, et le montant ainsi que la date d'expiration proviennent de la transaction ou des champs capturés, comme décrit ci-dessus.

Création et mise à jour des fiches

Une fiche est créée la première fois qu'un document est produit, puis mise à jour sur place au fur et à mesure que le document progresse dans l'exécution. Un document correspond à une fiche unique tout au long de son cycle de vie, de sorte que le comptage des fiches équivaut au comptage des documents.

Le statut suit l'avancement du travail : un brouillon en attente de révision devient Draft, puis Approved, puis Signature Requested, puis Partially Signed ou Signed au fur et à mesure que les signataires agissent, et Sent une fois l'e-mail envoyé. Un workflow sans étape de révision ni de signature aboutit à Completed.

Un workflow qui génère plusieurs documents en une seule exécution crée une fiche par document, chacune étant associée à la même fiche source.

Prérequis et limites

L'application Portant doit être installée dans votre portail HubSpot, avec les autorisations relatives aux objets de document accordées lors de la connexion de HubSpot. Consultez Install the Portant app in HubSpot.
Les fiches sont créées au fur et à mesure que les documents sont générés, de sorte que les documents générés avant la disponibilité des fiches Document n'apparaîtront pas. Il n'existe pas de remplissage rétroactif, ce qui signifie que vos rapports accumulent l'historique à partir du moment où vous commencez, sans remonter dans le passé.
Le PDF est joint à la fiche uniquement lorsque le workflow est configuré pour téléverser des fichiers vers HubSpot. Les pièces jointes sur la fiche source sont décrites dans View created documents in HubSpot. Lorsqu'il est joint, il figure sur la fiche en tant que fichier :

Les fonctionnalités de rapports personnalisés et de tableaux de bord disponibles dépendent de votre abonnement HubSpot.

Si les fiches n'apparaissent pas

Les autorisations permettant à Portant d'écrire des fiches Document sont accordées lors de la connexion de HubSpot. Ainsi, une connexion autorisée avant l'existence de cette fonctionnalité peut ne pas les inclure. La reconnexion relance l'invite d'autorisation HubSpot : suivez la procédure Reconnect HubSpot, puis générez un nouveau document et vérifiez les associations de la fiche source.

Si les documents continuent de se générer normalement mais qu'aucune fiche Document n'apparaît, copiez un code d'assistance et ouvrez un ticket d'assistance en indiquant l'identifiant de votre portail HubSpot afin que nous puissions vérifier la connexion de notre côté.