Le CRM signale une tâche en retard. Faut-il relancer le prospect ? Pas forcément.
Une échéance CRM mesure un décalage par rapport à une date prévue. Elle ne dit pas si le prospect attend votre devis, si un collègue a déjà répondu, si le dossier est bloqué en interne ou si la relance reste prioritaire. Transformer automatiquement ce signal en email peut donc créer une relance inutile, contradictoire ou maladroite.
La bonne règle est plus simple : aucun brouillon tant que le contexte récent ne permet pas d’identifier qui doit agir.
Le problème : le CRM connaît la date, pas toujours la situation
Dans beaucoup de pipelines, une tâche est créée après un appel : « relancer vendredi ». Entre-temps, plusieurs événements peuvent modifier le prochain pas :
- le prospect envoie une réponse par email ;
- un collègue reprend la conversation ;
- le rendez-vous est déplacé ;
- une pièce jointe manque ;
- votre équipe promet un devis corrigé ;
- l’opportunité perd sa priorité.
Le CRM peut conserver l’ancienne échéance alors que la réalité a changé. La tâche reste utile comme alerte. Elle devient dangereuse seulement si elle déclenche directement un message.
Cette distinction rejoint un principe général de supervision humaine : le système peut préparer et recommander, mais l’organisation doit définir quand une personne contrôle le résultat et peut l’arrêter [1].
Les cinq contrôles avant toute relance
Un workflow fiable peut vérifier cinq points dans un ordre fixe.
1. Le prochain pas explicite
Cherchez le dernier engagement clair : « je vous réponds mardi », « nous envoyons la version corrigée », « votre collègue reprend le dossier ».
La question n’est pas « la date est-elle dépassée ? », mais « qui devait faire quoi ensuite ? ».
Si l’engagement appartient à votre équipe, la bonne action est interne. Le système ne doit pas préparer de relance externe.
2. Le dernier message reçu
Un email récent peut rendre la tâche CRM obsolète. Le contrôle doit comparer l’échéance avec le dernier échange disponible et afficher sa date, son auteur et un extrait vérifiable.
Une réponse plus récente ne signifie pas toujours que le dossier avance, mais elle impose une nouvelle lecture avant tout message.
3. L’owner réel de l’action
Le propriétaire de l’opportunité n’est pas nécessairement la personne qui doit agir maintenant. Le prochain pas peut appartenir au prospect, au commercial, à un consultant ou à l’équipe administrative.
Le workflow doit distinguer owner du dossier et owner de l’action. En cas d’ambiguïté, il bloque le brouillon et demande une décision humaine.
4. Un blocage interne
Avant de solliciter le prospect, vérifiez si votre entreprise lui doit encore un document, une validation, un prix ou une réponse technique.
Ce contrôle évite le scénario le plus irritant : demander au prospect d’avancer alors que le retard vient de votre propre organisation.
5. La priorité business
Toutes les tâches en retard ne méritent pas la même urgence. Une opportunité inactive, non qualifiée ou sans budget confirmé peut nécessiter une mise à jour du pipeline plutôt qu’une relance.
La priorité doit reposer sur des critères visibles : étape, valeur, engagement récent, risque de perte et coût de l’inaction. Elle ne doit pas être inventée par le modèle.
Trois sorties, pas une seule
Après ces contrôles, le workflow produit l’un des trois résultats suivants :
- Relance pertinente : le prospect devait agir, aucun message récent ne change la situation et le destinataire est confirmé.
- Action interne : votre équipe doit d’abord envoyer, corriger ou décider quelque chose.
- Information insuffisante : les sources se contredisent ou ne permettent pas d’identifier le prochain acteur.
Seul le premier résultat autorise la préparation d’un brouillon. Même dans ce cas, l’envoi reste soumis à validation humaine. Le système affiche les éléments qui soutiennent sa recommandation : tâche CRM, dernier échange, engagement cité et donnée manquante.
Une fois la relance justifiée, il reste à choisir le bon délai et la bonne condition d’arrêt. Le modèle opérationnel est détaillé dans Relances email par scénarios : 4 branches pour agir sans harceler.
Ce fonctionnement suit une logique de gestion des risques adaptée aux systèmes génératifs : documenter le contexte, les limites, les contrôles humains et les incidents observés [2].
Exemple : une relance qui devait devenir une action interne
Cas fictif. Une PME prévoit de relancer un prospect vendredi. Mercredi, le prospect demande une modification du devis. Un consultant répond qu’une version corrigée sera envoyée jeudi, mais le CRM n’est pas mis à jour.
Vendredi, la tâche apparaît en retard. Un automatisme simple prépare : « Avez-vous pu avancer sur notre proposition ? »
Les cinq contrôles donnent un autre résultat :
- prochain pas : envoyer le devis corrigé ;
- dernier message : demande de modification du prospect ;
- owner de l’action : équipe interne ;
- blocage : document non envoyé ;
- priorité : forte, mais interne.
La bonne action est une alerte au responsable du devis, pas un email au prospect.
Tester sur un petit lot avant d’automatiser
Prenez vingt tâches CRM déjà échues. Pour chacune, reconstituez manuellement les cinq contrôles, puis comparez l’action réellement justifiée avec l’action suggérée par le workflow.
Mesurez trois erreurs :
- relance proposée alors que l’action était interne ;
- relance proposée malgré un message récent ;
- décision prise sans source suffisante.
Conservez les cas d’erreur et ajustez les règles d’arrêt. Pendant le pilote, aucun email ne part automatiquement.
Enfin, ce contrôle de contexte ne remplace pas les règles de prospection, l’information des personnes et la gestion de leur opposition. Ces obligations doivent rester explicites dans le processus commercial [3].
Si vos équipes ouvrent plusieurs outils avant chaque relance, le Diagnostic Pulse peut cartographier ce parcours et identifier où un assistant IA peut aider sans envoyer à la place du commercial.
Sources
[1] Règlement européen sur l’IA — Article 14, contrôle humain [2] NIST — Artificial Intelligence Risk Management Framework: Generative AI Profile [3] CNIL — Les fiches pratiques sur l’IA générative