チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
タイムゾーンでサポートチケットを振り分ける
請求先の国でサポートチケットを振り分けるのは、うまくいきそうに思えて、たいていうまくいきません。請求先の国からわかるのはアカウントが作成された場所であり、チケットを送信した人がいま実際にいる場所ではありません。3つのシフトにサポート担当者を配置していたある会社は、たまたま旅行中だったり、別の国からリモートで働いていたり、単に請求先住所に反映されていない場所に住んでいたりする顧客に、午前2時に届く返信を送り続けていました。
そこで会社は、顧客の実際の現在時刻に基づく振り分けに切り替えました。受信するすべてのチケットには訪問者のIPアドレスが含まれており、/v1/ipがそれを国、地域、都市、座標に変換し、同じレスポンスでタイムゾーンのフィールドも返します。チケットがどのシフトに割り当てられるかを決めたのは、登録されている請求先の国ではなく、このタイムゾーンでした。その地域で現在就業時間内にあたるIPから届いたチケットは、世界のその地域で人員がいて起きているシフトに回されました。就業時間を大きく外れて届いたチケットは、通常の時間に返信が届くと十分に見込める次のシフトの待ち行列に入れられました。
非同期の返信ではなく、予約した折り返し電話が必要なチケットについては、チームはさらに一手間かけて、特定した座標を/v1/timezoneに渡しました。このエンドポイントは、その地点のIANAタイムゾーン名とUTCオフセットの両方を、折り返し電話を予約する将来の時点について計算して返します。これが重要だったのは、夏時間の切り替えに伴うオフセットの変化が国によって異なる時期に起こるためで、3週間先に予約した折り返し電話には、今日有効なオフセットではなく、その日に実際に有効となるオフセットが必要でした。
その結果、明らかに不適切な時間に送られる返信が減り、顧客が引っ越したり、旅行したり、単にアカウントの記録に反映されていない場所に住んでいたりしても、自動的に適応する振り分けシステムができました。また、チームはそれまでなかった本当に役立つ指標も得ました。どのシフトの就業時間にも当てはまらない時間に届くチケットがどれだけあるかという指標で、これは疲れた担当者1人の勘ではなく、データに裏付けられたシフト表の見直しの根拠になりました。
これはどれも、顧客が何かを入力することに依存していませんでした。IPアドレスはサポートウィジェットが行うすべてのリクエストにすでに含まれていたため、システム全体が、追加のフォーム項目も、タイムゾーンの確認を求めるプロンプトもなしに動作しました。そうしたプロンプトは、いずれにせよ人々が飛ばしたり、旅行中に間違えたりしがちなものです。
リクエスト量はチケット量と1対1で推移し、この規模のヘルプデスクであれば、すべてのMy Geocodeキーに付いている1日あたりの無料割り当ての範囲に余裕をもって収まりました。チケット量がそれを超えて増えた場合は、通常のプリペイドの選択肢も利用できました。稼働を始めてからチームがコストについて考える必要は一度もありませんでした。これは一般に、インフラの一部が裏側で静かに役割を果たしていることのしるしです。
両エンドポイントの完全なフィールドリファレンスは/docs/ipv4-lookup/と/docs/timezone-lookup/にあり、レート制限の挙動は/docs/rate-limits/で説明しています。