Food bank volunteer coordination is the logistics, not just the warehouse

Friday afternoon, 3.45pm. The duty manager at a regional food bank picks up a call from a supermarket store manager. The supermarket has 250kg of fresh produce that needs to leave the store by 6pm or it goes to landfill. The fruit isn’t damaged. It’s just past the cosmetic standard the store displays. Can the food bank collect?

The food bank has the warehouse space to take it. They have volunteers who’d be willing to do the pickup. What they don’t have, in this exact moment, is a confirmed driver with a vehicle big enough for 250kg of produce, available between 4.30pm and 5.30pm.

Forty-five minutes later, after six text messages to people who might be free, the duty manager gets a yes. The pickup happens. The produce goes into Saturday’s distribution. By Monday morning, the same supermarket calls again about a different load.

This is one half of the part of food bank work that doesn’t show up in volunteer rotas. The recurring shifts inside the food bank (Tuesday morning sorting, Saturday distribution, Friday kitchen prep) are the visible work, and the part most coordination software is built around. But the work that actually expands what a food bank can do happens at the edges, in two directions: getting food in from where it’s about to be wasted, and getting food out to people who can’t make it to the food bank.

There is no global food shortage. Supermarkets discard produce that doesn’t meet display standards. Bakeries throw out unsold bread at end of day. Restaurants and caterers have leftover meals that meet food safety standards but don’t make it to a second service. Farms have surplus from over-ordering. The food exists, in volume, every single day. What’s missing is the coordination capacity to pick it up before it spoils, before the bin lorry arrives, before the offer expires.

At the other end of the operation, a parallel constraint. The clients who’d benefit most from a food bank are often the ones least likely to make it to one: people with mobility limitations, people with disabilities, elderly residents without transport, single parents without childcare, people who are too unwell to attend, people in rural areas with sparse public transport. Most food banks know this. Most don’t run delivery programmes anyway. Not because they don’t want to, but because they don’t have the volunteer driving capacity to support it. The same logistics gap that limits what comes in also limits who can be reached.

Food bank coordination has two shapes. The recurring operation is one of them. The logistics layer (the pickup runs that bring food in and the delivery runs that take food out) is the other. The first is what most coordination tools support, and most food banks are running it adequately. The second is where most of a food bank’s untapped capacity lives, and it’s the layer that’s structurally underbuilt across the sector.

The recurring operation

This is the visible layer. Sorting, kitchen prep, distribution, intake. The same shifts week after week, with regular volunteers who know the layout and the routine. The compliance requirements (food safety training, allergen awareness, dress code) are real and have to be visible at signup. The volunteer mix is broader than most sectors, including regulars, faith groups, corporate teams, court-mandated hours, and holiday families, each needing different handling. These are real coordination challenges, and most food banks have built workable systems for them already.

The recurring operation isn’t the focus of this post because it isn’t where the constraint sits. A food bank running a tight Tuesday morning sort and a smooth Saturday distribution still has a ceiling on how much food it can move and how many people it can reach. That ceiling is set by what comes in the door and what goes out to people who can’t reach the door themselves. The logistics layer is what raises both ceilings.

The logistics layer, in two directions

The pickup is one direction. The delivery is the other. They’re the same coordination challenge with different orientations.

The pickup is what most coordinators think about first because it’s where new food comes from. Supermarkets, bakeries, restaurants, and farms all have surplus on a daily basis, and the food bank that can answer the call gets the food. This is what the Friday 3.45pm scene was about: a pool of volunteers with vehicles, ready to take a run within an hour or two of the call coming in. A pickup that’s confirmed in fifteen minutes happens. A pickup that’s still being chased after an hour often doesn’t, and the food goes to landfill.

The delivery is what most food banks know they should do but can’t sustain. The shape is different from a pickup. Boxes are prepared in advance, usually on Wednesday morning, ready by 1pm. Routes get split among available drivers, typically three to six addresses each, completed by 4pm. The work isn’t heavy (boxes are pre-loaded) and the time window is more predictable than a rescue call. What it requires is a driver pool, a way to put the routes out for claim, and the household notes attached to each stop. The food banks that run delivery programmes well are the ones where the same logistics infrastructure supports both directions. The pool is one pool, with volunteers indicating their preferences. The call mechanism is one mechanism. The decision about whether to add delivery isn’t really about the work; it’s about whether the coordination layer can support another category of mobilisation alongside the pickup.

What the logistics layer requires

Three things. They apply to both pickups and deliveries; the differences are in the task descriptions, not the principles.

A standing pool of volunteers with vehicles. Different from the regular shift list. Drivers, with vehicles ranging from small cars (good for delivery routes and smaller pickups) to vans and refrigerated transport (good for larger pickups and frozen or dairy donations). The pool is built by signing people up for a different kind of commitment: not “I’ll come every Tuesday morning,” but “tell me when there’s a run that fits, and I’ll come if I can.” Some volunteers prefer pickups (more straightforward, single stops, no client interaction). Some prefer deliveries (less heavy lifting, the satisfaction of seeing the receiving end). Some do both. The signup captures the preferences, and the calls go to the right people.

The fast call. When the supermarket calls at 3.45pm with a 250kg pickup, or when the Wednesday delivery routes need three drivers for a 1pm to 4pm window, the system has to push the request to the pool within minutes. Phones, not inboxes. The message has to carry the practical information someone needs to make the decision: where, when, what’s involved, vehicle requirement, weight estimate or stop count. The first qualified volunteer to accept gets the run. The duty manager doesn’t compose six messages individually; the system handles the broadcast and the response. The speed of the operation lives here.

Logistics attached to the task itself. A pickup volunteer arriving at a supermarket loading dock needs to know the procedure: what entrance to use, who to ask for, what to bring (crates, hand truck, blankets for fragile produce), any documentation that has to be signed. A delivery volunteer arriving at a household needs the equivalent: which addresses, what’s in each box, any client notes (don’t ring the bell, leave at the side door, household has a dog, the resident uses a wheelchair so leave the box on the kitchen counter), how to confirm the delivery happened. All of this should be attached to the task itself, not relayed in real-time messages while the duty manager is running the warehouse.

How to think about choosing tools

For the recurring operation, you may already have something workable. A spreadsheet, a posted rota, a few group chats can hold a regular shift schedule. The risk of switching that is the same one this post is mostly about: introducing change before peak season and being half-set-up when you most need to be running.

For the logistics layer, you’ll want something different. Push notifications that reach phones in seconds. Light signup that lets people join the pool without onboarding through a recurring rota. Group communication that activates with the call and quiets down when the run is done. Mobile-first, because that’s where the call lands and where the volunteer responds. Free or close to it, because the pool should be as large as possible, and per-seat fees discourage growth at exactly the size where growth matters most.

Don’t try to use one tool for both layers. The recurring operation and the logistics mobilisation have different volunteers, different mechanics, different urgency. Software that handles both well is rare. Software that handles the logistics well, alongside whatever’s working for the recurring operation, is more practical.

Don’t try to use one tool for coordination and food data either. Inventory tracking, weight reporting, donor records, and client records (which are sensitive and should sit in dedicated systems) live in food bank operations platforms. The volunteer coordination layer underneath is a different problem.

Where Zelos fits

Zelos is built for the logistics layer, not the recurring operation. The trained team running Tuesday morning sorting probably doesn’t need it; their existing system holds. What Zelos is good at is the call: a request comes in, the system instantly notifies qualified volunteers, the first to accept gets the task. The mechanism is the same whether the run goes outbound or inbound.

For a pickup: a single task (250kg of produce, store address, 4.30 to 5.30pm pickup window, estate car or larger, ask for Sam at the loading dock, hand truck helpful) goes out as a notification to the pickup pool. The first qualified volunteer to accept takes the run.

For a delivery: a coordinator publishes the day’s routes (Route A: four households in the south postcode area, boxes ready for collection at 1pm, completion by 4pm, household notes attached including any access instructions and dietary requirements). Drivers claim the routes that fit their afternoon. After delivery, drivers mark each address as completed and the duty manager has a record of which households were served and which weren’t.

A coordinator can keep a standing pool of drivers signed up to a workspace, organised by vehicle size, geography, or preference for pickup vs delivery. When the call goes out, the right volunteers see it. People accept tasks as their availability allows. Group chat handles any quick questions during the run. After the work, the task closes and the chat goes quiet until the next call.

The free plan covers unlimited members, which is what the logistics pool actually needs. Two hundred volunteers signed up to be on call, with maybe twenty of them responding to any given run, is exactly the kind of pool where per-seat tools become absurd. Workspaces are persistent: the pool you build over a year is still there next month, with the people who came last time and the patterns of who’s available when. New donors and new delivery routes can be added as the operation grows without rebuilding anything.

For inventory tracking, weight reporting, donor records, and client records (which are sensitive and should sit in dedicated systems), you’ll want dedicated platforms. Zelos handles the volunteer coordination layer underneath: who got the call, who said yes, who’s at the loading dock, who’s at the kerb in front of the house with the Wednesday delivery.

It is not the run. The run is the food that didn’t go to landfill, the supermarket that called again because last time you came through, the box that arrived at the door of someone who couldn’t have made it to the food bank otherwise. Zelos holds the structure that lets the call get answered. You can explore the product or start a free account and try it before next quarter starts. The work, either way, is yours.