CRM intégré à vos outils ou CRM central : quand le module de Brevo ou Zendesk ne suffit plus

Beaucoup d’entreprises commencent de la même façon. Un outil d’emailing pour la lettre d’information, puis un outil de support quand les demandes débordent de la boîte partagée, puis une solution de téléphonie pour l’équipe commerciale. Chacun arrive avec sa base contacts, souvent présentée comme « un CRM ». Pendant un temps, c’est suffisant, et c’est même la bonne décision.

Le problème apparaît plus tard, et sans prévenir. Une cliente se désinscrit et reçoit quand même une séquence de prospection. La direction demande combien de clients sont actifs, et trois personnes donnent trois chiffres. Cet article vous aide à situer le moment où le module de vos outils cesse de suffire, et à décider lequel de vos outils doit faire foi sur votre client.

Ce que le module CRM de vos outils fait bien

Un outil, une équipe, un canal : le module est fait pour ça

Un outil d’emailing a besoin de savoir à qui envoyer, dans quelle liste se trouve la personne et ce qu’elle a ouvert. Un outil de support a besoin de savoir qui écrit, ce qu’il a déjà demandé et où en est sa demande. Leur base contacts le fait bien. Tant que la fiche n’est modifiée que par l’équipe qui utilise l’outil, et que vous ne suivez que des personnes, aucun conflit n’est possible : il n’existe qu’une version du client, celle de l’outil.

L’erreur consiste à croire qu’un outil qui affiche un onglet « CRM » peut servir de référentiel à toute l’entreprise.

Marketing, support, téléphonie : trois bases contacts qui ne servent pas le même but

• Marketing et emailing. Des outils comme Brevo, ActiveCampaign ou Klaviyo organisent les contacts pour segmenter et envoyer : listes, inscription aux campagnes, ouvertures et clics.
• Support et relation client. Zendesk, Intercom ou Freshdesk (Freshworks) rattachent chaque contact à ses conversations et à ses demandes, pour que la personne qui répond sache à qui elle parle.
• Téléphonie. Ringover et les solutions du même type associent un numéro à un historique d’appels ; leur liaison avec la base commerciale fait l’objet de notre article sur l’intégration de la téléphonie au CRM.

Chacune est juste pour son usage, et aucune ne sait d’elle-même ce que savent les autres.

Quand les modules se contredisent

Une cliente, trois statuts

Prenons Julie Martin, chez Exemple SAS (exemple fictif). Dans l’outil d’emailing, elle est « abonnée » et a reçu l’offre de rentrée le 3 octobre. Dans l’outil de support, elle a un ticket « en attente » depuis le 28 septembre, en priorité haute. Dans la base commerciale, elle est « prospect », sans affaire ouverte. Chaque fiche est exacte pour son outil ; ensemble, elles décrivent trois clientes différentes.

Résultat : une relance commerciale part vers quelqu’un qui attend une réponse du support. Personne n’a fait d’erreur de saisie ; il manque un endroit où son statut est décidé une fois pour toutes.

Le consentement enregistré dans un outil, ignoré dans les autres

Le cas le plus sensible est celui du consentement. Une désinscription est enregistrée là où la personne a cliqué, le plus souvent dans l’outil d’emailing. Si rien ne la transmet, la base commerciale continue de considérer le contact comme joignable, et une séquence de prospection peut repartir. Chaque outil respecte le consentement qu’il connaît : c’est une question d’endroit, pas de fonctionnalité. Les durées de conservation et la purge des contacts sont un autre sujet, traité dans notre article sur la conservation des contacts dans le CRM ; ici, la seule question est de savoir où le consentement est tenu.

Les doublons nés de la synchronisation

Pour faire circuler l’information, on relie souvent les outils deux à deux : l’emailing avec la base commerciale, le support avec l’emailing, la téléphonie avec le support. Chaque connecteur a sa propre règle de rapprochement. L’un compare l’e-mail, l’autre le numéro de téléphone, un troisième crée une fiche dès qu’il ne trouve rien. Corriger ensuite sans tout recréer demande de la méthode, comme le détaille notre guide sur les doublons CRM et ERP.

CRM intégré ou CRM central : les quatre signaux de bascule

Le choix entre un CRM intégré à vos outils et un CRM central ne se tranche ni sur la taille de l’entreprise ni sur le nombre de logiciels. Il se tranche sur quatre signaux. Un signal isolé se traite avec quelques règles de partage ; quand plusieurs apparaissent ensemble, le module ne suffit plus.

Plusieurs équipes écrivent sur la même fiche

Le marketing met à jour la fonction, le support corrige le téléphone, l’ADV change l’adresse de livraison. Quand trois équipes écrivent dans trois outils, chaque outil garde la dernière modification de son équipe et ignore celles des autres.

Vous suivez des entreprises, des affaires, des contrats, pas seulement des contacts

Les bases des outils marketing et support sont d’abord organisées autour de la personne, même quand elles savent la rattacher à une entreprise. Or une relation B2B se lit au niveau de l’entreprise : plusieurs interlocuteurs, une affaire en cours, un contrat signé, une date de renouvellement. Pour savoir qu’une demande vient d’un client qui renouvelle le mois prochain, il faut un endroit où la personne, l’entreprise et le contrat sont reliés.

Un changement chez le client n’arrive que dans un outil

Julie Martin change de société. Elle le signale au support en répondant à son ticket. L’emailing continue d’écrire à son ancienne adresse, et la base commerciale la rattache toujours à Exemple SAS. Les changements ne circulent pas.

Personne ne peut dire combien vous avez de clients actifs

C’est le signal le plus simple à tester : posez la question à trois équipes. Si les réponses diffèrent, aucune ne compte mal. Chacune compte dans son outil, avec sa propre définition de « client actif ». Un CRM central commence par fixer cette définition.

Le diagnostic en tête d’article reprend ces signaux et vous indique, selon vos réponses, la première règle à écrire.

Le nombre de connexions explique pourquoi la situation se dégrade vite. Quatre outils reliés chacun à chacun demandent six synchronisations ; avec un référentiel au centre, quatre suffisent. Un cinquième outil porte le total à dix dans le premier cas, à cinq dans le second. Surtout, un changement d’e-mail part d’un seul endroit, au lieu de traverser plusieurs liens qui ont chacun leur règle.

Qui fait foi sur quoi

Le référentiel tient l’identité, le statut et le consentement

Un CRM central n’est pas un outil de plus à remplir. C’est l’endroit où trois informations sont décidées : qui est ce client (nom, entreprise, coordonnées), où il en est avec vous (prospect, client, ancien client) et ce qu’il a accepté de recevoir. Les autres outils lisent ces informations ; ils ne les réécrivent pas chacun de leur côté.

Un CRM central ne remplace pas vos outils : il décide de ce qu’ils doivent tous croire.

Chaque outil garde ce qu’il produit : ouvertures, tickets, appels

L’erreur inverse consiste à vouloir tout remonter dans le référentiel. Ouvertures, tickets et enregistrements d’appels restent dans l’outil qui les produit. Le référentiel n’en reçoit qu’un résumé utile à tous, comme la date du dernier échange. La frontière tient en une phrase : ce qui décrit le client va au centre, ce qui décrit une activité reste dans l’outil.

La clé qui relie les fiches : l’e-mail ne suffit pas toujours

Pour que chaque outil retrouve la bonne fiche, il faut une clé commune. L’e-mail est le choix naturel, mais il atteint ses limites dans trois cas.

• Le changement d’adresse. La personne change de société ou d’adresse, et la clé change avec elle : sans identifiant stable, l’outil crée une nouvelle fiche.
• Les adresses génériques. Une adresse contact@ ou commandes@ représente plusieurs personnes, parfois plusieurs services.
• Plusieurs contacts dans une même société. Rapprocher par l’e-mail relie des personnes, pas des entreprises ; l’entreprise a besoin de sa propre clé, le SIREN par exemple.

Le plus sûr est un identifiant attribué par le référentiel et recopié dans chaque outil. La fiabilité de cette clé se suit dans le temps, comme le reste de la base : notre article sur la mesure de la qualité des données CRM détaille comment la surveiller.

Synchroniser sans fabriquer de doublons

Dédoublonner avant de brancher

Une synchronisation copie ce qu’elle trouve. Si la base d’emailing contient deux fiches pour Julie Martin et la base commerciale une troisième, relier les deux outils ne fusionne rien : cela propage les trois. Le nettoyage se fait donc avant, dans chaque base, avec une règle de fusion écrite : quelle fiche on garde, quels champs l’emportent.

Décider le sens de chaque flux

Pour chaque champ partagé, une seule question : qui l’écrit ? Trois réponses sont possibles.

• Du référentiel vers l’outil. Le statut client, décidé au centre, est lu par l’emailing et le support.
• De l’outil vers le référentiel. Une désinscription cliquée dans l’emailing remonte au centre, qui la transmet à tous les autres outils.
• Dans les deux sens. À réserver à quelques champs nommés, comme le téléphone, avec une règle explicite en cas de conflit.

Une synchronisation « tout, dans les deux sens » est la plus rapide à configurer, et la plus sûre façon de recréer des doublons.

Une synchronisation copie ce qu’elle trouve, y compris ses erreurs.

Surveiller la synchronisation après le démarrage

Une synchronisation peut dériver : un champ ajouté d’un seul côté, un connecteur modifié, une erreur silencieuse. Prévoyez un contrôle régulier : fiches créées par chaque outil, erreurs de synchronisation, fiches sans clé.

C’est la situation qu’a connue Mirakl. La synchronisation entre HubSpot et Salesforce produisait des données incohérentes, la base devait être débarrassée de ses doublons, et aucune règle claire n’encadrait l’usage des propriétés ni des workflows dans HubSpot. turnK a supprimé les doublons et les informations obsolètes, audité et corrigé les paramètres d’intégration entre les deux outils, et posé une gouvernance : des règles d’usage des propriétés et des workflows. Deux outils, deux vérités, et une règle pour revenir à une seule.

Le même raisonnement vaut au-delà du CRM : chez Focal, l’absence de liaison entre Freshdesk et l’ERP Infor LN obligeait à saisir deux fois les demandes SAV.

Par où commencer

Recenser les bases contacts qui existent déjà, y compris les tableurs

Avant de choisir un outil, faites l’inventaire. Pour chaque base : qui l’alimente, quels champs elle contient, qui la modifie, et ce qu’elle sait que les autres ignorent. N’oubliez pas les tableurs : le fichier des salons, la liste des distributeurs, la base tenue à part par l’ADV. Ce sont souvent elles qui créent des doublons à chaque import.

Cet inventaire suffit souvent à répondre à la question de départ. Si une seule base est réellement partagée et qu’une seule équipe y écrit, le module peut suffire, avec quelques règles. Si plusieurs bases se disputent le même client, il vous faut un référentiel.

Ce que turnK apporte : un référentiel client fiable et des règles de partage entre vos outils

turnK intervient sur la donnée client elle-même : inventaire des bases, dédoublonnage, choix de ce qui fait foi et de la clé de rapprochement, règles de partage entre vos outils et contrôle dans la durée. Vos équipes gardent leurs outils. L’objectif est qu’ils décrivent tous le même client.