Um atendente que conhece as particularidades regulatórias locais e os padrões típicos de sinistros de uma região atende uma chamada dessa região com mais rapidez e qualidade do que um atendente igualmente qualificado que nunca tratou um sinistro de lá, e uma seguradora que opera um call center nacional percebeu que o seu sistema de "encaminhar para o próximo atendente disponível" ignorava isso por completo, tratando todos os atendentes como intercambiáveis, independentemente da região de quem ligava.
Para os contatos que chegavam pelo formulário de contato na web e pelo sistema de solicitação de retorno de ligação da empresa, e não por uma linha telefônica tradicional, o endereço IP de quem entrava em contato já fazia parte de cada requisição. O /v1/ip resolvia esse endereço em região e cidade, que o sistema de roteamento usava para associar a pessoa a atendentes designados como especialistas naquela região específica, em vez de encaminhar apenas para quem estivesse livre primeiro.
Isso não eliminou totalmente a disponibilidade como fator, já que um atendente perfeitamente adequado que ficará indisponível por mais vinte minutos costuma ser um resultado pior do que um atendente disponível com conhecimento geral; por isso, a lógica de roteamento pesava os dois juntos: uma boa correspondência regional com uma espera curta vencia uma correspondência ruim sem espera nenhuma apenas até certo ponto, ajustado com base nos dados reais de tempo de espera que a empresa coletou depois que o novo sistema entrou no ar.
A empresa também usou os mesmos dados regionais para encaminhar certas chamadas a atendentes fluentes em uma variante local relevante do idioma, e não apenas em uma categoria ampla de idioma, já que um grupo genérico de "atendentes que falam espanhol" atendia pior do que um que levasse em conta as diferenças regionais de terminologia que surgem especificamente em conversas sobre seguros e sinistros, um detalhe que pesou mais nos índices de satisfação dos clientes do que a empresa esperava inicialmente.
Nada disso exigiu uma reformulação do sistema telefônico. A resolução da localização acontecia no ponto em que a solicitação de contato chegava pela primeira vez aos servidores da empresa, antes mesmo de ser repassada à lógica de roteamento de chamadas, que só precisava de um campo de região para tomar a decisão, um pequeno ponto de integração em vez de uma reconstrução do sistema de roteamento como um todo.
A empresa tratava a região detectada como um sinal forte, e não como um fato absoluto, ciente de que alguém usando uma VPN corporativa ou em viagem poderia ser resolvido para uma região diferente daquela em que realmente tinha a apólice. Nos casos em que a região da apólice e a região detectada divergiam, o sistema passava a usar o cadastro da apólice da pessoa, tratando a detecção baseada em IP como útil principalmente para o caso mais comum, em que os segurados também estão fisicamente na região coberta pela apólice e ligam de uma conexão residencial ou móvel comum.
O volume acompanhava os envios do formulário de contato, uma carga de trabalho bem dentro da cota diária gratuita para uma empresa desse porte, já que a consulta era feita uma vez por solicitação de contato, e não continuamente durante uma chamada. A mudança não exigiu novas contratações nem novos treinamentos de atendentes, além de formalizar quais atendentes já tinham domínio de quais regiões, um levantamento que a empresa tinha de maneira informal, mas nunca havia usado de forma sistemática para o roteamento.
A documentação do endpoint está em /docs/ipv4-lookup/ e /docs/ipv6-lookup/.