Community event volunteer coordination runs on goodwill

The summer fair starts at 11. By 9.45 the coordinator is on her third lap of the field. The cake stall has its team of three, all of whom signed up via a link on the residents’ Facebook page two weeks ago. The bouncy castle is being inflated by the teenager who runs it every year, this time with two friends from school. The retired teacher who said yes to “any role” has been quietly arranging the tombola prizes and doesn’t need to be told what to do. By 10.30 the volunteers will start arriving for parking, refreshments, and the welcome desk. They will all have the same look on their faces: faintly nervous, definitely on a Saturday morning, here because they were asked nicely by someone they like.

None of this is about software. But all of it depends on a coordination system that didn’t get in the way of any of these people deciding to give up half their day for a fair they don’t actually run.

That’s what makes community events their own kind of coordination. The volunteers aren’t here for a cause they care about, or a career they’re building, or a duty they signed up to. They’re here because their neighbour asked, because their kid is in the dance display, because they like seeing the same people on the same field every year. They’re here on goodwill, and goodwill is fragile in ways the other things aren’t.

This post is about what goodwill requires, what software does for it, and what it can’t.

What goodwill requires

Four things. Each one is a place where the wrong tool, or the wrong message, or the wrong assumption breaks something.

The signup that respects them. The volunteer signing up from a Facebook link has thirty seconds. If the form asks for an account, a profile, a confirmation email, a password reset because they didn’t get the confirmation email, you’ve already lost half of them. The signup has to feel like saying yes to a friend, not joining a system. One screen, their name, the role they want, done. And it has to be their choice, not an assignment. Self-selection isn’t a feature, it’s a sign of trust. The volunteer who picks the cake stall over the parking team because they prefer cake is showing the first piece of evidence that this is their event too, not just yours. The corporate signup form is the first place goodwill leaks; top-down assignment is the second.

The information they need, when they need it. The parking marshal needs to know where to stand and what to say to the cars before 9am, not in a briefing email at 6.30am the day of, and not in a separate document she has to download. The role description lives where she’s already going to look, which is her phone. If she has to ask the coordinator what to do, the system has failed both of them.

The arrival that says they were expected. When the volunteer turns up at 10am she shouldn’t have to wander the field looking for someone. The role lead should know she’s coming, know what role she’s filling, and have somewhere for her to put her bag. The list should match the people. A volunteer who arrives and feels like she’s inconveniencing the coordinator becomes a volunteer who doesn’t come back, even if she finishes her shift. The first fifteen minutes set whether the goodwill she brought lasts the day.

The structure that outlives the coordinator. Half the work of community event coordination is for next year’s coordinator, who isn’t you and might not have met you. The role list, the time slots, the briefing notes for each role, the lessons from last year: all of it has to live in something the next person can open and understand without explanation. A spreadsheet that only made sense to its author is a liability the moment its author moves on.

What software does for each

The signup respects time and choice when the form is short, mobile-first, and free of account creation rituals. Volunteers can browse roles, see what’s still open, and claim what fits. The coordinator stops being the bottleneck for matching neighbours to the cake stall.

Information arrives when the role description is part of the role itself, accessible from a phone, not a separate document the volunteer is expected to download and remember. Each role carries its briefing inside the task.

The arrival lands well when the role lead has the list of who’s coming, when the role description includes where to find the team, and when the day-of reminder sounds like a friendly nudge rather than an automated confirmation. Software handles the logistics of being expected. The welcome itself is yours.

The structure outlives the coordinator when it lives in a tool that anyone on the committee can open. Last year’s role list, last year’s notes, last year’s lessons: all of it carries forward without a handover meeting that may or may not happen.

These are real features doing real work. Worth choosing carefully. Also: a smaller part of the actual coordination than the brochures imply.

What software can’t do

Software can’t recreate the friend-of-a-friend asking the retired teacher to come help. That’s recruitment as relationship work, done in WhatsApp groups and at the school gate and by the secretary who knows everyone. Software gives the form the teacher fills in once she’s said yes, and holds the record so next year’s coordinator can ask her again.

Software can’t put the apron on the volunteer when she arrives, or introduce her to the team, or tell her where to put her bag. That’s the role lead doing role-lead work, in person, in the moment. Software puts her on the right list, shows the role lead who’s coming, and gives the briefing she read before she got here. The first ten minutes of the shift are theirs.

Software can’t tell the cake stall lead that the woman who’s just shown up is actually the chair’s mother-in-law, who has views about how the cakes should be displayed. That’s social information that lives in the committee, not in any database. Software gives the role description she’ll see, and the activity feed where she can ask if she’s confused.

Software can’t have the conversation with the volunteer who’s been doing the parking marshalling for eight years and isn’t sure she should keep doing it because of her knees. That conversation is yours, and the answer matters, not just for her but for what you’re modelling about how the community treats its long-time givers. Software holds the record of what gets decided. The talk itself is yours.

Software can’t bridge the gap between the outgoing coordinator and the incoming one when they don’t know each other. That’s a coffee, a phone call, a deliberate handover meeting that has to be made to happen. Software holds what’s been written down during the year, which makes the meeting shorter and more useful but doesn’t replace it.

Software can’t replace the moment after the event when the committee has tea together and knows the day went well. That’s the renewal of the goodwill that makes next year possible. Software has nothing to add to that moment, and shouldn’t try.

This is most of the work. The coordinator who lasts in this role is the one who keeps the signup short, trusts volunteers to choose, puts the briefing where the volunteer can find it, makes sure she’s expected when she arrives, and writes things down so the next coordinator doesn’t start from zero. The one who has the conversations software can’t have, and who lets the post-event tea be what it is.

None of which is a setting you can configure. All of which software can support without replacing. Where the line falls determines whether the volunteer comes back next year, whether the next coordinator inherits something workable, and whether the event runs five years from now without the same person carrying it every time.

How to think about choosing tools

Pick something simple. The tool that makes sense to a sixteen-year-old volunteering with friends and to a retiree volunteering for the first time is the tool that works for community events. Anything that requires explanation costs you volunteers.

Free or close to it makes sense. Community event budgets are small. Tools that charge per volunteer or per event become a tax on goodwill itself, paid by the committee that’s already doing this for free.

Mobile-first is non-negotiable. Volunteers sign up from their phones, check their roles from their phones, message you from their phones the morning of. If the experience is built for desktop, the experience is built for the wrong people.

Boring is good. The tool that runs the same way every year is the tool the next coordinator can pick up. The clever feature you turn on this year is the feature the next coordinator can’t figure out and works around.

Where Zelos fits

A short note, because the post’s whole argument is that the tool isn’t the event.

Zelos is built around a signup that takes seconds and doesn’t punish the volunteer for wanting to help. Volunteers see the available roles and time slots, claim what fits, and see the role description right there in the task. There’s no account creation ritual standing between the link and the yes. The committee can open the workspace and see what’s set up, what’s claimed, and what last year’s structure looked like. The structure carries forward without a handover meeting that has to happen and often doesn’t. All messaging is admin-supervised, by design, which is the right shape for community events that include children alongside adult volunteers. The free plan covers unlimited volunteers and 25 active tasks at a time, which is enough for a community fair, a Christmas market, or a multicultural day without paying anything.

It is not the event. The event is what you build with it across the people you’ve asked nicely to give up a Saturday. You can explore the product or start a free account and try it on the next thing you’re running. The work, either way, is yours.