Manage my order

Avant le portail, le consommateur n'avait aucune autonomie : il écrivait sur la plateforme du retailer, et une trentaine d'agents, freelances et salariés, traitaient tout le SAV à la main. Chacun gérait de l'ordre de 100 à 200 messages par jour. Ils avaient d'autres tâches, mais répondre aux messages était le plus gros de la charge.

Deux choses ont déclenché le projet : le volume, qui explosait avec la croissance, et des retailers partenaires qui demandaient plus de visibilité sur les commandes. La direction a alors décidé d'investir dans un portail consommateur. J'ai mené le design seul, de la recherche à la livraison, avec une cheffe de projet, 2 à 3 développeurs back et 1 développeur front.

Le point de départ n'a pas été une maquette, mais la boîte de réception des ops. Chaque type de message a été passé au même crible.

1. 01

   Mesurer le volume

   Repérer les demandes qui pèsent le plus dans les messages entrants.

2. 02

   Chercher la réponse par l'interface

   Pour chaque demande, se demander comment un écran peut la résoudre à la place d'un échange humain.

3. 03

   Prioriser par faisabilité

   Ce qui est simple à afficher, à concevoir et à développer part en premier.

4. 04

   Garder le reste en feuille de route

   Ce qui n'est pas encore automatisable reste manuel, puis entre dans le portail brique après brique.

Cette grille a donné l'ordre de livraison. D'abord les actions directes, celles où un clic suffit : voir où en est sa commande, l'annuler. Ensuite les actions qui ouvrent un process, comme une réclamation, avec des pièces à fournir et un suivi étape par étape.

La première version affichait un simple tag de statut. La timeline l'a remplacé : elle reprend des codes que tout le monde connaît, annonce une étape de plus quand un prestataire intermédiaire intervient, et donne une date estimée à chaque étape. Moins de doute, donc moins de « où est mon colis ? ».

Encore fallait-il que le client retrouve sa commande, alors que les identifiants changent d'un système à l'autre. La recherche se fait donc avec ce qu'il a sous la main, le code postal de livraison et la date de commande. Une vérification légère, les 3 premières lettres de son nom, évite de lui faire créer un compte.

Un exemple : la contestation de livraison

Un colis marqué livré mais jamais reçu : ce parcours demande des documents au client. L'intégrer au portail supposait un envoi de fichiers côté consommateur, une vérification des documents dans le back-office et de nouveaux process pour les ops. Trop lourd pour une première version.

Il est donc resté manuel au début, mais cadré : le portail envoyait un message pré-rempli, toujours au même format. Les ops recevaient une demande lisible au premier coup d'œil, et le développement ne coûtait presque rien puisque l'envoi de message existait déjà. Le parcours complet est arrivé ensuite, une fois les premières briques en place.

C'est après la mise en ligne de la première version que j'ai le plus appris. Aucune donnée n'existait avant le portail. J'ai donc mappé tous les parcours dans Contentsquare, avec un événement GA4 à chaque étape. On a enfin vu comment les gens se comportaient, et surtout comment ils comprenaient nos mots.

Un bouton, deux lectures

Sur la réclamation « Article différent de celui acheté », les données montraient un décrochage : des utilisateurs arrivaient au formulaire, revenaient en arrière, recommençaient. Certains finissaient par écrire aux ops. Les sessions enregistrées ont donné la cause. Le bouton principal s'appelait « Annuler », en rouge. Pour nous, il annulait la commande. Pour eux, dans une fenêtre, il voulait dire « sortir ».

J'ai corrigé le libellé et la couleur moi-même, avec Cursor, en suivant le circuit des développeurs : une pull request, l'intégration continue, puis la production. C'était réglé dans la matinée. Deux à trois jours plus tard, le décrochage avait disparu, le parcours était redevenu linéaire et les messages sur ce sujet avaient baissé. Vers la fin du projet, livrer ainsi de petites corrections et de petites fonctionnalités était devenu une habitude.

Le widget « Messages » reste une porte de sortie. Mais chaque message envoyé depuis le portail est lu comme le signal d'un parcours self-service à améliorer.

L'annulation est l'exemple le plus net. Avant le portail, environ 30 % des annulations passaient par un agent, le reste étant automatisé par les connecteurs des retailers. Un an après, le portail en traite 20 à 25 %, et il n'en reste qu'environ 5 % pour les ops.

Pour l'entreprise, la croissance du volume a été absorbée sans recrutement supplémentaire. Pour les équipes, le travail a changé de nature : les tâches simples sont devenues marginales, et les agents sont montés en compétence sur des réclamations et des dossiers plus complexes. Ils en parlaient comme d'un travail plus intéressant.

Si c'était à refaire : poser le plan de tracking dès le premier jour. C'est lui qui a rendu les itérations rapides, et il est arrivé trop tard.