チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
カスタマーサポートのチャットに位置情報のコンテキストを追加する
電話サポートの担当者は、会話が始まる前から発信者の市外局番を知ることができます。小さな情報ですが、本当に役に立つコンテキストです。これに対し、ライブチャットの担当者は、名前と顧客が最初に入力した内容しかない状態で始めることがよくあります。ライブチャットでサポートを提供しているあるソフトウェア会社は、顧客に余計なことを尋ねずに、同じような基本的な位置情報のコンテキストを自動で表示して、この差を埋めたいと考えていました。
この解決策は、チャットのセッションが始まった時点で、完全にサーバー側で実行されました。/v1/ipが訪問者のIPアドレスを国、地域、市区町村、タイムゾーンのフィールドに解決し、それらはすべて担当者の参考用としてチャットウィンドウの横の小さなパネルに表示されました。顧客には一切表示されませんでした。これは顧客が見たり操作したりする必要のある機能ではなく、担当者のためのコンテキストだったからです。
すぐに得られたメリットは単純でした。担当者は返信する前に顧客の現地時刻を確認できるようになり、「お待たせして申し訳ありません」が適切か、それとも顧客は実際には自分のタイムゾーンでまったく常識的な時間にチャットしていたのかを判断するのに役立ちました。担当者は尋ねなくても顧客の国と地域を確認することもできました。地域ごとのポリシー、配送ルール、規制の違いによって実際に正しいアドバイスが変わる製品を扱うサポートチームにとって、これは役に立つコンテキストでした。
この会社は、この位置情報のコンテキストを何に使い、何に使わないかについて慎重でした。地域による製品の違いを踏まえて、担当者がどのように返答を組み立てるか、またときにはどのナレッジベースの記事が最も関連しているかを判断する材料にはなりました。しかし、担当者自身の判断を経ずに、担当者が顧客に伝える内容を自動的に変えることは決してありませんでした。また、顧客がどこにいるかを正確に示すものとして顧客に提示することもありませんでした。企業が、顧客が明示的に伝えた以上に自分の所在地を知っているように見えるときに、一部の顧客が当然感じる不快感を避けるためです。
VPNや企業ネットワークを使っている顧客の場合、表示された所在地が顧客の実際の場所と一致しないことがあり、担当者はそれを確定した事実ではなく役に立つヒントとして扱うよう教育されました。特に、間違えると問題になる場面、たとえばアカウントに別のより信頼できる所在地が登録されている顧客に特定の地域のポリシーが適用されると思い込むような場面ではそうでした。両者が食い違う場合は、常にアカウント自体の所在地データがIPベースのヒントより優先されました。
これは新しい製品機能ではなく既存のサポートツールへの小さな追加で、サポートソフトウェアがすでに提供していた社内の担当者用ダッシュボードに、会社自身のエンジニアリングチームが追加したものでした。チャットの接続にすでに含まれているIPアドレスだけで機能するため、顧客側では許可のプロンプトも位置情報の共有ダイアログも一切必要ありませんでした。
リクエスト量はチャットのセッション数にそのまま対応し、新しいセッションごとに1回の検索でした。この会社のサポートチャットのトラフィックであれば、1日の無料の割り当ての範囲内に十分収まる処理量です。このような小さなコンテキストが名指しで注目されることはめったにありませんが、会話の最初のメッセージに答えるときに担当者がどれだけ準備ができていると感じるかを、さまざまな小さな面で変えます。
エンドポイントのドキュメントは/docs/ipv4-lookup/と/docs/ipv6-lookup/にあります。