Chaque rapport de pipeline que j'analyse présente la même faiblesse. Les étapes sont obsolètes. Des opportunités restent en « Proposition envoyée » deux jours après la signature du contrat, parce qu'un commercial a oublié de déplacer une carte sur le tableau. C'est une omission mineure, mais elle fausse vos prévisions, rend vos indicateurs de vélocité peu fiables et transforme vos revues de pipeline en exercice d'improvisation.
La solution est simple. Plutôt que de compter sur les humains pour mettre à jour les étapes des opportunités, vous laissez le document lui-même déclencher l'avancement. Quand une proposition est envoyée, l'opportunité passe à « Proposition envoyée ». Quand une demande de signature est émise, elle passe à « Contrat envoyé ». Quand le document est signé, l'opportunité passe à « Gagné ». Aucune action manuelle requise.
Voici comment configurer la progression automatique des étapes d'opportunité dans HubSpot en utilisant la propriété Document Status de Portant et les workflows standard de HubSpot. Si votre pipeline semble toujours avoir quelques jours de retard sur la réalité, c'est probablement la raison.
Pourquoi les mises à jour manuelles des étapes échouent
Les commerciaux sont occupés. Ils passent des appels, rédigent des e-mails, relancent des prospects. Mettre à jour une étape d'opportunité est une tâche de faible priorité qui n'apporte aucune valeur à la vente elle-même. Elle est donc ignorée, reportée ou traitée en lot en fin de semaine.
L'impact est plus important que la plupart des responsables ne le réalisent. Si cinq commerciaux oublient chacun de mettre à jour trois opportunités par semaine, cela représente quinze opportunités mal classées à tout moment. Votre rapport de pipeline raconte une histoire à la direction. La réalité en raconte une autre.
Les prévisions dépendent des étapes. Si votre modèle de prévision pondère les opportunités selon la probabilité de l'étape, des étapes obsolètes produisent des chiffres inexacts. Une opportunité réellement gagnée mais toujours affichée en « Contrat envoyé » sous-estime votre chiffre d'affaires clôturé. Une opportunité dont la proposition a échoué mais qui reste en « Proposition envoyée » surestime votre pipeline. Les deux situations sont problématiques.
La solution n'est pas plus de discipline ou une nouvelle relance sur Slack. Vous n'arriverez jamais à former les humains à mettre à jour systématiquement un champ CRM à chaque fois qu'un événement externe se produit. La solution consiste à supprimer entièrement l'étape manuelle et à laisser l'événement lui-même déclencher la mise à jour.
Le cycle de vie du document comme signal de pipeline
Lorsque vous utilisez Portant avec HubSpot, Portant enregistre chaque document généré sous la forme de son propre enregistrement (un Custom Object) rattaché à l'opportunité. Cet enregistrement porte une propriété appelée Document Status, qui se met à jour automatiquement au fil de l'avancement du document dans son cycle de vie.
C'est le signal dont votre pipeline a besoin. Plutôt que de demander aux commerciaux de surveiller leur boîte de réception puis de mettre à jour HubSpot, la propriété Document Status évolue d'elle-même lorsqu'un événement concret se produit. Un document est envoyé. Une signature est demandée. Le document est signé. Quelque chose se passe mal. Chacun de ces changements de statut correspond à un moment réel du processus de vente, ce qui signifie que chacun peut être directement associé à une étape d'opportunité.
J'ai rédigé un article connexe sur comment aligner les étapes d'opportunité avec les types de documents qui couvre la correspondance conceptuelle entre les étapes et les documents. Cet article va plus loin. Il automatise cet alignement afin que le pipeline se mette à jour de lui-même.
Valeurs de Document Status dans Portant
Le Document Object de Portant suit neuf valeurs de statut. Voici ce que chacune signifie et dans quel cas elle s'applique.
- Pending: Portant a créé l'enregistrement du document, mais la génération n'a pas encore démarré.
- Draft: Portant a généré le document, mais il est toujours en brouillon et n'est pas encore finalisé.
- Approved: Votre équipe a examiné et approuvé le document en interne. Cela s'applique si vous utilisez les approval workflows.
- Sent: Portant a remis le document au destinataire.
- Signature Requested: Portant a envoyé une demande de signature électronique au(x) signataire(s).
- Partially Signed: Au moins un signataire a apposé sa signature, mais d'autres restent en attente.
- Signed: Tous les signataires ont apposé leur signature.
- Completed: Le cycle de vie du document est terminé, y compris les éventuelles étapes post-signature.
- Error: Une erreur s'est produite lors de la génération, de l'envoi ou de la signature.
Toutes les opportunités ne passeront pas par les neuf statuts. Un devis simple peut passer de Pending à Sent sans nécessiter de signature. Un contrat peut traverser les étapes Sent, Signature Requested, Partially Signed, Signed et Completed. Les workflows que vous créez doivent prendre en compte les statuts qui comptent réellement dans votre processus.
Pour tous les détails sur le fonctionnement de ces propriétés, consultez la documentation Portant sur le déclenchement de workflows HubSpot à partir des changements de statut de document.
Création des workflows
La configuration utilise l'outil de workflow standard de HubSpot. Vous allez créer des workflows basés sur les opportunités qui se déclenchent en fonction des modifications apportées à la propriété Document Status de l'objet Portant Document Object associé.
Voici la correspondance principale que je recommande pour la plupart des processus commerciaux.
Workflow 1 : Document Sent → Passer à « Proposal Sent »
- Accédez à Automation > Workflows dans HubSpot.
- Créez un nouveau workflow basé sur les opportunités.
- Définissez le déclencheur d'inscription sur : Associated Portant Document Object > Document Status is "Sent."
- Ajoutez une action : Set deal property > Deal Stage sur « Proposal Sent » (ou l'étape équivalente dans votre pipeline).
- Enregistrez et activez.
Lorsque Portant remet une proposition ou un devis à l'acheteur, le Document Status passe à « Sent ». Ce workflow détecte ce changement et fait avancer l'opportunité automatiquement.
Workflow 2 : Signature Requested → Passer à « Contract Sent »
Même structure, déclencheur différent.
- Déclencheur d'inscription : Document Status is "Signature Requested."
- Action : Set deal stage to "Contract Sent."
Ce workflow couvre le moment où le processus de signature commence. L'acheteur a reçu le document accompagné d'une demande de signature électronique, et l'étape de l'opportunité doit le refléter.
Workflow 3 : Signed or Completed → Passer à « Closed Won »
- Déclencheur d'inscription : Document Status is "Signed" OR "Completed."
- Action : Set deal stage to "Closed Won."
Vous pouvez utiliser « Signed » ou « Completed » selon votre processus. Si vous souhaitez que toutes les étapes post-signature soient finalisées avant de clôturer l'opportunité, déclenchez sur « Completed ». Si la dernière signature constitue votre événement de clôture, déclenchez sur « Signed ».
Workflow 4 : Error → Notifier le responsable de l'opportunité
- Déclencheur d'inscription : Document Status is "Error."
- Action : Envoyer une notification interne au responsable de l'opportunité avec un message tel que : « Un document rattaché à [Deal Name] présente une erreur. Veuillez vérifier le document et le renvoyer si nécessaire. »
Ce workflow est important, car les états d'erreur sont invisibles sans alerte. Un commercial pourrait ne pas remarquer qu'un contrat n'a pas été généré ou qu'une demande de signature a échoué. Une notification immédiate évite que les opportunités ne restent bloquées silencieusement.
Alternative : un seul workflow avec des branches
Si vous préférez gérer moins de workflows, vous pouvez créer un workflow unique basé sur les opportunités avec une branche If/Then qui vérifie la valeur de Document Status et oriente vers l'action appropriée. La logique est identique, seule l'organisation diffère. Je commence généralement avec des workflows séparés, car ils sont plus faciles à déboguer, puis je les consolide si l'équipe souhaite une vue plus épurée.
Ajout de tags d'opportunité pour la visibilité du pipeline
Les tags d'opportunité sont des étiquettes colorées qui apparaissent sur les cartes d'opportunité dans la vue tableau de HubSpot. Ils offrent aux commerciaux et aux managers un indicateur visuel rapide lors de l'examen du pipeline, sans avoir à ouvrir chaque opportunité.
Portant vous permet d'ajouter des tags d'opportunité en fonction du Document Status, afin que votre tableau de pipeline indique en un coup d'œil où en est chaque opportunité dans le cycle de vie du document. Par exemple :
- Un tag vert pour les opportunités « Signed »
- Un tag jaune pour les opportunités « Signature Requested »
- Un tag rouge pour les opportunités « Error »
- Un tag bleu pour les opportunités « Sent »
C'est particulièrement utile lors des revues de pipeline. Plutôt que de cliquer sur chaque opportunité pour vérifier l'avancement des documents, les managers peuvent parcourir le tableau du regard et repérer immédiatement les opportunités qui nécessitent une attention, qu'il s'agisse d'une signature bloquée ou d'une erreur passée inaperçue.
Pour les instructions de configuration, consultez le guide Portant sur l'ajout de tags d'opportunité à partir des statuts de document.
Cas particuliers à anticiper
Aucune automatisation ne fonctionne parfaitement dès le premier jour. Voici les situations qui posent le plus souvent problème aux équipes, et comment les gérer.
Plusieurs documents par opportunité
Une seule opportunité peut comporter un devis, une proposition et un contrat, chacun avec son propre statut de document. Si le devis est « Complété » mais que le contrat est « En attente », quel statut doit piloter l'étape de l'opportunité ?
Ma recommandation : utiliser le statut du document le plus récent comme signal principal. Dans votre configuration d'inscription au workflow, vous pouvez filtrer sur le modèle ou le nom du document si vous adoptez des conventions de nommage cohérentes. Cela demande quelques tests, mais bien configurer cette logique évite qu'un devis complété ne ferme prématurément l'opportunité alors que le contrat n'a pas encore été envoyé.
Propositions renvoyées
Si un commercial renvoie une proposition parce que l'acheteur a demandé des modifications, le statut du document repassera par ses différentes valeurs. Votre workflow doit gérer la réinscription afin que l'étape de l'opportunité se mette à jour correctement lorsqu'un nouveau statut « Envoyé » apparaît sur un document différent.
Sachez que cela peut faire reculer une opportunité dans le pipeline. Si une nouvelle proposition est envoyée alors qu'un contrat était déjà en cours, l'opportunité pourrait revenir à « Proposition envoyée ». Demandez-vous si vos workflows doivent uniquement faire avancer les étapes et ne jamais les faire reculer. Pour la plupart des équipes, je recommande une logique de progression uniquement vers l'avant, avec un workflow distinct et délibéré pour tout mouvement en arrière.
États d'erreur
Une erreur ne signifie pas que l'opportunité est perdue. Elle indique qu'un problème technique s'est produit, comme un échec de fusion de modèle ou un délai d'attente du service de signature. Le workflow de notification du Workflow 4 est votre filet de sécurité dans ce cas. Assurez-vous que la notification contient suffisamment de contexte pour que le commercial puisse agir : le nom de l'opportunité, le nom du document et une indication pour vérifier le statut dans Portant.
Documents partiellement signés
Pour les contrats à plusieurs signataires, « Partiellement signé » est un statut intermédiaire utile. Vous n'avez peut-être pas besoin d'une étape distincte dans le pipeline, mais un tag d'opportunité tel que « En attente de signatures » aide les managers à suivre quels contrats sont en cours par rapport à ceux qui attendent un signataire spécifique.
Ce que cela apporte au reporting du pipeline
Lorsque les étapes des opportunités se mettent à jour automatiquement en fonction d'événements documentaires réels, trois choses s'améliorent.
Précision des prévisions. Les étapes reflètent ce qui s'est réellement passé, et non ce qu'un commercial a pensé à enregistrer. Si votre modèle de prévision utilise des probabilités par étape, ces probabilités reposent désormais sur la réalité plutôt que sur une estimation approximative issue du nettoyage de données du vendredi précédent.
Vélocité du pipeline. Les métriques de durée par étape deviennent significatives. Vous pouvez mesurer le temps réellement nécessaire entre « Proposition envoyée » et « Contrat envoyé », car les deux transitions sont liées à des événements documentaires et non à des clics manuels. Cela vous donne de vraies données sur les points de ralentissement des opportunités.
Hygiène du pipeline. Les opportunités obsolètes deviennent plus faciles à repérer. Si une opportunité est en « Contrat envoyé » depuis deux semaines et que le statut du document indique toujours « Signature demandée », c'est l'opportunité qui pose problème, pas les données. Les managers peuvent concentrer leurs revues de pipeline sur le coaching plutôt que sur les audits de saisie de données.
Vous configurez cela une seule fois, et chaque opportunité qui passe dans le pipeline bénéficie d'une étape plus précise sans que personne n'ait à y penser.
Premiers pas
Si vous utilisez déjà Portant avec HubSpot, la propriété Document Status est déjà présente sur vos enregistrements de documents. Commencez par les quatre workflows principaux décrits ci-dessus. Testez-les sur quelques opportunités avant de les déployer à toute l'équipe.
Si vous souhaitez approfondir la façon dont les étapes et les documents doivent être connectés sur le plan conceptuel, lisez mon article précédent sur la correspondance entre étapes d'opportunité et types de documents.
Et si vous n'utilisez pas encore Portant, la page d'intégration HubSpot explique ce qu'il fait et comment le configurer.
Questions fréquentes
Cela fonctionne-t-il avec n'importe quel pipeline d'opportunités dans HubSpot ?
Oui. Les workflows se déclenchent sur la propriété Document Status des objets Document Portant associés, qui n'est pas liée à un pipeline spécifique. Vous pouvez définir des correspondances d'étapes différentes pour différents pipelines à l'aide de branches de workflow.
Et si mes étapes d'opportunité ne correspondent pas aux exemples ?
La correspondance est entièrement flexible. Les exemples utilisés (« Proposition envoyée », « Contrat envoyé », « Conclu ») sont des libellés courants, mais vous devez associer les changements de Document Status aux étapes que votre pipeline utilise réellement. L'essentiel est que chaque changement de statut corresponde à une transition d'étape significative pour votre processus.
Cela remplacera-t-il les modifications d'étape effectuées manuellement ?
Cela dépend de la façon dont vous configurez les workflows. Si un commercial déplace manuellement une opportunité vers « Conclu » avant que le document soit signé, le workflow ne reviendra pas en arrière, sauf si vous le configurez spécifiquement pour le faire. Je recommande de créer des workflows qui ne font avancer les étapes que vers l'avant. Si vous avez besoin d'un mouvement en arrière, ajoutez-le sous forme de workflow distinct, avec des protections supplémentaires et une documentation claire pour l'équipe.
Puis-je utiliser cela avec des workflows d'approbation également ?
Oui. Si votre équipe utilise le workflow d'approbation de Portant, le Document Status passe à « Approuvé » après la révision interne. Vous pouvez ajouter un workflow qui fait passer l'opportunité à une étape telle que « En attente d'envoi » ou « Prêt pour l'acheteur » lorsque cela se produit. C'est utile pour les équipes qui ont besoin de la validation d'un manager avant qu'une proposition soit envoyée à un client.