Résumé

  • Hors de la bêta de conservation de l'identifiant principal, une fusion retire les deux contacts de leurs workflows actifs. Dans cette bêta, seul le parcours de la fiche principale continue.
  • Le critère de dernière mise à jour utilisé pour une fusion en masse inclut des propriétés internes masquées. La fiche la plus récente ne porte pas forcément la prochaine action la plus importante.
  • Réinscrire un contact fait repartir le workflow du début. La fusion elle-même ne s'annule pas : il faut donc décider du sort du travail restant avant de célébrer le nettoyage.

Le ménage dans un fichier clients a cet avantage sur le ménage au bureau : il produit de beaux chiffres. Une ligne en moins, un doublon résolu, une jauge qui baisse. La question embarrassante arrive ensuite : qui s'occupe de la relance qui attendait sur la fiche disparue ?

Prenons une situation fictive, entièrement banale. Deux fiches concernent bien la même personne. Sur l'une, un parcours automatisé attend avant d'envoyer un suivi de démonstration. Sur l'autre, un autre parcours attend avant un point sur l'essai du produit. Fusionner les fiches résout le doublon. Cela ne suffit pas à régler le sort des deux actions promises.

La distinction est au cœur des règles publiées par HubSpot. Elle donne à une opération de rangement une portée commerciale que son nom ne suggère guère.

La belle continuité du passé

Les règles de fusion rassemblent notamment les activités, les associations et l'historique des propriétés. En ouvrant la fiche obtenue, un commercial retrouve donc beaucoup de matière. Le dossier ressemble à une relation enfin réunifiée.

Les actions encore en attente suivent une autre logique. Pour les comptes Professional ou Enterprise concernés par les workflows, le partage décisif est l'inscription à la bêta publique Primary ID Preservation for Merged Records. Sans cette bêta, les deux fiches quittent leurs workflows actifs au moment de la fusion. Avec elle, la fiche principale poursuit ses délais, ses branches et ses actions en attente ; la fiche secondaire quitte ses workflows.

Autrement dit, la qualité de l'archive et la continuité du travail se vérifient séparément. Un échange passé peut rejoindre le dossier final alors que l'action qui devait lui succéder perd son parcours d'exécution. Dans notre exemple, choisir la fiche principale revient, sous la bêta, à choisir quelle attente reste en place. L'autre exige une décision.

Le piège est assez élégant pour passer inaperçu. L'administrateur regarde la disparition du doublon. Le commercial regarde la présence des échanges. Chacun contrôle quelque chose d'utile, chacun peut conclure que tout va bien. Personne n'a encore regardé le prochain geste attendu par le client.

Le pouvoir discret du « plus récent »

Quand on fusionne une paire à la main, on peut discuter du dossier à conserver. En masse, il faut une règle. HubSpot propose notamment de départager les fiches par interaction, date de création ou mise à jour dans son outil de gestion des doublons.

Le dernier critère examine toutes les propriétés, y compris des propriétés internes masquées. Ce détail compte. La modification la plus récente peut être parfaitement réelle sans désigner le dossier auquel l'équipe commerciale accorde le plus de valeur. Une horloge classe des événements ; elle ne hiérarchise pas les promesses faites à un client.

Dans la bêta, ce classement peut pourtant sélectionner le parcours qui reste actif. Une préférence technique devient ainsi une décision sur le travail à poursuivre. Le problème vient moins du critère lui-même que de l'autorité qu'on lui confie sans la nommer.

Il serait absurde de réunir un comité pour chaque fiche inactive. Il est tout aussi absurde de traiter une fiche sans activité en cours comme une fiche chargée d'une prochaine action importante. Le bon tri se situe là. Après avoir confirmé que les fiches sont réellement des doublons, l'équipe doit repérer celles qui transportent encore du travail.

Le retour à la case départ coûte aussi du temps

On pourrait penser qu'il suffit de réinscrire le contact. Les paramètres d'inscription permettent d'autoriser l'entrée de contacts fusionnés remplissant les conditions ; par défaut, les changements produits par la fusion ne les font pas entrer automatiquement dans de nouveaux workflows. Ce réglage ouvre une porte. Il ne restitue pas la position antérieure.

La réinscription recommence au début. Les premières étapes reviennent donc dans le parcours, avec une exécution qui dépend de leurs conditions. Réparer une action manquante peut ainsi remettre à l'ordre du jour des actions déjà accomplies. Il faut examiner ce qui doit réellement se reproduire.

L'inscription manuelle démarre elle aussi au début. Pour ne jouer que les étapes suivantes, HubSpot suggère de créer ou de cloner un workflow distinct commençant à l'action voulue. La réparation prend alors la forme d'un petit travail de reconstruction : distinguer le fait du restant à faire, choisir les contacts, décider de leur nouveau point de départ.

C'est du temps humain, même si le bouton initial portait la promesse rassurante d'un nettoyage automatisé. Un doublon supprimé peut laisser plusieurs vérifications à quelqu'un d'autre. La productivité ne se mesure pas très bien lorsqu'on s'arrête au premier clic réussi.

Une trace explique, elle ne rembobine pas

La page de détail des workflows permet d'examiner actions, événements et horaires. Rapprocher la fusion d'une désinscription, d'une nouvelle entrée et de l'action effectivement exécutée donne une preuve plus utile que la seule présence d'un historique client. Pour établir une perte commerciale réelle, il manque encore les positions et journaux du compte concerné.

Enfin, HubSpot ne propose pas de défusionner les fiches. Retirer une adresse secondaire puis créer un contact avec cette adresse crée un nouveau dossier. Retrouver les anciens identifiants aide à comprendre la provenance ; cela ne reconstitue pas deux processus interrompus.

Une équipe peut donc avoir un fichier plus propre et un travail moins bien transmis. Elle évite cette contradiction en posant une question simple avant de déclarer l'opération terminée : où est passée la prochaine action due au client ? Si personne ne sait répondre, on a rangé la paperasse. Le service, lui, attend encore.