Most humanitarian volunteer coordination happens between crises

Saturday afternoon, 47 hours since the call went out. The reception centre is operational. Eighty volunteers across twelve roles. The medical triage station has two qualified clinicians and a Farsi-speaking translator. Registration is processing arrivals at twelve per hour. The supply distribution lane has its lead, its briefing, and stock that came in overnight. The activity feed has been updated four times today as conditions on the ground keep shifting. The first family came through the door at 2pm. They were met in their language, by someone who knew what they were doing.

None of this happened today. None of it happened in 47 hours. It happened over the four years before the call went out, when the organisation now running this reception centre maintained a coordination capacity for a crisis it didn’t know was coming.

That’s what makes humanitarian volunteer coordination its own particular kind of work. The visible part, the surge, the 48 hours that goes well or doesn’t, is the smallest part of the job. The actual work is the dormancy: the months and years when nothing’s happening but the coordination capacity has to stay alive, ready, and calibrated for a crisis that might be tomorrow or might be three years away.

This post is about both halves of the work, what software does for each, and what it can’t do for you.

The two states

Dormancy

Three things to do, none of them urgent, all of them necessary.

Maintain the pool deliberately. Volunteers who signed up two years ago aren’t necessarily volunteers now. Some have moved cities. Some have changed careers. Some have lost interest. Some are now busier with their own families and aren’t actually available for deployment. The pool that’s “120 people on a list” might be 25 people who would actually answer the call. The work is staying in light, occasional contact, doing periodic availability checks, knowing who’s actually deployable. A pool you haven’t checked in with in a year is a pool you don’t have.

Keep skills calibrated. Volunteers who haven’t deployed in three years aren’t necessarily trained anymore. Certifications expire. Skills atrophy. New situations call for new training. The work is running modest, regular touchpoints (briefings, simulations, refresh sessions) that keep the pool genuinely capable of doing the work they signed up for. Not military drills. Practical, periodic refreshers that respect that volunteers have other lives.

Build the systems before you need them. The mobilisation flow, the role structure, the decision authorities, the partner agency contacts. All of this has to exist on the morning the call goes out. Building it during the crisis is too late. The work is designing and stress-testing the systems during dormancy, when there’s actually time to think. The first activation should not be the first time the system has run.

Surge

Three things to deliver, all under load.

Mobilise in hours, not weeks. The window between need and staffed is small. Volunteers who can see a need and confirm in one step will sign up. Volunteers facing a multi-step onboarding flow won’t, especially the ones already managing their own travel and logistics to reach a deployment site. The work in a surge is removing every step that doesn’t have to be there while keeping the steps that do: skill verification, safety briefings, the basics of duty of care. The systems built in dormancy make this possible. Building them now isn’t an option.

Get the right people to the right roles. A general volunteer cannot cover for a credentialed medical professional. A trauma-informed responder is needed for some roles and not others. The right Farsi speaker has to be at the right reception desk. Differentiation isn’t bureaucracy; it’s the difference between people getting helped well and getting helped badly. The work is routing people quickly and accurately to roles that match their qualifications, even when the temptation to fill any open slot with anyone willing is intense.

Hold duty of care under pressure. Volunteers in disaster response carry weight. Some will be seeing things that affect them. Some are making decisions about other people’s vulnerability without much support. The work is protecting volunteers from being overwhelmed: rotation, debriefing, rest, supervision, the option to step back. Coordinators who skip this in the rush of the surge pay for it later, in burnout, in trauma, in volunteers who don’t come back for the next deployment.

If you’re scrambling

Some of you are reading this with the call already going out. Some of you are six months into building a coordination capacity that didn’t exist before. Some of you are the volunteer who’s just been asked to coordinate the volunteers because nobody else will. The framework above assumes years of dormancy work. Most coordination capacities aren’t built that way. Most are built in the middle of something.

A few things help.

Start with what exists. The contact list from the previous campaign. The partner org with the volunteer database. The community group that’s been quietly running for years. The volunteer in your pool who’s deployed with three other organisations and has seen the playbook from multiple angles. You’re not actually building from zero, even if it feels that way. Most crises pull existing networks toward them, and the work in the first 48 hours is identifying which networks you have and connecting them. Other coordinators in the sector will share what they know if you ask.

Triage the readiness work. The full dormancy framework above takes years. The minimum-viable version takes days. You need a way to differentiate volunteers by skill (a tagged spreadsheet works for now). You need a way to broadcast a need to a group (an existing channel works for now). You need a basic role structure with compliance gates on the high-risk roles (a one-page document works for now). Build the rest as you go.

Accept the trade-offs out loud. A scramble response will have gaps. You’ll route some volunteers to roles that aren’t perfect for them. You’ll send messages to people who haven’t been onboarded properly. You’ll make duty-of-care calls without enough information. The work isn’t pretending you have full readiness. It’s being clear-eyed about which gaps you’re carrying. Tell your team where the gaps are. They can compensate for what they know about. They can’t compensate for what they don’t.

Build the debrief into the response. If this is your first time, the post-crisis debrief is the start of your dormancy work for next time. Capture the gaps as you go. Note what you wished existed when you were scrambling. The dormancy framework you’ll have in three years is what you’re writing down now, in pencil, between shifts.

What software does for each state

Software supports each state differently and shouldn’t be optimised for one at the expense of the other.

In dormancy, software does little, and that’s what you need. A volunteer database that’s actually accurate. A way to push a quiet message every few months without the whole pool thinking they’re being deployed. A record of who’s done what training, when their certifications expire, who’s done what deployments. A place where the role structure and the mobilisation templates live, ready to be activated. The tool should hold value while doing almost nothing. If you’re spending more than an hour a month in it during dormancy, something’s wrong.

In a surge, software earns its place. Broadcast a need and capture signups in a single step. Groups separate qualified medical from general volunteers, separate language pairs from each other, separate one role from the next. Tasks for credentialed roles are visible only to the credentialed. The activity feed posts updates as conditions change, visible to everyone deployed. Push notifications reach exactly the volunteers affected by a specific change. The systems set up in dormancy do their work without needing to be invented in the moment.

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 maintain the relationships that make people actually answer the call when it goes out. That comes from years of staying in occasional, genuine contact, knowing your people, treating them as more than a list. Software holds the records that make those check-ins easier and tracks who’s heard from you and when.

Software can’t do the multi-agency negotiation about who’s responsible for what when several NGOs and government emergency services are working the same response. That’s coordinator-to-coordinator conversations, often on first-name terms built up before the crisis. Software provides the shared visibility that supports those conversations and reduces the chance of duplicated effort or dangerous gaps.

Software can’t match a volunteer to a role with the kind of judgment that requires reading a person. The volunteer who’s medically qualified but hasn’t deployed in two years and may not be the right call for the most demanding triage role this weekend. That’s the coordinator’s read, often made in minutes, often with incomplete information. Software surfaces the data (skills, deployment history, last training) that informs the judgment without making it.

Software can’t identify the volunteer who’s getting overwhelmed and needs to be rotated out before they break. That’s pastoral work, often done by someone who knows the person and notices what’s changed. Software flags some patterns (longer shifts, repeated difficult deployments) but the noticing is human.

Software can’t have the duty-of-care conversation when someone needs to step back from a role mid-deployment. The volunteer who realises after one shift at the hospital that this isn’t sustainable for them right now. That conversation is yours, often without much language for what you’re trying to protect. Software holds the record of what was offered and what was decided.

Software can’t navigate the trust dynamic with beneficiaries. The volunteer who can sit with a family that’s been through something terrible, who can do that with dignity and presence, who knows when to speak and when to be quiet. That’s the coordinator’s recruitment and training work, done over time. Software stays out of the way of those moments. It can hold the briefing notes that prepare a volunteer for what they’ll encounter. The encounter itself is theirs.

Software can’t replace the post-deployment debrief that captures lessons before they fade. The meeting where the team that just stood down shares what worked, what didn’t, what nearly went wrong. The kind of conversation that has to happen within a few weeks of teardown or it never happens. Software holds what’s written down. Writing it down is human.

Software can’t carry the coordinator’s own load. The weight of being responsible for both volunteers and beneficiaries. The moral weight of the decisions made under pressure, often with incomplete information. The post-crisis recovery that often gets pushed aside because the next crisis is already brewing somewhere. This isn’t a thing software can support. Other coordinators see what software can’t. That’s why the people who do this work for years either find a peer network or don’t last.

This is most of the work. The coordinator who lasts in this role is the one who maintains the pool deliberately during dormancy, builds the systems before they’re needed, mobilises in hours when the call goes out, gets the right people to the right roles, holds duty of care under pressure, and looks after themselves in a job that asks for more than is reasonable to ask.

None of which is a setting you can configure. All of which software can support without replacing. Where the line falls determines whether the response runs reliably, whether the same volunteers come back for the next deployment, and whether the organisation is still standing in five years to respond to the crisis after that.

How to think about choosing tools

Pick something that does its slice well and doesn’t pretend to be the response.

Mobile-first is non-negotiable. Volunteers are signing up from their phones during a crisis, often while moving between locations, often with intermittent connectivity. If the experience requires a desktop or a strong connection, you’ll lose people you can’t afford to lose.

Push notifications, not email. Email is too slow for crisis conditions. The communication tool needs to be in the volunteer’s pocket with notifications that reach them immediately when something changes.

Sustainable through dormancy. Most humanitarian organisations have a near-zero active volunteer count for months at a time, then need to scale to hundreds overnight. A tool that requires constant engagement to stay functional, or that charges in a way that punishes a dormant pool, is the wrong tool for this sector. The right tool holds value while doing almost nothing, and is ready when the call goes out.

Free or close to it makes sense for most organisations. Humanitarian groups are generally running on tight budgets. A tool that holds the volunteer pool, runs role-gated mobilisation, and provides real-time communication during a surge is what’s needed. Nothing more.

Boring is good. The tool that runs the same way every deployment is the tool the volunteers can use under stress. The clever feature you turn on for the first time during a crisis is the feature that breaks at the worst possible moment.

Where Zelos fits

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

Zelos handles the pieces software handles across both states. In dormancy, the workspace holds the pool’s records and lets you push occasional messages without spinning up new infrastructure. Custom profile fields hold qualifications, certifications, languages, and deployment history. Groups separate qualified roles from general ones, and one mission area from another. The systems wait, ready, while nothing’s happening.

In a surge, broadcasts reach the right groups in one step. Tasks are visible only to volunteers who match the role’s requirements. Self-signup means people see what’s needed and claim what fits, without a coordinator manually assigning anyone. Push notifications reach exactly the volunteers affected when conditions change. The activity feed gives everyone deployed a shared, real-time picture of the response. All messaging is admin-supervised, by design, which is the right shape when volunteers and beneficiaries include vulnerable people in difficult circumstances. The free plan covers unlimited volunteers and 25 active tasks at a time, which is enough to run most surge deployments without paying anything. There are no per-seat fees, ever, which means a dormant pool of hundreds doesn’t punish your budget between crises.

It is not the response. The response is what you build with it across the years that run between calls. You can explore the product or start a free account and try it on the next quiet stretch. The work, either way, is yours.