チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
住所のスプレッドシートを営業テリトリーマップに変える
1万1千行の顧客住所がスプレッドシートに入っていました。請求には役立っても、計画には役に立たないものでした。ある営業企画チームは、何年も前に誰かが選んだ郡の境界ではなく、顧客が実際にいる場所に基づいてテリトリーを引き直したいと考えていました。しかし、番地入りの住所で埋まったスプレッドシートは地理的に並べ替えることができません。できるのはアルファベット順の並べ替えだけで、それは同じことではありません。
解決策は1回のバッチジョブでした。チームは顧客リストから重複のない住所をすべてエクスポートし、1回の一括リクエストとして/v1/forwardに送りました。住所のリストでは項目ごとに1件の課金リクエストとして数えられ、1万1千回の個別検索のように呼び出しごとに課金されるわけではないからです。返ってきたのは各住所の位置の一致結果で、緯度と経度、つまり地図ツールやスプレッドシートの数式で実際に扱える構造化された座標が含まれていました。
すべての顧客に座標が付いたことで、テリトリーの再設計は推測の問題ではなくデータの問題になりました。チームは顧客を近さでクラスタリングし、提案した地域の組み合わせで売上がどれだけ均等に分布しているかを測り、テリトリーの境界が密集した顧客のクラスターを正当な理由なく二分している場合はすぐにわかるようになりました。位置の情報がスプレッドシートでは距離を測れない住所のテキストだけだったときには、そのどれも見えませんでした。
チームはまた、各一致結果の国と地域のフィールドを営業担当者の既存のアカウント割り当てと照合しました。すると、時間とともに誤ったテリトリーに流れていたいくつかのアカウントが浮かび上がりました。オフィスを移転した顧客や、何年も前に誤って隣の地域の担当者に割り当てられたまま修正されていなかった顧客です。その整理は誰も計画していなかった副産物でしたが、ノルマの公平性にとっては、テリトリーの再設計そのものよりも重要だったことがわかりました。
顧客リスト全体を少しずつではなく一度にジオコーディングしたため、これは継続的な連携というより一度きりのプロジェクトに近いものでした。チームはバッチを実行し、結果を計画用のスプレッドシートにエクスポートし直し、次の大きなテリトリーの見直しまでエンドポイントを再び呼び出す必要はありませんでした。この種の作業量であれば、1日の無料の割り当てで実行分をまかなえ、プリペイドクレジットはまったく必要ありませんでした。プロジェクト全体も、外部ベンダーとの数週間にわたる地図作成の契約ではなく、午後の半日で終わりました。
より大きな変化は、その後チームが自分たちのデータをどう考えるかにありました。住所に座標が付くと、どの地域が顧客密度に比べて手薄か、あるいは負担過多かといった、以前はコンサルタントが必要だった問いに、チーム自身がスプレッドシートと少しの計算で答えられるようになりました。外部のサービスが必要だったのはジオコーディングの工程だけで、それはプロジェクトの中で最も小さな部分でもありました。
住所のバッチは顧客リストである必要はありません。店舗の所在地、サービスのテリトリー、イベント会場など、スプレッドシートにテキストの住所として入っているものなら何でも同じ手順で処理できます。バッチの上限とリクエストの形式については、/docs/forward-geocoding/と/docs/rate-limits/で説明しています。