Demandez à quiconque fait du SAV sur marketplaces à quelle question il répond le plus, et vous obtiendrez partout la même réponse : où est ma commande ? Elle se décline en cent formulations. « Des nouvelles ? » « C’est indiqué expédié, mais rien. » « Le suivi n’a pas bougé depuis quatre jours. » « C’est marqué livré et je n’ai rien reçu. »

C’est aussi la question à laquelle on répond le plus souvent mal, parce que la réponse tentante consiste à rassurer (« il est en route, vous devriez l’avoir bientôt ») alors que la bonne réponse est un fait qu’il faut aller chercher.

Ce que veut vraiment le client

Sous les formulations, le client veut quatre choses :

Où se trouve le colis maintenant, avec les mots du transporteur, pas les vôtres.
Quand il a bougé pour la dernière fois, pour juger par lui-même si « en route » est vrai.
Quand l’attendre, si quelqu’un le sait.
Un moyen de vérifier sans vous redemander : le numéro de suivi et un lien.

Une réponse qui contient ces quatre éléments est terminée. Une réponse qui n’en contient aucun et dit « ne vous inquiétez pas » n’est pas une réponse. C’est un délai de plus, avec de bonnes manières.

Chaque fait a une source, et ce n’est jamais vous

C’est l’étape que les équipes de SAV sous pression sautent. Chacun de ces quatre faits ne se trouve qu’à un seul endroit :

Fait	Source de vérité	Ce qui n’est pas une source
État actuel	Le transporteur, via votre plateforme d’expédition (Sendcloud, Packlink…) ou l’API du transporteur	L’indicateur « expédié » de la marketplace, votre mémoire, le dernier e-mail
Dernier événement	L’historique de suivi du transporteur	« D’habitude, ça prend 3 jours »
Date prévue	L’estimation du transporteur, quand il en donne une	Votre promesse
Numéro de suivi et lien	L’enregistrement de l’expédition	Le recopier depuis une étiquette

La marketplace sait que la commande a été expédiée, parce que vous le lui avez dit en imprimant l’étiquette. Elle ne sait pas que le colis dort dans un centre de tri depuis mardi. Seul le transporteur le sait. Si votre réponse est construite à partir de l’état affiché par la marketplace, elle dira « expédié » à un client dont le colis a été renvoyé à l’expéditeur.

La règle que nous suivons est donc simple : dans une réponse, un état de livraison, une date ou un numéro de suivi vient de la source de suivi, ou n’y figure pas. Si l’outil ne peut pas joindre la source, la réponse honnête est « nous vérifions auprès du transporteur », pas une supposition déguisée en fait.

Les quatre états, et quoi dire dans chacun

Les statuts des transporteurs forment un vrai bestiaire (Sendcloud à lui seul en normalise des dizaines), mais pour le client ils se ramènent à quatre situations.

Pas encore pris en charge. L’étiquette existe, le transporteur ne l’a pas scannée. Dites-le simplement : la commande est préparée et le transporteur ne l’a pas encore enlevée. Ne dites pas « expédiée ». Si plus d’un jour ouvré s’est écoulé, c’est votre problème, pas celui du transporteur : vérifiez l’enlèvement.

En transit. Donnez le dernier événement et sa date, la date prévue s’il y en a une, et le lien de suivi. C’est la réponse qui s’écrit toute seule une fois les faits en main.

Livré. Donnez la date et l’heure de livraison. Si le client dit qu’il n’a pas le colis, c’est le seul cas où la réponse a besoin d’une étape suivante plutôt que d’un fait : demandez-lui de vérifier auprès des voisins, de l’accueil de l’immeuble ou du point relais indiqué dans le suivi, et dites-lui que si le colis ne réapparaît pas, vous ouvrirez une réclamation auprès du transporteur. Ne promettez ni remboursement ni remplacement dans le même message. Cette décision dépend de la réclamation, et une promesse faite maintenant devient un litige plus tard.

Incident. Tentative de livraison échouée, adresse erronée, colis refusé, colis retourné. Dites au client ce qui s’est passé selon le transporteur et ce que vous faites pour y remédier. C’est la situation où une réponse rapide et factuelle évite une rétrofacturation.

Pourquoi une IA ne doit pas écrire l’état

Les modèles de langage savent très bien donner la forme d’une réponse rassurante, et sont incapables de savoir où se trouve un colis. Si vous en laissez un rédiger des réponses « où est ma commande » à partir de la seule conversation, il produira des dates de livraison fluides, assurées et inventées. Les clients en feront des captures d’écran.

La bonne répartition des tâches est la plus ennuyeuse. Le code va chercher les faits à la source de suivi. La réponse est assemblée à partir de ces faits : un gabarit avec l’état, le dernier événement, la date, le numéro et le lien. Un modèle peut la reformuler sur un ton plus chaleureux ou la traduire dans la langue du client, à condition que les chiffres et l’état en sortent inchangés. Un modèle ne doit jamais être ce qui décide de l’état.

Dans Miross, c’est ainsi que fonctionne l’action « Où est ma commande ». Elle ne s’exécute que si une source de suivi est connectée. Elle lit les colis de la commande, lit le dernier événement transporteur de chacun, et rédige la réponse à partir de ces faits. S’il n’y a pas d’expédition pour la commande, elle le dit au lieu de rédiger un brouillon. L’agent lit le résultat et l’envoie. Rien de ce qui concerne un colis ne vient jamais d’une supposition.

Une liste de contrôle pour vos propres réponses

Que vous utilisiez ou non un outil pour cela, une réponse « où est ma commande » est complète quand elle contient :

l’état actuel chez le transporteur, en des termes que le client comprend ;
la date du dernier événement ;
la date de livraison prévue, si le transporteur en donne une ;
le numéro de suivi et un lien ;
pour « livré mais non reçu » : l’étape suivante, sans promesse ;
pour les incidents : ce qui s’est passé et ce que vous faites.

Et elle est honnête quand chacun de ces éléments vient du transporteur, et aucun de vous.