应用场景

构建利用邮政编码风险的保险报价工具

在线即时保险报价需要平衡两件相互矛盾的事情:它必须足够快,最好只需填写几个字段;同时它需要足够的真实信息来合理地为保单定价,而不是凭空猜测。一家地区性家庭财产保险公司在构建即时报价工具时发现,在显示任何价格之前就要求填写完整地址,会让大量访客在看到数字之前就离开,而这些恰恰是快速报价工具本应留住的访客。

事实证明,邮政编码是能够较好地同时满足这两个约束的输入。它只是一个简短的字段,快到大多数访客输入时不会犹豫;同时又足够具体,能够把一处房产定位到一个区域,而这个区域与保险公司自己的精算模型用于保单定价的风险因素有着有意义的关联,这些因素包括区域天气模式、当地理赔历史,以及与已知洪水或野火风险区的距离,均由保险公司自己的风险团队独立维护。

报价工具将输入的邮政编码发送到 /v1/postcode,由它解析出该编码对应的区域,保险公司自己的定价引擎再用解析出的区域查找其内部的地区风险评级。这完全是保险公司自己的专有数据和方法,邮政编码查询只充当访客输入的内容与保险公司风险表中适用的那一行之间的桥梁。My Geocode 在保险公司如何权衡风险方面没有任何参与,也无从知晓,只负责解析某个邮政编码实际描述的是哪个位置。

以这种方式生成的即时报价被明确标注为初步报价,因为完整的核保流程仍然需要完整的地址、具体房产的详细信息,以及仅凭邮政编码无法提供的其他信息,例如屋顶的年限或是否具备特定的防火措施。即时报价的任务是足够快地给访客一个现实的大致数字,让他们继续参与流程,而不是作为最终的、具有约束力的价格,保险公司自己的网站在每一步都明确说明了这一区别。

这种分阶段的做法,即现在先给出快速估算,等到有人准备继续办理正式保单时再收集完整地址,与访客原本的行为方式相吻合:大多数请求即时报价的人都在货比三家,希望在投入更长的申请流程之前先得到一个大致数字;而在给出这个大致数字之前就要求填写完整地址,恰恰让保险公司失去了这些货比三家的客户。

与大多数保险比价流量一样,报价工具的流量在续保季以及某地区发生重大天气事件后会激增,使保险公司在这些时期的用量超出每日免费配额并转入预付额度。与一次由快速、低门槛的报价体验带来的完整保单申请的价值相比,这笔费用微不足道。

该端点的文档位于 /docs/postal-code-lookup/,API 价格详情见 /pricing/。