チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
発送前に配送先住所を検証する
家具の配達の失敗は、小包の配達の失敗とは比べものにならないほど高くつきます。注文の住所が役に立つ場所につながらないと、トラック、2人組の作業員、予約された時間枠がすべて無駄になります。予約制の配達時間枠で大型商品を出荷していたある家具販売店は、そのコストを週に数回負担していました。
失敗の大半は同じ根本原因にさかのぼりました。顧客からすれば正しく入力した住所なのに、実際には配達可能な場所に解決されない、というものです。原因は通り名の入力ミス、入力された市区町村と一致しない郵便番号、あるいは部屋番号の欠落などでした。これらはどれも、住所の文字列を見ただけでは明らかになりません。その住所を実際の地理データと照合しようとして初めて明らかになるのです。
この販売店は、注文が配達スケジュール管理システムに渡される前の、注文確定の時点にチェックを追加しました。顧客が入力した住所は/v1/forwardに送られます。これは照合を試み、位置の結果とともに一致の品質を示す情報を返すもので、あらゆる入力が同じように信頼できるかのように装うのではなく、住所がどの程度の確信度で解決されたかを示します。それとは別に、顧客が入力した郵便番号を/v1/postcodeで照合し、そのコードが何に対応するかを調べました。これにより、郵便番号と市区町村名が互いに一致しないという特有のケースを捕捉できました。この不一致は、顧客が自動入力のミスで起こしやすく、注文フォームを読んでも見つけるのが非常に難しいものです。
両方のチェックで問題がなかった注文は、そのままスケジュール設定に進みました。住所が部分的にしか一致しなかった注文や、郵便番号と市区町村が食い違っていた注文には、配達時間枠を予約する前に、確認のための電話かメールを手短に行うフラグが付きました。自動的に実行され、トラックのコストが発生する前に効果を発揮するこのたった1つの追加ステップによって、修正のタイミングが工程の早い段階に移りました。「間違った住所に立っている作業員が発見する」ものから、「注文当日にメールで解決する」ものに変わったのです。
この販売店は、顧客に対して何を約束するかに慎重でした。このような検証チェックで確認できるのは、住所が正しい形式で、地理的にあり得るものであることです。大規模な集合住宅の中に特定の部屋番号が存在することや、注文者が実際にそこに住んでいることまでは確認できません。そのため、フラグ付けのロジックは、少しでも珍しいものをすべて却下するのではなく、明らかに壊れた住所を捕捉するように調整されました。前者では、解決する問題よりも多くの誤警報を生んでいたでしょう。
チェックはページビューごとではなく注文ごとに1回実行されたため、リクエスト量は予測しやすく、この規模の販売店であれば1日あたりの無料枠に十分収まりました。セール期間中の超過分はプリペイドクレジットでまかないました。この変更の効果は、無駄になる配達枠の減少という形で直接表れました。これは測定しやすく、リクエストあたりのごく小さな料金と比べて正当化しやすいコストです。
一致の品質がどのように表現されるかを含め、両方のエンドポイントのドキュメントは/docs/forward-geocoding/と/docs/postal-code-lookup/にあります。