Casos de uso

Adicionando contexto de localização a um chat de suporte ao cliente

Um agente de suporte por telefone recebe o código de área de quem liga antes mesmo de a conversa começar, uma informação de contexto pequena, mas realmente útil. Um agente de chat ao vivo, em comparação, muitas vezes começa sem nada além de um nome e do que o cliente digitar primeiro, e uma empresa de software que oferecia suporte por chat ao vivo quis eliminar essa diferença exibindo automaticamente o mesmo tipo de contexto básico de localização, sem pedir nada a mais ao cliente.

A solução rodava inteiramente no servidor, no momento em que uma sessão de chat começava. /v1/ip resolvia o endereço IP do visitante em país, estado, cidade e um campo de fuso horário, tudo exibido em um pequeno painel ao lado da janela de chat para referência do próprio agente, nunca mostrado ao cliente, já que era um contexto em benefício do agente, e não um recurso que o cliente precisasse ver ou com o qual precisasse interagir.

O benefício imediato era simples: o agente podia ver o horário local do cliente antes de responder, algo útil para avaliar se um “desculpe a demora” fazia sentido ou se o cliente, na verdade, estava conversando em um horário totalmente razoável para o seu próprio fuso horário. O agente também podia ver o país e o estado do cliente sem precisar perguntar, um contexto útil para uma equipe de suporte que atende um produto com políticas regionais, regras de envio ou diferenças regulatórias que mudavam qual orientação era realmente correta.

A empresa teve cuidado com aquilo para que esse contexto de localização era e não era usado. Ele orientava a forma como o agente formulava uma resposta e, às vezes, qual artigo da base de conhecimento era mais relevante, dadas as diferenças regionais do produto, mas nunca mudava automaticamente o que o agente dizia ao cliente sem o julgamento do próprio agente, e nunca era apresentado ao cliente como uma afirmação sobre exatamente onde ele estava, evitando o desconforto que alguns clientes compreensivelmente sentem quando uma empresa parece saber mais sobre a localização deles do que eles compartilharam explicitamente.

Para clientes em uma VPN ou em uma rede corporativa, a localização exibida às vezes não correspondia ao lugar onde o cliente realmente estava, e os agentes eram treinados para tratá-la como uma pista útil, e não como um fato confirmado, principalmente em qualquer situação em que errar fosse importante, como supor que uma política regional específica se aplicava a um cliente cuja conta mostrava uma localização cadastrada diferente e mais confiável. Quando as duas divergiam, os dados de localização da própria conta sempre prevaleciam sobre a pista baseada no IP.

Foi um pequeno acréscimo a uma ferramenta de suporte existente, e não um novo recurso de produto, adicionado pela própria equipe de engenharia da empresa ao painel interno de agentes que o software de suporte já oferecia, e não exigia nada do lado do cliente, nenhum pedido de permissão, nenhuma caixa de diálogo de compartilhamento de localização, já que funcionava inteiramente a partir do endereço IP já presente na conexão do chat.

O volume acompanhava diretamente o volume de sessões de chat, uma consulta por nova sessão, uma carga de trabalho bem dentro da cota diária gratuita para o tráfego do chat de suporte da empresa. Um contexto pequeno como este raramente é notado pelo nome, mas muda, de muitas pequenas formas, o quanto um agente se sente preparado para responder à primeiríssima mensagem de uma conversa.

A documentação do endpoint está em /docs/ipv4-lookup/ e /docs/ipv6-lookup/.