Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Маршрутизация обращений в поддержку по часовому поясу
Распределение обращений в поддержку по стране оплаты кажется рабочим вариантом, но в большинстве случаев не работает. Страна оплаты говорит о том, где был создан аккаунт, а не о том, где прямо сейчас находится человек, отправивший обращение. Компания, у которой агенты поддержки работали в три смены, постоянно отправляла ответы, приходившие в два часа ночи клиентам, которые оказались в поездке, работали удалённо из другой страны или просто жили там, где не отражал их платёжный адрес.
Компания перешла на распределение по фактическому текущему времени клиента. Каждое входящее обращение содержит IP-адрес посетителя, который /v1/ip определяет как страну, регион, город и координаты, а в том же ответе есть и поле часового пояса. Именно этот часовой пояс, а не указанная в данных страна оплаты, решал, в какую смену попадёт обращение. Обращение с IP, где в его регионе сейчас рабочее время, уходило той смене, которая работала и бодрствовала в этой части мира. Обращение, пришедшее далеко за пределами рабочего времени, ставилось в очередь следующей смены, от которой можно было обоснованно ожидать ответа в нормальный час.
Для обращений, требующих запланированного обратного звонка, а не асинхронного ответа, команда делала дополнительный шаг: передавала определённые координаты на /v1/timezone, который возвращает и имя часового пояса IANA, и смещение от UTC для этой точки, рассчитанное на тот будущий момент, на который планируется звонок. Это было важно, потому что смещения меняются при переходе на летнее и зимнее время в разные даты в разных странах, и для звонка, назначенного через три недели, нужно было смещение, которое будет действовать именно в тот день, а не сегодня.
В результате стало меньше ответов, отправленных в явно неподходящее время, а система распределения автоматически подстраивалась под клиентов, которые переезжали, путешествовали или просто жили там, где не отражала запись их аккаунта. Кроме того, команда получила действительно полезный показатель, которого у неё раньше не было: сколько обращений приходит вне рабочего времени любой из смен. Он превратился в подкреплённый данными аргумент для изменения графика смен, а не в догадку одного уставшего агента.
Ничего из этого не требовало от клиента что-либо вводить. IP-адрес уже был частью каждого запроса виджета поддержки, поэтому вся система работала без дополнительного поля в форме и без просьбы подтвердить часовой пояс, которую люди и так обычно пропускают или заполняют неправильно, когда путешествуют.
Объём запросов в точности соответствовал объёму обращений и для службы поддержки такого размера спокойно укладывался в бесплатную дневную квоту, которая входит в каждый ключ My Geocode, а на случай роста числа обращений была доступна обычная предоплата. Как только система заработала, команде больше ни разу не пришлось думать о стоимости, а это обычно признак того, что элемент инфраструктуры тихо делает свою работу в фоновом режиме.
Полные справочники по полям обоих эндпоинтов находятся на /docs/ipv4-lookup/ и /docs/timezone-lookup/, а работа лимитов запросов описана на /docs/rate-limits/.