Gestion des statuts de demande : cycle de vie, règles de transition et alerte de stagnation
1. Six statuts : pourquoi pas huit ni dix
Beaucoup d’équipes ont une dizaine de statuts de demande dans leur CRM : à attribuer, à contacter, contacté, en discussion, devis envoyé, phase d’échantillon, échantillon en cours, en négociation, vendu, perdu, invalide, doublon, spam… Ça paraît précis, mais en réalité les commerciaux ne les mettent pas à jour : changer un statut demande trois clics, alors ils préfèrent ne pas cliquer. Résultat : toutes les demandes restent bloquées sur « en discussion » et vous ne savez pas où en est réellement le dossier.
| État | Définition | Condition d’entrée | Condition de sortie | Durée de séjour maximale |
|---|---|---|---|---|
| Nouvelles demandes | Tout juste reçue, non attribuée | Formulaire envoyé | Attribution à un commercial | 24 heures |
| Contacté | Première réponse envoyée, en attente du retour de l’acheteur | Le commercial envoie sa première réponse | L’acheteur a répondu | 48 heures |
| En discussion | Échanges sur le besoin et la solution | L’acheteur a répondu à la première réponse | Devis envoyé | 7 jours |
| Devis envoyé | Devis envoyé, en attente du retour de l’acheteur | E-mail de devis envoyé | L’acheteur accepte ou refuse | 7 jours |
| Ventes conclues | Commande confirmée, contrat signé | L’acheteur confirme la commande | Statut final, plus de transition | — |
| Fermer | Non conclu, suivi arrêté | Refus explicite / invalide / délai dépassé | Statut final, plus de transition | — |
Le principe de conception de ces six statuts : chaque statut correspond à une action précise, et le commercial clique seulement quand l’action a lieu. Première réponse envoyée, il clique sur « contacté » ; l’acheteur répond, il clique sur « en discussion » ; devis envoyé, il clique sur « devis envoyé » ; affaire conclue ou fermée, il clique sur le statut final. Pas besoin de subdivisions du type « phase d’échantillon » ou « échantillon en cours » : ça se note dans les commentaires, ça ne se gère pas dans les statuts. Moins il y a de statuts, plus les commerciaux les mettent à jour, et plus les données sont fiables.
Exemple concret : une demande de devis arrive, le système la place automatiquement dans « Nouvelle demande ». Le commercial envoie une première réponse en moins de 5 minutes et clique sur « Contacté ». Le lendemain, l’acheteur répond qu’il lui faut 500 unités livrées à Hambourg, le commercial clique sur « En discussion ». Le troisième jour, le commercial envoie un devis et clique sur « Devis envoyé ». Une semaine plus tard, l’acheteur confirme sa commande, le commercial clique sur « Conclu ». Sur tout le processus, il n’a cliqué que quatre fois sur un statut, chaque clic correspondant à une action réelle. C’est ça, la force des 6 statuts. Pour l’articulation entre le SLA de première réponse et le flux de statuts, voir SLA de première réponse aux demandes et taux de conversion.
2. Règles de transition : avancer seulement, pas de retour en arrière
Le flux de statuts obéit à une règle stricte : on avance, on ne recule pas. Impossible de repasser de « Contacté » à « Nouvelle demande », ni de « En discussion » à « Contacté ». Si l’acheteur dit « je vais réfléchir », ce n’est pas un recul, c’est une pause : la demande reste en « En discussion » ou en « Devis envoyé » en attendant la prochaine relance. Seuls deux cas autorisent un retour en arrière : une erreur d’attribution du commercial, ou une demande en doublon. Le retour doit être motivé, pas question de cliquer n’importe comment.
| Action de transition | Condition de déclenchement | Action du système | Confirmation manuelle requise |
|---|---|---|---|
| Nouvelle demande → Contacté | Le commercial envoie le premier e-mail de réponse | Horodatage enregistré automatiquement | Non, un clic du commercial suffit |
| Contacté → En discussion | L’acheteur a répondu à l’e-mail | Passage automatique dès réception de la réponse | Non, automatique |
| En discussion → Devis envoyé | Le commercial envoie le devis | Date du devis enregistrée automatiquement | Non, un clic du commercial |
| Devis envoyé → Conclu | L’acheteur confirme la commande | Déclenche le processus de contrat | Oui, validation du responsable requise |
| N’importe quel statut → Clôturé | Refus explicite / invalide / délai dépassé | Motif de clôture obligatoire | Oui, motif de clôture obligatoire |
| Retour en arrière | Erreur d’attribution / demande en doublon | Motif de retour obligatoire | Oui, validation du responsable |
La règle de transition a un objectif central : empêcher la « dérive de statut ». Un commercial qui suit une demande depuis trois semaines, faute de mouvement récent, la fait repasser de « Devis envoyé » à « En discussion » pour faire croire qu’elle avance normalement. Cette dérive vous laisse croire que la demande est vivante alors qu’elle est morte. C’est pourquoi tout retour doit être motivé et validé par un responsable : le commercial ne recule pas quand il en a envie.
Le motif de clôture est obligatoire et doit être classé. Il y a cinq catégories courantes : refus de l’acheteur (prix trop élevé / concurrent choisi / pas besoin pour l’instant), acheteur non qualifié (spam / concurrent / coordonnées erronées), absence de réponse dans les délais (plus de trois relances sans retour), demande en doublon (même acheteur ayant soumis plusieurs fois), autre. En classant les motifs de clôture, vous saurez à quelle étape vos demandes meurent : devis trop cher ou suivi insuffisant. Pour la conception de la séquence de relance, voir Séquence de relance des e-mails de demande.
3. Alerte de stagnation : un mécanisme à trois niveaux
En gestion des statuts, le vrai danger n’est pas le désordre : c’est un statut qui stagne sans que personne ne s’en occupe. Une demande reste deux semaines en « Contacté », le commercial a oublié de relancer et vous ne le savez même pas. C’est là que vous perdez vraiment des clients. L’alerte de stagnation consiste à définir une durée maximale de séjour pour chaque statut : au-delà, une alerte se déclenche automatiquement pour qu’aucune demande ne meure en silence.
| Niveau d’alerte | Condition de déclenchement | Destinataire | Action requise | Délai d’escalade |
|---|---|---|---|---|
| Voyant jaune | Dépassement de 50 % de la durée maximale | Le commercial en charge de la demande | Relancer dans les 24 heures | Passage au voyant orange après 48 heures sans relance |
| Escalade voyant orange | Dépassement de 100 % de la durée maximale | Commercial + responsable commercial | Le responsable intervient pour comprendre la situation | Passage au voyant rouge après 72 heures sans traitement |
| Intervention voyant rouge | Dépassement de 200 % de la durée maximale | Le responsable doit traiter | Le responsable relance lui-même ou clôture | Un résultat doit être obtenu cette semaine |
Un exemple concret : la durée maximale du statut « Contacté » est de 48 heures. Le voyant jaune se déclenche à 72 heures (48 × 1,5) et prévient le commercial : « Cette demande n’a pas bougé depuis 3 jours, relancez-la. » Le voyant orange se déclenche à 96 heures (48 × 2) et prévient aussi le responsable. Le voyant rouge se déclenche à 144 heures (48 × 3) : le responsable doit intervenir personnellement, soit en relançant lui-même, soit en clôturant directement. Ce mécanisme à trois niveaux empêche les demandes de mourir en silence.
La durée maximale varie selon le statut. « Nouvelle demande » : 24 heures, car elle n’est pas encore attribuée et une attribution trop lente fait échouer le SLA de première réponse. « Contacté » : 48 heures, car si l’acheteur ne répond pas en deux jours, c’est généralement qu’il n’est pas intéressé. « En discussion » : 7 jours, car si après une semaine d’échanges aucun devis n’est envoyé, c’est que le besoin n’est pas encore cadré. « Devis envoyé » : 7 jours, car sans retour une semaine après l’envoi, soit le prix est trop élevé, soit l’acheteur compare les offres. Chaque durée maximale correspond à un moment où « attendre davantage ne sert à rien ». Pour la méthode globale de scoring et de priorisation des leads, voir Scoring et priorisation des demandes entrantes.
IV. Les erreurs courantes de gestion des statuts
| Erreur | Ce qu’on fait | Ce que ça donne | Bonne pratique |
|---|---|---|---|
| Trop de statuts | Plus de 10 statuts détaillés | Les commerciaux ne mettent pas à jour, tout reste en « En discussion » | 6 statuts, chacun associé à une action |
| Aucune durée maximale définie | Peu importe combien de temps un statut stagne | Les demandes meurent en silence sans que personne ne le remarque | Définir une durée maximale et une alerte par statut |
| Clôturer sans indiquer le motif | On clique sur clôturer et c’est fini | Impossible de savoir à quelle étape la demande a échoué | Motif de clôture obligatoire, avec statistiques par catégorie |
| Revenir en arrière sur un statut sans justification | Le commercial recule le statut quand il veut | Dérive des statuts, données faussées | Tout retour en arrière exige un motif et la validation du responsable |
| Alertes envoyées uniquement par e-mail | L’alerte repose sur la notification par e-mail | Le commercial ne lit pas ses e-mails, l’alerte ne sert à rien | Notification dans le système + push DingTalk / WeCom |
Parmi ces cinq erreurs, la plus insidieuse est la dernière : alerter uniquement par e-mail. Un commercial reçoit des dizaines d’e-mails par jour et ceux de l’alerte de stagnation se noient dans la masse. La bonne approche consiste à pousser l’alerte sur la page d’accueil de son espace de travail : le tableau de bord CRM affiche directement « Vous avez 3 demandes en voyant jaune et 1 en voyant orange ». Il le voit dès qu’il ouvre le CRM, sans avoir à fouiller ses e-mails. Pour la conception d’un tableau de bord visuel, voir Tableau de suivi des citations par les moteurs IA la logique de tableau de bord.
Le but final de la gestion des statuts n’est pas de faire joli dans le CRM : c’est qu’en jetant un œil au tableau de bord chaque semaine, vous sachiez combien de demandes sont bloquées, à quel statut, depuis combien de temps, et lesquelles demandent l’intervention d’un responsable. Sans alerte de stagnation, la gestion des statuts n’est qu’une pile de chiffres que personne ne regarde. La connexion entre le site et le CRM est la condition d’un changement de statut automatique ; voir Des contacts du site au CRM.
FAQ — Questions fréquentes
Combien de statuts prévoir pour une demande ?
À partir de combien de temps une demande est-elle considérée comme bloquée ?
Le client dit « je vais réfléchir », quel statut appliquer ?
Faut-il obligatoirement indiquer un motif pour fermer une demande ?
Que faire si les commerciaux changent les statuts n’importe comment ?
Comment faire remonter les alertes de stagnation aux commerciaux ?
Pour conclure
La gestion des statuts de leads, ça ressemble à un problème de configuration CRM, mais c’est en réalité l’œil qui vous permet de voir votre pipeline de leads. Sans gestion des statuts, vous savez seulement combien de leads vous avez reçus ce mois-ci et combien ont été signés, mais pas combien se sont perdus à chaque étape. Avec la gestion des statuts, vous voyez d’un coup d’œil : ce mois-ci, 30 leads sont bloqués au statut « devis envoyé », dont 12 sont à l’arrêt depuis plus d’une semaine — ces 12 leads sont votre goulot d’étranglement.
Trois étapes pour passer à l’action : réduisez d’abord les statuts à 6, chacun associé à une action ; fixez ensuite une durée maximale de séjour pour chaque statut, avec trois niveaux d’alerte de stagnation ; exigez enfin un motif de clôture obligatoire et des statistiques par catégorie. Une fois ce dispositif en place, un coup d’œil hebdomadaire au tableau de bord vous dit qui convoquer et où renforcer l’effort.
Une phrase à retenir : le but de la gestion des statuts n’est pas de faire remplir des formulaires aux commerciaux, c’est de vous montrer d’un coup d’œil quels leads sont bloqués et depuis combien de temps — 6 statuts et trois niveaux d’alerte valent dix fois plus que 15 statuts et un tableau de bord que personne ne regarde.