Compte client multi-établissements : groupe, agence ou chantier ?

Un compte client multi-établissements devient vite un problème commercial quand le siège, l’agence qui achète et le chantier qui utilise la machine ne sont pas distingués. Une demande de chargeuse arrive d’un conducteur de travaux, le domaine e-mail renvoie au siège, l’historique atelier est rangé sous une agence et un devis est déjà ouvert ailleurs. Si tout est attaché à un compte unique, le commercial peut appeler le mauvais interlocuteur, ignorer une affaire en cours ou traiter comme prospect un client déjà connu.

La réponse n’est pas de créer davantage de fiches au hasard. Il faut séparer quatre objets, puis rattacher chaque fait à celui qui en est réellement responsable : le groupe économique pour la vue consolidée, l’unité légale pour le contrat, l’établissement pour l’exploitation locale et le chantier pour le contexte temporaire. L’opportunité garde ensuite des liens explicites vers l’entité qui achète, le site qui utilise et le projet qui fixe le calendrier.

Le groupe, le SIREN, le SIRET et le chantier ne répondent pas à la même question

Le registre Sirene donne une base utile pour éviter les confusions. Selon l’Insee, l’unité légale est l’entité juridique enregistrée dans Sirene. Le site officiel Service Public Entreprendre précise que le SIREN identifie l’entreprise, tandis que le SIRET identifie chacun de ses établissements et comporte une dimension géographique.

Ces identifiants ne suffisent pourtant pas à modéliser la relation commerciale. Un groupe peut réunir plusieurs unités légales. Une unité légale peut exploiter plusieurs établissements. Un chantier, lui, est un contexte d’exécution avec une adresse, des dates, des contraintes et parfois plusieurs entreprises. Il ne doit pas devenir artificiellement un client s’il n’a pas d’existence juridique propre.

• Groupe économique : consolider l’exposition commerciale, les accords et les relations, sans le confondre avec une entité contractante.

• Unité légale : porter l’identité de l’entité susceptible de signer, commander et être facturée.

• Établissement : représenter un site d’exploitation identifié par un SIRET, avec son adresse et son statut.

• Chantier ou projet : conserver le lieu d’usage, la fenêtre de besoin, l’application et les contraintes temporaires.

Les CRM savent généralement représenter des relations parent-enfant. Microsoft documente par exemple une hiérarchie de comptes construite à partir d’une relation entre un compte parent et ses comptes enfants. HubSpot permet également d’associer une société mère et des filiales. Ces mécanismes affichent une structure existante, mais ils ne décident pas à votre place quelle entité achète, quel établissement utilise la machine ni où doit vivre l’opportunité.

Rattacher chaque fait à son propriétaire réel

La règle la plus robuste consiste à ne pas demander « quel est le bon compte ? », mais « qui porte ce fait ? ». Un même dossier peut ainsi référencer plusieurs niveaux sans dupliquer l’information.

• Le devis et la commande se rattachent à l’unité légale qui peut contracter. L’établissement acheteur ou livré reste un lien séparé.

• La livraison, le passage atelier et l’emplacement d’une machine se rattachent au site concerné, avec le SIRET lorsqu’il existe et qu’il est vérifié.

• Le besoin opérationnel se rattache au chantier ou au projet : dates, application, accès, configuration attendue et lieu d’utilisation.

• Le contact se rattache à son employeur vérifié, puis reçoit un rôle et un périmètre : acheteur central, responsable d’agence, chef de chantier ou utilisateur.

Une demande entrante devrait donc répondre à trois questions séparées : quelle entité peut acheter, où la machine sera-t-elle utilisée, et qui participe à la décision ? Si la première réponse manque, il est prématuré de créer automatiquement un devis au nom du siège. Le dossier doit rester en statut « rattachement à confirmer », avec un propriétaire chargé de lever l’ambiguïté.

Une règle de décision avant l’attribution commerciale

Le rattachement précède l’attribution. L’article sur l’attribution d’une opportunité commerciale matériel TP répond à la question « qui doit agir ? ». Ici, la question est différente : « à quelle entité, quel site et quel projet appartiennent les faits qui justifient l’action ? ».

Pour chaque demande liée à une organisation multi-sites, appliquez les règles dans cet ordre :

• 1. Identifier l’entité contractante candidate. Chercher un SIREN ou un SIRET fourni, puis vérifier la raison sociale et l’adresse. Un domaine e-mail ou un nom commercial ne suffit pas à fusionner deux comptes.

• 2. Isoler le lieu d’usage. Conserver l’établissement ou le chantier séparément de l’entité contractante. L’adresse de livraison n’est pas, à elle seule, une preuve d’identité juridique.

• 3. Vérifier l’autorité d’achat. Noter si l’achat est centralisé, local ou encore inconnu. Sans cette information, la hiérarchie décrit l’organisation mais ne permet pas un routage fiable.

• 4. Rechercher les affaires et relations actives. Contrôler les devis ouverts, les contacts récents et le propriétaire commercial au niveau de l’unité légale, de l’établissement et du groupe.

• 5. Bloquer les décisions irréversibles en cas de conflit. Ne pas fusionner silencieusement des fiches, ne pas réattribuer une affaire en cours et ne pas envoyer une relance tant que l’ambiguïté n’est pas arbitrée.

Cette séquence évite une erreur fréquente : utiliser la hiérarchie comme une preuve d’intention. La compatibilité de la machine, le timing et l’intention d’achat restent trois dimensions distinctes. Une machine peut convenir techniquement sans être disponible dans la fenêtre du chantier. Un contact peut appartenir au bon groupe sans avoir exprimé un besoin. Une demande réelle peut enfin concerner une entité qui n’est pas encore identifiée avec certitude.

Le minimum de données qui rend la décision explicable

Il n’est pas nécessaire d’enrichir chaque compte avec des dizaines de champs. Il faut surtout conserver les preuves qui permettent de comprendre le rattachement et de le corriger.

• Identité : SIREN, SIRET lorsqu’il s’applique, raison sociale, nom commercial, adresse et statut de l’établissement.

• Structure : identifiant du groupe, lien parent-enfant, type de relation et période de validité.

• Demande : source, date, famille de machine, caractéristiques bloquantes, lieu d’usage et fenêtre de livraison.

• Relation : contacts, rôles, périmètre géographique, dernier échange utile, devis et opportunités encore ouverts.

• Traçabilité : source de chaque donnée, date de vérification, personne ayant validé et motif d’un éventuel changement.

La source compte autant que la valeur. Une adresse saisie dans un ancien devis, un SIRET issu d’une source officielle et une mention libre dans un e-mail n’ont pas le même niveau de fiabilité. Le modèle doit permettre de conserver cette différence au lieu d’écraser la donnée la plus récente par la dernière synchronisation arrivée.

Exemple fictif : une demande, quatre niveaux

Exemple entièrement fictif. Le groupe Bâtiments Nord possède plusieurs unités légales. Une agence de Metz, identifiée par son SIRET, a déjà un devis ouvert pour une chargeuse. Un conducteur de travaux contacte le négociant depuis un chantier à Strasbourg avec une adresse e-mail portant le domaine du siège.

Le domaine e-mail fait remonter le groupe, mais ne prouve pas que le siège achètera. Le chantier explique l’application et la date du besoin, mais il n’est pas le client à facturer. L’agence de Metz est une candidate crédible parce qu’elle est déjà liée au devis, mais son autorité d’achat doit encore être confirmée.

La bonne action n’est donc ni de créer un nouveau prospect « chantier Strasbourg », ni d’envoyer immédiatement la demande au responsable grands comptes. Le responsable des données rattache provisoirement la demande au groupe, lie le chantier comme contexte, signale le devis existant et demande au propriétaire de l’agence de confirmer l’entité contractante. Une fois ce point validé, le directeur commercial peut arbitrer l’attribution sans perdre l’historique.

Qui arbitre, et à quel moment ?

La responsabilité doit être visible, sinon les ambiguïtés restent dans une file sans propriétaire.

• Administration des ventes ou référent données : vérifie l’identité et les doublons, documente la source, propose le rattachement.

• Responsable de compte : confirme le modèle d’achat du client et les relations actives.

• Responsable occasions ou chef des ventes : vérifie l’adéquation entre la demande, le stock et la fenêtre commerciale.

• Directeur commercial : arbitre les conflits de territoire, de compte national ou de marge lorsque plusieurs équipes ont une légitimité.

L’automatisation peut proposer des correspondances à partir des identifiants, des noms, des adresses et des relations existantes. Elle peut aussi signaler un doublon ou un devis ouvert. Elle ne devrait pas fusionner ou router seule lorsqu’un SIRET contredit le domaine e-mail, lorsque plusieurs unités légales sont possibles ou lorsque l’autorité d’achat n’est pas connue. Le passage à un humain doit être déclenché par ces conflits précis, pas par un score opaque.

Mesurer la qualité du rattachement, pas le nombre de fiches

Le nombre de comptes nettoyés est un indicateur d’activité, pas un indicateur de qualité. Suivez plutôt un taux avec un dénominateur explicite :

Taux de rattachement validé = nombre de demandes multi-sites dont l’entité contractante et le lieu d’usage sont confirmés sans correction après revue / nombre total de demandes multi-sites revues.

Ajoutez deux mesures de diagnostic : le délai médian entre la réception et la validation du rattachement, puis la part des demandes bloquées par motif, par exemple SIRET manquant, autorité d’achat inconnue, doublon ou conflit de propriétaire. Ces mesures n’annoncent pas un gain financier. Elles montrent où la donnée empêche encore l’action.

Un tableau partagé peut suffire pour tester la méthode sur quelques dossiers. Il devient fragile lorsque les agences changent, que plusieurs systèmes portent des identifiants différents ou que les commerciaux travaillent en parallèle. La difficulté n’est plus seulement de trouver une ligne, mais de maintenir les liens, leur validité et la trace de l’arbitrage.

Du compte structuré à l’action commerciale

La hiérarchie n’a de valeur que si elle aide à décider. Une fois l’entité contractante, le site d’usage et le chantier distingués, l’équipe peut rapprocher le besoin du stock disponible, de l’historique de relation et des affaires ouvertes. Le CRM conserve la relation, mais l’action stock reste à organiser : qualifier la compatibilité, vérifier le calendrier, puis transmettre une action motivée au bon propriétaire.

Ironwise est conçu pour rapprocher stock, historique clients et signaux du marché afin de prioriser des opportunités explicables. Sur un compte multi-établissements, le problème à résoudre est précis : éviter qu’une demande pertinente soit séparée de l’historique utile ou confiée à la mauvaise équipe parce que groupe, société, agence et chantier ont été confondus.

Une prochaine étape concrète consiste à prendre trois comptes multi-sites, une demande récente et les devis ouverts associés. Vérifiez ensemble l’entité qui peut acheter, le lieu d’usage, le propriétaire actuel et les données manquantes. Si ce test révèle des ruptures récurrentes, discutons du cas et d’une démonstration d’Ironwise si elle est disponible.