Gestion des shifts chauffeurs taxi

Un logiciel de planning répond à la question « qui est censé travailler jeudi ? ». C'est utile, mais ce n'est pas la question qui coûte son week-end à un gestionnaire de taxi. La question coûteuse, c'est « que s'est-il passé pendant le shift qui a été presté ? » — combien la voiture a roulé, ce qui a été gagné, comment cela a été payé, et ce que le chauffeur a dépensé.

Tomcabs traite le shift comme le conteneur de tout cela. Il a un chauffeur, un taxi, un début et une fin, un index kilométrique d'ouverture et de clôture, un ensemble de courses et un ensemble de frais. Tout ce que la société doit savoir d'une journée de travail y est rattaché.

C'est pourquoi le shift est la bonne unité. Une course seule ne dit pas si la voiture était en service. Une journée seule ne dit pas quel chauffeur en était responsable. Le shift relie les deux.

Le chauffeur ouvre Tomcabs sur son téléphone, sélectionne le taxi qu'il prend, saisit l'index kilométrique et démarre le shift. C'est toute la cérémonie, et elle a lieu une fois.

Pendant le shift, il encode les courses au fur et à mesure : le montant et le moyen de paiement. S'il prend du carburant, paie un lavage ou un parking, il l'encode comme frais sur le shift. À la fin, il saisit l'index de clôture et ferme le shift.

La contrainte de conception est ici qu'un chauffeur n'utilisera pas un système qui lui coûte du temps au volant. Encoder une course, c'est quelques gestes ; si c'était un formulaire, ce ne serait pas fait — et un journal de shifts rempli seulement de temps en temps est pire que pas de journal du tout, parce qu'il a l'air complet.

Les shifts actifs, en direct : qui est dehors, dans quel véhicule, depuis quand, et ce qu'il a encodé jusqu'ici. Les shifts clôturés, avec leurs courses, les recettes par moyen de paiement, les frais et la distance parcourue.

Entre chauffeurs, la vision est comparative : combien de shifts chacun a prestés, ce qu'il a généré, et comment cela alimente sa balance hebdomadaire. Entre véhicules, les mêmes données répondent aux questions d'utilisation et révèlent les ruptures dans la séquence kilométrique.

Rien de tout cela n'oblige le gestionnaire à courir après qui que ce soit. La donnée arrive au rythme du travail, ce qui est tout l'intérêt de déplacer la saisie sur le téléphone du chauffeur.

Les chauffeurs oublient de clôturer leurs shifts. C'est le trou le plus fréquent dans tout système de suivi de shifts, et la manière dont un produit le traite détermine si la donnée reste fiable.

Tomcabs laisse le shift ouvert et visible plutôt que de deviner discrètement une heure de fin. La séquence kilométrique du véhicule montre une rupture à cet endroit : le gestionnaire voit un shift non résolu au lieu d'un shift crédible mais inventé.

Le gestionnaire peut corriger le shift depuis le tableau de bord. La propriété importante est que la correction est un acte délibéré d'une personne qui sait ce qui s'est passé, pas une inférence d'un logiciel qui l'ignore.