E-mails sur les commandes : quels messages sont vraiment utiles aux clients

Les demandes d'assistance après une commande sont presque toutes la même question : « est-ce que ça a fonctionné ? ». Elles naissent d'un vide entre deux moments — quand le client paie et quand il reçoit — que les communications automatiques existent pour combler. Si le vide persiste, le client écrit, téléphone, ou commande à nouveau en pensant que la première tentative a échoué.

Le problème ne se résout pas en envoyant plus de messages. Il se résout en en envoyant peu, chacun lié à un fait réellement survenu, contenant l'information que le client recherchait. Ce guide sert à décider lesquels envoyer et à vérifier qu'ils arrivent.

Un message part d'un fait, pas d'une intention

La règle qui évite la plupart des malentendus : chaque communication automatique correspond à un événement vérifié par un système, pas à une étape prévue par la procédure.

• « Commande expédiée » ne part pas quand l'entrepôt imprime l'étiquette, mais quand le transporteur a pris le colis en charge. Ce sont deux moments qui peuvent être espacés de plusieurs jours.
• « Paiement reçu » ne part pas quand le client clique sur payer, mais quand le système de paiement confirme. Entre les deux se trouvent les paiements en attente et ceux refusés.
• Si un événement n'est vérifiable par aucun système, il ne mérite pas de message automatique : il mérite qu'une personne écrive quand c'est nécessaire.

Le second critère est la source unique : pour chaque état, un seul système fait foi. Si l'état de la livraison est connu à la fois par le système de gestion et par la plateforme de vente, tôt ou tard ils diront deux choses différentes au même client le même jour.

Réception, paiement et expédition sont trois choses différentes

Ce sont les trois moments les plus souvent confondus, et la confusion produit le pire cas : le client reçoit la confirmation de commande, le paiement échoue, personne ne le lui dit et la marchandise ne part pas. Lui attend, vous attendez.

1. Réception : nous avons votre demande, voici ce que vous avez commandé. Cela ne signifie pas que la commande est confirmée.
2. Confirmation : le paiement est arrivé (ou la commande est acceptée, en cas de paiement à la livraison) et la marchandise est réservée. C'est le message que le client conserve.
3. Expédition : la marchandise est partie, voici comment la suivre et ce que contient le colis s'il est divisé.

Quand les trois moments coïncident vraiment — paiement immédiat, marchandise en stock, expédition le jour même — on peut fusionner réception et confirmation. En revanche, on ne les fusionne jamais s'il existe ne serait-ce qu'une seule méthode de paiement pouvant rester en suspens.

La carte événement, message, destinataire

On écrit une ligne par événement, avant de configurer quoi que ce soit. Les objets sont illustratifs : ils servent à montrer que le contenu se trouve aussi dans l'objet, pas seulement dans le texte.

La dernière ligne rappelle une chose que l'on oublie : certains messages ne sont pas pour le client. Une commande que personne dans l'entreprise ne voit est le moyen le plus simple de ne jamais l'expédier.

Retards et demandes d'assistance

Les messages faciles sont ceux qui annoncent que tout va bien. La valeur se voit sur les autres, et la règle est la même : dire ce qui s'est passé, ce qui se passe maintenant, ce que le client doit faire.

• Un retard communiqué avant la date promise est une information. Communiqué après, c'est une excuse. Si le système connaît la date prévue, le message peut être déclenché quand la date approche et que la marchandise n'est pas partie.
• Ne promettez pas une nouvelle date que vous ne pouvez pas vérifier. Mieux vaut dire que vous vérifiez et indiquer quand vous recontacterez.
• Chaque message automatique doit permettre de répondre à une personne : une adresse que quelqu'un lit vraiment, pas une boîte qui refuse les réponses. Les réponses aux communications automatiques sont souvent les demandes d'assistance les plus urgentes.
• La personne qui répond doit voir la commande. Si le service client ne sait pas quel message le client a reçu et quand, la conversation repart de zéro.

Délivrabilité, doublons et données affichées

Trois contrôles à faire une fois, puis à répéter à chaque modification.

• Délivrabilité : les messages de service partent d'un domaine authentifié, avec un expéditeur reconnaissable, et doivent être testés sur au moins trois services de messagerie différents, en vérifiant aussi les courriers indésirables. Un message que le système marque comme envoyé n'est pas un message arrivé.
• Doublons : si la plateforme de vente, le système de gestion et le service de livraison envoient chacun leur propre avis, le client reçoit trois fois la même information avec trois numéros de commande différents. On choisit qui parle et on désactive les autres.
• Données affichées : le message ne doit contenir que ce qui permet de reconnaître la commande, pas tout ce que le système connaît. Jamais les données complètes de paiement ; avec prudence les pièces jointes, qui n'arrivent souvent pas.

Quand un message de moins vaut mieux

Chaque communication en plus diminue l'attention portée à toutes les autres. Si le client reçoit six messages en deux jours, il arrête de les lire, et celui qui compte — la livraison échouée — passe inaperçu.

• Un message qui n'apporte pas d'information nouvelle ne sert à rien : « nous préparons votre commande » dit ce que le client imagine déjà.
• Si un événement ne change rien pour le client, on se contente de l'enregistrer.
• Si vous ne pouvez pas garantir qu'un message soit toujours vrai, mieux vaut ne pas l'envoyer : un avis d'expédition qui part avant l'expédition génère plus de demandes d'assistance que le silence.

Ce que ce guide ne couvre pas

Ce guide traite des communications de service : celles liées à une commande passée par le client. Les communications promotionnelles — newsletters, offres, relance des paniers abandonnés — suivent des règles différentes, exigent des consentements recueillis de façon vérifiable et ne doivent pas être mélangées avec les messages transactionnels. Restent également en dehors la gestion des paiements échoués et remboursés et les règles de livraison, qui sont des processus à part.