01 / SNAPSHOT
THE PROBLEM
Every event meant managing a workforce from scratch. Applications via Google Form, approvals via manually copy-pasted emails, check-in via spreadsheet, communications with no language support. No continuity between events. No single system anyone trusted.
WHAT I BUILT
The workforce lead went from managing spreadsheets and inboxes to a platform that handles the entire volunteer lifecycle. Every decision in this system was made deliberately, most of them in response to something that broke at a real event.
WHAT CHANGED
ROLE
Sole Designer & Builder
MY CONTEXT
Director of Judges · ATHX. I tested every version of this at live events I was also running.
TIMEFRAME
2025–2026
02 / The Eight Volunteer Roles
Volunteers apply for one of eight roles: Judge, Athlete Support, Bag Drop, Steward, Registration, Equipment, Scoring, and Media.
Seven are open to any volunteer. Media is the only restricted role, and deliberately so. More on that decision below.
Staff access roles sit separately. These determine what platform pages and data each operational person can see: Admin, Workforce Lead, Athlete Support Lead, Registration Lead, Floor Lead, Zone Lead, Endurance Contractor, and ATHX Staff. Floor Leads have broad operational access: floor management, workforce, judge assignments, and athlete queries, to support the workforce lead and handle issues across the event. Other roles are scoped to their specific area. Athlete Support Leads have no access to floor pages. Endurance Contractors access lane updates only. Workforce pages are locked to all non-admin roles to protect volunteer data.
03 / The Problem With the Old Process
Three compounding failures across recruitment, communications, and event day operations.
Volunteers re-entered their details on a Google Form for every event. No profile, no history, no continuity. The organisation had no memory of who had worked before, what role they preferred, or what sizes they needed.
Approval emails were copy-pasted by hand. Before language support was added, emails went out in English only. When translations were sourced manually the assumption was that volunteer language matched event location, English for Germany, French for Paris. That assumption broke immediately with Spanish-speaking volunteers at a Paris event, who received neither a French nor a Spanish email. The manual process had no way to account for it.
There was no system for leads to see who was on their team, who was on a break, who had left, or whether judge numbers were sufficient for the next heat. That information existed only in people's heads and on the radio.
04 / The Decisions That Changed It
The re-entry problem compounded with every event
Volunteers who had worked multiple ATHX events were filling in the same Google Form every time: same name, same sizing, same availability, same role preference. The platform had no memory of them.
I built the persistent profile system before anything else in V2 because without it every feature on top would inherit the same problem. Fill it in once. Apply to any event in one click. The platform now holds over 3,500 profiles. Not one person has filled in the same details twice.
Volunteers were turning up without the right kit or skills
Media was originally handled the same way as any other volunteer role: apply, get approved, show up. The problem was that media volunteers need professional camera equipment and demonstrable photography or videography experience. People were applying without either, turning up to cover an international fitness competition on a phone, and the quality of coverage suffered.
I built a separate media application funnel at V5 to solve this directly. Media applicants submit portfolio details, relevant experience, and their Instagram handle. The ATHX media team reviews submissions on a dedicated dashboard and builds an approved roster. Only volunteers on that roster can apply to work media at an event.
The application itself now sets expectations before anyone commits: this role requires professional equipment and demonstrated experience. That clarity alone reduced unsuitable applications. If a volunteer applies for the roster and is not yet approved, the other seven roles remain open to them.
New features shouldn't punish existing users
When I introduced the media funnel, there was an existing pool of volunteers who had been working as media or had active applications. I had a choice: require everyone to start from scratch, or acknowledge that these people had a relationship with ATHX that predated the new system.
I built a banner that appeared on the dashboards of existing media volunteers and applicants, prompting them to complete the new media application. Their history was acknowledged. Nothing was lost. No one who had already been contributing to ATHX events found themselves locked out by a system change they hadn't been consulted on.
That decision added build time. It was the right call.
Commitment without accountability was a recurring problem
The media team can directly add a roster member to a specific event. When they do, the volunteer must actively confirm their spot or forfeit it.
I added that confirmation requirement after the team raised a consistent problem: people committing to events and not showing up. A media gap on event day is a specific, visible failure: coverage that doesn't happen, moments that aren't captured. The confirmation step introduced accountability at exactly the right moment: when someone is making a commitment, not on the day they fail to honour it.
Copy, paste, send, hope nothing was missed
Before the email template system, approval communications were manual. The risk of sending a judge the wrong WhatsApp group link, or forgetting to include key information for a specific role, was real and recurring.
I built a template system with separate approval, reserve, and rejection templates for each role, in six languages, with automatic selection based on the volunteer's UI language. Approval emails contain the WhatsApp group link specific to the volunteer's role. The template editor has compose and preview tabs, placeholder insertion, and a full audit log of every email sent.
The language automation was a specific decision driven by a specific failure. Before the template system, emails went out in English only. When translations were sourced manually the assumption was that volunteer language matched event location. That assumption broke with Spanish-speaking volunteers at a Paris event who fell outside both the English and French versions. The manual process had no way to account for volunteers whose language didn't match the country they were travelling to for the event.
Automatic language selection based on the volunteer's UI preference removes that assumption entirely. The platform knows what language each volunteer uses. The right email goes out without anyone having to make a judgement call.
Line-by-line approval doesn't scale
As the volunteer database grew, approving applications individually became impractical. I built a bulk approval modal that lets the workforce lead approve large numbers of volunteers in a single action, with role assignment within the same step.
Volunteers on the reserve list receive the same approval email as direct approvals when their spot becomes available. From their perspective the flow is identical. The distinction is timing, not experience.
Visibility without access to data people shouldn't touch
Floor leads and zone leads need to see their team on event day. They do not need access to the backend. I made the decision to build the Workforce Teams Dashboard specifically for leads without admin access, giving them a live view of their team, scoped to what they need to do their job.
Zone leads mark judges off for breaks or competing, keeping counts accurate in real time. The floor lead sees judge count against active lanes and knows immediately if there is a gap, without walking the floor or calling it on radio. Eight panels, one per volunteer role. Break management, competing status, and departure tracking all visible.
The afternoon check-in pass is built into the platform flow. Leads check in their team a second time later in the event day. This confirms who is still on site and working, which matters for payment and gift card eligibility. It is not an afterthought. It closes a gap I identified after building the initial check-in system.
An English-only system would have excluded a significant part of the judge pool
ATHX runs in Paris and Berlin. The judge pool is genuinely international. I built the judge training system in V6 with six languages from the start, not as an addition, but as a requirement. An English-only training system would have excluded volunteers who were otherwise qualified and willing.
Movement standards with count scenarios, a quiz engine with pass/fail scoring persisted to each volunteer's record, and a training readiness panel giving admins visibility across the entire roster before the event. Three UI states per volunteer: not started, in progress, complete.
I added the readiness panel specifically to see how volunteers were engaging with the training content, not just whether they had finished it. Knowing that someone is in progress two weeks before the event is different from knowing they haven't started. That visibility changes what the admin team can do about it before it becomes a problem on the floor.
05 / What I Learned
Design for the People Already There
The grandfathering decision taught me to think about the existing user base before shipping any new feature. It is easy to design for new users. They arrive at the system as you intended it. Existing users carry expectations from the version they already know. Ignoring that creates a two-tier experience where newer volunteers have a cleaner journey than the people who have been contributing the longest. That is always the wrong outcome.
Build for the Ones Who Don't Show Up
The media confirmation requirement is a reminder that design has to account for edge cases with real consequences. Most volunteers confirm and show up. The confirmation step exists for the ones who don't. Building for the edge case made the whole system more trustworthy for everyone.
The Harder Thing Was Obviously Right
The six-language requirement for training was one of the clearest cases where doing the harder thing was obviously the right thing. It took more time to build. It meant the platform worked for the actual community ATHX has, not a hypothetical English-speaking one.
06 / Impact
3,500+
Volunteers in the database, each with a single profile
8
Volunteer roles with separate approval flows and communications
6
Languages for approval emails, training, and UI
0
Google Forms filled in twice
1
Click to apply to any event after profile creation