CRM pour courtiers en douane et transitaires
La relation client d’un transitaire n’est pas une affaire; c’est un corridor : le même importateur qui expédie les mêmes marchandises mois après mois, et qui vous juge sur la dernière expédition qui a mal tourné. Un CRM de vente peut noter qu’un importateur a été gagné; il ne peut pas voir que ses trois dernières expéditions ont été dédouanées en retard, qu’une soumission pour un nouveau corridor attend une réponse depuis une semaine, ou que le volume du compte glisse depuis un trimestre. Les systèmes opérationnels connaissent les expéditions; rien ne surveille la relation.
Où le CRM générique ne tient pas :
Gagné une fois, invisible pour toujours. Un importateur est gagné une fois, puis expédie pendant des années. Le CRM conclut l’affaire et cesse de regarder, alors un compte qui transfère discrètement du volume à un concurrent ne montre rien tant que les totaux mensuels ne le montrent pas — des mois trop tard pour avoir la conversation.
Les soumissions ne sont pas des affaires. Un bureau de transit émet des dizaines de soumissions par semaine pour chaque compte, la plupart sur un tarif qui expire. Modéliser chacune comme une affaire de pipeline noie le bureau sous les étapes; ne pas les modéliser veut dire que personne ne connaît le taux d’obtention par corridor, ni quelles soumissions sont mortes à cause du prix plutôt que du silence.
Le CRM ne voit pas les expéditions. La santé du compte est écrite dans ses expéditions — volumes, exceptions, retenues, dédouanements en retard — et tout ça vit dans le système de gestion du transport (TMS) ou le logiciel de déclaration. Un CRM sans flux d’expéditions réduit la gestion de compte à penser à appeler.
Des documents de conformité au dossier, mais nulle part. Les procurations, les détails de cautionnement et les conditions de crédit ont des dates d’entrée en vigueur et d’expiration, et un document expiré arrête les expéditions. Classés comme pièces jointes sur un contact, ils n’avertissent personne au bureau avant que l’importateur l’apprenne à la frontière.
Le modèle de données qui convient vraiment :
Compte avec flux d’expéditions. L’importateur comme entité alimentée par le nombre d’expéditions et le taux d’exceptions tirés du système opérationnel, pour qu’un compte en baisse ou chargé d’exceptions ressorte sur une liste plutôt que dans un bilan de fin d’année.
Soumission avec expiration. Chaque soumission suivie par corridor avec la validité de son tarif et son résultat, pour que le suivi se fasse avant l’expiration et que le bureau apprenne quels corridors et quels comptes il obtient réellement.
Corridor. Origine, destination et mode de transport comme élément à part entière de ce que le compte expédie, parce que les relations de transit grandissent corridor par corridor et que personne ne peut vendre le prochain corridor sans voir ceux qui existent.
Document de conformité avec expiration. Procurations, cautionnements et ententes de crédit datés et suivis jusqu’à leur expiration pour chaque compte, signalés bien avant qu’ils arrêtent une expédition.
Fiche d’incident. Retenues, dommages, litiges de facturation et défaillances de service consignés sur le compte, pour que la personne qui fait le prochain appel de renouvellement sache exactement ce dont l’importateur se souvient.
Notre verdict : Gardez le TMS et le logiciel de déclaration; les déclarations en douane sont réglementées et ces systèmes sont bien implantés pour de bonnes raisons. Le vrai manque, c’est la couche commerciale qui lit leurs données — la santé des comptes à partir des expéditions, le suivi des soumissions avec leurs dates d’expiration, des documents de conformité qui avertissent avant d’expirer. Un CRM générique configuré à fond vous donne le registre des soumissions; il ne verra jamais vos expéditions. Cette connexion, c’est le développement, et il est modeste.
Pourquoi ne pas utiliser le module CRM que vend le fournisseur de notre TMS?
Examinez-le d’abord honnêtement — s’il suit les soumissions par rapport à leur expiration et montre les tendances des comptes, utilisez-le. La plupart sont une liste de contacts greffée à l’écran des expéditions. Le test : peut-il produire la liste des comptes dont le volume a baissé ce trimestre et dont la dernière soumission est restée sans réponse? S’il le peut, c’est réglé; généralement, il ne le peut pas.
Quelle est la liste la plus précieuse que ce système produit?
Les comptes en baisse. Volume qui diminue, exceptions qui augmentent, ou soumission sans réponse au-delà de sa validité — chacun est une conversation qui sauve un compte si elle a lieu tôt. Aucun système opérationnel ne produit cette liste, parce qu’aucun système opérationnel ne surveille la relation.
Comment suivre les soumissions sans se noyer dans les étapes de pipeline?
Comme des soumissions, pas comme des affaires : émise, relancée, obtenue, perdue ou expirée, rattachée à un corridor et à un compte. Deux dates et un résultat par soumission suffisent pour connaître les taux d’obtention et relancer avant l’expiration. C’est la métaphore du pipeline qu’il faut abandonner, pas le suivi.
Est-ce que ça recoupe un portail de suivi pour les importateurs?
Non — les deux regardent dans des directions opposées. Un portail de suivi dit à l’importateur où se trouve son expédition; ce système dit à votre bureau comment va le compte. Ils partagent les mêmes données d’expédition en dessous, ce qui est une raison de les bâtir sur les mêmes fondations, pas de les confondre.
Dernière révision le 27 août 2026