PickupRoutes
Back to How It Works

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:

  1. Workload balance is the primary objective, not total distance
  2. Street contiguity is preferred (volunteers should not zigzag between streets)
  3. Terminal constraint: all routes end at a common drop-off location
  4. 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:

  1. Build one complete route using momentum steering
  2. Calculate total work across all stops
  3. 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

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:

  1. Calculate mean of all leg distances
  2. Flag legs exceeding the mean distance
  3. Split the route at outlier points
  4. Reconnect segments by closest entry point (forward or reverse)
  5. 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 Overhead

Where:

  • 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

AddressesMetricOR-ToolsOur AlgorithmWinner
200Total Distance83.9 mi121.4 miOR-Tools
Work Std Dev11327Ours (4x better)
Runtime34.0s0.028sOurs (1,214x faster)
Stop Range0-2614-26Ours (no empty routes)
500Total Distance131.3 mi197.0 miOR-Tools
Work Std Dev26994Ours (3x better)
Runtime40.0s0.119sOurs (336x faster)
1,000Total Distance171.8 mi265.2 miOR-Tools
Work Std Dev1,040545Ours (2x better)
Runtime50.1s0.399sOurs (126x faster)
2,000Total Distance215.8 mi367.8 miOR-Tools
Work Std Dev2,2831,826Ours
Runtime70.2s1.500sOurs (47x faster)

Summary

MetricOR-ToolsOur Algorithm
Total DistanceBaseline+55% longer
RuntimeBaseline428x faster
Work BalanceBaseline3x more even
Empty RoutesFrequentNever

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

  1. No optimality guarantees: As a greedy heuristic, we cannot bound solution quality relative to theoretical optimal.
  2. Single-depot assumption: All routes end at one location. Multi-depot scenarios (multiple food banks) would require extension.
  3. Static assignment: No dynamic re-routing as volunteers complete stops.
  4. 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

  1. Toth, P., & Vigo, D. (2014). Vehicle Routing: Problems, Methods, and Applications. SIAM.
  2. Google OR-Tools. https://developers.google.com/optimization
  3. Dantzig, G. B., & Ramser, J. H. (1959). The truck dispatching problem. Management Science, 6(1), 80-91.
  4. 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.
  5. Matl, P., Hartl, R. F., & Vidal, T. (2018). Workload equity in vehicle routing problems: A survey and analysis. Transportation Science, 52(2), 239-260.
  6. 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 R

Built for Betty Lou's Pantry in Coopersburg, PA