チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
オンラインの即時保険見積もりは、相反する2つの要素のバランスを取る必要があります。理想的には数項目を入力しただけで素早く出てくること、そして当て推量ではなく妥当な保険料を算出できるだけの実際の情報があることです。即時見積もりツールを構築していたある地方の住宅保険会社は、価格を一切表示する前に完全な住所を最初に尋ねると、多くの訪問者が数字を見る前に離脱してしまうことに気づきました。それはまさに、素早い見積もりツールで引き留めるはずだった訪問者たちでした。
両方の制約をかなりうまく満たす入力は、郵便番号であることがわかりました。1つの短い項目で、ほとんどの訪問者がためらわずに入力できるほど手軽でありながら、物件を十分に特定のエリアに位置づけられます。そのエリアは、保険会社独自の保険数理モデルがすでに保険料の算出に使っているリスク要因と意味のある相関がありました。地域の気象パターン、その土地の保険金請求の履歴、既知の洪水や山火事のリスク区域への近さといった要因で、これらは保険会社のリスクチームが独自に管理していました。
見積もりツールは入力された郵便番号を /v1/postcode に送信し、その郵便番号が対応するエリアを特定します。保険会社独自の料率エンジンは、特定されたエリアを使ってその地域の社内リスク評価を参照しました。これは完全に保険会社独自のデータと手法によるもので、郵便番号検索は、訪問者が入力した内容と保険会社のリスク表のどの行が該当するかをつなぐ橋渡しの役割だけを担っていました。My Geocodeは、保険会社がリスクをどう重み付けするかには一切関与せず、その内容を知ることもありません。担ったのは、ある郵便番号が実際にどの場所を表しているかを特定することだけです。
こうして作成された即時見積もりには、暫定的なものであることがはっきりと表示されていました。完全な引き受け審査には、完全な住所、個々の物件の詳細、そして屋根の築年数や特定の防火対策設備の有無など、郵便番号だけでは得られないその他の情報が引き続き必要だったためです。即時見積もりの役割は、訪問者が手続きへの関心を失わないうちに、現実的な概算額を素早く示すことであり、最終的な確定価格を提示することではありませんでした。保険会社のサイトは、あらゆる段階でこの違いを明示していました。
今は素早い概算を示し、完全な住所は実際の保険契約に進む準備ができた時点で初めて尋ねるという、この段階的なアプローチは、訪問者がすでにとっていた行動と一致していました。即時見積もりを求める人の多くは比較検討中で、長い申込手続きに進む前におおよその数字を知りたがっていました。そのおおよその数字を示す前に完全な住所を尋ねていたことで、保険会社はまさにそうした比較検討中の人たちを失っていたのです。
見積もりツールのトラフィックは、保険の比較検討に関するトラフィックの多くと同様に、更新時期や地域で大きな気象災害が起きた後に急増しました。そうした期間には保険会社の利用量が1日あたりの無料割り当てを超えてプリペイドクレジットでの利用に移りましたが、手軽で素早い見積もり体験によって得られる保険契約の申込1件の価値と比べれば、取るに足らないコストでした。
このエンドポイントのドキュメントは /docs/postal-code-lookup/ に、APIの料金の詳細は /pricing/ にあります。