Intégration des DM au CRM : où les rendez-vous se perdent

L'intégration des DM au CRM, c'est l'ensemble des règles qui transforment une conversation de messagerie en une fiche que votre équipe commerciale peut réellement travailler, mesurer et défendre au renouvellement. Mal faite, elle se réduit à une automatisation qui crée un contact et jette tout le reste, et c'est ainsi qu'on termine un mois avec des agendas pleins et un pipeline qui paraît vide.

Ce texte s'adresse à celui qui pilote plusieurs setters ou plusieurs comptes clients : patron d'agence, directeur commercial, responsable des opérations. À cette échelle, la question n'est pas de savoir si le message arrive dans le CRM, mais s'il arrive avec assez de contexte pour qu'un closer ouvre la fiche à froid, cinq jours plus tard, et sache ce qui a été promis, par qui, sur quel compte.

En bref

• Ce n'est pas un problème de tuyauterie. Une messagerie est structurée par fil, un CRM par personne, et chaque fuite ci-dessous est un endroit où les deux ne sont pas d'accord sur ce qu'est un objet.
• La fiche se crée par règle, jamais au jugé. Si un setter décide quels fils méritent d'être enregistrés, votre pipeline est un échantillon et votre coût par rendez-vous une fiction.
• La source, le compte client et le setter s'écrivent à la création. Rien de rattrapé plus tard ne survit à un rapport mensuel.
• Un rendez-vous qui n'existe que dans l'outil de réservation n'est pas pris, du point de vue de l'entreprise. Le résultat doit revenir le jour même à celui qui l'a décroché.
• Les agences ont un problème de plus : dix CRM clients. Gardez la vérité dans votre couche opérationnelle et traitez chaque CRM client comme une destination, pas comme la source.

Sommaire

• Pourquoi une intégration des DM au CRM casse aux jointures
• Les sept fuites sur une seule page
• Fuites 1 à 3, avant que le rendez-vous soit pris
• Fuites 4 et 5, la prise de rendez-vous et les absences
• Fuites 6 et 7, plusieurs comptes et le contrat de champs
• La fiche minimale que doit porter un rendez-vous
• Par quoi commencer, dans cet ordre
• Ce que fait SetScale
• FAQ
• Conclusion

Pourquoi une intégration des DM au CRM casse aux jointures

La plupart des équipes décrivent le sujet comme un problème de connexion : la messagerie d'un côté, le CRM de l'autre, un tuyau manquant entre les deux. Le tuyau est rarement la difficulté. La difficulté, c'est que les deux systèmes ne modélisent pas le monde de la même façon.

Une messagerie est organisée par fil : un fil, une conversation, un endroit où les messages arrivent. Un CRM est organisé par personne et par affaire. Un même être humain peut détenir trois fils sur deux de vos comptes clients, sur deux plateformes, sous un pseudo qui ne correspond pas au nom de la facture. Dès que vous reliez les deux sans avoir décidé comment un fil devient une personne, vous n'intégrez pas : vous dupliquez.

La deuxième raison tient au calendrier. Personne ne construit ça le premier jour. L'intégration se construit la semaine où un client demande pourquoi le rapport annonce onze rendez-vous quand son agenda en montre neuf. À ce moment-là, il y a déjà des mois de fils que personne n'a consignés, des setters avec chacun leur convention, et des fiches dont l'origine se résume au mot « réseaux » ou à rien du tout.

La bonne question n'est donc pas « comment relier ces deux outils », mais « où, précisément, un rendez-vous perd-il de l'information entre la première réponse et la discussion de renouvellement ». Il existe sept endroits de ce type, les mêmes dans presque toutes les opérations, que le CRM soit une plateforme d'agence complète ou un tableur ambitieux. Pour la vue d'ensemble, voyez l'infrastructure de setting.

Les sept fuites sur une seule page

#	Fuite	Ce que ça donne dans le rapport mensuel	La règle qui la colmate
1	La fiche qui n'est jamais créée	Moins de conversations que la messagerie n'en a réellement portées	La création est déclenchée par le système à la première réponse qualifiante, jamais par un setter qui trouve un fil intéressant
2	Le doublon qui coupe l'historique	Deux demi-fiches pour un seul acheteur, aucune avec l'histoire complète	Une clé d'identité par humain, choisie à l'avance et appliquée partout
3	La source qui disparaît	Tout attribué aux « réseaux » ou à rien	Source, campagne et compte client écrits à la création, jamais rattrapés après coup
4	Le rendez-vous qui ne vit que dans l'agenda	L'agenda montre des rendez-vous dont le CRM n'a jamais entendu parler	Le rendez-vous est un événement posé sur la fiche, portant le setter qui l'a décroché
5	Le résultat qui ne revient jamais	Le taux de présence connu du closer, ignoré du setter	Les résultats sont réécrits sur la fiche et remontés au setter dans la journée
6	Un CRM par compte client	Un rapport reconstruit à la main chaque mois, client par client	Votre couche opérationnelle détient la vérité, les CRM clients en reçoivent une copie
7	Le contrat de champs que personne n'a signé	Des notes en texte libre qu'aucun rapport ne sait lire	Un contrat de champs court et écrit, identique sur tous les comptes

Lisez ce tableau comme un diagnostic, pas comme un ordre de chantier. La plupart des équipes en cumulent quatre ou cinq, et les traiter dans le mauvais ordre gâche le travail. L'ordre qui tient est en fin d'article.

Fuites 1 à 3, avant que le rendez-vous soit pris

Fuite 1, la fiche qui n'est jamais créée. Dans beaucoup d'opérations, la fiche CRM apparaît quand un setter juge la conversation prometteuse. Cette seule décision détruit tous les chiffres en aval : votre taux de passage de la conversation au rendez-vous est flatté, et votre coût par rendez-vous paraît meilleur qu'il n'est parce que le dénominateur a été discrètement rogné. Pire, le jugement n'est pas stable : le même fil est enregistré par un setter et ignoré par un autre, ce qui est la dérive qu'une grille de qualification est censée supprimer.

La règle est ennuyeuse et non négociable. Une fiche est créée par le système, sur un déclencheur que vous savez décrire en une phrase, pour toute conversation entrante qui le remplit. Le déclencheur habituel est la première vraie réponse du prospect, pas le message automatique : cela écarte les robots sans réintroduire de goût personnel.

Fuite 2, le doublon qui coupe l'historique. La même personne écrit au compte de marque en mars, puis au compte publicitaire sur une autre plateforme en juin. Vous avez deux fiches, chacune avec la moitié de l'histoire, et le closer qui ouvrira la seconde commencera son appel par une question à laquelle le prospect a déjà répondu.

Choisissez la clé d'identité avant de construire quoi que ce soit. Un numéro de téléphone, quand le canal vous en donne un, est la clé la plus solide que vous obtiendrez. À défaut, un pseudo de plateforme associé au compte client d'origine, plus fragile mais stable. Ce qui compte davantage que le choix, c'est que tout le monde applique la même clé, et que la fusion soit une opération définie plutôt qu'un nettoyage de fin de trimestre. Les équipes qui pilotent beaucoup de comptes de marque rencontrent ce mur en premier, et c'est pour cela que le playbook multi-comptes traite l'identité comme un sujet d'opérations et non d'outillage.

Fuite 3, la source qui disparaît. C'est celle qui coûte de l'argent au renouvellement. Une fiche arrive sans campagne, sans compte d'origine et sans canal, si bien qu'en fin de mois l'organique et le payant s'effondrent dans un même bloc appelé « réseaux ». Vous ne pouvez plus dire à un client quelle part de son budget a produit les rendez-vous, et les neuf chiffres qui portent un rapport client deviennent des estimations.

L'attribution s'écrit à la création, dans l'opération même qui crée la fiche. Ni enrichie plus tard, ni déduite d'un horodatage. Si une conversation vient d'une publicité vers la messagerie, ce fait existe dès le premier message et coûte trois fois rien à stocker à cet instant, l'argument exact de l'article sur les publicités qui ouvrent une conversation. La reconstituer trois semaines plus tard coûte un après-midi et produit un chiffre auquel personne ne croit.

Colmater ces trois premières fuites est aussi ce qui rend le temps de réponse mesurable : un engagement de délai de réponse ne veut rien dire si le chronomètre démarre quand quelqu'un pense à créer une fiche.

Si vous pilotez plusieurs setters sur plusieurs comptes et voulez que ces trois règles tiennent à l'identique partout sans une procédure écrite que personne ne lit, Rejoindre la liste d'attente.

Fuites 4 et 5, la prise de rendez-vous et les absences

Fuite 4, le rendez-vous qui ne vit que dans l'agenda. Un setter envoie un lien de réservation, le prospect choisit un créneau, l'événement se crée dans un outil d'agenda. La fiche CRM, si elle existe, indique toujours une conversation en cours. Tous vos comptages issus du CRM sont désormais faux dans la direction qui compte le plus, puisque le rendez-vous est l'unité que vos clients paient.

La correction consiste à traiter le rendez-vous comme un événement écrit sur la fiche, portant au minimum le créneau, le closer assigné et le setter qui l'a décroché. Ce dernier champ est celui qu'on oublie, et celui qui rend tout le modèle setter closer auditable : sans lui, vous n'attribuez le rendez-vous à personne, donc vous ne pouvez ni le rémunérer, ni le coacher, ni le défendre.

Fuite 5, le résultat qui ne revient jamais. L'appel a lieu, ou pas. Dans les deux cas le résultat atterrit chez le closer, et le setter qui a passé neuf messages à décrocher ce créneau l'apprend des semaines plus tard, en agrégé, quand il l'apprend. Deux choses cassent : le coaching, faute de boucle de retour assez courte, et la reprogrammation, parce que personne ne détient l'absence tant que le fil est chaud.

Réécrivez les résultats sur la fiche et remontez-les au setter le jour même : présent, absent, reporté, écarté pendant l'appel, avec un code de motif assez court pour que les gens l'utilisent. Une absence qui revient au setter en quelques heures est une conversation de report. La même absence remontée une semaine plus tard est une prise de contact à froid, et elle relève du processus de relance plutôt que du fil d'origine. La nuance vaut de l'argent réel sur des agendas à fort ticket, tout le sujet de garder les agendas de closers pleins.

Fuites 6 et 7, plusieurs comptes et le contrat de champs

Fuite 6, un CRM par compte client. Cette fuite n'existe que pour les agences, et c'est celle qui plafonne discrètement le nombre de clients que vous pouvez porter. Chaque client a sa plateforme, ses noms de champs, sa propre idée de ce qu'est une étape. Si vous laissez chaque CRM client faire autorité sur son compte, votre vision de votre propre activité devient un réassemblage mensuel, un client plus lourd à chaque signature.

Inversez. Votre couche opérationnelle détient la fiche : toutes les conversations, tous les rendez-vous, tous les résultats, sur tous les comptes, dans une seule forme. Chaque CRM client en reçoit une copie dans la forme qu'il souhaite. C'est plus long à mettre en place et c'est la seule version qui survit à la croissance, parce que le travail de correspondance devient additif par client au lieu d'être répété à chaque rapport. Le jour où un client part, votre histoire opérationnelle ne part pas avec lui. Si vous soupesez ce qu'une plateforme d'agence coûte réellement à cette échelle, la décomposition du prix d'une plateforme d'agence mérite une lecture préalable.

Fuite 7, le contrat de champs que personne n'a signé. Demandez à trois setters ce qui doit figurer dans le champ notes et vous obtiendrez trois réponses raisonnables, aucune lisible par une machine. Le texte libre est l'endroit où l'information devient invisible : elle est là, un humain la retrouverait, aucun rapport ne la verra.

Un contrat de champs est un document court qui dit quels champs existent, ce que chacun signifie, qui l'écrit et quelles valeurs sont autorisées. Le mot « court » travaille ici : un contrat à quarante champs est un contrat que personne n'applique. Huit à douze champs, avec des listes fermées partout où c'est possible, c'est la version qui survit à la première semaine d'un nouveau setter, et ce qui accélère tout plan de formation en trente jours.

La fiche minimale que doit porter un rendez-vous

Si vous retirez tout le reste, un rendez-vous qui arrive chez un closer devrait porter les champs suivants. Le test est simple : ouvrez une fiche au hasard, cinq jours après la conversation, et regardez si un closer pourrait mener l'appel sans poser de question à personne.

• L'identité, sous la clé choisie, plus le pseudo ou le numéro utilisé dans la conversation.
• Le compte client et le canal, pour que l'attribution n'ait jamais à être reconstituée.
• La source, au niveau de la campagne quand la conversation vient du payant, du compte sinon.
• L'horodatage du premier contact et de la première réponse, dont dérive toute mesure de délai.
• Le verdict de qualification et sa preuve, idéalement les mots du prospect plutôt qu'un résumé.
• La promesse faite, ce qu'on a réellement annoncé au prospect sur l'objet de l'appel. Le champ le plus souvent absent, et celui qui produit les pires appels.
• Créneau réservé, closer assigné, setter qui a décroché.
• Résultat et code de motif, réécrits après l'appel.

Remarquez ce qui n'y est pas : ni score de lead, ni statut de cycle de vie, ni note d'engagement. Ce sont des sorties, calculables plus tard à partir des champs ci-dessus. Ce qu'un humain saisit sous pression se limite à ce que seul un humain présent dans la conversation peut savoir.

Par quoi commencer, dans cet ordre

Dans cet ordre : chaque étape rend la suivante moins chère, et les inverser oblige à reconstruire.

1. Écrivez le contrat de champs. Une page, huit à douze champs, listes fermées quand c'est possible. Aucune décision d'outil n'est sûre avant, parce que tous les outils vous laisseront volontiers encoder un mauvais contrat.
2. Traitez la création et l'identité ensemble. Le déclencheur systématique et la clé d'identité sont une seule décision, et les rattraper sur des mois de fiches est le travail le plus coûteux de cet article.
3. Écrivez l'attribution à la création. Peu coûteux une fois l'étape deux en place, quasi impossible après.
4. Posez l'événement de rendez-vous sur la fiche, avec le setter qui l'a décroché. C'est là que vos chiffres internes et l'agenda du client commencent à s'accorder.
5. Refermez la boucle des résultats vers le setter. En dernier, parce qu'elle dépend des quatre précédentes, et parce que c'est celle qu'on remarque : elle change les comportements la semaine où on l'allume.

Une équipe arrivée seulement à l'étape trois a une opération qui fonctionne. Une équipe qui a sauté à l'étape cinq sans les étapes un et deux a un tableau de bord bâti sur un échantillon partiel, pire que rien, parce qu'on y croit.

Ce que fait SetScale

SetScale se construit comme la couche de setting pour les équipes et les agences : plusieurs comptes clients, plusieurs closers, une seule fiche opérationnelle en dessous. L'argument de cet article, la vérité qui vit dans votre couche et se copie vers les systèmes clients plutôt que de s'assembler à partir d'eux, est la forme autour de laquelle le produit est bâti.

Soyons directs : le produit n'est pas encore ouvert. Pas de liste d'intégrations à publier, pas de tarif à annoncer, aucun cas client à montrer. Une orientation en marque blanche est prévue pour les agences qui revendent le setting sous leur marque, et un essai gratuit de sept jours est prévu à l'ouverture. Si l'architecture décrite ici est ce qui manque à votre opération, Rejoindre la liste d'attente et vous serez prévenu. En attendant, tout ce qui précède se construit avec les outils que vous faites déjà tourner.

FAQ

Faut-il un vrai CRM, ou un tableur suffit-il pour démarrer ? Un tableur suffit pour un compte et deux setters, à condition qu'il respecte le contrat de champs et la clé d'identité. Il cesse de suffire quand deux personnes doivent écrire sur la même fiche en même temps, ou quand un client veut sa copie. Le point de rupture est la concurrence d'accès, pas l'outil.

L'intégration doit-elle être en temps réel ? La création et l'attribution doivent être immédiates : toutes deux dépendent d'informations qui n'existent qu'au moment du message. La réécriture des résultats tolère quelques heures de décalage, tant qu'elle atteint le setter le jour même. Le temps réel partout est un coût sans bénéfice.

Comment gérer un prospect qui nous parle sur deux canaux ? Fusionnez vers une seule fiche sous votre clé d'identité, et gardez les deux identifiants de canal dessus. L'essentiel n'est pas la fusion, c'est que la personne qui reprend la conversation voie l'historique complet plutôt que la moitié ouverte par hasard.

Qui doit être responsable de l'intégration, le commerce ou les opérations ? Les opérations détiennent le contrat et la tuyauterie, le commerce détient la définition des champs. Quand l'un des deux détient tout, vous obtenez une donnée propre mais inutilisée, ou utile mais illisible.

Conclusion

L'intégration des DM au CRM se joue bien avant que quiconque relie deux outils. Elle se joue sur quatre choix : quand une fiche est créée, ce qui fait qu'une personne est une seule personne, ce qui s'écrit à la création, et où va le résultat ensuite. Réussissez ces quatre-là et presque n'importe quel CRM fera l'affaire. Ratez-les et la meilleure plateforme du marché vous donnera une version rapide et chère des mauvais chiffres.

Commencez par le contrat de champs cette semaine : c'est l'étape la moins chère, la seule qui ne coûte rien à défaire, et toutes les autres deviennent plus simples une fois qu'elle existe. Pour comparer ce que cette architecture coûte face aux alternatives, la décomposition des trois voies de la prise de rendez-vous met des chiffres en face de l'internalisation, de l'externalisation et de l'outillage. Et si vous préférez que la couche de fiche arrive avec l'opération plutôt que de la construire vous-même, Rejoindre la liste d'attente.