Vos relances ont pris du retard. Faut-il rattraper, ou repartir des plus récentes ?
Quand une séquence de relances a pris du retard, il vaut mieux servir d'abord les relances et les prospects les plus récents, que vider le stock dans l'ordre. Mais changer l'ordre a un piège : la relance 3 peut partir avant la relance 2. Sur un moteur que nous exploitons, plus d'une relance en retard sur dix aurait été touchée.
De quoi parle-t-on quand une séquence prend du retard ?
Une séquence de relances, c'est une suite de messages programmée d'avance. Le jour où un prospect y entre, l'outil prévoit tout : le premier message aujourd'hui, une relance dans trois jours, une autre dans une semaine. Chaque message attend son heure dans une file, comme des lettres posées sur un bureau avec une date d'envoi.
Chaque jour, l'outil prend les lettres dont la date est passée et les envoie. Mais il a une limite. Une boîte d'envoi ne peut pas partir à mille destinataires par jour sans finir en courrier indésirable. On plafonne donc le nombre d'envois quotidiens.
Si on inscrit plus de monde que le plafond ne permet d'en servir, les lettres s'empilent. La file grossit. Et personne ne le voit, parce que l'outil envoie bien, tous les jours, son quota habituel.
Comment un simple mail de test a-t-il révélé près de 900 envois en retard ?
Nous voulions vérifier un réglage sur le moteur d'envoi que nous exploitons pour un client B2B. Le geste habituel : programmer un mail de test à l'instant, et regarder s'il arrive. Il n'est pas arrivé. Ni dans l'heure, ni dans l'après-midi.
Le moteur fonctionnait. Il envoyait. Mais il servait chaque campagne dans l'ordre de programmation, la plus ancienne date d'abord. Notre test, programmé à l'instant, était le dernier de la pile. Devant lui attendaient près de 900 envois dus, certains depuis des semaines.
Une heure de test perdue. Mais c'est ce blocage qui a montré le retard. Sans lui, la file aurait continué de grossir en silence.
Pourquoi servir d'abord les prospects les plus récents ?
Parce qu'un premier message envoyé avec trois semaines de retard ne vaut plus grand chose. Le prospect inscrit il y a trois semaines l'a été pour une raison : un signal, un événement, une ouverture. Cette raison s'est refroidie.
Le prospect inscrit hier, lui, est encore dans la fenêtre. Le faire attendre derrière le stock, c'est le refroidir à son tour. En vidant la file dans l'ordre, on transforme un retard en retard permanent.
Nous avons donc inversé l'ordre de service, compte par compte : les envois dus les plus frais d'abord. Le stock ancien passe quand il y a de la place.
Le lendemain, nous avons ajouté une seconde priorité. Les relances passent avant les premiers messages. Un prospect déjà contacté attend une suite, et la conversation est engagée. Un prospect nouveau peut attendre un jour de plus sans rien perdre.
Le temps commercial est trop rare pour le gaspiller sur des relances mal servies. Selon l'étude State of Sales de Salesforce, un commercial ne passe que 28 % de son temps à vendre. Une relance automatique bien servie lui rend du temps. Une relance mal servie lui en prend.
Quel piège cache l'inversion de l'ordre ?
Toutes les étapes d'une séquence sont programmées le jour de l'inscription. Tant qu'on sert dans l'ordre chronologique, la relance 2 passe toujours avant la relance 3, puisque sa date est plus ancienne. L'ordre des étapes était garanti, mais par accident.
Dès qu'on sert les plus frais d'abord, cet accident disparaît. Prenez un prospect dont la relance 2 est en retard depuis dix jours. Sa relance 3 est due d'hier. Elle est plus fraîche. Elle part en premier. Le prospect reçoit « je reviens vers vous une dernière fois » avant « je me permets de vous relancer ».
Nous l'avons vu en simulation, avant la mise en service. Sur les envois en retard, plus d'une centaine seraient partis dans le désordre. Aucun n'est parti, parce que la simulation a été faite d'abord.
Quelles règles poser avant de rattraper un retard ?
Deux règles, et une habitude.
La première règle : une étape ne part jamais tant qu'une étape précédente du même prospect attend encore. Cette garde ne change rien quand on sert dans l'ordre. On la pose donc pour tous les comptes, sans exception.
La deuxième règle : l'écart prévu entre deux étapes se respecte après l'envoi réel, pas d'après le calendrier d'origine. Si la relance 2 part avec dix jours de retard, la relance 3 attend ensuite son délai complet. Sinon, deux messages partent le même jour.
L'habitude : avant d'injecter un test, regarder l'ordre de service réel et le nombre d'envois dus devant. Et suivre chaque jour la taille de la file. Une file qui grossit est un retard qui commence.
| Avant | Depuis |
|---|---|
| La date la plus ancienne d'abord | Les relances d'abord, puis les envois les plus frais |
| Ordre des étapes garanti par accident | Aucune étape avant la précédente, garde écrite |
| Délai entre étapes compté sur le calendrier d'origine | Délai compté après l'envoi réel |
| Retard découvert par un test bloqué | Taille de la file suivie chaque jour |
| Changement d'ordre décidé sur le papier | Changement simulé avant la mise en service |
Pourquoi les relances ne partent pas quand on les laisse aux commerciaux, c'est l'article pourquoi vos commerciaux ne relancent pas. Comment voir le jour même qu'une chaîne s'est arrêtée, c'est cet autre article. Notre manière de livrer ces agents est décrite sur la page d'accueil, et un exemple de chaîne vérifiable dans le cas une publication au vert, une page absente.
Les questions qu'on nous pose
Faut-il envoyer tout le stock en retard ?
Pas forcément. Un premier message en retard de plusieurs semaines a perdu sa raison d'être. On peut le laisser passer quand la file le permet, ou retirer de la séquence les prospects dont le signal d'origine est trop ancien.
Pourquoi ne pas simplement augmenter le plafond d'envois ?
Parce que le plafond protège la réputation de votre boîte d'envoi. Le relever d'un coup pour rattraper un retard est le meilleur moyen de finir en courrier indésirable. Mieux vaut inscrire moins de monde que de dépasser ce que la boîte peut servir.
Comment voir qu'une file prend du retard ?
En suivant chaque jour le nombre d'envois dus et non partis. Si ce nombre monte plusieurs jours de suite, vous inscrivez plus que vous ne servez. C'est un indicateur simple, et l'outil d'envoi ne le montre presque jamais de lui-même.
Que vérifier avant de changer l'ordre d'une file ?
Ce que l'ancien ordre garantissait sans le dire. Ici, c'était l'ordre des étapes. On simule ensuite la nouvelle règle sur la file réelle, et on compte les envois qui changeraient de comportement avant de la mettre en service.