在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
把地址表格变成销售区域地图
一万一千行客户地址存放在一张电子表格里，用来开账单很有用，用来做规划却毫无用处。一个销售运营团队希望根据客户的实际所在位置重新划分销售区域，而不是沿用多年前某人选定的县界，但一张满是街道地址的电子表格无法按地理位置排序。它只能按字母顺序排序，而这完全是两回事。
解决办法是一个批处理任务。团队从客户名单中导出了所有不重复的地址，并将它们作为一个批量请求发送到 /v1/forward，因为地址列表中的每一项按一次计费请求计算，而不是像一万一千次单独查询那样按调用次数收费。返回的是每个地址的位置匹配结果，包括纬度和经度，也就是地图工具或电子表格公式真正能够处理的结构化坐标。
每个客户都附上坐标之后，区域重新设计就从一个靠猜测的问题变成了一个数据问题。团队可以按距离远近对客户进行聚类，衡量营收在一组拟议区域之间的分布是否均衡，并且当某条区域边界毫无理由地把一个密集的客户群一分为二时，能够立即看出来。当唯一的位置字段还是电子表格无法据以测量距离的文本地址时，这一切都是看不到的。
团队还把每个匹配结果中的国家和地区字段与销售代表现有的客户分配进行了比对，从而发现了少数随着时间推移被划错区域的客户：有的搬迁了办公地点，有的在多年前被错误地分配给了相邻区域的销售代表，却一直没有纠正。清理这些问题是一个没人预料到的附带收获，而事实证明，它对配额公平性的影响比区域重新设计本身还要大。
由于整个客户名单是一次性完成地理编码的，而不是随时间陆续处理，这更像是一个一次性项目，而不是持续性的集成。团队运行了批处理任务，把结果导回规划用的电子表格，在下一次重大区域评审之前都无需再调用该端点。对于这类工作负载，每日免费配额就足以覆盖这次运行，完全不需要预付额度，整个项目只花了一个下午，而不是与外部供应商进行为期数周的地图绘制合作。
更大的转变在于团队此后如何看待自己的数据。一旦地址附上了坐标，过去需要请顾问来回答的问题，例如相对于客户密度而言哪些区域服务不足或负担过重，就变成了团队用一张电子表格和一点算术就能自己回答的问题。地理编码这一步是唯一需要外部服务的环节，也是整个项目中最小的一部分。
一批地址不一定非得是客户名单。门店位置、服务区域、活动场地，任何以文本地址形式存放在电子表格中的内容，都可以经过同样的流程处理。批量限制和请求格式在 /docs/forward-geocoding/ 和 /docs/rate-limits/ 中有详细说明。