Stockly Backoffice

Avant l'outil, le service après-vente se traitait de manière artisanale. Les informations d'une commande vivaient dans des pages Notion, des boîtes mail et des tableurs, sans endroit unique où les réunir. Un agent qui prenait un dossier devait reconstituer l'histoire avant de pouvoir agir.

Le problème n'était pas le confort des équipes, c'était le coût. Avec la croissance du volume de commandes, absorber la charge sans outil voulait dire recruter des agents au même rythme. C'est le calcul qui a lancé le projet.

J'étais seul au design, sans PM, en lien direct avec le CTO, les développeurs et les managers ops. Le projet s'est étalé sur plusieurs années : ce n'est pas une livraison, c'est un outil qui a grossi fonctionnalité après fonctionnalité.

Un backoffice ne se conçoit pas depuis l'extérieur. Les frictions réelles d'un agent ne se voient pas dans une réunion : elles se voient quand on fait le travail. J'ai donc croisé trois sources, dont aucune ne suffit seule.

• Faire le travail

  Des journées entières en agent ops, pour sentir ce qui coince : les allers-retours, les copier-coller, les décisions prises sans avoir l'information sous les yeux.

• Écouter les remontées

  Les tickets des ops et les cas atypiques rencontrés sur le terrain, qui disent où le process se casse plutôt que là où il fatigue.

• Vérifier en base

  L'analyse des données pour objectiver : quelles actions prennent réellement le plus de temps, lesquelles génèrent le plus de reprises.

Cette phase a aussi fixé une contrainte de conception. Les dossiers sont priorisés par complexité : les cas simples partent à des agents freelances, les cas complexes montent vers des profils plus seniors. Tout doit être traité sous 24 heures, avec de nouveaux dossiers qui tombent toutes les quatre à cinq heures. L'interface devait donc rendre visibles l'urgence et la charge, pas seulement les données.

« Le terrain dit ce qui énerve, la base dit ce qui coûte. Il faut les deux pour savoir quoi redessiner en premier. »

La première décision a été de faire tenir un dossier entier sur un seul écran, et de figer la place de chaque chose. Un agent qui ouvre un dossier ne cherche pas : il sait déjà où se trouve ce qu'il vient vérifier. Cette mise en page est le squelette de l'outil : tout ce qui s'y est ajouté depuis est venu s'y ranger.

Ce découpage répond à une contrainte précise, et pas à un goût pour la symétrie : un dossier ne se traite pas d'une traite. Il s'étale sur plusieurs jours, le temps d'attendre un délai légal, un document, une réponse du retailer. Entre-temps, l'agent a changé. L'état du dossier ne peut donc pas vivre dans la tête de celui qui l'a ouvert.

Concevoir pour la passation, pas pour une session

« L'interface doit être lisible par quelqu'un qui n'était pas là quand le dossier s'est ouvert. C'est la contrainte qui a le plus structuré l'outil. »

Faire tenir une messagerie hétérogène dans un seul fil

La colonne du milieu a été le morceau le plus difficile, à cause des échanges avec les retailers vendeurs. Les emails arrivaient dans une boîte où un LLM les triait pour les rattacher au bon dossier ; il fallait retranscrire tout ça dans l'écran, sans que le fil devienne illisible.

Ce dernier point n'était pas une fonctionnalité de confort. Sans retour, un tri automatique se dégrade en silence : l'agent corrige à la main, chaque jour, et personne ne le sait.

Reste à montrer comment on agit dans cette structure. Prenons une réclamation « article défectueux ». Son traitement est encadré par une réglementation qui change selon le pays et le transporteur : des délais légaux à respecter avant d'agir, des justificatifs différents selon le pays d'expédition et de livraison. Rempli comme un formulaire, ce process produit des erreurs. Découpé en étapes, il devient suivable.

Six écrans, et pas une seule personne du début à la fin : entre la demande de justificatifs et leur enregistrement, il se passe souvent plusieurs jours, et ce n'est presque jamais le même agent qui reprend. C'est exactement ce que la structure de l'écran doit encaisser.

L'outil est utilisé tous les jours par trente-cinq agents, qui traitent ensemble près de 2 000 dossiers par jour. L'enjeu de départ était un enjeu de coût : il est tenu, puisque le volume de commandes a pu monter sans que le nombre d'agents suive la même courbe.

Au lancement, tout passait par les ops internes : ouvrir un dossier demandait de connaître la maison. C'est l'outil qui a déplacé cette frontière. Les internes n'y ont pas perdu de travail, ils sont passés de 7 à 20 et gardent les dossiers que personne d'autre ne peut traiter, pendant qu'une partie du métier devenait transmissible à des gens qui n'ont jamais mis les pieds dans l'entreprise.

Ce que je referais autrement tient au démarrage. En arrivant sur un outil déjà chargé de concepts métier, je ne me suis pas donné le temps de me les approprier : à chaque amélioration d'un process existant, il fallait redécouvrir ce qui était là, et souvent refaire.

« Sur un outil métier, la phase d'appropriation n'est pas du temps perdu avant de concevoir. C'est la conception. »