Encaminhar um chamado de suporte pelo país de cobrança parece que deveria funcionar e, na maioria das vezes, não funciona. O país de cobrança diz onde a conta foi criada, e não onde a pessoa que abriu o chamado está neste momento. Uma empresa com agentes de suporte distribuídos em três turnos continuava enviando respostas que chegavam às duas da manhã para clientes que estavam viajando, trabalhando remotamente de outro país ou simplesmente morando em um lugar que o endereço de cobrança não refletia.
A empresa passou a encaminhar pelo horário atual real do cliente. Cada chamado recebido traz o endereço IP do visitante, que /v1/ip resolve em país, região, cidade e coordenadas, junto com um campo de fuso horário na mesma resposta. Esse fuso horário, e não o país de cobrança cadastrado, decidia em qual turno o chamado caía. Um chamado vindo de um IP que estava dentro do horário comercial da sua região ia para o turno que estivesse ativo e acordado naquela parte do mundo. Um que chegasse bem fora do horário comercial entrava na fila do próximo turno que pudesse razoavelmente esperar que a resposta chegasse em um horário normal.
Para chamados que precisavam de um retorno de ligação agendado em vez de uma resposta assíncrona, a equipe deu o passo extra de enviar as coordenadas resolvidas para /v1/timezone, que retorna tanto o nome de fuso horário IANA quanto o deslocamento UTC daquele ponto, calculado para o momento futuro em que o retorno estava sendo agendado. Isso importava porque os deslocamentos mudam com o horário de verão em datas diferentes em países diferentes, e um retorno marcado para dali a três semanas precisava do deslocamento que realmente estaria em vigor naquela data, e não do que estava em vigor hoje.
O resultado foi menos respostas enviadas em horários obviamente ruins e um sistema de encaminhamento que se adaptava automaticamente à medida que os clientes se mudavam, viajavam ou simplesmente moravam em um lugar que o registro da conta não refletia. Isso também deu à equipe uma métrica realmente útil que ela não tinha antes: quantos chamados chegavam fora do horário de trabalho de qualquer turno, o que se transformou em um argumento baseado em dados para ajustar as escalas de turnos, e não em um palpite de um agente cansado.
Nada disso dependia de o cliente digitar alguma coisa. O endereço IP já fazia parte de cada requisição feita pelo widget de suporte, então o sistema inteiro funcionava sem um campo extra no formulário ou uma solicitação pedindo que alguém confirmasse o seu fuso horário, algo que as pessoas costumam pular ou preencher errado quando estão viajando, de qualquer forma.
O volume de requisições acompanhava na proporção de um para um o volume de chamados, com folga dentro da cota gratuita diária que vem com cada chave do My Geocode para uma central de atendimento desse porte, com a opção pré-paga habitual disponível caso o volume de chamados ultrapassasse esse limite. A equipe nunca precisou pensar em custo depois que o sistema entrou em funcionamento, o que geralmente é sinal de que uma peça de infraestrutura está fazendo o seu trabalho silenciosamente em segundo plano.
As referências completas dos campos dos dois endpoints estão em /docs/ipv4-lookup/ e /docs/timezone-lookup/, e o comportamento dos limites de taxa é explicado em /docs/rate-limits/.