Skip to content

COMMUNITY EVENT PLAYBOOK · v1.2

Turn an eventinto a next step.

A tool-agnostic operating model. Use the same promise, ownership, experience, and learning across workshops, meetups, mixers, hacknights, and large events.

About 18 minutes

PART I

This chapter belongs to the host.

This edition does not invent the author’s values, principles, or voice. The framework can operate first; the stance must be filled by lived experience.

THE OPERATING MODEL

Not a longer to-do list.

Four core objects keep the event whole. Six states move it forward. Tools only carry the work.

01

Four core objects

01

Promise

Who is this event for, and what ability, relationship, work, or next step will exist when they leave?

02

Ownership

Who owns the result? Which decisions can be made on site, and which must be escalated?

03

Experience

How does a participant understand, prepare, arrive, participate, and continue afterward?

04

Learning

How are participation facts separated, outcomes interpreted, and useful learning left for the next event?

02

Six lifecycle states

01

Frame

Name who the event serves and what it resolves

Event Brief
02

Commit

Commit resources, owners, and partnership boundaries

Ownership Map
03

Ready

Validate content, recruitment, venue, tech, and fallback

Experience Flow
04

Run

Operate from shared state and handle exceptions

Run of Show
05

Close

Give people, assets, payments, and promises a destination

Outcome Record
06

Learn

Turn outcomes into changes for the next event

Postmortem
03

Five decision gates

FrameCommit
  • Audience, need, and promise are specific
  • Primary outcome and minimum evidence are defined
  • Non-goals and reduction conditions are written
CommitReady
  • Each workstream owner has accepted responsibility
  • Budget, venue, partnership, and content sources are viable
  • Safety, access, consent, and cancellation have owners
ReadyRun
  • Public information matches on-site reality
  • The run of show is rehearsed and fallbacks tested
  • Check-in, interaction, output, and feedback capture work
RunClose
  • Attendance and participation facts are frozen
  • Promises and unfinished work are routed
  • Follow-up has one CTA and one owner
CloseLearn
  • Definitions, costs, and data gaps are marked
  • 30/60/90-day follow-up is scheduled
  • Each learning has a destination to update
04

Tool-agnostic operating rules

  1. 01
    One canonical source

    Keep one master version of event state; every other page links back.

  2. 02
    One owner per critical outcome

    Many may collaborate, but final decision and closure cannot be shared.

  3. 03
    Separate state from date

    A date says when; a state says whether conditions are met. Due is not done.

  4. 04
    Separate core from optional

    Keep six core artifacts; load format, venue, and brand details as needed.

  5. 05
    Separate decisions from tasks

    Record what was decided and why before expanding execution tasks.

  6. 06
    Make exceptions visible

    Delay, overrun, technical failure, incidents, and data gaps cannot live only in chat.

  7. 07
    Let on-site information degrade gracefully

    The run of show, contacts, and roster remain available when tools or network fail.

05

Minimum data structure

CategoryMinimum fields
IdentityEvent name, format, date, place / platform, canonical URL
PromiseAudience, leaving outcome, non-goals, primary KPI
OwnershipDecision owner, workstream owners, on-site escalation
StatusLifecycle state, next gate, blocker, last update
ExperienceParticipant journey, run of show, access / consent, fallback
LearningCohort definition, source, outcome, incident, decision, next change
06

Tool mapping examples

ConceptLinearNotionSheet / docs
EventProjectEvent page / database itemIndex row + event folder
Core objectsProject overview / documentsPage sections / linked databasesEvent Brief tabs / docs
LifecycleProject status / milestoneStatus propertyStatus column
OwnerLead / assigneePerson propertyOwner column
GateMilestone / issue groupGate checklistGate review row
Exceptions & learningIssue / project updateDecision log / postmortemIssue log / retrospective tab

This table explains correspondence only. It does not prescribe a tool or interface configuration.

FORMAT MODULES

Keep the core. Change the form with the promise.

01WS

Hands-on Workshop

Complete a verifiable action or artifact on site

Interaction rhythm
Explain → Demo → Build → Checkpoint → Share
Critical risk
Prerequisites, setup, accounts/network, pace gaps
02MT

Tool / Community Meetup

Exchange applicable cases, perspectives, and peer connections

Interaction rhythm
Story → Local case → Q&A → Connect
Critical risk
Product promotion overwhelms participant value; content runs long
03MX

Founder Mixer

Create relevant new connections and follow-up conversations

Interaction rhythm
Warm-up → Prompt → Regroup → Open exchange
Critical risk
Closed circles and business-card exchange without follow-through
04HN

Hacknight / Demo Night

Produce demonstrable progress, learning, or a failure path

Interaction rhythm
Frame → Team → Build → Submit → Demo
Critical risk
Team imbalance, failed submission, opaque judging
05MTX

Large Multi-track Event

Let tracks deliver independently within one coherent experience

Interaction rhythm
Open → Route → Tracks → Report → Close
Critical risk
Central bottlenecks, capacity gaps, unowned cross-track incidents

ARTIFACT LIBRARY

Save repeated decisions as reusable assets.

Twenty templates grouped by function. Open one to see the decision it carries—not a prescription for tool fields.

Core Pack

Required for every event

05
A1Event Brief

Audience, promise, outcome, constraints, and next gate

Event name:
Date / place / format:
Decision owner:

Who this is for:
Need / opportunity observed:
Participant leaving outcome:
Why an event is the right intervention:
Out of scope:

Primary outcome KPI:
Eligible cohort:
Observation window:
Evidence source:

Critical constraints:
Cancel / reduce conditions:
Next gate and date:
A2Ownership Map

Decision rights, collaboration, escalation, and backup

Workstream | Final owner | Collaborators | May decide | Must escalate | Backup
Overall outcome / scope | | | | |
Content / speakers | | | | |
Production / on-site | | | | |
Technical | | | | |
Safety / access / consent | | | | |
Budget / partnerships | | | | |
Evidence / follow-up | | | | |
A3Experience Flow

The participant path from Discover to Continue

Stage | Participant action | Touchpoint / message | Friction | Owner | Evidence
Discover | | | | |
Decide / Register | | | | |
Prepare | | | | |
Arrive / Join | | | | |
Participate | | | | |
Close | | | | |
Continue | | | | |
A4Run of Show

Timing, outcome, owner, success condition, and fallback

Time | Segment | Participant outcome | Owner | Cue / asset | Success condition | Fallback
| | | | | |
A5Outcome Record

Attendance, engagement, outputs, incidents, and open promises

Registered / Approved:
Checked in:
Completed / meaningfully engaged:
Outputs / demos / stories:
Incidents / exceptions:
Outstanding commitments:

Primary KPI status:
Known data gaps:
Immediate follow-up queues:
Decisions to keep / change / stop:

Content & Communication

Public information and on-site language

05
B1活動頁架構

Audience, outcomes, flow, rules, and one CTA

One-sentence promise
Who it is / is not for
What participants will do and take away
Date, timezone, place / platform, language, fee
Prerequisites and what to prepare
Flow summary
Hosts / speakers and their roles
Capacity, waitlist, cancellation, and walk-in rules
Access, media, Code of Conduct, contact
One registration CTA
B2講者邀請

Reason, format, fee, rights, and timing

Subject: [Event] invitation to share [topic / case]

Hi [name],
We are planning [event] for [audience], with the goal that participants leave able to [outcome].
We would like to invite you because [why this person / experience], in a [length + talk / conversation / workshop + Q&A] format.

Date / timezone:
Place / format:
Audience and expected size:
Please cover:
Please avoid:
Fee / travel / recording and asset use:
Dry run / submission date:

If interested, reply by [date]. We can shape the topic and format together.
B3講者 Brief/簡報骨架

Context, attempt, decision, result, limits, and next step

What the audience knows / does not know
What they should be able to do afterward
Suggested arc: context → attempt → decision → result → limitation / failure → next action
Must explain: case context, assumptions, limits, and sources
Avoid: long company intros, unexplained terms, feature tours with no takeaway
Timing: total / content / Q&A / removable section
Format and equipment: ratio, type, video, demo, backup
Rights: recording, public slides, adaptation
B4參與者確認信

Arrival, preparation, access, cancellation, and next step

You are confirmed for [event]
Time / timezone / address or join link:
Check-in and late-arrival rules:
Complete / bring in advance:
What happens on site:
Access, food, media, and contact:
Cancellation / waitlist:
The one next step after the event:
B5主持 Cue

Opening, transition, overtime, and closing

Opening: who this is for / today’s promise / how to participate / safety and help / next segment
Transition: what was completed / what is next / what to prepare
Overtime: which outcome to protect / what to cut / when to stop
Closing: what was completed / where materials live / one next step / thanks

Participation

Turn attendance into participation

04
C1Facilitation Sheet

Instructions, grouping, observation, intervention, and output

Segment | Instruction | Time | Grouping | Facilitator observes | Intervention | Output
| | | | | |
C2Workshop Checkpoints

Completion, blockers, resources, and unfinished paths

Checkpoint | Visible completion | Common blocker | Self-serve resource | Help path | Unfinished path
| | | | |
C3Mixer Prompt Card

Building, blocked by, can offer, and want to meet

I am building:
I am blocked by:
I can help others with:
I want to meet / ask:
I consent to a follow-up introduction: yes / no
C4Hacknight Submission

Goal, progress, demo, blocker, and review rubric

Team / members:
Original intent:
What was actually completed:
Demo / repo / work link:
Biggest blocker and response:
Next step:

Review rubric: problem and audience / implementation or validation / learning and honesty / communication
Judge conflicts and overtime rules:

Safety & Inclusion

Infrastructure for participation

03
D1Access Statement

Available support, limits, contact, and alternatives

Venue / platform currently provides:
We cannot currently guarantee:
Language, captions / transcript, route, seating, toilets, quiet space:
Food and allergy information:
Request deadline and contact:
Response and alternative if a need cannot be met:
D2Media Consent

Purpose, choices, no-camera signal, and withdrawal

This event may be photographed / recorded for: [purpose and channels]
Participants may choose: [consent / no camera / confirm individually]
On-site identifier:
Contact and deadline for questions or withdrawal:
Work, slides, demos, and quotes require separate permission: yes / no
D3Incident Record

Necessary facts, response, protection, escalation, and change

Time / place:
Reporter and receiving owner:
What happened (necessary facts only):
Immediate response:
Protected personal data / access limits:
External support or escalation:
Follow-up promise and deadline:
Process-level change:

Learning & Follow-up

Give one event a next step

03
E1回饋表

Intent, value, completion, blocker, and consent

What did you hope to get from this event?
Which part helped most, and why?
What did you complete / what will you do next?
Where are you still blocked?
Did you feel able to participate, ask, and get help?
What should we keep, change, or stop next time?
Do you consent to follow-up / interview / public quote? (choose separately)
E2Postmortem

Facts, impact, causes, changes, and owners

Event promise and primary KPI:
Expected vs actual:
What happened (facts and timeline):
What worked / did not work:
Impact on participants and team:
Root causes / enabling conditions:
Keep / change / stop:
Action, owner, deadline:
Template / module / rule to update:
E3KPI Tracker

Consent, attendance, 30d activation, 90d repeat/contribution

Participant ID | Consent | Checked in | In-event action | 30d activation | 90d repeat | 90d contribution | Source | Follow-up owner
| | | | | | | |

MEASUREMENT & LEARNING

The event ending does not mean the outcome has happened.

Separate registration, attendance, engagement, completion, and follow-through. Then choose one primary outcome.

01

Separate participation facts first

FieldMeaningRule
Registered / GoingRegistration or RSVPNever add to attendance
ApprovedReviewed or confirmed rosterMark waitlist and cancellation in the denominator
Checked in / AttendedActual check-in / attendancePreferred denominator for on-site participation
Meaningfully engagedCompleted a predefined interactionDefine before the event
CompletedCompleted a task or checkpointAn outcome, not an additional person
Outputs / Demos / StoriesNumber of works, demos, or storiesDo not combine with people
02

Choose one primary outcome KPI

30DAY

30-day Activation

Among checked-in attendees who had not taken the action before, the share completing a meaningful action within 30 days.

90DAY

90-day Repeat

Among traceable, opted-in attendees, the share joining a qualifying activity again within 90 days.

90DAY

90-day Contribution

Among eligible attendees, the share completing a verified contribution within 90 days.

Define meaningful action, eligible cohort, qualifying activity, and contribution before the event; do not change definitions after seeing results.

03

Drivers, guardrails, and cost

Drivers
landing conversion、attendance、checkpoint completion、CTA click / booking、time to first action
Guardrails
relevance / belonging、access / CoC incident、volunteer load、opt-out / privacy、newcomer vs returning
Cost
Track cash, in-kind support, labor time, venue, and tools separately.

Report numerator and denominator together, for example 18/51 = 35.3%. NPS, satisfaction, registrations, and reach are diagnostics—not community outcomes by default.

04

Conversion is not one number

InviteVisitRegisterCheck-inEngageActivateRepeatContribute
Attendance rate = checked-in ÷ approved registrations
Engagement rate = meaningful engagement ÷ checked-in
Activation rate = new activations ÷ pre-event unactivated checked-in cohort
Repeat rate = qualifying repeat participants ÷ follow-up eligible cohort
Contribution rate = verified contributors ÷ eligible cohort
Cost per activated attendee = fully loaded event cost ÷ new activated attendees
05

Attribution levels

01

Sourced

The event is the first identifiable acquisition touch.

02

Influenced

The event appears before the outcome; it is not claimed as the sole cause.

03

Incremental

Claim lift only with a credible comparison design.

Incremental lift = outcome rate(invited cohort) − outcome rate(random holdout)
Event ROI = (incremental attributable gross profit − fully loaded event cost)
            ÷ fully loaded event cost

When the sample is small, comparison is absent, or data is incomplete, report influenced outcomes and cost—do not present correlation as causal revenue.

06

Follow-up rhythm

FOLLOW-UP RHYTHM

T+0–2T+7T+14–21T+30T+60T+90
T+0–2

Segment attendees, no-shows, speakers, volunteers; send assets, feedback, one CTA

T+7

Route by completion state and blocker

T+14–21

Office hour, unfinished clinic, mentor follow-up

T+30

Freeze activation cohort; interview both successful and unsuccessful cases

T+60

Run a second ritual; invite activated members to a light contribution

T+90

Freeze repeat / contribution; update cost and attribution

07

Learning Loop

Complete a postmortem after each Close. Run a cross-event Learning Jam after 3–5 events of the same format.

Compare cohorts only when definitions, format, and acquisition channels are comparable. Write repeated, generalizable practices back into the core or format module; keep city, brand, account, and short-term policy details in event records.

Prefer the median and quartiles from your own 3–5 events. External benchmarks are provisional planning ranges, not universal targets.

APPENDICES

Execution detail, loaded only when needed.

These are execution aids, not the core workflow. Load only the modules relevant to the event’s risks.

A

Optional implementation checklists

General production

  • Canonical event page, registration entry, and timezone agree.
  • Capacity, waitlist, cancellation, walk-in, public/private, and fee rules are public.
  • Access control, route, seating, toilets, exits, and venue contact are confirmed.
  • Confirmation, speaker brief, run of show, and host cues share one version.
  • On-site roles completed a walk-through and know escalation and fallback.
  • Payments, thanks, assets, survey, and unfinished promises have owners.

Technical event

  • Prerequisites, accounts, permissions, versions, and setup were tested by a non-author.
  • Network, power, projection, audio, adapters, and test devices are verified.
  • The demo has a recording, screenshots, sample output, or offline version.
  • Do not expose API keys, private screens, personal data, or unauthorized repos.
  • Checkpoints, helper ratio, blocker routing, and unfinished paths are clear.

Media and evidence

  • Media purpose, consent choices, no-camera signal, and withdrawal contact are communicated.
  • Shot list covers event identity, scale, and actual interaction / work.
  • Registration, approved, attendance, completion, and outputs are separate.
  • Originals, selects, captions / credits, and consent remain traceable.
  • Confirm public rights separately for photos, quotes, slides, and work.

Multi-track / large event

  • One master roster; each track’s capacity and owner are clear.
  • Channels, naming, shared issue log, and reporting rhythm agree.
  • Each track knows what it may decide without central approval.
  • Opening / closing messages and safety information are consistent.
  • Each track can close independently and roll into the overall outcome summary.
B

Public assets and usage boundaries

Order of use: take the method first, then use the license to decide whether text or files may be copied.

SourceReusable layerBoundary
Cursor Ambassador workspaceFormats, brand assets, slides, attendance copy, ambassador toolsMostly workspace / brand restricted; not a general public license
本地 Zeabur Event GuideOn-site execution, technical preflight, media, event recordsUse as a practice case; keep brand, accounts, and policies out of the core
CNCF Kubernetes Community DaysComplete community-event asset structureApache-2.0; verify attribution in the source
Write the DocsSpeaker, volunteer, and role designCC BY-NC-SA 4.0; reassess for commercial publication
MLH Organizer GuideHackathon flow and judgingCC BY 4.0
OpenHatch HandbookTechnical preflight and contribution continuationCC BY 3.0 US
Community-Led Co-design KitFacilitation, access, consent, outcomeCC BY 4.0
Drupal / W3C WAIEvent accessibilityFollow each source document’s license

Document boundary

This is an organization-neutral Community Event Playbook—not a brand ambassador program, brand asset library, reimbursement policy, or account manual. Brand-specific forms, budgets, benefits, accounts, and governance stay with their sources. Before publicly adapting an original template, return to the asset index and verify license and attribution.

Close the room. Keep the path open.

Community Event Playbook · Ling Wu