A
Deux publics, un seul système
Les clients sur leur téléphone. Les équipes sur ordinateur, toute la journée. Mêmes données, missions différentes.
Étude de cas · Plateforme
Chronopost Mauritius — Track N Pay
Où est-il, et a-t-il été payé ? Un seul écran pour les deux.
- Client
- Chronopost Mauritius
- Secteur
- Logistique · livraison de colis
- Notre rôle
- Design produit, UX/UI, prototypage, accompagnement design pendant le développement
- Développement
- Future Buzz, notre partenaire de développement
Panneau d’administration et connexion mobile · scène illustrative, écrans réels
Logistique · livraison de colis
01 — Contexte
Chronopost Mauritius livre des colis pour les entreprises et les particuliers. Track N Pay permet au client de suivre un colis et de régler ce qu’il doit dessus, depuis son téléphone.
Derrière, un panneau d’administration permet aux équipes de Chronopost de voir chaque envoi, chaque paiement et chaque utilisateur au même endroit. Nous avons conçu les deux côtés, en collaboration avec notre partenaire de développement Future Buzz, qui les a réalisés.
02 — Le problème
Un colis soumis à des frais pose deux questions avant de pouvoir partir : où est-il, et a-t-il été payé ? Les équipes avaient besoin des deux réponses sur un seul écran. Les clients devaient pouvoir payer sans passer au guichet.
03 — Contraintes
Ce avec quoi nous avons dû composer.
B
Le paiement se fait ailleurs
Les clients valident dans leur application MCB Juice. L’interface doit attendre un tiers, et le montrer.
C
Des données transmises en aval
Les données d’envoi doivent alimenter d’autres systèmes. Tout ce qui bloque pendant la transmission doit apparaître, pas rester caché.
D
Une marque internationale
L’identité et le ton de Chronopost sont fixés par le groupe. Nous avons travaillé dans ce cadre.
04 — Ce que nous avons conçu
Quatre décisions, et pourquoi.
Décision 01
Ouvrir sur ce qui bloque.
Le tableau de bord s’ouvre sur quatre compteurs : total des envois, transmission de données en attente, paiement en attente, paiement effectué. La première question d’un opérateur, c’est ce qui demande une action : les exceptions sont donc placées à côté des totaux, codées par couleur et filtrables par période.
Décision 02
Rendre l’attente visible.
Le paiement se finalise dans une autre application. L’écran affiche le montant, invite le client à ouvrir sa notification MCB Juice, lance un compte à rebours et propose une annulation explicite — pour que personne ne paie deux fois ni ne reparte dans le doute.
Décision 03
Des rôles et des journaux, pas d’identifiants partagés.
Les utilisateurs et leurs journaux d’activité figurent dans la navigation principale, pas dans un coin des paramètres. Chaque personne a un rôle ; chaque modification a un nom et une heure. Quand un paiement est contesté, la réponse est à un clic.
Décision 04
Le côté client tient dans la main.
Se connecter, trouver le colis, payer. Trois étapes sur un écran de téléphone, avec les mêmes libellés de statut que ceux des équipes côté administration — pour qu’un client et un opérateur au téléphone lisent la même chose.
05 — Rôles
Qui a fait quoi.
365CREAStratégie produit, recherche UX, design d’interface, prototypage, accompagnement design pendant le développement
Partenaire de développementFuture Buzz — développement et mise en œuvre du panneau d’administration et du site mobile client
ChronopostResponsabilité produit, apports opérationnels, recette
Étude de cas suivante
