Un agente que conoce las particularidades normativas locales y los patrones de siniestros habituales de una región atiende una llamada de esa región más rápido y mejor que un agente igual de capacitado que nunca ha gestionado un siniestro de allí, y una aseguradora con un centro de llamadas nacional se dio cuenta de que su sistema de "enrutar al siguiente agente disponible" lo ignoraba por completo y trataba a todos los agentes como intercambiables sin importar en qué región estuviera quien llamaba.
Para las llamadas que llegaban a través del formulario de contacto web de la empresa y de su sistema de solicitud de devolución de llamada, en lugar de una línea telefónica tradicional, la dirección IP de quien llamaba ya formaba parte de cada solicitud. /v1/ip resolvía esa dirección en región y ciudad, que el sistema de enrutamiento usaba para emparejar a quien llamaba con agentes a los que se había asignado una especialización en esa región concreta, en lugar de enrutar solo según quién quedara libre primero.
Esto no eliminó por completo la disponibilidad como factor, ya que un agente perfectamente adecuado que no estará disponible hasta dentro de veinte minutos suele ser peor resultado que un agente disponible con conocimientos generales, así que la lógica de enrutamiento ponderaba ambos factores juntos: una buena coincidencia regional con una espera corta ganaba a una falta de coincidencia sin espera solo hasta cierto punto, ajustado a partir de los datos reales de tiempos de espera que la empresa recopiló una vez que el nuevo sistema estuvo en marcha.
La empresa también usó los mismos datos regionales para enrutar ciertas llamadas a agentes que dominaban una variante local pertinente del idioma, no solo una categoría lingüística amplia, ya que un grupo general de "agentes hispanohablantes" atendía peor a quienes llamaban que uno que tuviera en cuenta las diferencias regionales de terminología que surgen específicamente en conversaciones sobre seguros y siniestros, un detalle que influyó en las puntuaciones de satisfacción más de lo que la empresa esperaba al principio.
Nada de esto requirió renovar el sistema telefónico. La resolución de la ubicación se hacía en el momento en que la solicitud de contacto llegaba por primera vez a los servidores de la empresa, antes de pasarla a la lógica de enrutamiento de llamadas propiamente dicha, que solo necesitaba un campo de región para tomar su decisión: un pequeño punto de integración en lugar de reconstruir el sistema de enrutamiento en su conjunto.
La empresa trató la región detectada como una señal fuerte y no como un hecho absoluto, consciente de que alguien que llamara desde una VPN corporativa o de viaje podía resolverse en una región distinta de aquella en la que tenía contratada su póliza. En los casos en que la región de la póliza y la región detectada no coincidían, el sistema recurría a emparejar según el registro de la póliza de quien llamaba, y consideraba la detección basada en IP útil sobre todo para el caso más habitual, en el que los asegurados también se encuentran físicamente en la región que cubre su póliza y llaman desde una conexión doméstica o móvil normal.
El volumen seguía al de los envíos del formulario de contacto, una carga de trabajo holgadamente dentro de la cuota diaria gratuita para una empresa de este tamaño, ya que la consulta se ejecutaba una vez por solicitud de contacto y no de forma continua durante una llamada. El cambio no requirió más personal ni nueva formación de agentes, más allá de formalizar qué agentes ya destacaban en qué regiones, un inventario que la empresa tenía de manera informal pero que nunca había usado sistemáticamente para el enrutamiento.
La documentación del endpoint está en /docs/ipv4-lookup/ y /docs/ipv6-lookup/.