CRM pour firmes de génie et d’architecture
Une firme de conception ne conclut pas des ventes; elle remporte des propositions : des offres de services déposées avant une date limite, souvent avec des partenaires de consortium, et évaluées en partie sur les projets et les personnes que la firme peut citer. Les relations qui génèrent ces propositions passent par des individus — un chargé de projet chez un promoteur, un directeur dans une municipalité — qui changent d’employeur et emportent la relation avec eux. Un CRM de vente ne modélise ni la proposition ni la relation centrée sur la personne, et c’est pourquoi le CRM de la plupart des firmes est un cimetière d’occasions périmées, à côté d’un dossier de propositions qui contient la vérité.
Où le CRM générique ne tient pas :
Une occasion d’affaires n’est pas une proposition. Une proposition a une date limite de dépôt, une décision d’y aller ou non, des partenaires de consortium et une offre à monter. Une occasion dans un CRM a un montant et une date de conclusion. La firme finit par gérer ses vraies propositions dans les courriels et les dossiers pendant que le CRM enregistre de la fiction.
Les relations suivent les personnes, pas les entreprises. Le client, sur papier, c’est le promoteur ou la municipalité; la relation, elle, est avec une personne qui change d’emploi toutes les quelques années. Un CRM centré sur les entreprises perd le fil à chaque changement, c’est-à-dire exactement au moment où il serait le plus précieux d’avoir suivi la relation.
L’expérience ne se consulte pas. Chaque proposition exige des projets pertinents et des personnes disponibles qui ont les bons titres professionnels. Quand l’expérience de projet vit dans d’anciennes propositions, chaque proposition reconstruit les mêmes qualifications à partir de zéro, et la réponse à « avons-nous déjà fait un bâtiment comme celui-là? » dépend de qui est au bureau.
Aucune discipline pour décider d’y aller ou non. Les firmes perdent plus de marge à courir après le mauvais travail qu’à perdre le bon. Un CRM sans étape structurée pour décider d’y aller ou non n’enregistre cette décision nulle part, alors la firme ne peut pas voir son propre taux de succès par type de client ou par taille de projet — les chiffres qui devraient guider la décision.
Le modèle de données qui convient vraiment :
Proposition. L’effort de proposition comme objet distinct : date limite de dépôt, décision d’y aller ou non, partenaires de consortium, effort assigné et résultat. C’est l’objet que la coordination marketing gère réellement, et c’est celui qui manque au CRM.
Relation centrée sur la personne. Les contacts suivis comme des individus avec leur historique d’emploi, pour que, quand le chargé de projet passe d’un promoteur à un autre, la relation — et son historique de projets — le suive.
Fiche d’expérience de projet. Les projets terminés classés par type, taille, rôle et membres du personnel impliqués, pour que les pages de qualifications se montent par requête plutôt que par archéologie dans d’anciennes propositions.
Historique des consortiums. Avec quelles firmes vous avez soumissionné, dans quel rôle, et avec quel résultat — parce que la moitié du pipeline arrive par des partenaires et que personne ne peut dire aujourd’hui quels partenariats gagnent vraiment.
Registre des taux de succès. Les résultats par client, par type et par taille de projet, qui alimentent la décision d’y aller ou non avec l’historique réel de la firme plutôt qu’avec de l’optimisme.
Notre verdict : Configurez avant de bâtir. Un CRM générique, avec de la discipline, couvre les contacts centrés sur la personne et le suivi de base des propositions mieux que la plupart des firmes ne le croient, et les CRM de services professionnels conçus pour le marché de l’architecture, de l’ingénierie et de la construction méritent d’être évalués en premier. La pièce qui justifie généralement un développement sur mesure, c’est la fiche d’expérience de projet reliée aux propositions — monter les qualifications à partir d’une base qu’on peut interroger — parce qu’elle touche les données de projet de la firme et qu’aucun outil tout fait ne les connaît. Bâtissez-la seulement une fois que la discipline des propositions existe, sinon ce sera une base de données bien modélisée, mais vide.
Pourquoi les déploiements de CRM échouent-ils si systématiquement dans les firmes de conception?
Parce que ce sont les associés qui obtiennent les mandats, et que les associés ne font pas de saisie de données. Tout système qui dépend d’un associé qui consigne ses appels est mort en un trimestre. La conception qui fonctionne saisit les propositions et leurs résultats — ce que la coordination tient à jour de toute façon — et traite la connaissance des relations qu’ont les associés comme quelque chose à recueillir en entrevue, pas à taper.
La métaphore du pipeline est-elle utile, ne serait-ce qu’un peu, ici?
Comme prévision des honoraires, vaguement. Comme outil de gestion, moins que la liste des échéances : les propositions dues ce mois-ci, dans l’ordre, avec leurs responsables. Les firmes fonctionnent selon les dates de dépôt comme les entrepreneurs fonctionnent selon les dates de coulée du béton, et le calendrier bat l’entonnoir.
Le CRM devrait-il être relié aux systèmes de réalisation de projets?
Légèrement, et dans un seul sens. Quand une proposition est remportée, elle devrait devenir une fiche de projet sans ressaisie; quand un projet se termine, ses données devraient revenir comme expérience. Au-delà de ça, gardez la réalisation dans les outils de réalisation — le CRM sert à obtenir le travail, pas à le gérer.
Quelle est la première chose à régler si le CRM actuel est un cimetière?
Le réduire à ce qui sera réellement tenu à jour : les propositions actives avec leurs échéances et leurs résultats. Un petit ensemble de données vraies vaut mieux qu’un gros ensemble périmé, et chaque couche utile — taux de succès, expérience, historique des consortiums — ne peut se bâtir que sur des fiches que quelqu’un tient à jour.
Dernière révision le 27 août 2026