Affecter le technicien disponible le plus proche semble évident, jusqu'à ce qu'on regarde comment fonctionnent réellement la plupart des petits systèmes de répartition : souvent par simple disponibilité, la prochaine intervention revenant au technicien qui termine la sienne en premier, même s'il se trouve à l'autre bout de la zone d'intervention par rapport à la nouvelle intervention. Une entreprise de réparation d'électroménager gérant une flotte de techniciens a constaté que cela lui coûtait discrètement du temps de trajet sur l'ensemble de son activité, ses techniciens traversant la zone d'intervention pour rejoindre des interventions qu'un collègue proche aurait pu atteindre en une fraction du temps.
Pour y remédier, il fallait connaître, en coordonnées, la position actuelle de chaque technicien et l'emplacement de chaque nouvelle intervention, au lieu de traiter les deux comme des descriptions textuelles qu'un répartiteur devait interpréter de mémoire en fonction de sa connaissance du secteur. Les adresses des nouvelles interventions étaient géocodées via /v1/forward dès leur arrivée, chaque demande d'intervention étant convertie en coordonnée au moment de sa planification. Les positions des techniciens, suivies par leur propre application mobile au fil de leurs déplacements entre les interventions, arrivaient directement sous forme de coordonnées issues de la localisation de l'appareil et n'avaient donc pas besoin d'être géocodées. En revanche, la recherche inverse, /v1/reverse, fournissait aux répartiteurs une description lisible, au niveau de la rue, de la position actuelle d'un technicien, utile à un répartiteur qui jetait un coup d'œil à son écran et devait comprendre rapidement où se trouvait un technicien sans déchiffrer des coordonnées brutes.
Avec les deux côtés exprimés en coordonnées, le système de répartition pouvait calculer la distance réelle entre chaque technicien disponible et une nouvelle intervention, et affecter selon une combinaison de distance et de disponibilité plutôt que selon la seule disponibilité. La pondération faisait qu'un technicien un peu moins immédiatement disponible mais beaucoup plus proche ressortait souvent comme un meilleur choix qu'un technicien libre tout de suite mais éloigné, un compromis que l'entreprise a ajusté pendant quelques semaines en observant les résultats réels des affectations.
L'effet mesurable a été une réduction du temps de trajet moyen par intervention sur l'ensemble de la flotte, qui s'est directement traduite par davantage d'interventions réalisées par technicien et par jour, puisque moins de temps passé à rouler entre les interventions laissait plus de temps pour les interventions elles-mêmes. Le coût du carburant par intervention a également baissé, un avantage supplémentaire plus modeste mais réel, que l'entreprise ne cherchait pas spécialement à obtenir au lancement du projet.
L'entreprise a gardé un répartiteur dans la boucle plutôt que d'automatiser entièrement les affectations, car la distance est un facteur important mais pas le seul : la certification d'un technicien pour une marque d'appareil précise, ou la préférence d'un client pour un technicien qu'il avait déjà vu, l'emportait parfois sur une affectation optimale du seul point de vue de la distance. L'outil présentait la suggestion classée par distance comme une valeur par défaut forte que le répartiteur pouvait modifier, plutôt que comme une affectation automatique sans aucun contrôle humain.
Le volume évoluait avec le nombre d'interventions, un appel de géocodage par nouvelle intervention plus un plus petit nombre de recherches inverses pour afficher la position des techniciens aux répartiteurs, confortablement dans le quota quotidien gratuit pour une entreprise gérant une flotte de cette taille, avec une marge disponible grâce au crédit prépayé si l'entreprise s'étendait à de nouvelles zones d'intervention.
La documentation des deux endpoints se trouve sur /docs/forward-geocoding/ et /docs/reverse-geocoding/.