Chaque reconstruction de CRM pour laquelle on nous demande un devis commence de la même manière : quelqu’un décrit le système comme un désordre et demande à quelle vitesse il peut être remplacé. L’instinct est compréhensible et généralement faux. Un audit du système CRM montre presque toujours que la plateforme va bien et que la pratique autour d’elle a dérivé : champs ajoutés pour une campagne et jamais supprimés, trois pipelines décrivant le même processus de vente différemment, automatisations construites par des personnes qui sont parties depuis, et une couche de reporting à laquelle personne ne fait confiance. Remplacer le logiciel déplace tout cela dans une nouvelle base de données.
Donc nous auditons d’abord, toujours, et nous le faisons avant de proposer le moindre changement. Le but n’est pas de produire un document. Le but est de découvrir quels problèmes sont des problèmes de données, lesquels sont des problèmes de processus et lesquels sont réellement des limitations de la plateforme, car chacun d’eux a une solution différente et un seul d’entre eux justifie une migration. L’audit prend une période définie, produit une liste classée des conclusions et se termine par une recommandation qui est parfois simplement de nettoyer ce qui existe.
Où commence l’audit du système CRM : enregistrements, pas configuration
La première chose que nous mesurons est la duplication. Pas l’avertissement de doublon de la plateforme elle-même, qui a tendance à ne correspondre qu’à l’e-mail exact, mais un vrai passage sur le nom de l’entreprise, le domaine, le téléphone et le nom de contact normalisé. Dans la plupart des comptes, le taux de doublons est suffisamment élevé pour rendre tout rapport de revenus peu fiable, car le même client apparaît deux fois avec la moitié de l’historique chacun. Nous comptons également les enregistrements sans propriétaire, sans activité sur une longue période, et sans champs remplis au-delà de ceux que l’importation a créés.
Ensuite, l’exhaustivité par champ. Presque chaque CRM contient des champs qui sont requis en théorie et vides en pratique, et des champs remplis avec diligence mais jamais lus. Le premier vous dit où le processus a cassé ; le second vous dit quoi supprimer. Nous avons supprimé un grand nombre de champs personnalisés lors d’un audit du système CRM sans qu’un utilisateur ne le remarque, ce qui est la preuve la plus claire qu’ils n’étaient pas nécessaires.
Les définitions de pipeline sont là où vit le vrai désaccord
Demandez à quatre personnes ce qu’une opportunité qualifiée signifie et vous obtiendrez quatre réponses. C’est une définition non documentée, et cela rend chaque taux de conversion dans le système dénué de sens. Pendant l’audit, nous demandons aux ventes ce qui doit être vrai pour qu’un enregistrement se déplace entre les étapes, puis nous comparons cela à ce qui déplace réellement les enregistrements dans les données. L’écart est généralement grand : les étapes sont sautées, les deals sont créés à la signature, les catégories de prévision sont définies par habitude.
Les vérifications que nous effectuons du côté processus :
- Critères d’entrée et de sortie écrits pour chaque étape du pipeline, et si les données correspondent à eux
- Discipline de date de clôture : à quelle fréquence les dates sont poussées plutôt que les deals marqués comme perdus
- Raisons de perte, si elles sont obligatoires, et si les options décrivent quelque chose d’actionnable
- Règles de propriété et de transfert entre le marketing, les ventes et la gestion de compte
- Si les leads entrants du site web arrivent avec des données de source intactes ou aplatis à une seule valeur générique
Ce dernier point connecte le CRM à tout le reste que nous gérons. Si la source du lead est perdue lors du transfert, l’attribution pour les médias payants et la recherche organique s’arrête à la soumission du formulaire, et chaque discussion en aval sur la performance du canal devient des conjectures. Réparer le transfert de source est souvent l’élément de plus grande valeur dans tout l’audit, et c’est généralement une petite pièce de configuration.
Prolifération de l’automatisation et les règles dont personne ne se souvient
Les CRM matures accumulent des automatisations comme une base de code accumule des fonctions mortes. Nous inventarions chaque flux de travail, règle et déclencheur, enregistrons ce qui les déclenche, et vérifions quand ils ont été exécutés pour la dernière fois. Les règles qui n’ont pas été déclenchées depuis une longue période sont candidates à la suppression. Les règles qui se déclenchent constamment doivent être vérifiées pour les boucles.
Nous cherchons également des automatisations qui envoient des choses aux clients. Ce sont les éléments à plus haut risque dans tout CRM : une règle qui se déclenche mal envoie des e-mails à de vraies personnes, et l’échec est public. Toute règle avec un envoi externe est documentée, avec un propriétaire nommé, avant que nous ne touchions à quoi que ce soit à proximité.
Autorisations, visibilité et ce que l’audit trouve inconfortable
Un audit du système CRM fait généralement surface au moins un problème d’autorisations : droits d’exportation accordés trop largement, une intégration connectée avec le compte administrateur d’un ancien employé, ou une clé API émise pour un projet qui s’est terminé. Rien de tout cela n’est malveillant, c’est de l’accumulation. Nous listons les intégrations actives, identifions quel compte autorise chacune, et marquons tout ce qui est lié à une personne plutôt qu’à une identité de service.
L’adoption est mesurée en même temps : connexions, enregistrements touchés par utilisateur par semaine, et combien d’activité est enregistrée manuellement plutôt que capturée automatiquement. Une faible adoption est rarement un problème de formation. Habituellement, le système demande plus qu’il ne rend, et la solution est de réduire l’entrée requise.
À quoi ressemble le résultat
Le livrable est une liste classée avec trois colonnes : la conclusion, ce qu’elle coûte en termes pratiques, et l’effort pour résoudre. Rien n’est appelé urgent à moins que ce ne soit le cas. La plupart des conclusions deviennent un travail de configuration sur quelques semaines, un ensemble plus petit devient des accords de processus qui nécessitent une décision de l’entreprise, et occasionnellement un élément nécessite un changement de plateforme.
La raison pour laquelle nous insistons sur cet ordre est simple. Une migration effectuée sur des définitions non résolues et des enregistrements dupliqués reproduit chaque problème existant dans un système que personne ne connaît encore, et elle le fait à un coût considérable. Un audit du système CRM coûte une fraction de cela et élimine fréquemment la raison de la migration entièrement. Quand ce n’est pas le cas, l’audit devient la spécification pour la reconstruction, ce qui est la chose la plus utile qu’il puisse être.
Continuer à lire : Système CRM · Crm System