Avant de construire le multi-tour, on a vérifié si le problème existait vraiment

Le signal qu'on entendait à l'oral

Certains clients nous le disaient au téléphone, ou dans les retours du service commande : "Maintenant je connais bien le service. Quand je prépare ma commande, je sais déjà que ça va me prendre plus d'un camion. Sauf que je dois remplir exactement la même demande de livraison deux ou trois fois, et ça me fait perdre du temps."

Le point de peine n'était pas subtil. Ressaisir la même adresse, le même type de livraison, la même date, plusieurs fois de suite, pour des commandes qui n'étaient au fond qu'une seule tournée — c'était du temps perdu, à chaque fois, pour un besoin déjà connu d'avance.

Le signal revenait. Mais un signal oral n'est pas une priorité.

Il peut venir d'un client bruyant, pas forcément représentatif. Il peut décrire un vrai problème, ou juste une gêne ponctuelle.

Avant de le mettre sur la roadmap, on a voulu savoir : est-ce que ce comportement existe réellement dans nos données, à quelle fréquence, et chez qui ?

Croiser le signal avec la donnée

On a regardé les commandes qui se ressemblaient de façon suspecte : même client, même adresse de pickup, même adresse de livraison, le même jour.

Concrètement, quelqu'un qui crée 2 ou 3 commandes quasi identiques dans la même journée n'a probablement pas 2 ou 3 besoins différents. Il a un seul besoin — plusieurs tournées pour le livrer — et notre formulaire ne lui laissait pas d'autre choix que de le découper en plusieurs commandes.

Résultat :

• environ 10% des commandes correspondaient à ce schéma,
• 15 clients concernés sur la période analysée.

10%, ce n'est pas anecdotique. Ce n'est pas non plus la majorité des commandes — ça n'aurait pas mérité de repenser tout le moteur de tarification pour ça. Mais c'était suffisant pour dire : le signal oral n'était pas isolé, il correspondait à un vrai comportement mesurable.

Ce qu'on a construit — et ce qu'on n'a pas construit

Le multi-tour ajouté au formulaire de commande : un toggle "plusieurs tours de livraison" qui permet de saisir jusqu'à 5 tournées en une seule fois. Adresses, type et date de livraison partagés. Seul le poids change d'une tournée à l'autre.

Ce qu'on aurait pu faire à la place, plus simple à coder : un bouton "dupliquer la commande". Mais en termes d'UX, ça ajoute du travail là où le besoin était déjà clair. Le client n'avait pas besoin de repartir d'une commande existante et de la modifier plusieurs fois — il avait besoin de faire plus d'un aller-retour, tout simplement parce que le matériel ne rentre pas dans un seul camion. Autant le lui permettre en une seule saisie.

Ce que j'en retiens

Un signal oral qui revient souvent mérite d'être écouté. Mais il ne mérite pas d'être construit tel quel.

Avant de prioriser, croiser avec la donnée réelle sert à deux choses : confirmer que le problème existe vraiment au-delà des voix les plus fortes, et cadrer sa taille pour savoir jusqu'où aller dans la solution.

Nos camions peuvent charger jusqu'à 1,3 tonne, mais ce n'est parfois pas suffisant — pas pour le poids, mais pour le volume. Certains chargements pèsent à peine quelques centaines de kilos, mais le camion est déjà à ras bord.

C'est là qu'on comprend qu'un bouton "dupliquer" n'aurait pas suffi. Le problème n'était pas de refaire une commande identique — c'était de reconnaître, dès la saisie, qu'un seul trajet ne suffirait pas.