Peer support coordination is mostly about speed

Tuesday, 9.14am. A request comes in. The form was filled out at 2am the night before, by someone who couldn’t sleep, who’d been carrying something for weeks, who finally clicked submit and went to bed not expecting much. The system instantly surfaces the request to the seven peer supporters qualified for what was described. By 9.37am, the first one accepts. By Tuesday afternoon, a session is scheduled for Thursday evening. Two days, not two months.

NHS waiting lists for mental health often run weeks or months. In England, NHS Talking Therapies for anxiety and depression (formerly IAPT) is the commissioned clinical pathway for common anxiety and depression — NICE-recommended talking therapies, not volunteer peer support. By the time professional help arrives, the moment has often passed: the person hasn’t actively asked in three weeks, hasn’t slept in five, has either deteriorated or armoured. Peer support and befriending exist in the gap. Their operational value is speed: getting a qualified human to the person reaching out before the moment closes.

That is not the same as BACP-registered counselling. The British Association for Counselling and Psychotherapy is the professional association for the counselling professions; its Register is how the public finds practitioners who meet those standards. Volunteer peer support, listening, and befriending are a different job. A peer supporter is not assessing, diagnosing, or providing therapy. Someone in crisis can call Samaritans free on 116 123; that is a listening service staffed by volunteers, not a clinical record and not a substitute for 999. Coordination software has to keep that distinction visible in the role, not bury it.

That’s what peer support coordination is mostly about. The work is dispatch under pressure: match the right qualified person to the person in need, within hours of asking. The work takes different shapes depending on the model. Crisis helplines run on shifts, with listeners on-call for whatever comes in. Most peer support runs on scheduled sessions, with a request coming in and a session happening within days. The dispatch problem is the same shape in both. Time-to-help is the metric.

Find a match in hours, not days

The mechanism is straightforward when it’s built right. A request arrives. The system instantly notifies everyone qualified for it. The first to accept gets the session. People choose; software doesn’t assign. Email-and-phone administration breaks at any volume. Manual assignment by a coordinator becomes a bottleneck the moment the coordinator sleeps. This is the part software does well, and it’s where most of the speed comes from. Teams without a dispatch mechanism are usually the ones with two-week turnaround they can’t explain.

A simple system designed in advance

The matching system has to be designed before peer supporters are onboarded, so any incoming request automatically narrows to the right group. Focus on the dimensions that matter operationally: language (which the team’s volunteers cover, and in which combinations), training specialism (grief, suicide and safety planning, trauma, addiction, general support), and lived experience (recovery, bereavement, the situation someone’s in). Each becomes a segment in the system. A request from a Russian-speaking parent dealing with bereavement narrows to volunteers who match all three. Less granular and matching breaks; more granular and no one’s available. Most teams settle into three or four overlapping data points and learn to live with the tension. When the match is one volunteer to one person over time, not just dispatch to the next available session, you need client records in the system, not just volunteer profiles. Volunteero pairs named volunteers with named clients and runs the screening pipeline before they reach active missions. See Volunteero vs Zelos, compared in detail for where that depth wins and where instant dispatch fits instead.

A pool with real availability

Fast dispatch needs volunteers actually around to pick up. Engagement varies more than most volunteer coordination expects: some take a session or two a month and have for three years, others pick up ten in a busy week and none the next. The pool’s responsiveness depends on breadth, not depth. Ten people picking up two sessions each beats two people picking up ten. The coordinator’s job is maintaining a pool wide enough that any dispatch finds someone available, and reading the patterns: who’s gone quiet, who’s overcommitting, who needs a private message asking how they’re doing.

A pool that keeps showing up

Dispatch only works if the pool sustains. This is where wellbeing becomes operational: not a side concern, but what keeps speed possible six months from now.

• Training that’s tiered (formal qualification, plus programme-specific training, plus supervised practice before going live).
• Supervision that’s private (a direct message, not the group thread, asking how someone is after a hard session).
• Scope that’s clear (peer support isn’t therapy, isn’t assessment, isn’t crisis intervention beyond what training covers).
• Safeguarding that’s structural: the right level of DBS check in England and Wales where the role is eligible (PVG in Scotland, AccessNI in Northern Ireland), and a clear path for when a conversation needs to escalate. Companionship befriending is typically eligible for a basic DBS check, not automatically Enhanced with the Adults’ Barred List.

Volunteers who burn out are usually volunteers whose scope crept, whose supervision was insufficient, or whose training didn’t prepare them for what came through the door.

These are the four pieces the volunteer-coordination layer particularly has to hold. The post leaves to one side documentation and case notes, escalation protocols for active risk, recruitment and screening, and the specifics of vicarious trauma. Each is its own work.

What software can’t do

Software does the dispatch mechanism well, holds the matching infrastructure, tracks capacity patterns, and gates compliance. That’s a real contribution. It’s also a smaller part of the actual coordination than the brochures imply.

Software can’t have the supervision conversation when a volunteer is heading toward burnout. The direct message that opens the door is something software supports. The conversation itself, often quiet, often slow, often the thing that lets someone admit they need to step back, is yours. The cost of getting this wrong is the pool collapsing, which is the cost of dispatch slowing down six months later.

Software can’t read whether a volunteer’s “I’m fine” is the kind that means actually fine or the kind that means I need more support than I can ask for. Software can flag the signups that have changed (fewer this week, none for two weeks). The noticing of what those changes mean is human.

Software can’t replace the debrief after a particularly hard session. The volunteer who’s just finished a session involving active suicide ideation needs someone to talk to, sometimes immediately, sometimes the next day. Software holds the contact information that makes the call possible. The call itself is human.

Software can’t carry the coordinator’s own load. Most peer support coordinators are also volunteers, or have been. They carry the weight of being responsible for a team that’s holding other people’s worst days. The relationship with another supervisor, the peer network of other coordinators in the sector, the supervision the coordinator gets, none of this is software-shaped.

This is what makes fast dispatch possible across years rather than months. The coordinator who keeps the system working builds the dispatch mechanism, gets matching right, reads the pool, holds training as a structural floor, has the conversations software can’t, and looks after themselves in a job that absorbs more than it should.

How to think about choosing tools

Pick something built for small, careful teams. Peer support rotas typically sit at 10 to 40 volunteers. Tools designed for larger volunteer bases optimise for things this sector doesn’t need (mass mobilisation, public sign-ups, broadcast) at the expense of what it does need (instant dispatch, private supervision, careful matching).

Privacy by default. Invite-only, private messaging on, no public visibility. If the tool requires configuration to keep things private, it’s the wrong tool.

Mobile-first because volunteers mostly accept dispatches from their phones. The notification has to be pickable in seconds.

Free or close to it. Peer support teams usually run on grant funding or charitable budgets. The tool shouldn’t take money that could go to training or supervision.

Boring is good. The tool that runs the same way every week is the tool volunteers don’t have to think about. The cleverness should be in the work, not the software.

Where Zelos fits

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

Zelos is built around dispatch. A request comes in, the system notifies qualified volunteers, the first to accept gets the session. People choose; software doesn’t assign. Custom profile fields hold training dates, certifications, language and specialisation tags. Groups separate volunteers by skill so requests surface only to the right people. Direct messages sit alongside group channels; all messaging is admin-supervised, by design, which is the right shape when teams handle sensitive work. There is no unsupervised 1

. The free plan covers unlimited members and 25 concurrent active tasks. Workspaces are invite-only with no public directory. Zelos is not a clinical record, not a DBS product, and not a training LMS.

A small Estonian counselling consultancy uses this exact pattern to confirm bookings within hours instead of the days or weeks the medical system takes. Their model is contractor-based rather than volunteer, but the mechanism is the same: instant notification, first-to-accept, qualified groups doing the matching in advance.

It is not the infrastructure. The infrastructure is the pool you’ve built and the training, supervision, and scope that keep it sustainable. You can explore the product or start a free account and try it with your team. The work, either way, is yours.