Un agente de soporte telefónico recibe el prefijo de la persona que llama antes incluso de que empiece la conversación, un contexto pequeño pero realmente útil. Un agente de chat en vivo, en cambio, suele empezar sin nada más que un nombre y lo primero que escriba el cliente, y una empresa de software con soporte por chat en vivo quería cerrar esa brecha mostrando automáticamente el mismo tipo de contexto básico de ubicación, sin pedirle nada extra al cliente.
La solución funcionaba íntegramente en el servidor, en el momento en que empezaba una sesión de chat. /v1/ip resolvía la dirección IP del visitante en país, región, ciudad y un campo de zona horaria, todo ello mostrado en un pequeño panel junto a la ventana del chat como referencia para el agente, y nunca mostrado al cliente, ya que era un contexto en beneficio del agente y no una función que el cliente necesitara ver ni con la que tuviera que interactuar.
El beneficio inmediato era sencillo: el agente podía ver la hora local del cliente antes de responder, algo útil para juzgar si tenía sentido decir "perdona la espera" o si el cliente, de hecho, había estado chateando a una hora totalmente razonable en su propia zona horaria. El agente también podía ver el país y la región del cliente sin tener que preguntar, un contexto útil para un equipo de soporte que atiende un producto con políticas, normas de envío o diferencias normativas propias de cada región que cambiaban qué consejo era realmente el correcto.
La empresa tuvo cuidado con aquello para lo que se usaba y no se usaba este contexto de ubicación. Orientaba cómo el agente enfocaba una respuesta y, a veces, qué artículo de la base de conocimiento era el más relevante, dadas las diferencias del producto según la región, pero nunca cambiaba automáticamente lo que el agente le decía al cliente sin que interviniera el criterio del propio agente, y nunca se presentaba al cliente como una afirmación sobre dónde estaba exactamente, evitando la incomodidad que, comprensiblemente, sienten algunos clientes cuando una empresa parece saber más sobre su ubicación de lo que ellos han compartido explícitamente.
Para los clientes conectados a una VPN o a una red corporativa, la ubicación mostrada a veces no coincidía con donde estaba realmente el cliente, y los agentes estaban formados para tratarla como una pista útil y no como un hecho confirmado, sobre todo en cualquier cosa en la que equivocarse importara, como suponer que se aplicaba una política regional concreta a un cliente cuya cuenta mostraba en realidad otra ubicación registrada más fiable. Cuando las dos no coincidían, los datos de ubicación de la propia cuenta siempre tenían prioridad sobre la pista basada en la IP.
Fue un pequeño añadido a una herramienta de soporte existente y no una nueva función del producto, incorporado por el propio equipo de ingeniería de la empresa al panel interno de agentes que ya ofrecía el software de soporte, y no requería nada por parte del cliente, ni aviso de permisos ni diálogo para compartir la ubicación, ya que funcionaba íntegramente a partir de la dirección IP que ya estaba presente en la conexión del chat.
El volumen coincidía directamente con el de sesiones de chat, una consulta por cada sesión nueva, una carga muy dentro de la cuota diaria gratuita para el tráfico del chat de soporte de la empresa. Un contexto pequeño como este rara vez se menciona por su nombre, pero cambia, de muchas pequeñas maneras, lo preparado que se siente un agente al responder el primer mensaje de una conversación.
La documentación del endpoint está en /docs/ipv4-lookup/ y /docs/ipv6-lookup/.