Taking the copy and paste out of joining the Scouts

Where it started

Scout groups across the UK run on Online Scout Manager, or OSM, which holds every young person’s record, the waiting lists, the parent portal and the rest. The leaders know it well. What they didn’t have was a good way to get new families into it.

When I got involved, joining worked like this. A parent emailed, and a leader went back and forth with them collecting details, typed those details into an Excel spreadsheet, and then copied and pasted each field into OSM by hand. That’s time-consuming, repetitive and boring, and it takes up the time the leaders need to run the group.

That’s the part that frustrates me most, because the value in what leaders give sits in their ability to run the evenings. That’s what makes a difference to the children, and the administration is just a necessary evil so everything runs smoothly. When I see leaders spending their time copying data from a waiting list into OSM, which takes a huge amount of time and doesn’t need to, it frustrates me immensely.

It isn’t anyone’s fault. Every Scout group has a mix of people, some technical and some not, and they all do what they can to make things work. But you’re rarely going to find one volunteer who can handle the whole thing, from the website to the connections to OSM, and so the gaps between the systems get filled by people copying things across.

The first fix, in 2025

My first go was a better form. I built a join form in JotForm that collected everything the leaders needed, sent the answers into a Google Sheet, and set up OSM so the columns lined up and the leaders could import a batch at once. I recorded a walkthrough so they’d know how to do it.

It was better than typing, but when I counted the steps in my own walkthrough it came to 11 for each batch. Download the sheet as a CSV, open it in Excel, delete every row you’re not importing, save it, then go into OSM, find the import screen, upload the file, check the mapping, untick two fields that would otherwise make it fail, and click import. After that, each child still needed their lodge and status setting, and sometimes their dates correcting. My walkthrough hit the error on the two fields I’d forgotten to mention, and I built it. A leader doing it on a Friday night after a meeting was always going to find it harder.

It also left a copy of children’s details on whichever laptop did the import, every time, and all the applications sat in a shared spreadsheet. The form was on a separate site too, so “Join us” took parents away from the group’s website to finish.

What I built this time

A new website, and a join form on it that sends each application straight into the OSM waiting list the moment the parent presses send.

I love simplicity, and I’d rather use the functionality of the systems that are already there than add middlemen, because every extra tool adds steps that can go wrong and complicates the whole process. OSM was already where applications needed to end up, and the leaders already knew it, so the job was to get the form talking to OSM directly and take out everything in between. There’s no spreadsheet in the middle any more, and no import, and there’s nothing new for leaders to learn.

The form. It works out which section a child belongs in from their date of birth and tells the parent straight away. It’s five short steps instead of ten pages, and 16 required fields instead of 50. Where there’s a sibling already in the group, or a parent offering to volunteer, that goes to OSM as well, in the fields the leaders already use. The right section leader gets an email, with the group inbox always copied in so nothing depends on one person.

Collecting less. The new website collects no medical, allergy or dietary information at all. Parents enter it themselves, straight into their own child’s record in OSM’s Parent Portal, which is secure and which they can keep up to date. The form and the confirmation email both make it clear that a place isn’t confirmed until they’ve done it. That information never passes through anybody’s inbox now, which I think matters more than any number on this page.

A safe connection. The website connects to OSM with its own login, which 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.

A safety net. If OSM ever refuses an application or can’t be reached, the website doesn’t lose it. It emails the full details to the group inbox, marked as needing action, so a person can add it by hand.

The website around it. A page for each section, a page explaining the Parent Portal to families before they’re invited to it, a contact form, and the Christmas tree page, which is the group’s biggest fundraiser and now has this year’s prices and working payment links before the sale opens on 28 November. It’s built to load quickly and to work for everyone. The old homepage stopped people zooming in on their phones. My own first version failed seventeen colour-contrast checks, because the Cubs green and the brand teal are too light for small text on white, and the same test that measured the old site caught them, so I added darker shades for text and buttons before launch.

What a decade of handovers leaves behind

This part isn’t about the 77th in particular. It’s what happens to any organisation run by volunteers over ten years or more, and I’d expect to find most of it at any club, charity or group that’s been going that long.

The problem is mostly churn. Trustees and committee members come and go, and that makes it quite difficult for anyone to have long-term ownership of something like the website and the systems behind it. Each person does a good job of the bit they inherited, and nobody is ever in a position to look at the whole thing at once.

Here’s what that looked like when I did look at the whole thing. 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. Medical and dietary details arrived by email, so they ended up in personal inboxes and spreadsheets. And the group’s web address was registered in the personal account of someone who had long since moved on, so nobody currently involved could manage it or be sure it would renew.

Nothing was leaked, and nobody did anything wrong. The risk was in the structure. 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 answer was spread across inboxes, a spreadsheet and a form service.

As well as the website, a new privacy policy covering everything the group actually collects went up on 4 November. The medical details now live only in OSM. The web address is in an account the group controls.

Moving the waiting list

The last job before launch was moving the existing waiting list into OSM, so the new form wasn’t starting next to an old spreadsheet.

There were two lists that disagreed with each other, a main one of 42 children with contact details and a second of 15 names with notes. 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. It doesn’t survive an export, so a straight import would have put six children back on the waiting list who’d already left it.

I made 182 individual fixes on the way through and logged every one with its before and after, including 83 phone numbers, 28 postcodes, 44 address lines, 13 names in capitals and one mistyped email address. 29 children went into OSM on 5 November and I checked them afterwards. I left four phone numbers visibly wrong rather than guess, because guessing a digit in a parent’s phone number is worse than leaving it obviously broken for someone to ask about.

What the numbers say

The step counts come from the walkthrough I recorded for the leaders in September 2025. The old site was measured on 19 September 2026 and the new one on 5 November, the day it went live, both in a browser and both through Google’s PageSpeed test. The old homepage only loaded its images as you scrolled, so its weight may be an undercount, and the new one was measured after scrolling to the bottom. The three outside services the join page still uses are Google’s fonts and Cloudflare’s spam check. The PageSpeed figures are from Google’s simulated phone, and I’ve kept to the mobile ones because the old homepage scored 93 on desktop and putting the two side by side would flatter the result. Scores move by a few points between runs, but a page that took 7.7 seconds to show its main content now takes 2.5, and that’s not noise.

The number I care about most doesn’t fit in the table, which is the evenings the leaders get back. It isn’t a huge number of hours over a year, and I’m not going to dress it up as one, but it’s volunteer time, and volunteer time is the one thing a group like this can’t buy more of.

How it was built

The site is a fast static website on Cloudflare, and the join form is handled by a small piece of code that checks the application, places the child in the right section, sends it to OSM through its API, and emails the parent and the section leader. Emails go through a proper sending service so they don’t end up in junk. On launch day I sent two real applications through the live form, one Cubs age and one Scouts age, checked every field that landed in OSM, and deleted them afterwards. Both showed as changed by the website’s own waiting-list login rather than a leader’s account, which was the point.

Moving the web address meant moving its registrar and its DNS, and the group’s email didn’t drop for a minute, because I moved only the two records the website needed and left every mail record where it was. It runs at close to no cost for the group.

What this looks like for you

If you’re a charity or a volunteer-run group, the chances are someone is copying information from one place to another every week, because the website and the system you actually work in have never been connected. It’s also likely that nobody has looked at the whole set-up in years, because nobody’s been there long enough to. That’s usually fixable without buying anything new, because the system you already use has a way in, and the work is building the bridge and doing it carefully.

If you’re a business, it’s the same job with bigger numbers. A website form that feeds straight into your CRM, your booking system or your case management, with nobody re-keying it, is the same piece of work as this, and the same principle applies: use what you’ve got if it works, and take out the steps in the middle rather than adding more.

Between them that’s the website and the systems, and the contact page is where to start.