CRM pour cabinets de consultation en subventions et en crédits d’impôt
Un cabinet de consultation en subventions ou en crédits d’impôt ne gère pas un pipeline de ventes; il gère un portefeuille de demandes soumises à des échéances de dépôt. Chaque demande est un dossier de preuves qui doit être complet à une date fixe, et le client qui doit fournir ces preuves est le maillon le plus lent de la chaîne. Un CRM de vente ne modélise rien de tout ça : aucune échéance qui génère du travail, aucune liste de vérification qui mesure si le dossier est complet, et aucune mémoire du fait que ce même client déposera la même demande l’an prochain.
Où le CRM générique ne tient pas :
Gagné veut dire terminé. Dans un CRM de vente, la lettre de mission marque la conclusion. Dans un cabinet qui dépose des demandes, elle marque le début du seul travail qui compte — recueillir les preuves, rédiger, déposer et passer l’examen. Le CRM se tait exactement au moment où le risque commence.
Aucune dimension d’échéance. Une demande a une période de dépôt, et le cabinet en a des dizaines qui courent en même temps. Une date de conclusion est une prévision; une échéance de dépôt est un précipice. Un CRM qui les traite de la même façon ne peut pas classer le portefeuille selon la demande la plus proche du bord avec le plus de preuves encore manquantes.
Les tâches du client sont invisibles. La majeure partie de ce qui bloque une demande, c’est du travail que le client vous doit — registres de paie, descriptions de projets, une heure avec un ingénieur. Un CRM suit les tâches de votre équipe, pas celles du client, alors le vrai goulot d’étranglement de chaque dossier n’apparaît sur aucune liste.
Aucune récurrence annuelle. Le même client dépose une demande au même programme chaque année, et la demande de l’an dernier sert de modèle pour celle-ci. Une simple liste d’affaires l’oublie, alors chaque saison repart de zéro au lieu de partir de ce qui a déjà été recueilli, décidé et défendu.
Le modèle de données qui convient vraiment :
Demande. Une par client, par programme et par année, avec sa propre période de dépôt, sa liste de vérification des preuves et son statut. C’est l’unité que tout le cabinet gère réellement, et aucun objet d’affaire générique ne porte une échéance qui génère du travail.
Pièce justificative. Un document ou une information exigée, avec un type, un responsable — généralement le client —, un état et un historique de relances. L’état d’avancement du dossier devient un pourcentage par demande plutôt qu’une impression.
Tableau des échéances. Chaque période de dépôt du portefeuille dans une seule vue, classée selon les jours restants par rapport aux preuves manquantes. Ce classement est la liste de travail quotidienne, et on ne peut pas le tirer des dates de conclusion.
Définition du programme. La liste de vérification et les règles de chaque programme pour lequel vous déposez des demandes, définies une seule fois, pour qu’une nouvelle demande démarre déjà remplie au lieu d’être improvisée par la personne qui l’ouvre.
Historique des demandes. Les années précédentes liées à la demande en cours — ce qui a été déposé, ce qui a été remis en question à l’examen, ce qui a été accepté — pour que les modifications et les demandes répétées partent d’une fiche plutôt que d’une chasse aux dossiers.
Notre verdict : Un CRM générique convient à l’avant de cette entreprise — prospects entrants, suivi des recommandations, propositions. Gardez-le là, ou gardez un tableur là. Ce qu’il faut bâtir, c’est l’objet demande avec son échéance et sa liste de vérification des preuves, parce que c’est là qu’une période de dépôt ratée coûte son année à un client. C’est un développement ciblé autour d’un objet et d’un calendrier, pas une plateforme.
Pourquoi ne pas simplement utiliser un logiciel de gestion de projet pour les demandes?
Les outils de gestion de projet suivent vos tâches. Une demande est surtout bloquée par les tâches du client, et elle revient chaque année devant une date externe ferme. Vous pouvez plier un outil de projet dans ce sens, mais vous perdez les listes de vérification par programme, l’historique d’une année à l’autre et le classement des échéances sur tout le portefeuille, c’est-à-dire les parties qui évitent l’erreur coûteuse.
Quelle est la chose la plus utile à ajouter en premier?
Le tableau des échéances. Une seule vue de la période de dépôt de chaque demande, classée selon les preuves manquantes, change la façon dont le cabinet passe ses matinées, et il ne demande que l’objet demande en dessous. Tout le reste peut venir plus tard.
Comment amener les clients lents à fournir leurs preuves?
Avec de la structure et une escalade. Une demande précise pour un document nommé, avec un lien de téléversement, donne de meilleurs résultats qu’un paragraphe par courriel, et des rappels qui se resserrent à l’approche de l’échéance donnent de meilleurs résultats qu’un consultant qui pense à relancer. Le système fait les relances pour que le consultant fasse du conseil.
Est-ce que ça s’applique au-delà de la RS&DE et des programmes canadiens?
Oui. Tout cabinet qui monte des preuves en vue d’une date de dépôt — crédits provinciaux, subventions à l’innovation, financement à l’exportation, crédits pour le cinéma — fonctionne selon la même mécanique demande et échéance. Les listes de vérification des programmes diffèrent; le modèle, non.
Dernière révision le 27 août 2026