Étude de cas

DIVISER UN CRM EN DEUX

Quand une entreprise devient deux, le CRM ne se divise pas tout seul.

Centaines de contacts désuets supprimés
1 pipeline rationalisé
Première cartographie source de vérité documentée
Complète réassignation des propriétés

Un CRM construit par deux entreprises, entretenu par aucune

Deux entreprises opéraient dans un seul compte HubSpot depuis des années. Puis l'entreprise s'est divisée : l'une a été acquise, l'autre a continué de façon indépendante. Le CRM devait être scindé et nettoyé sans briser les opérations de l'entreprise restante.

Le CRM n'avait jamais été architecturé. Il avait été accumulé. Les propriétés, workflows, listes et formulaires de deux entreprises, empilés les uns sur les autres sans convention de nommage et sans documentation.

Les propriétés liées aux produits de l'entreprise sortante se trouvaient partout. Il n'y avait aucune frontière claire entre ce qui appartenait à l'une ou l'autre entité.

Le modèle de données lui-même était erroné. Des propriétés qui appartenaient aux fiches d'entreprise étaient stockées sur les contacts. Des données de transaction comme le nombre de licences, les produits sélectionnés et les termes du contrat se trouvaient aussi sur les contacts. L'objet contact était devenu un fourre-tout.

La base de données était remplie de fiches qui ne représentaient plus rien de réel. Des centaines de contacts n'avaient pas de titre de poste. Une grande proportion n'affichait aucune activité depuis plus de cinq ans. Des transactions restaient dans des pipelines actifs pendant des mois sans une seule mise à jour.

Le nettoyage

Avant de scinder quoi que ce soit, nous avons audité chaque propriété personnalisée, chaque workflow, chaque liste et chaque formulaire. Nous avons cartographié quels actifs appartenaient à l'entreprise sortante, lesquels à l'entreprise restante, et lesquels étaient partagés.

Ensuite, nous avons restructuré. Les propriétés de contact qui décrivaient des comptes ont été migrées vers les fiches d'entreprise. Les données spécifiques aux transactions ont été déplacées vers les transactions. Les propriétés liées aux produits de l'entreprise acquise ont été archivées ou supprimées.

Les contacts inactifs ont été signalés pour révision et archivés lorsque c'était approprié. Les transactions mortes ont été fermées avec des dispositions adéquates pour que le pipeline reflète la réalité.

Nous avons documenté la nouvelle architecture de données : ce qui se trouve où, ce que chaque propriété signifie, qui en est responsable.

Un champion interne qui a fait tenir le tout

Ce projet a fonctionné parce qu'il y avait un champion interne solide qui a pris possession du dossier dès le premier jour. Cette personne n'approuvait pas les décisions à distance. Elle s'est retroussé les manches.

Elle a révisé les listes ligne par ligne, nettoyé les propriétés à nos côtés, résisté aux équipes qui voulaient garder l'héritage encombrant, et s'est assurée que la nouvelle structure soit comprise et adoptée dans tous les départements.

C'est la différence entre un nettoyage qui tient et un qui régresse en six mois. Des consultants externes peuvent auditer, restructurer et documenter. Mais sans quelqu'un à l'interne qui s'approprie le résultat et l'applique au quotidien, la dette revient.

La vraie leçon

Personne ne planifie de construire un CRM désordonné. Ça se produit graduellement, surtout quand deux organisations partagent un système sans gouvernance commune.

Des propriétés sont créées pour des besoins ponctuels. Les données atterrissent sur l'objet le plus facile d'accès. Les contacts s'accumulent parce que supprimer semble plus risqué que garder.

La solution est méthodique : auditer ce qui existe, décider de ce qui va où, le déplacer, nettoyer le reste, et tout documenter pour que ça ne se reproduise pas. Ce n'est pas un travail glamour. Mais c'est le travail qui rend tout le reste possible.