Pourquoi chaque projet de nettoyage CRM régresse en six mois

J’ai vu ce motif dans cinq entreprises maintenant. RevOps atterrit un budget pour un projet de nettoyage CRM. Une consultance ou un entrepreneur arrive, exécute un sprint de six semaines, et livre un audit qui ferme 3 000 doublons, normalise 60% des champs de texte libre, et produit un rapport de 40 pages avec un trimestre de recommandations. L’équipe de données célèbre. La rapportage s’améliore de manière mesurable. Les prévisions deviennent plus propres pendant un couple d’examens de pipeline. L’équipe passe au projet suivant.

Six mois plus tard les doublons sont de retour, les champs de texte libre ont dérivé, et la plateforme utilisée pour expliquer pourquoi les nombres de pipeline ne correspondent pas est la même que celle utilisée six mois auparavant.

Pourquoi les projets régressent

L’audit corrige les données existantes. Il ne corrige pas le système qui a produit les mauvaises données en premier lieu.

Les importations continuent à se produire avec des formats mal appariés. Les formulaires web collectent du texte libre dans des champs qui devraient être des listes de sélection. Les AE travaillant une transaction hors plate-forme pendant un sprint ne synchronisent jamais le dossier, et plus ancien le le dossier devient, moins quelqu’un est susceptible de le nettoyer. Les opérations marketing livrent une nouvelle campagne avec ses propres conventions de champs parce que personne ne leur a dit que les conventions avaient été re-standardisées trois mois auparavant. Chacun d’eux est une source fraîche de dérive, et aucun d’eux n’a été abordé dans la portée du projet.

Le cadrage honnête est que le nettoyage est une maintenance, pas un projet. Les projets ont une date de fin et le travail s’arrête de se produire. La maintenance est une charge continue que quelqu’un possède à jamais, et faire semblant autrement est ce qui produit le projet de nettoyage suivant.

Ce que « continu » ressemble réellement

L’hygiène tient entre les nettoyages quand trois pièces sont en place. Elles manquent habituellement.

Une couche de règles qui s’exécute lors de l’écriture. Elle valide le format, vérifie par rapport à la liste de sélection, correspond floue à comptes existants, et accepte soit le dossier, soit l’acheminement vers une file d’attente. Sans elle, la dérive nouvelle arrive plus vite que l’ancienne dérive se résout, et la file d’attente est sans fond à partir du jour un.

Une file d’attente d’exception possédée, avec une personne nommée et un créneau récurrent. Pas « comme une partie de leur rôle » abstraitement — vraiment sur le calendrier de quelqu’un, chaque mardi à 10h00. Les entreprises qui maintiennent leur qualité des données entre les nettoyages ont tous cela. Les celles qui régressent traitent la file d’attente comme un meilleur effort, ce qui signifie qu’elle obtient le temps qui reste après tout le reste, ce qui signifie qu’elle n’obtient pas de temps.

La qualité des données signalée comme une première métrique de classe — taux de doublon, complétude des champs, compte de dossier obsolète — sur un tableau de bord que le responsable RevOps examine sur une cadence normale. Si ces nombres deviennent invisibles entre les projets, vous avez déjà étendu le prochain nettoyage d’ici que quelqu’un regarde à nouveau.

Notre playbook de nettoyage de données CRM est construit autour de la réalisation de ces trois pièces durables sans créer une nouvelle ligne d’effectif.

La version de ce travail qui ne régresse pas est celle qui prévient la dérive au point d’entrée. La version nettoyage régresse toujours.