Atlas Freight

Contexte

Chez Atlas Freight, le dispatch vivait dans des tableurs. Onze onglets, trois coordinateurs, un téléphone qui ne cessait de sonner. Affecter une seule cargaison exigeait de croiser à la main les heures des conducteurs, les quais disponibles et les créneaux de livraison.

Le vrai coût, c’était l’hésitation. Rien n’était centralisé, donc les coordinateurs vérifiaient tout deux fois, et chaque vérification repoussait le dispatch plus loin dans l’après-midi. Les camions attendaient. Les clients rappelaient. Le tableur gagnait un onglet de plus.

Le pari

La commande confortable, c’était un dashboard par service : les conducteurs ici, les quais là, les clients ailleurs. Nous avons refusé. Les services ne dispatchent pas les camions. Les dispatchers, oui.

Nous avons posé une règle et nous l’avons tenue à chaque revue : un écran par décision, pas un écran par service. Si un coordinateur doit changer de vue pour affecter une cargaison, le design a échoué.

Exécution

Nous avons d’abord construit le tableau de dispatch. Un écran sombre et dense : cargaisons non affectées classées par urgence à gauche, conducteurs viables notés à droite, conflits — heures, capacité, collisions de quai — signalés en ligne avant validation. Un clic engage l’affectation. Pas de fenêtre modale, pas de second écran.

L’app terrain applique la même logique sur la route. Le conducteur voit la prochaine étape et rien d’autre. Les confirmations remontent au tableau en temps réel : le plan à l’écran est le plan sur l’asphalte.

Résultats

Le délai de dispatch a chuté de 38%. La cohue du matin est devenue une session de travail : cargaisons affectées avant que le premier café refroidisse, exceptions traitées comme des exceptions et non comme la norme. Les tableurs ont disparu et personne ne les regrette.

Le chiffre compte moins que la forme de la journée qu’il a rendue. Ceci est un projet d’exemple, présenté en attendant la validation de nos premières études de cas publiques.