Plan and Maintain a Community Event Attendee FAQ

Build your attendee FAQ from a register, not from memory. Every published answer should trace back to an approved event record, such as the current schedule or venue information. Each answer also needs a named owner who confirms it, and a defined trigger for checking it again. Unconfirmed drafts stay internal until the owner approves them. This approach works for an amateur tournament, a community festival or a volunteer-run fundraiser. It covers the general questions attendees ask before and during the event. Individual enquiries that need a personal response stay with your information desk or enquiry process.

The three things every FAQ answer needs

• A source: the event record the answer is based on, including its version, such as schedule version 3 or the venue information sheet.
• An owner: the person accountable for that underlying detail. For example, the schedule lead owns timing answers and the venue contact owns facilities answers. The FAQ editor coordinates the answers but does not own them.
• An update rule: a next-check date, or a change that forces a recheck, such as a new schedule version.

Without these three, an FAQ tends to drift. A start time gets updated on the registration page but not on the FAQ, and attendees end up getting two different answers.

Inputs to gather before you draft

• The current event schedule, with a version number or date so you can tell which edition an answer relies on.
• Venue information as provided or confirmed by the venue, such as access, parking, facilities and any house rules.
• Attendance arrangements: registration, check-in, entry, and what participants or spectators need to bring.
• Event contacts: who attendees should reach for what, and through which channel.
• A list of owners for each area: schedule, venue, registration, volunteers and communications.
• Every place the FAQ or its answers will appear, such as the event page, registration confirmations, social posts, printed signs and volunteer briefing sheets.
• Who may approve publication, and any limits on what can be shared publicly.

Set up the FAQ register

The register is an internal spreadsheet or shared table where each row is one attendee question. One row per question keeps ownership and approval clear. A simple header row looks like this:

Question | Proposed answer | Source record & version | Answer owner | Approval status | Last checked | Next check / change trigger | Published in

Column	What it records	Why it matters
Question	The attendee's question in their own words	Keeps answers focused on what people actually ask
Proposed answer	The draft wording	Lets the owner approve exact text, not a summary
Source record & version	Which schedule, venue sheet or other record supports the answer	Shows when an answer has gone stale
Answer owner	The person accountable for the underlying detail	Makes clear who confirms changes
Approval status	Draft, approved or needs update	Stops unapproved text from being published
Last checked	Date the answer was last confirmed	Reveals answers nobody has reviewed recently
Next check / change trigger	A date or an event, such as a new schedule version	Turns maintenance into a rule rather than a memory
Published in	Every location where the answer appears	Tells you exactly what to update when something changes

Group the questions

Organize the register into groups so you can spot gaps. A practical set of groups is timing, location, attendance arrangements, facilities and event contacts. The questions below are illustrative. Use the ones that fit your event, and add your own.

• Timing: When do doors or check-in open? When does play start? When is the final expected to finish?
• Location: Where is the entrance? Where should participants report? Where can people park or drop off?
• Attendance arrangements: Do I need to register in advance? What should I bring? Can spectators attend?
• Facilities: Are there restrooms, seating, shade or a place to store equipment? What accessibility arrangements are available?
• Event contacts: Who do I contact about my registration, about a schedule change on the day, or about a lost item?

Step-by-step workflow

• 1. Collect likely questions. Pull them from past events, enquiries received so far, registration form comments, and volunteer feedback about what people asked on site. Add each one as a row.
• 2. Locate the approved information. Find the current record that answers each question and note its version. If no approved record exists, leave the row as a draft and flag it to the relevant owner. Do not fill the gap with a guess.
• 3. Draft a direct answer. Lead with the answer itself, such as a time, a place or a yes or no, and then add any needed detail.
• 4. Get the owner's approval. The owner of the underlying detail confirms the exact wording. Record the approval and the date.
• 5. Check publication permissions. Confirm the answer can be shared publicly and in each intended location. Some venue details or contact information may be for staff only.
• 6. Publish. Post the approved answer in each location listed in the register, and nowhere else without adding that location to the row.
• 7. Recheck when something changes. When a source record changes or a check date arrives, the owner reconfirms or replaces the answer, and the editor updates every listed location.

Choices that affect how well the FAQ holds up

• Who counts as the owner: choose the person who would actually make or receive the change to that detail, not whoever happens to be writing the FAQ.
• Date-based versus change-based checks: change triggers, such as a new schedule version or a revised venue sheet, catch the updates that matter most. Add a date-based check closer to the event as a backstop for anything that changes without notice.
• Organizer choices versus outside requirements: some answers reflect your own decisions, such as check-in time or a bring-your-own-equipment policy. Others reflect venue rules, a governing body's rules or local requirements. Get those answers from the venue or the applicable rule source, and name that party as the source in the register.
• How much detail to repeat: when a detail appears in several answers, such as the start time, each repetition is another place to update. Where you can, state it once and refer back to it.
• Where drafts live: keep unconfirmed answers only in the internal register, so a placeholder never reaches attendees.

Check the FAQ for omissions and conflicts

Before publishing, and again after any change to a source record, run a consistency check. Compare each approved answer with the current schedule, the venue information and other attendee communications, such as confirmation emails, social posts and signage. When you find a discrepancy, assign it to the relevant owner. Then record in the register which published locations need updating, so the fix reaches all of them rather than just the one you noticed.

• Every question group has at least one approved answer, or a deliberate decision not to cover it.
• Every row has an owner, an approval status, a last-checked date, a trigger and at least one publication location.
• No two answers rely on different versions of the same record.
• No published answer has a status of draft or needs update.
• Contact answers point to channels that will actually be staffed when attendees use them.

Example: handling a schedule change

This is a hypothetical example. The FAQ answer about opening time cites schedule version 3. The schedule lead then issues version 4, which changes the opening time. That change triggers a recheck. The schedule owner confirms the replacement answer, and the FAQ editor records the approval and the new source version. The editor then updates the event page, the confirmation email template and the printed entrance sign, because those are the locations listed in that row. Finally, the consistency check confirms that no other answer still refers to version 3.

Keep the FAQ separate from enquiry handling

The FAQ answers general questions with approved, published information. Questions about a specific person's registration, a dispute or a problem on the day stay with your staffed information desk or enquiry workflow. The two processes still connect: when the desk keeps getting the same question, add it to the register as a new row and send it through the same draft, approval and publication steps.