チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
距離で結び付ける非営利団体のボランティアマッチングツールを作る
手伝う意思はあっても片道40分の運転はしたくないボランティアは、いつの間にか依頼に応じなくなっていきます。都市圏全体で数百人のボランティアを調整しているある地域の非営利団体は、担当者が特定の支援要請の近くにおおよそ誰が住んでいるかを手作業で思い出し、個別に連絡するという従来のマッチング方法が、時間がかかるうえに、ボランティアの名簿が1人の人間が覚えていられる範囲を超えて増えるにつれて、ますます当てにならなくなっていることに気づきました。
マッチングの両側、つまりボランティアの自宅住所と、継続的な支援要請の住所は、どちらも簡単な登録フォームや依頼フォームで集めたテキストの住所として存在していました。支援要請には、定期的な手伝いが必要なフードパントリー、時々手助けが必要な高齢の住民、設営ボランティアが必要な地域イベントなどがあります。これらを実際の近さでマッチングできるものにする第一歩は、両方の一覧を/v1/forwardでジオコーディングすることでした。既存のボランティア名簿と支援要請の一覧は一括処理で実行し、その後は新しい登録や依頼が届くたびに1件ずつ実行しました。
両側に座標がそろったことで、マッチングは非営利団体自身のシンプルなデータベースが直接実行できる距離計算になりました。新しい支援要請があれば、登録済みのボランティアを自宅住所からの実際の距離順に並べ、担当者が町の適切な地域に住んでいるとたまたま覚えていた人に頼るのではなく、最も近い人から順に連絡します。これにより、意欲とはまったく関係のない理由、つまり担当者が特定の継続的な支援要請の近くに住んでいることを個人的に知らなかったというだけの理由で、システム内で活用されていなかったボランティアが浮かび上がりました。
非営利団体は、実際の連絡とマッチングの判断に担当者を関与させ続けました。距離は重要な要素ですが唯一の要素ではなく、ボランティアの特定のスキル、都合、あるいは特定の支援要請との既存の関係が、最も近いことより重要になる場合もあったからです。ツールの役割は、担当者がまず確認したいと考える割り当てを完全に自動化することではなく、担当者がすばやく順に対応できる、距離順に並べた一覧を示すことでした。
連絡がまず本当に近くにいる人に一貫して向けられるようになると、ボランティアからの応答率は目に見えて改善しました。団体が自らのデータでこれをはっきり確認すると、直感的にも納得のいく結果でした。ボランティアにとって実際に対応しやすい依頼は、担当者が近さではなくなじみがあるという理由で声をかけた遠くの依頼よりも、単純に引き受けてもらえる可能性が高かったのです。
実際の予算の制約がある非営利団体として運営していたため、ここでは費用が特に重要でした。このプロジェクトの利用量は、最初の名簿に対する控えめな一括ジオコーディングと、新しい登録や依頼に対する少量の継続的な利用だけで、プリペイドクレジットやUnlimitedキーを検討する必要もなく、1日あたりの無料枠に余裕で収まりました。つまり、限られた予算の1ドル1ドルが重要な団体にとって、位置に基づくマッチング機能全体を無料で利用できたということです。
地域の団体が同様のことを検討しているなら、出発点は思っているより小さなものです。すでにある住所をジオコーディングし、その上により凝った仕組みを作る前に、実際のボランティアと支援要請の一覧に対して距離に基づくマッチングが実際にどう見えるかを確かめてください。エンドポイントのドキュメントは/docs/forward-geocoding/にあります。