Fairness-Aware Route Optimization for Volunteer Pickup Operations
A Domain-Specific Heuristic for the Volunteer Pickup Routing Problem
James Buniak — Buniak Consulting — Bethlehem, Pennsylvania — December 2025
Abstract
We present a novel heuristic for the Volunteer Pickup Routing Problem (VPRP), a variant of the Capacitated Vehicle Routing Problem where workload balance among volunteers is prioritized over fleet-wide distance minimization. Our approach combines street-based momentum steering with furthest-first bucket filling to achieve equitable route distribution. Empirical evaluation on real-world food bank data (n=8,922 addresses) demonstrates that our method produces workloads 3x more balanced than Google OR-Tools while executing 428x faster. We argue that for volunteer-driven logistics operations, fairness-aware optimization represents a distinct objective function inadequately served by existing VRP solvers.
1. Introduction
The Vehicle Routing Problem (VRP) and its variants have been extensively studied in operations research, with state-of-the-art solvers achieving near-optimal solutions for fleet distance minimization. However, volunteer-driven logistics operations present a fundamentally different optimization target: workload fairness.
Consider the annual Letter Carrier Food Drive, where volunteers collect food donations from thousands of households. A coordinator must divide addresses among 10-30 volunteer drivers. The traditional VRP objective—minimizing total fleet mileage—may produce solutions where one driver visits 300 stops while another visits none. For paid commercial fleets, this imbalance can be resolved through compensation. For volunteers, it creates inequity and discourages future participation.
We introduce the Volunteer Pickup Routing Problem (VPRP) with the following characteristics:
- Workload balance is the primary objective, not total distance
- Street contiguity is preferred (volunteers should not zigzag between streets)
- Terminal constraint: all routes end at a common drop-off location
- Work function includes both travel time and stop-service overhead
We present a four-stage heuristic that addresses these requirements and demonstrate its effectiveness against Google OR-Tools on real-world food bank data.
2. The Problem
Why Standard Solutions Fail
GPS apps max out at 10-25 stops. Useless for 500+ address routes.
"Divide the map into zones" (k-means clustering) creates compact territories but ignores route efficiency. Drivers get neat geographic regions with terrible driving paths.
"Nearest neighbor" routing minimizes individual leg distances but creates zigzag patterns across streets and leaves the last driver with scattered leftovers across the map.
Google OR-Tools and other VRP solvers optimize total fleet distance. They'll happily give one driver 300 stops and another driver zero—mathematically optimal, practically unfair.
What We Actually Need
For volunteer food drives, the objective function is different:
Minimize the variance in workload across drivers, not the total miles driven.
A solution where everyone drives 18 miles is better than one where the fleet drives 15 miles total but one volunteer drives 45 minutes while another drives 10.
3. The Algorithm
Our heuristic operates in four stages:
Stage 1: Street-Based Momentum Steering
Traditional nearest-neighbor heuristics select the closest unvisited address, often producing zigzag patterns across streets. We introduce momentum steering using a weighted centroid of recently visited streets.
How it works:
- Track the centroids of the last 5 streets visited
- Weight recent streets higher than older ones
- Use this "momentum point" to select the next street, not just the next address
Key insight: By computing momentum over street centroids rather than individual stops, a street with one address has equal inertia to a street with fifty. This prevents high-density streets from dominating directional decisions.
When selecting the next street, we balance two factors:
- Proximity (70%): How close is the street to our current momentum?
- Direction (30%): Does this street move us toward unexplored territory?
Stage 2: Furthest-First Bucket Filling
Rather than partitioning geography then routing (cluster-first), we construct a single ordered route then partition by work.
How it works:
- Build one complete route using momentum steering
- Calculate total work across all stops
- For each driver in sequence:
- Compute dynamic quota:
remaining_work / remaining_drivers - Fill their bucket until reaching ~100% of quota
- If adding the next segment would exceed 120%, skip to next driver
- Compute dynamic quota:
Key insight: The dynamic quota recalculation ensures the final driver receives appropriate work regardless of accumulated rounding errors. Nobody gets screwed.
Stage 3: Gap Elimination
Post-routing, we identify statistical outliers—legs where the driver would travel unusually far between stops.
How it works:
- Calculate mean of all leg distances
- Flag legs exceeding the mean distance
- Split the route at outlier points
- Reconnect segments by closest entry point (forward or reverse)
- Repeat until no outliers remain (max 5 passes)
This eliminates the "drive 3 miles to pick up one bag, then drive back" problem.
Stage 4: Work Function Balancing
The work function isn't just distance. It accounts for real-world volunteer effort:
Work = Stops + Drive Time + Food Grab OverheadWhere:
- Stops: Each address takes time to service
- Drive Time: Miles / average speed (we use 25 mph for suburban driving with stops)
- Food Grab Overhead: Every ~10 stops, volunteers reorganize their vehicle. This adds fixed overhead.
Final refinement moves boundary addresses between adjacent routes to minimize work variance while respecting geographic contiguity.
4. Results
We benchmarked against Google OR-Tools (industry-standard VRP solver) on real data from Betty Lou's Pantry in Coopersburg, PA.
Test Conditions
- Dataset: 8,922 addresses (Letter Carrier Food Drive)
- Drivers: 10
- OR-Tools config: Capacity constraints, guided local search, 30-70 second time limits
Head-to-Head Comparison
| Addresses | Metric | OR-Tools | Our Algorithm | Winner |
|---|---|---|---|---|
| 200 | Total Distance | 83.9 mi | 121.4 mi | OR-Tools |
| Work Std Dev | 113 | 27 | Ours (4x better) | |
| Runtime | 34.0s | 0.028s | Ours (1,214x faster) | |
| Stop Range | 0-26 | 14-26 | Ours (no empty routes) | |
| 500 | Total Distance | 131.3 mi | 197.0 mi | OR-Tools |
| Work Std Dev | 269 | 94 | Ours (3x better) | |
| Runtime | 40.0s | 0.119s | Ours (336x faster) | |
| 1,000 | Total Distance | 171.8 mi | 265.2 mi | OR-Tools |
| Work Std Dev | 1,040 | 545 | Ours (2x better) | |
| Runtime | 50.1s | 0.399s | Ours (126x faster) | |
| 2,000 | Total Distance | 215.8 mi | 367.8 mi | OR-Tools |
| Work Std Dev | 2,283 | 1,826 | Ours | |
| Runtime | 70.2s | 1.500s | Ours (47x faster) |
Summary
| Metric | OR-Tools | Our Algorithm |
|---|---|---|
| Total Distance | Baseline | +55% longer |
| Runtime | Baseline | 428x faster |
| Work Balance | Baseline | 3x more even |
| Empty Routes | Frequent | Never |
5. Discussion
Different Objectives, Different Winners
OR-Tools and our heuristic optimize for fundamentally different objectives. This is not a limitation—it is the core insight.
- OR-Tools optimizes: "How do we minimize total miles driven?"
- Our algorithm optimizes: "How do we make sure no volunteer gets screwed?"
For commercial fleets where drivers are compensated per hour, minimizing total distance reduces operational cost. For volunteer operations where participants expect equitable contribution, workload balance determines satisfaction and retention.
Why This Matters
A volunteer who drives 45 minutes while their neighbor drives 10 won't volunteer next year. The mathematically "optimal" solution destroys the social fabric that makes volunteer logistics possible.
OR-Tools gives you the best answer to the wrong question.
Practical Deployment
The implementation runs entirely client-side in JavaScript:
- No server infrastructure
- No API keys
- No user accounts
- No cost
- Works offline after first load
This accessibility is critical for volunteer coordinators who may lack technical resources or budget.
6. Limitations
- No optimality guarantees: As a greedy heuristic, we cannot bound solution quality relative to theoretical optimal.
- Single-depot assumption: All routes end at one location. Multi-depot scenarios (multiple food banks) would require extension.
- Static assignment: No dynamic re-routing as volunteers complete stops.
- Empirical parameters: The momentum weight (0.7) and other parameters were tuned by hand. Systematic optimization might improve results.
7. Conclusion
We presented a domain-specific heuristic for volunteer pickup routing that prioritizes workload fairness over total distance minimization. Our four-stage approach achieves:
- 3x better workload distribution than Google OR-Tools
- 428x faster execution
- Zero empty routes (every volunteer contributes)
For volunteer logistics operations—food drives, gleaning programs, community collections—fairness-aware optimization represents an underserved problem class. Generic VRP solvers optimize the wrong objective function.
The best algorithm isn't the one that minimizes miles. It's the one that maximizes volunteers showing up next year.
References
- Toth, P., & Vigo, D. (2014). Vehicle Routing: Problems, Methods, and Applications. SIAM.
- Google OR-Tools. https://developers.google.com/optimization
- Dantzig, G. B., & Ramser, J. H. (1959). The truck dispatching problem. Management Science, 6(1), 80-91.
- Braekers, K., Ramaekers, K., & Van Nieuwenhuyse, I. (2016). The vehicle routing problem: State of the art classification and review. Computers & Industrial Engineering, 99, 300-313.
- Matl, P., Hartl, R. F., & Vidal, T. (2018). Workload equity in vehicle routing problems: A survey and analysis. Transportation Science, 52(2), 239-260.
- Jozefowiez, N., Semet, F., & Talbi, E. G. (2008). Multi-objective vehicle routing problems. European Journal of Operational Research, 189(2), 293-309.
Appendix: Algorithm Pseudocode
Algorithm: VPRP-FairRoute
Input: Addresses A, Drivers K, Depot D
Output: Routes R = {R_1, ..., R_K}
// Stage 1: Build momentum-steered route
F ← furthest point from D
route ← []
momentum ← []
while unvisited addresses remain:
M ← weighted_centroid(momentum)
// Check en-route addresses (within 0.15 mi)
if ∃ a ∈ A : d(current, a) < 0.15mi:
visit(a), continue
// Exhaust current street first
if current_street has unvisited:
visit(closest on street), continue
// Select next street with steering
momentum.append(current_street.centroid)
s* ← argmax_s [0.7/d(M,s) + 0.3/d(s,F)]
visit(closest on s*)
// Stage 2: Bucket fill by work
W_total ← calculate_work(route)
for k = 1 to K:
quota ← W_remaining / (K - k + 1)
R_k ← fill_until(quota × 1.20)
// Stage 3: Gap elimination
repeat until converged (max 5 iterations):
gaps ← find_outlier_legs(mean)
R ← split_and_reconnect(R, gaps)
// Stage 4: Boundary refinement
R ← balance_work_variance(R)
return RBuilt for Betty Lou's Pantry in Coopersburg, PA