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