Notes, November 2026

A volunteer group’s tech doesn’t break all at once. It drifts, one handover at a time.

I’m a parent volunteer at a Scout group in Bristol, and this year I rebuilt its website and connected the join form straight into the system the leaders use. That job is written up in the 77th Bristol Scouts case study. This note is about the part that wasn’t really about the website, because what I found isn’t particular to that group. I’d expect to find most of it at any club, charity or group that’s been run by volunteers for ten years or more.

Nothing I found was anybody’s fault, and nothing was leaked. It’s what happens to the tech when the people looking after it change every few years and each of them does a good job of the bit they inherited.

Nobody owns the whole thing

When I was asked what annoys me about how small charities and volunteer groups end up with their tech, my answer was that it’s mostly a problem with churn of volunteers and ownership. Over time trustees come and go, and that makes it quite difficult for anybody to have long-term ownership of something like the website and the systems behind it.

Somebody sets up the web address. Somebody else builds a form a few years later. A third person starts a spreadsheet because the form’s answers needed to go somewhere. Each decision makes sense on the day, and nobody’s ever in a position to look at all of them together, so nobody notices when they stop fitting.

What I check first, in this order

1. Who owns the web address. At the group I work with, it was registered in the personal account of someone who’d long since moved on, so nobody currently involved could manage it or be sure it would renew. That’s common, because the person who sets it up usually uses whatever account they’ve already got. If it lapses, the website and usually the email go with it. It now sits in an account the group controls. When I moved it, I moved only the two records the website needed and left every email record where it was, so the group’s email didn’t drop for a minute.

2. What every form collects, and where it goes. The privacy policy had been written for the Christmas tree sale, while the join form, which had grown up separately, was collecting children’s names, dates of birth and home addresses. Neither was wrong when it was written. They’d just never been read side by side. I’d list every form on the site, what it asks for, and where the answers end up, and then check the privacy policy covers all of it.

3. Whether sensitive details travel by email. Medical and dietary details used to arrive by email, so they lived in personal inboxes and spreadsheets. The honest consequence is that if a parent had asked what the group held on their child, or asked for it to be deleted, nobody could have answered accurately. The fix wasn’t a new tool. The system the group already uses has a secure parent portal, so the new form doesn’t ask for medical details at all, and parents enter them straight into their own child’s record.

4. Which list is the real one. There were two waiting lists that disagreed with each other. Thirteen rows were struck through as already joined or no longer interested, and for six of them the strikethrough was the only record of it, so a straight import would have put six children back on the list who’d already left it. I made 182 fixes on the way through and logged every one with its before and after. I left four phone numbers visibly wrong rather than guess, because guessing a digit in a parent’s number is worse than leaving it obviously broken for someone to ask about.

5. Whose login everything runs on. It’s normal for a website or a form to be connected using one volunteer’s own account, because that’s what was to hand. Then that person leaves, or changes their password, and something stops working and nobody knows why. When I connected the new form to the group’s system, I gave the website its own login that can only see the waiting list. I deliberately didn’t use a leader’s account, because if anything went wrong I didn’t want it to be the group leader who got locked out of the system the whole group runs on.

What I’d suggest to a committee

None of this needs a big project or anything new bought. What it needs is one person, once, looking at the whole set-up rather than the bit they look after, and then a single page that says where the web address is registered and who can get into it, where each form sends its answers, and whose logins things run on. That page is what gets handed over next time, so the next person inherits a picture rather than a puzzle.

I’m not a lawyer, and where something looks like a question about the law rather than the set-up, I’d say so and suggest the group asks someone who is. Most of what I find is the set-up, and that part’s fixable.

Who this is for

Committees, trustees and volunteers at clubs, charities and groups that have been going long enough for the people who set things up to have moved on. It’s the same work I do for businesses, where a form, a CRM and a spreadsheet have grown up separately and nobody’s sure which one’s right. That’s the systems work, and the contact page is the place to start.

Run a club, a charity or a group?

Tell me what you’ve inherited and what’s bothering you about it, and I’ll tell you what I’d want to look at first.

Get in touch