Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Агент поддержки в одном офисе, глядя на обращение, созданное в «3:47 утра», понятия не имеет, поздно ли это для клиента или середина его рабочего дня. Отметки времени без указания часового пояса почти бесполезны, когда клиенты компании находятся на нескольких континентах, и компания-разработчик ПО со службами поддержки в трёх регионах сталкивалась с этим постоянно. Агенты открывали обращение, проверяли страну клиента в платёжных данных, затем вручную выясняли, опережает эта страна их время или отстаёт, и ошибались достаточно часто, чтобы фраза «извините, что беспокоим так рано» стала в офисе расхожей шуткой.
Компания заменила догадки двумя вызовами, которые выполняются при поступлении обращения. Сначала /v1/ip считывает IP-адрес посетителя и возвращает страну, регион, город и координаты, а также поле часового пояса прямо в том же ответе. Для большинства обращений этого поля было достаточно. Для небольшого числа случаев, где требовалась большая точность, например при планировании обратного звонка, координаты из этого запроса передавались в /v1/timezone, который возвращает название часового пояса IANA и текущее смещение от UTC для этой конкретной точки, при необходимости с расчётом на определённый момент, а не на текущий.
Название IANA важнее, чем может показаться. Голое смещение от UTC меняется по правилам перехода на летнее время, которые различаются в разных странах, а иногда и в разных регионах одной страны, поэтому запись «UTC+2» в карточке клиента дважды в год незаметно становится неверной. Если вместо этого хранить «Europe/Warsaw», смещение всегда рассчитывается правильно для любой даты, на которую запланировано обращение или обратный звонок, потому что стоящая за ним база данных часовых поясов отслеживает изменения этих правил по мере их появления.
Видимым изменением стала небольшая строка вверху каждого обращения: местное время клиента прямо сейчас рядом с его именем. Агенты перестали спрашивать «у вас там не поздно?» и начали открывать сообщения точным «добрый день». Маршрутизация обращений тоже улучшилась, когда очередь смогла сортировать клиентов по тому, находятся ли они сейчас в пределах рабочего времени в своём регионе, а не по тому, в какой службе поддержки в этот момент были сотрудники.
Для всего этого не понадобилась база соответствий стран и часовых поясов, которую поддерживают вручную; именно такое самодельное решение компания использовала раньше, и оно ломалось каждый раз, когда IP клиента определялся в крупной стране с несколькими поясами. Определение часового пояса прямо по координатам устранило эту категорию ошибок целиком.
Объём был небольшим, один запрос на каждое новое обращение, с большим запасом в пределах 2 500 бесплатных запросов в день, включённых в ключ компании. Самому инструменту поддержки предоплаченный баланс ни разу даже близко не понадобился, хотя тот же ключ обслуживал и другие части продукта, которым он был нужен.
Работа с часовыми поясами одна из тех деталей, которые клиенты замечают, только когда что-то не так. Если делать это правильно и незаметно, в фоне каждого обращения, небольшое исправление даёт несоразмерно большой эффект на то, какое впечатление производит служба поддержки. Документация по обоим эндпоинтам находится на страницах /docs/ipv4-lookup/ и /docs/timezone-lookup/.