Outil interne
Customer Services Portal
Quatre outils remplacés par un portail que les équipes ont adopté sans y être obligées.
- 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, 95 % des commandes passées par le portail en 6 mois, Prix Or du programme d'excellence opérationnelle du groupe.
- La recherche : 26 head Customer Services interrogées dans le monde, deux ateliers en présentiel, et un besoin 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.
Nimbus · design system fictif
L'IA pré-remplit, la CS valide
Chaque champ rempli par le système est signalé, et rien n'est validé sans relecture. Reconstruction sur « Nimbus », un design system fictif : aucune interface ni règle métier Thales.
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.
Quatre outils, aucun connecté
Créer une commande de cartes SIM mobilisait 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é. Chaque étape imposait une ressaisie, et personne n'avait de vue d'ensemble.
Les commerciaux appelaient donc les CS pour obtenir un statut ou corriger une erreur. Une partie de leur journée passait à chercher des réponses qui existaient déjà quelque part.
Le sujet était identifié depuis huit ans. Il manquait 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, cinq 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 le handoff, et travaillé au quotidien avec les développeurs.
26 entretiens, quatre demandes, dont une inattendue
26 head Customer Services interrogées dans le monde, puis deux ateliers en présentiel. Le premier reconstituait la création réelle d'une commande, le second leur faisait décrire l'outil qu'elles voudraient.
Le plus dur était de leur faire formuler des gestes devenus automatiques. Nous leur avons posé une question simple : « Si vous aviez une baguette magique, qu'ajouteriez-vous à l'outil de vos rêves ? » La réponse dominante : un outil qui fait à leur place les tâches lourdes, à commencer par la saisie manuelle des données.
Trois demandes revenaient systématiquement : remplir les commandes automatiquement, ne plus écrire aux clients à chaque étape, garder une vue d'ensemble des commandes en cours. Une quatrième n'était attendue par personne : un canal pour se transmettre des dossiers entre CS, sans passer par l'e-mail. Ce besoin n'apparaissait dans aucune procédure.
Elles décrivaient des irritants sous forme de solutions. Mon travail : remonter de chaque demande au problème, puis concevoir la réponse, même 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 sur 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é. Les stakeholders l'ont défendu comme réponse au premier poste de perte de temps identifié en recherche.
Avec les CS et ma collègue UX Researcher, nous avons refusé l'automatisation opaque. L'IA pré-remplit, et chaque champ qu'elle a rempli est signalé : le système montre ce qu'il a supposé. La CS garde 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 : la CS relit tout. Le gain : elle n'a plus rien à retaper, et l'IA vérifie aussi que le bon de commande client est complet, un usage que personne n'avait demandé.
Deux autres décisions
Trois versions pour un seul parcours.
Créer une commande, c'est parcourir 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.
Le problème était en amont de l'interface. Nous avions modélisé le processus du seul point de vue des CS, sans les contraintes des autres parties prenantes. La troisième version est partie d'un atelier réunissant CS et stakeholders. J'en ai fait le design, en vérifiant avec des techniciens et des spécialistes de l'IA ce qui était faisable, et ce que la base de données permettait d'exploiter. C'est celle qui a tenu.
Rendre l'information consultable.
Le portail est connecté à l'ERP et aux systèmes de production. Le statut d'une commande se consulte en autonomie, et chaque jalon franchi déclenche une notification au client. Les CS n'ont plus à relayer une information que le système connaît déjà.
Le canal entre CS repéré en recherche a été livré en bêta après le cœur du produit : 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 sur « Nimbus » : aucune interface ni règle métier Thales.
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 passées par le portail en 6 mois, sans obligation d'usage
l'ancien système est resté ouvert tout du long
4 → 1
outils remplacés par un point d'entrée unique
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
Les deux premières versions du parcours ont échoué pour la même raison : nous avions écouté les CS sans les personnes qui contraignent leur travail. Une commande traverse plusieurs équipes, et la concevoir depuis un seul poste ne règle qu'une partie du problème.
La leçon : faire entrer dès les premiers ateliers les personnes qui contraignent le processus, en plus de celles qui utilisent l'écran.