Acheminer un ticket d'assistance selon le pays de facturation semble devoir fonctionner, et pourtant, la plupart du temps, cela ne fonctionne pas. Le pays de facturation vous indique où un compte a été créé, pas où se trouve en ce moment la personne qui ouvre le ticket. Une entreprise dont les agents d'assistance étaient répartis sur trois équipes envoyait ainsi régulièrement des réponses qui arrivaient à deux heures du matin chez des clients qui se trouvaient en voyage, travaillaient à distance depuis un autre pays ou vivaient tout simplement ailleurs que ce qu'indiquait leur adresse de facturation.
L'entreprise est passée à un acheminement selon l'heure actuelle réelle du client. Chaque ticket entrant comporte l'adresse IP du visiteur, que /v1/ip résout en pays, région, ville et coordonnées, avec un champ de fuseau horaire dans la même réponse. C'est ce fuseau horaire, et non le pays de facturation enregistré, qui décidait de l'équipe à laquelle le ticket était attribué. Un ticket provenant d'une IP dont la région se trouvait en pleines heures de bureau allait à l'équipe en service et éveillée dans cette partie du monde. Un ticket arrivant bien en dehors des heures de bureau était mis en file d'attente pour la prochaine équipe dont on pouvait raisonnablement attendre qu'elle réponde à une heure normale.
Pour les tickets qui nécessitaient un rappel programmé plutôt qu'une réponse asynchrone, l'équipe allait plus loin en transmettant les coordonnées résolues à /v1/timezone, qui renvoie à la fois le nom de fuseau horaire IANA et le décalage UTC pour ce point, calculé pour le moment futur auquel le rappel était programmé. C'était important, car les décalages changent avec l'heure d'été à des dates différentes selon les pays, et un rappel prévu trois semaines plus tard devait utiliser le décalage réellement en vigueur à cette date, et non celui en vigueur aujourd'hui.
Résultat : moins de réponses envoyées à des heures manifestement inappropriées, et un système d'acheminement qui s'adaptait automatiquement lorsque les clients déménageaient, voyageaient ou vivaient simplement ailleurs que ce qu'indiquait leur fiche de compte. Cela a aussi fourni à l'équipe un indicateur réellement utile qu'elle n'avait pas auparavant : le nombre de tickets arrivant en dehors des heures de travail de toutes les équipes, ce qui est devenu un argument chiffré pour ajuster les plannings plutôt que l'intuition d'un agent fatigué.
Rien de tout cela ne dépendait d'une saisie du client. L'adresse IP faisait déjà partie de chaque requête envoyée par le widget d'assistance : tout le système fonctionnait donc sans champ de formulaire supplémentaire ni invite demandant de confirmer son fuseau horaire, une étape que les gens ont de toute façon tendance à ignorer ou à mal remplir lorsqu'ils voyagent.
Le volume de requêtes suivait exactement le volume de tickets et restait sans difficulté dans le quota gratuit quotidien inclus avec chaque clé My Geocode pour un service d'assistance de cette taille, l'option prépayée habituelle restant disponible si le volume de tickets venait à le dépasser. Une fois le système en place, l'équipe n'a jamais eu à se soucier du coût, ce qui est généralement le signe qu'un élément d'infrastructure fait discrètement son travail en arrière-plan.
Les références complètes des champs des deux endpoints se trouvent sur /docs/ipv4-lookup/ et /docs/timezone-lookup/, et le fonctionnement des limites de débit est décrit sur /docs/rate-limits/.