Construire le service de gestion des réclamations de Rakuten

01 — Contexte

Ce projet portait sur l'expérience côté marchands : les vendeurs de la marketplace Rakuten, pas les acheteurs finaux. Le projet a démarré comme une refonte de la gestion des commandes legacy. Mais les premières recherches ont rapidement révélé la vraie priorité : les réclamations. Alors que les commandes étaient gérées via intégrateurs et API, les réclamations imposaient encore un passage manuel par le Merchant Center, sans organisation ni suivi, quelle que soit la taille du marchand, de la petite boutique aux grands comptes comme Boulanger. Ce constat nous a conduits à reprioriser entièrement la roadmap autour des réclamations.

Mon rôle : Product Designer dédiée à l'expérience marchands, pilotage de la refonte end-to-end du parcours réclamations, de la recherche à la livraison.

02 — Recherche

En parallèle, les insights de l'équipe Buyers, l'analyse de données et les entretiens avec les marchands ont révélé plusieurs frictions : un délai moyen de résolution de 4,5 jours, un processus géré via un service tiers et un parcours fragmenté entre plusieurs canaux, sans moyen cohérent de trier ou suivre les réclamations. Les marchands rencontraient également des difficultés à contacter le Service Client dans les situations bloquantes. Nous avons ensuite cartographié les parcours réels avec l'équipe User Care afin d'identifier les lacunes les plus critiques. Ces enseignements ont directement orienté les opportunités priorisées pour améliorer l'expérience des marchands comme celle des acheteurs.

03 — Livraison

Nous avons animé des ateliers collaboratifs avec des parties prenantes cross-fonctionnelles pour aligner les problèmes et co-construire des solutions, en nous appuyant sur des benchmarks concurrentiels comme Mirakl et ManoMano pour orienter nos choix.

Nous avons repensé les parcours de réclamations de bout en bout, en introduisant des moments clés où le système, grâce à l'IA, peut analyser automatiquement les documents et images justificatifs pour suggérer des résolutions sans nécessiter d'escalade vers le User Care. Ces designs ont été testés avec des marchands lors de deux rounds de sessions d'utilisabilité. Un manque s'est clairement dégagé : les marchands ne comprenaient pas l'issue financière d'une réclamation résolue. Pour y répondre, j'ai conçu un bloc paiement dédié et affiné le statut Résolu pour indiquer explicitement si le paiement avait été conservé ou annulé, éliminant une source majeure de confusion post-résolution.

04 — Apprentissages

Ce projet a confirmé l'importance de remettre en question le brief initial avant de s'engager dans une direction. Ce qui avait démarré comme une refonte de la gestion des commandes s'est transformé en une refonte bien plus impactante des réclamations, uniquement parce que nous avons écouté les utilisateurs assez tôt pour changer de cap. J'ai aussi compris que pour un marchand, résoudre une réclamation ne suffit pas. Il faut comprendre l'issue financière d'un coup d'œil : ce qu'il a conservé, ce qui a été annulé. Sans cette transparence, même une réclamation bien gérée laisse une impression durable d'opacité.