在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
发货前核验配送地址
一次失败的家具配送，其代价是一次失败的包裹配送无法相比的。当订单上的地址指向不了任何有用的地方时，一辆货车、一支两人配送队和一个预约时段都会白白浪费。一家按预约时段配送大件商品的家具零售商，每周都要承受好几次这样的损失。
大多数失败都可以追溯到同一个根本原因：客户认为自己输入无误的地址，实际上并不能解析到一个可送达的地点，可能是街道名称有笔误，可能是邮政编码与所填城市不符，也可能完全漏填了公寓号。这些问题单看地址文本都不明显。只有当某个程序尝试将该地址与真实地理数据进行匹配时，它们才会显现出来。
这家零售商在订单确认时加入了一项检查，在订单交给配送调度系统之前执行。客户输入的地址会发送到 /v1/forward，它尝试进行匹配，返回位置结果以及匹配质量的指示，显示地址的解析置信度，而不是假装每个输入都同样可靠。另外，客户输入的邮政编码会通过 /v1/postcode 进行检查，查询该编码对应的地点，从而捕获邮政编码与城市名称彼此不一致的特定情况。这种不一致很容易因客户的自动填充出错而产生，而仅靠阅读订单表单则很难发现。
两项检查都通过的订单直接进入调度。地址仅部分匹配，或邮政编码与城市不一致的订单，则会被标记，在预约配送时段之前先进行一次快速的确认电话或邮件。这一个额外步骤自动运行，并在产生任何货车成本之前生效，把纠正环节提前到了流程的更早阶段：从“配送队站在错误地址前才发现”变成了“在下单当天通过一封邮件解决”。
这家零售商对向客户作出的承诺十分谨慎。这样的验证检查只能确认地址格式正确、在地理上合理。它不能确认大型公寓楼内确有某个具体的单元号，也不能确认下单人确实住在那里。因此，标记逻辑被调整为捕获明显错误的地址，而不是拒绝任何稍显不寻常的地址，否则制造的误报会比解决的问题更多。
由于检查是每个订单运行一次，而不是每次页面浏览运行一次，调用量很容易预测，对这种规模的零售商来说远在每日免费配额之内，促销活动期间超出的部分则由预付额度覆盖。这项改动的回报直接体现在浪费的配送时段减少上，这是一项容易衡量的成本，与极低的单次请求价格相比也很容易证明其合理性。
两个端点的文档（包括匹配质量的表示方式）见 /docs/forward-geocoding/ 和 /docs/postal-code-lookup/。