Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Создание инструмента диспетчеризации выездного обслуживания по расстоянию
Назначать ближайшего свободного техника кажется очевидным, пока не посмотришь, как на самом деле работает большинство небольших диспетчерских систем: часто просто по доступности, следующий заказ получает тот техник, который первым закончил текущий, даже если он находится на другом конце зоны обслуживания от нового заказа. Компания по ремонту бытовой техники с целым штатом выездных техников обнаружила, что это незаметно отнимало время в пути повсеместно: техники пересекали всю зону обслуживания, чтобы добраться до заказов, куда коллега поблизости доехал бы за малую долю этого времени.
Чтобы это исправить, нужно было знать в координатах, где сейчас находится каждый техник и где расположен каждый новый заказ, а не воспринимать и то и другое как текстовые описания, о которых диспетчеру приходилось рассуждать по памяти о местности. Адреса новых заказов геокодировались через /v1/forward по мере поступления, и каждый запрос на обслуживание превращался в координату в момент назначения. Местоположение техников, отслеживаемое через их мобильное приложение при перемещении между заказами, поступало в виде координат прямо с устройства и не требовало геокодирования, но обратный запрос /v1/reverse давал диспетчерам понятное описание местоположения техника с точностью до улицы. Это было удобно для диспетчера, которому, глядя на экран, нужно было быстро понять, где находится техник, а не разбирать голые координаты.
Когда обе стороны были выражены в координатах, диспетчерская система могла вычислять реальное расстояние между каждым свободным техником и новым заказом и назначать с учётом сочетания расстояния и доступности, а не одной лишь доступности. Веса были подобраны так, что техник, который освободится чуть позже, но находится гораздо ближе, часто оказывался лучшим выбором, чем свободный прямо сейчас, но далёкий. Этот компромисс компания настраивала несколько недель, наблюдая за реальными результатами назначений.
Измеримым результатом стало сокращение среднего времени в пути на заказ по всему штату техников, что напрямую выразилось в большем числе выполненных заказов на техника в день, ведь меньше времени в дороге между заказами означало больше времени на сами заказы. Снизились и затраты на топливо на заказ: меньшая, но реальная дополнительная выгода, на которую компания изначально не рассчитывала, начиная проект.
Компания оставила диспетчера в процессе, а не автоматизировала назначение полностью, поскольку расстояние важно, но это не единственный фактор: сертификация техника по конкретной марке техники или желание клиента видеть знакомого техника иногда перевешивали назначение, оптимальное только по расстоянию. Инструмент показывал вариант, ранжированный по расстоянию, как сильное значение по умолчанию, которое диспетчер мог изменить, а не как автоматическое назначение вообще без проверки человеком.
Объём рос вместе с числом заказов: один вызов геокодирования на новый заказ плюс меньшее число обратных запросов для показа местоположения техников диспетчерам. Для компании с таким штатом это с запасом укладывалось в бесплатную дневную квоту, а при расширении на новые зоны обслуживания был доступен запас в виде предоплаченного баланса.
Документация по обоим эндпоинтам находится по адресам /docs/forward-geocoding/ и /docs/reverse-geocoding/.