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