Outil interne
Customer Services Portal
Repenser la création de commande dans un environnement B2B télécoms.
- Thales
- Product Designer
- 18 mois
Un outil de gestion de commandes conçu avec les équipes support, adopté sans que personne n'y soit obligé.
- Le produit : quatre outils remplacés par un, la quasi-totalité des commandes basculée en 6 mois, Prix Or du programme d'excellence opérationnelle du groupe.
- La recherche : 26 head CS interrogées, deux ateliers en présentiel, un insight que personne n'avait vu en huit ans.
- Mon rôle : Product Designer, en binôme avec une UX Researcher, dans une équipe de dix. 18 mois.
Nimbus · design system fictif
L'IA pré-remplit, la CS valide
Le pattern qui distingue le produit : chaque champ rempli par le système s'affiche en rouge, et rien n'est validé sans relecture. Reconstructions neutres : le contexte, les clients et le système de design sont inventés. Aucune interface ni règle métier réelle n'y figure.
La lecture du document renseigne une partie des champs seulement, et signale lesquels. Ce qu'elle a proposé reste à vérifier, ce qu'elle n'a pas trouvé reste à saisir : la personne sait toujours d'où vient chaque valeur.
Le projet
Créer une commande de cartes SIM impliquait quatre outils : un tableur pour le suivi, un traitement de texte pour les documents, une messagerie pour le client, un ERP pour le système. Aucun n'était connecté. Ressaisie manuelle à chaque étape, aucune vue consolidée.
L'effet en cascade se voyait ailleurs : les commerciaux appelaient les CS pour obtenir un statut ou corriger une erreur. Les CS passaient une partie de leur journée à répondre à des questions dont la réponse existait déjà, quelque part.
Le sujet était identifié depuis huit ans. Ce qui manquait n'était pas la volonté, mais une compréhension du travail réel assez fine pour ne pas livrer un outil de plus.
Mon rôle
Product Designer, en binôme avec une UX Researcher, dans une équipe de dix (PM, PO, PLM, 5 développeurs).
Elle a piloté le protocole de recherche et l'analyse. J'ai co-animé les entretiens et les ateliers, traduit les insights en partis pris de conception, produit l'ensemble des écrans et du handoff, et travaillé au quotidien avec la tech.
La recherche
26 head Customer Services à l'échelle mondiale. Deux ateliers en présentiel : reconstituer la façon dont une commande se crée réellement, puis leur faire décrire l'outil qu'elles voudraient.
La difficulté n'était pas de les faire parler, mais de les amener à formuler ce qu'elles faisaient sans y penser. L'habitude rend un geste évident au point de le rendre indescriptible. C'est ce que le dispositif de recherche est allé chercher.
Trois demandes sont revenues systématiquement : remplir les commandes automatiquement, ne plus avoir à écrire aux clients à chaque étape, garder une vue d'ensemble sur les commandes en cours. Une quatrième n'était attendue par personne : les CS voulaient un canal pour se transmettre des dossiers entre elles, sans passer par l'e-mail. Un besoin qui n'apparaissait dans aucune procédure, parce qu'il n'en relevait pas.
Elles ne demandaient pas des fonctionnalités, elles décrivaient des irritants sous forme de solutions. Mon travail a consisté à remonter de la demande au problème, puis à concevoir la réponse, y compris quand elle ne ressemblait pas à la demande.
26
head Customer Services interrogées à l'échelle mondiale, et deux ateliers en présentiel
le sujet était identifié depuis huit ans
La décision clé
L'IA propose, la CS décide.
La demande était un remplissage automatique. Le problème réel : la ressaisie de bons de commande reçus en PDF ou en papier, lente et source d'erreurs qui remontaient jusqu'aux commerciaux.
En 2024, intégrer un modèle de lecture de documents dans un outil interne était coûteux et contesté. Nous l'avons défendu comme réponse au premier poste de perte de temps identifié en recherche, pas comme un gadget.
Le parti pris a été de refuser l'automatisation opaque. L'IA pré-remplit, et chaque champ qu'elle a rempli s'affiche en rouge : le système signale explicitement ce qu'il a supposé. La CS conserve la validation de bout en bout. Sur un bon de commande télécom, une erreur non détectée coûte plus cher que le temps gagné.
Le coût de ce parti pris : la CS relit tout. Le gain : elle n'a plus rien à retaper, et l'IA vérifie en plus la complétude du bon de commande client, un usage que personne n'avait demandé.
Démonstration reconstruite sur « Nimbus », un design system fictif, pour illustrer le pattern sans divulguer les interfaces Thales.
Deux autres décisions
Trois versions pour un seul parcours.
Créer une commande n'est pas un formulaire : c'est un arbre de cas dont chaque branche existe parce qu'un client réel l'a exigée un jour. Les deux premières versions ont échoué en test, les utilisatrices ne retrouvaient pas leur cas, ou perdaient le fil. Nous cherchions le problème dans l'interface ; il était en amont. Nous avions modélisé le processus depuis le seul point de vue des CS, sans les contraintes portées par les autres parties prenantes. La troisième version est partie d'un atelier réunissant CS et stakeholders. C'est celle qui a tenu.
Rendre l'information consultable plutôt que demandée.
Le portail est connecté à l'ERP et aux systèmes de la chaîne de production : le statut d'une commande physique devient consultable en autonomie, et chaque jalon franchi déclenche une notification au client. Les CS ne relaient plus une information que le système connaît déjà.
Le canal interne repéré en recherche a été livré en bêta après le cœur du produit, un arbitrage assumé : il ne conditionnait pas la bascule.
Nimbus · design system fictif
Le système propose, la personne garde la main
Trois patterns, un même principe. Reconstructions neutres : le contexte, les clients et le système de design sont inventés. Aucune interface ni règle métier réelle n'y figure.
Le point de départ n'est pas un formulaire vide mais une commande déjà passée, en cours ou archivée, dont on reprend tout ou partie des lignes.
La plupart des commandes reprennent une commande passée. Le parcours part de l'historique plutôt que d'un formulaire vide, y compris pour les commandes clôturées d'il y a plusieurs années.
Résultats
L'adoption
5 % → 95 %
des commandes basculées vers le portail en 6 mois, sans obligation d'usage : l'ancien système est resté disponible
et l'ancien système est resté ouvert tout du long
4 → 1
outils remplacés par un point d'entrée unique
~50 %
de la charge quotidienne des CS désormais traitée dans le portail
La reconnaissance
Prix Or
programme d'excellence opérationnelle du groupe, parmi plusieurs dizaines de candidatures internes
2
lignes produit étudient l'adoption de la solution pour leurs propres équipes
elles étudient l'adoption, elles n'ont pas basculé
Ce que j'en retiens
Concevoir une interface métier pour un domaine qu'on ne connaît pas ne s'improvise pas. Nous n'y sommes pas arrivés en nous mettant à la place des Customer Services, mais en construisant un dispositif pour aller chercher ce qu'elles savaient : des entretiens, des ateliers, plusieurs cycles de co-conception avant que le parcours de commande tienne. Le designer n'est pas celui qui devine le besoin, c'est l'outil qui permet aux utilisateurs de le formuler et de le rendre concret.