Asignar un ticket de soporte según el país de facturación parece que debería funcionar y, en general, no funciona. El país de facturación te dice dónde se creó una cuenta, no dónde está sentada ahora mismo la persona que abre el ticket, y una empresa con agentes de soporte repartidos en tres turnos no dejaba de enviar respuestas que llegaban a las dos de la madrugada a clientes que estaban de viaje, trabajaban en remoto desde otro país o simplemente vivían en un lugar que su dirección de facturación no reflejaba.
La empresa pasó a asignar los tickets según la hora actual real del cliente. Cada ticket entrante lleva la dirección IP del visitante, que /v1/ip resuelve en país, región, ciudad y coordenadas, junto con un campo de zona horaria en la misma respuesta. Esa zona horaria, y no el país de facturación registrado, decidía a qué turno iba el ticket. Un ticket que llegaba desde una IP que en ese momento estaba en horario laboral para su región iba al turno que estuviera activo y despierto en esa parte del mundo. Uno que llegaba muy fuera del horario laboral quedaba en cola para el siguiente turno que pudiera esperar razonablemente que su respuesta llegara a una hora normal.
Para los tickets que necesitaban una llamada programada en lugar de una respuesta asíncrona, el equipo dio el paso adicional de pasar las coordenadas resueltas a /v1/timezone, que devuelve tanto el nombre de zona horaria IANA como el desfase UTC de ese punto, calculado para el momento futuro en que se programaba la llamada. Eso importaba porque los desfases cambian con el horario de verano en fechas distintas según el país, y una llamada programada para dentro de tres semanas necesitaba el desfase que realmente estaría vigente en esa fecha, no el vigente hoy.
El resultado fue que se enviaron menos respuestas a horas claramente inoportunas y un sistema de asignación que se adaptaba automáticamente a medida que los clientes se mudaban, viajaban o simplemente vivían en un lugar que el registro de su cuenta no reflejaba. También le dio al equipo una métrica realmente útil que antes no tenía: cuántos tickets llegaban fuera del horario laboral de cualquier turno, lo que se convirtió en un argumento respaldado por datos para ajustar los horarios de los turnos, en lugar de una corazonada de un agente cansado.
Nada de esto dependía de que el cliente introdujera ningún dato. La dirección IP ya formaba parte de cada solicitud que hacía el widget de soporte, así que todo el sistema funcionaba sin un campo adicional en el formulario ni un aviso pidiendo a alguien que confirmara su zona horaria, algo que la gente suele saltarse o rellenar mal cuando está de viaje.
El volumen de solicitudes seguía uno a uno al volumen de tickets, holgadamente dentro de la cuota diaria gratuita que incluye cada clave de My Geocode para un servicio de asistencia de este tamaño, con la opción prepago habitual disponible si el volumen de tickets superaba esa cifra. El equipo nunca tuvo que pensar en el coste una vez en marcha, lo que suele ser la señal de que una pieza de infraestructura hace su trabajo en silencio, en segundo plano.
Las referencias completas de los campos de ambos endpoints están en /docs/ipv4-lookup/ y /docs/timezone-lookup/, y el comportamiento de los límites de frecuencia se explica en /docs/rate-limits/.