How to Hand Off a Swim Club Board Role

Every volunteer-run swim club eventually asks the same question: what happens when the person who's been quietly running this for three years finally steps down? Board roles at member-owned clubs turn over constantly, often every year or two, and the quality of that turnover determines whether the next season starts smoothly or starts with three weeks of forwarded emails and best-guess reconstruction. This guide is a practical starting point for handing off a board role well, whether you're the outgoing volunteer, the incoming one, or the board chair trying to make sure neither of you has to improvise.

Why board handoffs fail in volunteer-run clubs

The common failure mode isn't malice or neglect, it's structure. A volunteer board role tends to accumulate its own private system over time: a personal email folder of vendor threads, a spreadsheet only one person edits, login credentials nobody wrote down, a mental model of "how renewal season actually goes" that was never captured anywhere. None of that is anyone's fault. It's just what happens when a real operational role runs informally for long enough.

The problem shows up the moment that person leaves. Their replacement doesn't inherit a system, they inherit a gap, and they usually discover the size of that gap at the worst possible time: mid-renewal season, mid-dispute, or mid-emergency, when there's no time to reconstruct three years of undocumented decisions from scratch.

What to hand off: accounts, vendor relationships, the renewal calendar, open exceptions

A complete handoff covers more than most outgoing volunteers think to mention unprompted. At minimum:

• Account access. Every system the role touches: banking, payment processing, email, the club's website or membership platform, shared drives. Transfer or re-provision access; don't hand over a personal password.

• Vendor relationships. Who the club's pool service, insurance broker, lifeguard staffing agency, and any other regular vendors are, and who the actual point of contact is at each.

• The renewal calendar. When notices go out, when dues are due, when the waitlist typically moves, and what depends on what. A calendar that lives only in the outgoing volunteer's head isn't a calendar the club owns.

• Open exceptions. Any member currently getting a payment extension, a waived fee, or a pending resignation under review. These are exactly the items most likely to get dropped in a handoff, because they're mid-flight rather than filed away.

• Where documents live. Bylaws, meeting minutes, the current membership roster, past correspondence templates. If the honest answer is "in my personal inbox," that's the first thing to fix.

• Communication templates already in use. The renewal letter, the dues-increase letter, the welcome email. Reusing what already works is faster than reinventing it under time pressure.

A handoff packet template

A short, written packet turns an oral tradition into something the next three volunteers can actually use. A workable starting point:

Board handoff checklist
[ ] Bank and payment-processor account access transferred
[ ] Vendor contacts (pool service, insurance, staffing) listed with names
[ ] Renewal calendar dates for the upcoming season documented
[ ] Open waitlist offers and their status listed
[ ] Pending relinquishments or resignations in progress listed
[ ] Document library location shared (bylaws, minutes, templates)
[ ] Communication templates (renewal, dues-increase, welcome) handed over
[ ] Prior year's exception list (extensions, waivers, disputes) reviewed together

Walk through this list together, outgoing and incoming volunteer, rather than emailing it as a one-way document. A live walkthrough surfaces the context a checklist alone can't.

Timing it against your renewal season, not the calendar year

Many clubs elect or rotate board roles at an annual meeting that falls at a fixed point on the calendar, regardless of where that lands relative to the club's actual operating season. That's a reasonable governance choice, but it has a real cost if the timing puts a brand-new treasurer or membership chair in charge right as renewal season opens. Where your bylaws allow it, consider overlapping outgoing and incoming volunteers for a defined window that spans at least one real operational cycle: one renewal season, one camp registration period, whatever the role's busiest stretch actually is. A handoff that happens on paper in June but only gets tested for the first time in September, under pressure, is a handoff that hasn't really happened yet.

What "institutional memory" should live in the system, not a person's head

The deepest fix here isn't a better checklist, it's reducing how much of the club's operating knowledge depends on any one person remembering it. A few practical habits help:

• Keep a running, dated log of nonstandard decisions (a fee waived, an exception granted, a policy interpreted a particular way) somewhere the whole board can see it, not in a personal notebook.

• Prefer systems that record who did what and when over systems that require someone to remember and re-explain it later.

• Treat every "ask [outgoing volunteer] about that" as a signal that something needs to be written down before they leave, not after.

How Swim Ops handles this

Swim Ops was built to reduce exactly this kind of single-person dependency. Every account, role, and permission change writes an entry to an audit log — an append-only record of who changed what and when, kept separately from any one person's memory or inbox — so "who changed the late fee" or "when was this household's exception granted" has a real answer months later. Role-based access means an incoming volunteer gets exactly the access their role needs on day one, without inheriting someone else's personal login. See the back office page for the full picture of what stays with the club, not with any one volunteer, or talk to us about board continuity for your own club.