Un conseiller qui connaît les particularités réglementaires locales et les types de sinistres fréquents d'une région traite un appel venant de cette région plus vite et mieux qu'un conseiller tout aussi compétent qui n'a jamais géré de sinistre là-bas. Une compagnie d'assurance exploitant un centre d'appels national s'est rendu compte que son système « vers le prochain conseiller disponible » ignorait totalement cet aspect et traitait tous les conseillers comme interchangeables, quelle que soit la région de l'appelant.
Pour les appels passant par le formulaire de contact en ligne et le système de demande de rappel de la compagnie, plutôt que par une ligne téléphonique classique, l'adresse IP de l'appelant faisait déjà partie de chaque requête. /v1/ip traduisait cette adresse en région et en ville, que le système de routage utilisait pour associer l'appelant à des conseillers spécialisés dans cette région précise, au lieu d'orienter l'appel uniquement vers le premier conseiller libre.
Cela n'a pas complètement supprimé la disponibilité comme critère, car un conseiller parfaitement adapté mais indisponible pendant encore vingt minutes est souvent un moins bon choix qu'un conseiller disponible aux connaissances générales. La logique de routage pondérait donc les deux ensemble : une bonne correspondance régionale avec une courte attente l'emportait sur une mauvaise correspondance sans attente, mais seulement jusqu'à un certain point, réglé à partir des données réelles de temps d'attente recueillies par la compagnie une fois le nouveau système en service.
La compagnie a également utilisé ces mêmes données régionales pour orienter certains appels vers des conseillers maîtrisant une variante locale pertinente d'une langue, et pas seulement une grande catégorie linguistique. En effet, un groupe général de « conseillers hispanophones » servait moins bien les appelants qu'un groupe tenant compte des différences régionales de vocabulaire qui apparaissent spécifiquement dans les conversations sur l'assurance et les sinistres, un détail qui a pesé plus lourd sur les scores de satisfaction des appelants que la compagnie ne l'avait prévu au départ.
Rien de tout cela n'a exigé de refonte du système téléphonique. La résolution de la localisation se faisait au moment où la demande de contact de l'appelant atteignait pour la première fois les serveurs de la compagnie, avant même d'être transmise à la logique de routage des appels, qui n'avait besoin que d'un champ région pour prendre sa décision : un petit point d'intégration plutôt qu'une reconstruction complète du système de routage.
La compagnie traitait la région détectée comme un signal fort plutôt que comme un fait absolu, sachant qu'un appelant sur un VPN d'entreprise ou en déplacement pouvait être associé à une autre région que celle où il avait souscrit son contrat. Lorsque la région du contrat et la région détectée ne concordaient pas, le système se rabattait sur le dossier du contrat de l'appelant, en considérant la détection basée sur l'IP comme utile surtout dans le cas le plus courant, celui des assurés qui se trouvent physiquement dans la région couverte par leur contrat et appellent depuis une connexion domestique ou mobile ordinaire.
Le volume suivait le nombre de formulaires de contact envoyés, une charge largement dans le quota quotidien gratuit pour une entreprise de cette taille, puisque la recherche s'exécutait une fois par demande de contact et non en continu pendant un appel. Le changement n'a nécessité ni embauche ni formation supplémentaire des conseillers, au-delà de la formalisation des régions dans lesquelles chaque conseiller était déjà fort, un inventaire que la compagnie connaissait de façon informelle mais n'avait jamais utilisé systématiquement pour le routage.
La documentation de l'endpoint se trouve sur /docs/ipv4-lookup/ et /docs/ipv6-lookup/.