La messagerie retail échoue de façons précises et répétables : un rappel de retrait arrive après que le client a déjà récupéré sa commande ; une notification de livraison et un push promotionnel arrivent à une minute d'écart depuis deux systèmes différents ; un client répond STOP à un message marketing et continue à le recevoir parce que le désabonnement n'a été enregistré que dans l'outil de campagnes. Voici la couche opérationnelle : sept pratiques qui déterminent si la messagerie retail est utile ou nuisible.
1. Ancrer chaque message à un seul état actuel
Chaque message doit se référer à exactement une chose qui existe maintenant : une commande, une livraison, un retrait, un rendez-vous, un retour ou un dossier de service ouvert. Cet état vit dans un système de référence, et le message est une tentative contre lui — pas une étape d'une séquence qui tourne quoi qu'il arrive. Il faut relire l'état au moment de l'envoi : programmer un rappel pour 9h et l'envoyer sans vérifier si la commande a déjà été récupérée, c'est ainsi que naissent les messages obsolètes.
2. Séparer trafic promotionnel, de service, support et urgent
Ces classes diffèrent en base de consentement, urgence, tolérance au délai et échéance utile. Séparez-les par identité d'expéditeur, file, route, règle de consentement et expiration. Un envoi promotionnel ne doit jamais pouvoir retarder un message de retrait ou de fraude, et un client désabonné du marketing doit continuer à recevoir des messages de service sur une commande qu'il a passée.
3. Centraliser la preuve de consentement et la suppression
Le consentement a besoin d'une preuve reproductible : ce qui a été montré, quand, sur quel canal, pour quel périmètre. La suppression — désabonnements, plaintes, destinations invalides — doit se propager entre canaux, fournisseurs et outils dans une fenêtre courte et définie. Le retail a aussi besoin d'heures de silence calculées dans le fuseau local du client par classe de trafic, et d'une limite de pression de contact inter-canaux.
4. Définir explicitement l'éligibilité de canal et le fallback
Le choix du canal doit être une politique écrite par cas d'usage, évaluée au moment de l'envoi : préférence du client, consentement pour ce canal, adresse vérifiée, urgence, sensibilité du contenu et fiabilité des signaux du canal. Le SMS ordinaire doit être traité comme non chiffré et visible sur écran verrouillé. Le fallback doit être déclenché par une échéance métier et des signaux fiables — rejet explicite, destination invalide — pas par la simple absence d'accusé de réception.
5. Garder une identité et une destination cohérentes
La messagerie retail est une cible de phishing, donc la cohérence est un contrôle de sécurité autant que de marque : même expéditeur enregistré pour le même usage sur le même marché, domaines de lien propres plutôt que des raccourcisseurs génériques, et la page de destination doit dire la même chose que le message.
6. Dédupliquer entre systèmes et arrêter à la complétion
Les organisations retail envoient depuis plusieurs systèmes à la fois : commerce, CRM, logistique, magasin, support et paiement. La déduplication doit se faire au niveau de l'état, rattachée à la commande ou au dossier, avec un système faisant autorité par événement, et les parcours doivent s'arrêter immédiatement quand l'état change ou l'action se termine, y compris sur les réponses entrantes.
7. Mesurer les résultats et les dommages, pas les accusés de réception
Les données de livraison parlent des routes et des réseaux, pas de savoir si le message a fonctionné. Il faut mesurer le résultat applicatif (retrait effectué, retour planifié, rendez-vous confirmé), le délai de complétion, et les indicateurs de dommage souvent absents des rapports retail : messages obsolètes ou faux, contacts dupliqués sur le même état, plaintes, taux de désabonnement par classe de trafic et contacts support causés par la messagerie elle-même.
Table d'états pour un parcours de retrait en magasin
| État de la commande | Message | Classe | Échéance | Condition d'arrêt |
|---|---|---|---|---|
| Confirmée, paiement autorisé | Commande confirmée | Service | Aucune | Commande annulée |
| Prête en magasin | Prête à retirer, avec magasin et créneau | Service | Ouverture du créneau | Retirée, annulée ou créneau clos |
| Prête, non retirée, créneau proche | Rappel, une tentative | Service, urgent | Deux heures avant la fermeture | Retirée ou annulée |
| Créneau clos, non retirée | Avis de remise en stock avec options | Service | Aucune | Le client répond ou un remboursement est émis |
| Retirée | Aucun | — | — | Parcours terminé |
| Annulée ou remboursée à tout moment | Confirmation du résultat | Service | Aucune | Parcours terminé |
Tout ce qui est promotionnel reste hors de cette table, sur un expéditeur, une file et une règle de consentement distincts, soumis aux limites de pression de contact qui comptent aussi les messages de service ci-dessus.
Checklist d'implémentation
- Chaque message correspond à un état dans un système de référence nommé, relu au moment de l'envoi.
- Classes de trafic séparées par expéditeur, file, route et expiration ; les messages de service ne dépendent pas du désabonnement marketing.
- Preuve de consentement avec périmètre et date ; suppression propagée sur tous les canaux dans une fenêtre définie.
- Heures de silence en fuseau local par classe de trafic, plus une limite de pression de contact inter-canaux.
- Politique écrite d'éligibilité de canal et de fallback, avec échéances et signaux fiables.
- Un seul système faisant autorité par événement entre commerce, CRM, logistique, magasin, support et paiement.
- Reporting couvrant résultats, délai de complétion, messages obsolètes ou dupliqués, plaintes et désabonnements, segmenté par marché et route.
Les règles opérateur, les tarifs et la réglementation changent par marché et doivent être vérifiés auprès de sources primaires actuelles avec vos propres conseillers.