在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
按时区分配支持工单
按账单国家分配支持工单，听起来应该可行，实际上大多行不通。账单国家告诉您的是账户在哪里开设，而不是提交工单的人此刻身在何处。一家支持人员分布在三个班次的公司，不断把回复发给那些恰好在出行、在另一个国家远程办公，或者居住地与账单地址并不一致的客户，而这些回复到达时正是他们那里的凌晨两点。
这家公司于是改为按客户实际的当前时间来分配。每张进来的工单都带有访客的 IP 地址，/v1/ip 会将其解析为国家、地区、城市和坐标，同一个响应中还包含时区字段。决定工单进入哪个班次的，是这个时区，而不是档案中的账单国家。来自当前正处于所在地区工作时间内的 IP 的工单，会分配给在世界那一端有人值班且正清醒的班次。远在工作时间之外到达的工单，则会排队等候下一个能够合理预期回复在正常时间送达的班次。
对于需要预约回电而不是异步回复的工单，团队多做了一步：把解析出的坐标传给 /v1/timezone，它会返回该点的 IANA 时区名称和 UTC 偏移量，并按回电所预约的未来时刻进行计算。这一点很重要，因为不同国家的夏令时切换时间不同，偏移量会随之变化，一个预约在三周之后的回电，需要的是那一天实际生效的偏移量，而不是今天生效的偏移量。
结果是在明显不合适的时间发出的回复减少了，分配系统也能随着客户搬家、出行，或者居住在与账户记录不一致的地方而自动调整。它还为团队提供了一个以前没有的真正有用的指标：有多少工单是在所有班次的工作时间之外到达的，这变成了调整班次安排的数据依据，而不是某个疲惫的客服人员的直觉。
这一切都不需要客户输入任何内容。IP 地址本来就包含在支持小部件发出的每个请求中，因此整个系统无需额外的表单字段，也无需弹出提示让用户确认时区，而人们往往会跳过这种提示，或者在出行时填错。
请求量与工单量一一对应，对于这种规模的服务台，完全在每个 My Geocode 密钥所含的每日免费配额之内；如果工单量超出配额，还可以使用常规的预付选项。系统运行之后，团队再也不必考虑成本，这通常说明一项基础设施正在后台默默地尽职工作。
这两个端点的完整字段参考位于 /docs/ipv4-lookup/ 和 /docs/timezone-lookup/，速率限制行为见 /docs/rate-limits/。