上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
サポートダッシュボードに現地時刻の時計ウィジェットを追加する
今すぐ顧客に電話するかどうかを判断するサポート担当者にとっては、オフィスの時刻ではなく、その顧客がいる場所で実際に何時なのかを知ることが役に立ちます。
顧客のタイムゾーンを取得する
配送先や請求先の住所がすでに登録されている場合は、一度ジオコーディングして座標を取得し、その座標を/v1/timezoneに渡します。前回の訪問時のIPアドレスしかない場合は、/v1/ipエンドポイントがtimezoneフィールドを直接返すため、別途検索する必要はありません。
GET /v1/timezone?lat=35.6762&lon=139.6503{
"status": "ok",
"timezone": "Asia/Tokyo",
"utc_offset": "+09:00",
"abbreviation": "JST"
}住所もIPも登録されていない場合
住所もIPの記録もないリードやチケットには、タイムゾーンを検索するための信頼できる座標がありません。また、電話の国番号や言語設定から推測することは、このエンドポイントではできません。その場合は、数時間ずれている可能性が十分にある推測に基づく時計を表示するのではなく、タイムゾーンやおおよその所在地を直接尋ねてください。
時計を表示する
タイムゾーン識別子を顧客レコードに保存し、ダッシュボードを表示するたびにそこから現在の現地時刻を計算します。夏時間の切り替え前後で古くなってしまう固定オフセットを保存するのは避けてください。サイトにはクライアント側のJavaScriptがないため、ブラウザでリアルタイムに時刻を進めるのではなく、ページ読み込み時にサーバー側で現在の現地時刻を表示し、ページをリクエストするたびに更新します。
検索はページ表示ごとではなく顧客ごとに1回
顧客の所在地のタイムゾーン識別子は日々変わるものではありません。そのため、ダッシュボードを読み込むたびにAPIを呼び出すのではなく、住所やIPを最初に記録したときに一度検索して識別子を保存してください。こうすれば、この機能のリクエストはページ表示ごとに1件ではなく合計でわずかな件数にとどまります。サポートチームがダッシュボードを1日に何度も開く場合、これは重要です。
避けるべき間違い
過去のサポート対応のオフセットを、対応時のタイムスタンプではなく今日のタイムゾーン検索で再計算すると、夏時間の切り替え前後で誤った時刻が表示されることがあります。過去のチケットが提出された時点で顧客の現地時刻が何時だったかをダッシュボードに表示する必要がある場合は、現在のオフセットに頼るのではなく、そのチケット自体のタイムスタンプをtimeパラメーターで渡してください。
コスト
識別子をキャッシュしなくても、各検索は1リクエストです。そのため、常識的な規模のサポートチームであれば、すべてのキーに含まれる1日あたりの無料リクエスト2,500件、またはキーなしで1つのアドレスから利用できる同じ割り当ての範囲内に十分収まります。
最新の状態に保つ
登録されている顧客の住所が変わったら、古い識別子をレコードに付けたまま放置するのではなく、同時に保存済みのタイムゾーン識別子も更新してください。引っ越した顧客に古いタイムゾーン識別子が残っていると、レコードが更新されるまで誤った現地時刻が表示されます。古い検索結果そのものが失敗したりエラーになったりすることはないため、この問題は気づかれないまま続きます。
チケットの横に現地時刻の時計を置くのは小さな追加ですが、サポート担当者が毎回電話の前に頭の中でタイムゾーンの計算をする手間を省きます。リクエストの詳細はタイムゾーン検索のドキュメントで説明しています。