Writing Your Own Training Content — Style Guide — GoClubPro

Training Module 108 | How to Extend This Library with Club-Specific Modules That Match the House Style

---

What This Guide Covers

This library covers the platform; it cannot cover your club — your ground quirks, your fee amounts, your association's specific rules, your canteen roster. Clubs get the most from the library when they add their own club-specific modules alongside it. This guide is the style manual for doing that: the structure every module follows, the writing rules that keep content usable, and how to slot new documents into the index and the annual review cycle (Module 100).

Primary audience: Club Admins, Secretaries, anyone assigned to write club documentation See also: 100 Training Library Implementation Roadmap · 45 Message Templates

---

SECTION 1: WHEN TO WRITE A NEW MODULE (AND WHEN NOT TO)

Write a club module when:

• The information is club-specific and asked more than twice — "how do we open the clubrooms", "who has the canteen keys", "what's our wet-weather ground for training"
• Your association has rules the generic modules can't know — permit limits, local heat thresholds, finals eligibility
• A club policy needs a practical how-to — the constitution says fees are set by committee (Module 80); your module records this year's actual amounts and payment dates

Don't write a new module when:

• The platform already covers it — link to the existing module instead. A club rewrite of "how to RSVP" goes stale the first time the app changes; Module 03 doesn't.
• It's a one-off announcement — that's a Noticeboard post or Broadcast, not documentation
• It's sensitive per-person information (waivers, medical, discipline) — that lives in member Notes and committee records, never in shared training docs

The test: will this answer the same question for the next person who asks, a year from now? Yes → module. No → message.

---

SECTION 2: THE MODULE TEMPLATE

Every module in this library follows the same skeleton. Copy it exactly — consistency is what makes 100+ documents navigable.

# [Title] — [Club Name]
**Club Module C[NN] | [One-line subtitle: what this covers]**

---

## What This Guide Covers
[2–4 sentences: what's here, who it's for]

**Primary audience:** [roles]
**See also:** [links to related modules]

---

## SECTION 1: [First topic]
[Numbered steps, tables, short paragraphs]

## SECTION 2: [Next topic]
...

---

## VISUAL: [Name of the flow]
[Text diagram of the key workflow]

---

## TOOLTIPS & HINTS
[5–6 one-line memorable rules]

## FAQ
[3–5 real questions, answered directly]

## COMMON MISTAKES
| Mistake | Consequence | Prevention |

## SHORT ONBOARDING SCRIPT
["Read this aloud to a new person" — one paragraph]

## MICRO-TRAINING QUICK TIPS
[5–8 bullet fragments — the 60-second version]

---

*Club Module C[NN] | See also: [links]*

Numbering: prefix club modules with C (C01, C02, …) so they never collide with library numbers, and future library updates can't overwrite them.

Not every module needs every section — a two-page "clubroom opening procedure" might skip the FAQ. But never skip the Quick Tips: the 60-second version is the most-read part of any module.

---

SECTION 3: WRITING RULES

The Seven Rules of the House Style

1. Lead with the action. "Broadcast the cancellation, then update the Schedule" — not "It is important that communication occurs."
2. Steps are numbered and start with a verb. Navigate, tap, enter, save. One action per step.
3. Name the exact UI labels. "Settings → Fee Configuration", not "the fees area". If the button says Enter Result, write Enter Result.
4. Tables for comparisons, prose for reasoning. If you're contrasting three options, that's a table. If you're explaining why, that's a sentence.
5. Say who does it. Every workflow names a role: "the Treasurer records…", "the home Team Manager relays…". Documentation without an owner describes work nobody does.
6. State the consequence, not just the rule. "Mark them Withdrawn — otherwise they're charged a match fee for a game they didn't play" teaches more than "always update statuses."
7. Write for the reader who is stressed and skimming. Bold the load-bearing phrase. Front-load the decision word. Assume they'll read the Quick Tips and nothing else.

---

Placeholders and Club Specifics

Use square brackets for anything the reader must fill in: [Name], [Date], $[X]. But in club modules, prefer real values — the whole point of a club module is that it says "$180" and "Oval 2", not "[amount]" and "[venue]". Put a "reviewed [Month Year]" line at the top so stale values are visible.

Never put in a shared training doc: passwords or credentials (Module 82), individual members' medical or financial details (Module 33), or door codes for secure areas — reference where those live ("keys register held by the Secretary"), don't reproduce them.

---

SECTION 4: STORING, INDEXING, AND MAINTAINING

Where Club Modules Live

Keep club modules in the same committee Google Drive folder as your copy of this library (Module 100, delivery method 2), in a club-modules/ subfolder. Add each new module to a C00-club-index.md file mirroring the library's index format:

| [C01](C01-clubroom-procedures.md) | Clubroom Opening & Closing | Team Managers, Coaches | Keys, alarms, canteen open/close, lockup checklist |

Announce new modules the way you'd deliver any training — a Noticeboard "Platform Tip of the Week" style post with the link, sent when it's relevant, not as a document dump.

---

The Review Cycle

Club modules go stale faster than platform modules — fees change yearly, key-holders change at every AGM. Fold them into the annual post-AGM library review (Module 100):

POST-AGM REVIEW — CLUB MODULES
☐ Fee amounts match this year's committee-approved fees
☐ Named people still hold the named roles
☐ Venue/ground details still correct (council changes)
☐ Association rules referenced still current
☐ "Reviewed [Month Year]" line updated on every touched module

Assign each module an owner by role, not by name — "maintained by the Treasurer", not "maintained by Sarah". Names leave; roles are refilled.

---

VISUAL: From Repeated Question to Maintained Module

SAME QUESTION ASKED TWICE+
 │
 ▼
Platform topic? ──yes──► Link to the library module. Done.
 │ no (club-specific)
 ▼
Copy the template · number it C[NN]
Write it: real values, exact UI labels,
named roles, consequences stated
 │
 ▼
Save to Drive club-modules/ · add to C00 index
Announce via Noticeboard when relevant
 │
 ▼
ANNUAL POST-AGM REVIEW
fees · names · venues · association rules
update "Reviewed [Month Year]"

---

TOOLTIPS & HINTS

• Link, don't rewrite — platform how-tos belong to the library; your modules cover what only your club knows
• C-numbering — C01, C02… keeps club modules collision-proof against library updates
• Real values in club modules — "$180 by March 1", not "[amount] by [date]"; with a "Reviewed" date on top
• Owner by role — "maintained by the Treasurer" survives the AGM; "maintained by Sarah" doesn't
• Quick Tips are mandatory — the 60-second version is the most-read section of every module

---

FAQ

Q: Who should write club modules — one person or the whole committee? A: One writer per module, chosen by domain: the Treasurer writes the fee module, the grounds officer writes the clubroom procedures. A second person reads it before it's shared — not for style, but to catch the step the expert forgot because it's automatic to them. That forgotten step is exactly what the new person needs.

Q: How long should a club module be? A: As short as completeness allows. Most club modules are one to two pages — a clubroom procedure is a checklist with context, not an essay. If a module is growing past four or five pages, it's probably two modules.

Q: Can we edit the library modules themselves to add our club's details? A: Better not to — edits are lost or create conflicts when the library is updated. Instead, write a short C-module with your specifics and link it from your role-based onboarding packs next to the library module it complements ("Module 04 for how payments work; C03 for this year's amounts and dates").

Q: What do we do with a module when the thing it documents stops existing? A: Don't delete it — move it to an archive/ subfolder and remove it from the C00 index. Deleted knowledge has a way of becoming needed again (Module 95's history principle applies to operations too).

---

COMMON MISTAKES

---

SHORT ONBOARDING SCRIPT

"When the same club-specific question gets asked twice, it becomes a document. Copy the module template, give it a C-number so it never collides with the library, and write it with real values — this year's fees, the actual gate code holder, the exact button labels. Lead every step with a verb, name the role who does it, and state the consequence of skipping it. Always include the Quick Tips section — that's the part people actually read. Store club modules in the committee Drive next to the library, index them in C00, and review them every post-AGM: fees, names, venues. And the golden rule — if the platform already covers it, link to the library module instead of rewriting it."

---

MICRO-TRAINING QUICK TIPS

• Same question twice + club-specific = write a C-module; platform topic = link the library
• Copy the template; C-numbering (C01, C02…) avoids library collisions
• Steps: numbered, verb-first, exact UI labels, one action each
• Real values + "Reviewed [Month Year]" line; no credentials or personal data ever
• Every module: owner by role, entry in C00 index, Quick Tips section mandatory
• Post-AGM: review fees, names, venues in every club module
• Retire modules to archive/, don't delete

---

Training Module 108 | See also: 100 Training Library Implementation Roadmap · 45 Message Templates · 36 Admin Handover Guide · 33 Data Privacy · 79 Committee Meeting Minutes