Un agent d'assistance téléphonique connaît l'indicatif régional de l'appelant avant même le début de la conversation, un élément de contexte modeste mais réellement utile. Un agent de chat en direct, en comparaison, ne dispose souvent que d'un nom et de ce que le client tape en premier, et un éditeur de logiciels proposant une assistance par chat en direct voulait combler cet écart en faisant apparaître automatiquement le même type de contexte de localisation de base, sans rien demander de plus au client.
La solution fonctionnait entièrement côté serveur, au moment où une session de chat démarrait. /v1/ip convertissait l'adresse IP du visiteur en pays, région, ville et champ de fuseau horaire, le tout affiché dans un petit panneau à côté de la fenêtre de chat à l'usage exclusif de l'agent, jamais montré au client, puisqu'il s'agissait d'un contexte destiné à l'agent et non d'une fonctionnalité que le client avait besoin de voir ou d'utiliser.
L'avantage immédiat était simple : un agent pouvait voir l'heure locale d'un client avant de répondre, ce qui l'aidait à juger si un « désolé pour l'attente » avait du sens, ou si le client écrivait en fait à une heure tout à fait raisonnable pour son propre fuseau horaire. Un agent pouvait aussi voir le pays et la région du client sans avoir à les demander, un contexte utile pour une équipe d'assistance gérant un produit soumis à des politiques, des règles d'expédition ou des différences réglementaires propres à chaque région, qui modifiaient le conseil réellement correct à donner.
L'entreprise a veillé à ce que ce contexte de localisation serve à certaines choses et pas à d'autres. Il orientait la manière dont un agent formulait sa réponse et, parfois, le choix de l'article de la base de connaissances le plus pertinent compte tenu des différences régionales du produit, mais il ne modifiait jamais automatiquement ce que l'agent disait au client sans que son propre jugement intervienne, et il n'était jamais présenté au client comme une affirmation sur l'endroit exact où il se trouvait, ce qui évitait le malaise que ressentent, à juste titre, certains clients lorsqu'une entreprise semble en savoir plus sur leur localisation que ce qu'ils ont explicitement partagé.
Pour les clients passant par un VPN ou un réseau d'entreprise, la localisation affichée ne correspondait parfois pas à l'endroit où ils se trouvaient réellement, et les agents étaient formés à la considérer comme un indice utile plutôt que comme un fait établi, en particulier lorsqu'une erreur avait des conséquences, par exemple supposer qu'une politique régionale donnée s'appliquait à un client dont le compte indiquait en réalité une autre localisation, plus fiable. En cas de désaccord entre les deux, les données de localisation du compte primaient toujours sur l'indice issu de l'IP.
Il s'agissait d'un petit ajout à un outil d'assistance existant plutôt que d'une nouvelle fonctionnalité produit, intégré par l'équipe technique de l'entreprise au tableau de bord interne des agents déjà fourni par le logiciel d'assistance, et il ne demandait rien du côté du client, ni invite d'autorisation, ni boîte de dialogue de partage de position, puisqu'il fonctionnait entièrement à partir de l'adresse IP déjà présente dans la connexion du chat.
Le volume suivait directement celui des sessions de chat, une recherche par nouvelle session, une charge largement dans le quota quotidien gratuit pour le trafic du chat d'assistance de l'entreprise. Un petit contexte comme celui-ci est rarement remarqué en tant que tel, mais il change, de bien des petites façons, le degré de préparation d'un agent lorsqu'il répond au tout premier message d'une conversation.
La documentation de l'endpoint se trouve sur /docs/ipv4-lookup/ et /docs/ipv6-lookup/.