CRM pour ébénistes et ateliers de menuiserie architecturale
Le problème d’une ébénisterie avec le CRM, c’est que la vente est la partie la plus courte du travail. Une cuisine ou un lot de menuiserie architecturale commerciale vit pendant des mois après le contrat — dépôt, dessins, révisions, production, livraison, installation, déficiences, paiement final — et un CRM de vente ferme la fiche exactement au moment où la vraie correspondance commence. Pendant ce temps, le vrai moteur de vente de l’atelier, les designers, architectes et entrepreneurs qui le prescrivent dans leurs projets, n’a aucun modèle dans un outil conçu pour courir après des acheteurs individuels.
Où le CRM générique ne tient pas :
« Conclu-gagné », c’est le premier mois sur six. Le dépôt lance le projet; le CRM croit qu’il est terminé. Chaque question qui suit — où en est le solde, qu’est-ce qui a été convenu à la troisième révision, quand a lieu l’installation — trouve sa réponse dans des archives de courriels plutôt que dans une fiche.
L’argent arrive par étapes que le CRM ne voit pas. Dépôt, paiement progressif à la production, solde à l’installation, parfois une retenue après les déficiences. Un seul montant et une seule date de conclusion ne peuvent pas le représenter, alors les comptes à recevoir sont suivis dans la tête du propriétaire, sur des projets que le CRM dit terminés.
Les prescripteurs ne sont pas des clients, alors ils ne sont personne. La designer qui vous a confié quatre cuisines vaut plus que n’importe quel propriétaire pris isolément, mais elle n’achète jamais rien elle-même — alors le CRM la classe comme contact sur les affaires des autres, et sa prochaine recommandation est laissée au hasard.
La correspondance n’a pas de colonne vertébrale. Des mois de révisions, de sélections et de discussions sur les changements s’accumulent dans des fils de courriels. Quand un client conteste une finition ou une dimension à l’installation, l’atelier reconstitue l’historique à partir des boîtes de réception — généralement pendant que l’équipe attend sur le chantier.
Le modèle de données qui convient vraiment :
Grand livre de projet. Le projet, du dépôt à la fermeture des déficiences : jalons de paiement avec montants, déclencheurs d’échéance et statut, pour que la réponse à « qu’est-ce qui est dû, sur quels projets » soit un rapport, pas une enquête.
Compte de prescripteur. Designers, architectes, entrepreneurs et constructeurs comme comptes de recommandation évalués — projets confiés, revenus générés, dernier contact — travaillés comme le territoire de vente qu’ils sont réellement.
Registre des décisions. Sélections, révisions et ententes de modification consignées sur le projet avec les dates et les confirmations, pour que la dispute du jour de l’installation se règle avec la fiche plutôt qu’en faveur de celui qui a le mieux gardé ses courriels.
Installation et liste de déficiences. Dates d’installation, déficiences à corriger avec leurs responsables, et l’approbation finale qui libère le dernier paiement — parce que les déficiences non réglées sont l’endroit où les derniers dix pour cent de chaque projet vont mourir.
Pipeline de soumissions avec vieillissement. Les soumissions en attente comme objets vivants avec un suivi, puisqu’une soumission d’armoires est souvent magasinée pendant des mois et que l’atelier qui fait un suivi à la sixième semaine obtient des contrats qu’il avait déjà rayés.
Notre verdict : Si le problème de l’atelier se trouve sur le plancher de production — listes de coupe, planification, matériaux — c’est un logiciel de fabrication, pas un CRM, et il faut l’acheter, pas le bâtir. Le manque du côté CRM se situe avant et après l’atelier : le grand livre de projet, les comptes de prescripteurs et le registre des décisions. Un CRM générique configuré à fond peut en contenir peut-être la moitié; les jalons de paiement et la trace des décisions sont la moitié qu’il ne peut pas contenir, et ils forment un développement compact qui s’installe à côté de ce qui fait tourner la production.
Pourquoi le dernier paiement d’un projet est-il si long à encaisser?
Parce qu’il dépend généralement de déficiences que personne ne suit. Le client retient le solde pour trois déficiences, celles-ci vivent dans un fil de textos, et les semaines passent. Une liste de déficiences avec responsables, et une approbation qui déclenche la facture finale, transforment cette dérive en un processus court et daté.
Comment un atelier devrait-il gérer les designers et les architectes qui lui recommandent des projets?
Comme des comptes avec des chiffres : projets confiés, revenus, temps écoulé depuis le dernier contact. Les ateliers qui croissent de façon régulière traitent leurs dix meilleurs prescripteurs comme une équipe de vente traite ses comptes clés — contacts réguliers, premier regard sur les nouvelles capacités, suivi impeccable — parce que cinq prescripteurs fiables suffisent à remplir le carnet de commandes.
Qu’est-ce qui doit aller dans le registre des décisions?
Tout ce que le client a choisi ou modifié : finitions, quincaillerie, dimensions, révisions d’aménagement, et l’incidence de chacun de ces choix sur le prix, avec la confirmation du client. C’est trente secondes de saisie par décision, contre des heures d’archéologie dans les courriels par dispute — et sur des travaux sur mesure qui durent des mois, la question n’est pas de savoir s’il y aura des disputes, mais quand.
Un seul système peut-il couvrir les soumissions, la production et le côté client?
En pratique, aucun bon système ne le fait à lui seul. Le logiciel de production est une discipline en soi et devrait le rester. L’architecture réaliste, c’est une couche commerciale — soumissions, grand livre, prescripteurs, décisions — qui remet un projet libéré à la production et reçoit les dates en retour. Les ateliers qui essaient de forcer un seul outil à tout faire se retrouvent avec un outil qui ne fait rien de bien.
Dernière révision le 27 août 2026