チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
複数地域のサポートキューで正しい現地時刻を表示する
あるオフィスのサポート担当者が「午前3:47時」に起票されたチケットを見ても、それが顧客にとって遅い時間なのか、仕事の真っ最中なのかはまったくわかりません。顧客が複数の大陸にまたがる会社にとって、タイムゾーンの付いていないタイムスタンプはほとんど役に立ちません。3つの地域にサポート窓口を持つあるソフトウェア企業は、この問題に常に直面していました。担当者はチケットを開き、顧客の請求先の国を確認し、その国が進んでいるのか遅れているのかを手作業で調べていましたが、間違えることがあまりに多く、「朝早くから失礼します」がオフィスのお決まりの冗談になるほどでした。
同社は推測に頼るのをやめ、チケットが届いたときに2つの呼び出しを行うようにしました。まず、/v1/ipが訪問者のIPアドレスを読み取り、国、地域、都市、座標を返します。同じレスポンスにはタイムゾーンのフィールドも直接含まれています。ほとんどのチケットでは、そのフィールドだけで十分でした。折り返しの電話を予約する場合など、より高い精度が重要になる少数のケースでは、その検索で得た座標を/v1/timezoneに渡しました。このエンドポイントは、その地点のIANAタイムゾーン名と現在のUTCオフセットを返し、必要に応じて現在ではなく特定の時点について計算することもできます。
IANA名は、思っている以上に重要です。生のUTCオフセットは、国によって、ときには国内の地域によっても異なる夏時間のルールに従って変わるため、顧客レコードに「UTC+2」と保存しておくと、年に2回、知らないうちに誤った値になります。代わりに「Europe/Warsaw」と保存しておけば、チケットや折り返し電話がどの日付に予定されていても、オフセットは常に正しく計算されます。それを支えるタイムゾーンデータベースが、ルールの変更を発生時点で追跡しているからです。
目に見える変化は、すべてのチケットの上部に追加された小さな1行でした。顧客の名前の横に、その顧客の現在の現地時刻が表示されるようになったのです。担当者は「そちらはもう遅い時間ですか」と尋ねるのをやめ、代わりに正確な「こんにちは」でメッセージを始めるようになりました。チケットのルーティングも改善されました。キューを、たまたま人員が配置されているサポート窓口の順ではなく、自分の地域で現在営業時間内にいる顧客の順に並べ替えられるようになったからです。
これには、国とタイムゾーンの対応表を手作業で管理するデータベースは一切必要ありませんでした。それは同社が以前にその場しのぎで作っていた方法で、顧客のIPが複数のタイムゾーンにまたがる大きな国に判定されるたびに破綻していました。座標から直接タイムゾーンを読み取ることで、その種類の誤りがまるごとなくなりました。
リクエスト量は少なく、新しいチケット1件につき1回の検索で、同社のキーに含まれる1日あたり2,500件の無料リクエストの範囲に十分収まりました。サポートツールだけでプリペイドクレジットが必要になることはありませんでしたが、同じキーは、実際にクレジットを必要とする製品の他の部分でも使われていました。
タイムゾーンの扱いは、間違っているときにだけ顧客が気づく細部の一つです。すべてのチケットの裏側で、目立たずにそれを正しく処理することは、小さな修正でありながら、サポートチームの印象に大きな効果をもたらします。両方のエンドポイントのドキュメントは、/docs/ipv4-lookup/と/docs/timezone-lookup/にあります。