event-marketing-plan

Event Marketing Plan

You build the acquisition plan that fills a technical event: which audience segments get reached through which channels, at what weight, on what dates, against what per-phase targets. This is the umbrella plan. It decides when and how much each channel gets and hands the channel's own content to the sibling that owns it.

Four inputs arrive already decided. Do not re-derive them:

• The message - samber/dev-event-organizer-skills@event-positioning supplies the promise and the audience definition every channel's copy carries.
• The demand read - samber/dev-event-organizer-skills@event-market-fit supplies whether there is an audience at all, and is diagnostic where this plan is prescriptive.
• The dates - samber/dev-event-organizer-skills@event-ticket-pricing sets the price points and the early-bird cutoff. Those cutoffs are fixed calendar moments this plan reacts to; this skill never moves one to make a campaign more convenient.
• Two channels' deal mechanics - samber/dev-event-organizer-skills@cross-event-promotion and samber/dev-event-organizer-skills@event-media-partnerships own how those barter deals are sourced and structured. This plan only weights and schedules them.

Two organizer guides ground this plan:

• DevOpsDays' organizer guide names five acquisition channels and calls a mailing list "a powerful tool for ticket sales".
• MLH's organizer guide catalogs campus tactics and publishes a signup-to-attendance drop-off rate.

Both publish checkpoint numbers for total registrations, and both stop there: the funnel as a whole carries published figures, a single channel's yield in registrations does not. So when presenting the plan, say which targets are which:

• Whole-funnel checkpoints: published.
• Channel value ordering: your judgement.
• Per-channel targets: set from scratch.

Every ranking below is a default, not a law: it shifts with context and with who executes it. After the interview, re-rank both menus against what you already know about this organizer. Each of these overturns a default rung:

• An existing large mailing list.
• An organizer with a popular newsletter or podcast.
• A single-campus audience.
• A sponsor who bundles ad credits.
• A volunteer team with zero content-production capacity.

Interview

Ask one question at a time, multiple-choice where possible.

Questions 4 and 7-9 exist because the channel and budget menus diverge sharply on time-to-effect, durability and effort; the default order cannot be picked for the user. Q4 carries the deadline axis: doors are the hard date. A short runway between announcement and doors promotes fast-acting rungs (paid ads, a partner's next send) over slow ones (building a list from zero, local relationship-building), which cannot repay inside one compressed cycle.

1. Ticketed (paid) or free registration? This picks the calendar spine, and it is the single most consequential answer in the interview.
2. Community-run or company/vendor-run? The channel economics differ (see the next section).
3. What is the target number - expected paid ticket sales, or an attendance goal? For a ticketed event, ask for expected sales net of sponsor, speaker, organizer and volunteer comps; those tickets never had to be sold.
4. Which dates are already fixed: announcement, early-bird close, CFP close, speaker announcement, full-agenda announcement, doors? Collect them before planning anything.
5. Where does the target audience already read, listen and gather - which lists, communities, meetups, campuses, employers? Name real properties; this settles the channel weights and breaks the value ties below.
6. What does the event already own: a mailing list and its size, social accounts and their reach, a prior edition's own sales curve, an existing partner roster?
7. Is there a cash acquisition budget at all, and who approves it? A community event funded ~80%+ by sponsorship spends acquisition money against catering, not against a marketing line.
8. One edition's push, or a compounding asset across editions? A compounding mandate promotes the slow rungs (list building, local presence, partner relationships) that a single edition never repays.
9. What is the effort ceiling - organizer hours per week, who writes, who shows up in person?
10. Is the edition in person, online-only, or hybrid?

Community-run vs company-run

The buyer of a conference ticket is an individual developer whose employer often pays, so every event straddles employer-funded and self-funded attendance. The axis that actually changes the plan is who owns the event - the same axis this collection's positioning and sponsor skills argue:

• Community-run - the community-run organizer guides define the checkpoints and channel taxonomy used here. Acquisition is mostly owned and barter channels because cash competes with the event's own costs, and reciprocal-visibility swaps replace paid placement.
• Company/vendor-run - the community organizer guides are written for community events, so extrapolate rather than cite them at this pole. Expect a real budget line, a marketer who owns it, paid channels that a community event cannot reach, and media properties routing vendor promotion through commercial ad inventory rather than barter. The calendar spines still apply unchanged; only the budget posture moves.

Say which pole the plan assumes before allocating anything.

Pick the calendar spine - never blend the two

Two calendar spine types exist. They measure different denominators and belong to structurally different events. Averaging them, or carrying a checkpoint from one into the other, produces targets that are wrong in both directions.

• Ticketed conference → percent of expected ticket sales (DevOpsDays organizing guide). Checkpoints sit at named marketing moments, not fixed calendar offsets, because sales spike at announcements. The risk being managed is under-selling.
• Free event → percent of the attendance goal (MLH hackathon organizer guide). Checkpoints sit at fixed offsets (2 weeks, 1 week) and the target exceeds 100% on purpose. The risk being managed is no-shows, not under-selling.

Full checkpoint ladders, the worked numbers behind both, and the phase-target method: references/calendar-spines-and-phase-targets.md.

This choice is deliberately not ranked. The two spines are not competing options with different value per unit of effort - they are descriptions of two different demand shapes, and the event's revenue and no-show structure picks one outright. Ranking them would be false precision: the "more efficient" spine is simply the one measuring the wrong thing for that event.

For the in-between case - a nominal-fee event, or a free event with a hard capacity cap - pick the spine by the failure you actually fear: unsold seats or empty seats. Run it as the plan's only target line. Read the other spine's checkpoint as a secondary sanity check that never enters a target.

Workflow

1. Run the interview. Fix the spine (Q1), the pole (Q2), the target number net of comps (Q3), and the fixed dates (Q4).
2. Restate the message and the demand read from samber/dev-event-organizer-skills@event-positioning and samber/dev-event-organizer-skills@event-market-fit in one paragraph each. If either is missing, stop and route there first - a channel plan for an undefined audience allocates effort at random.
3. Map audience segments to channels from the Q5 answers, then weight them with the ranked menu below. Name the segment each channel is bought for.
   • One segment can need several channels.
   • One channel can serve several segments.
4. Lay the spine's checkpoints on the calendar, then pin every fixed date from Q4 onto it. Work backward from doors, not forward from today. Earliest anchor: T-7 months, "ensure marketing is off and running" (DevOpsDays organizer guide).
5. Allocate budget with the posture menu below. The percentage allocation table comes from B2B / B2C SaaS conventions, not from event-industry practice. Say so explicitly when showing it, so nobody reads a borrowed convention as an events standard.
6. Set funnel targets per phase against the spine's checkpoints, never against a straight line. Method and worked example: references/calendar-spines-and-phase-targets.md.
7. Route each channel to the sibling that executes it (see References). Hand over the weight, the phase, and the dates. Do not write the sibling's content here.
8. Re-forecast at each checkpoint against the plan's own line, and diagnose a miss before reacting to it (see Measurement).

If your harness has persistent memory, record for each edition:

• The spine chosen and why.
• The target net of comps.
• The channel weights, with the segment each was bought for.
• The fixed dates.
• The budget posture.
• Each checkpoint's planned-vs-actual.

The next edition's plan starts from a real prior curve instead of a blank calendar, which is exactly what the pace-index method needs.

Channel mix

Ranked menu: value returned per unit of organizer effort, drawn from DevOpsDays' five-channel visibility taxonomy and MLH's campus and social tactic catalog. The value ranking is judgement rather than a measured benchmark. Re-rank it against what this organizer already owns.

Channel taxonomy, quotes from the guides, campus-scale tactics and the owned/earned/paid framing: references/channel-menu-and-budget-allocation.md.

• effort (organizer hours, coordination, recurrence): local and campus engagement > partner channels > own social presence > paid ads == pre-event press > own mailing list > comms hub
• value (registrations bought, judged not measured): own mailing list > local and campus engagement == partner channels > own social presence > paid ads > pre-event press > comms hub
• efficiency: own mailing list > comms hub > partner channels > paid ads > local and campus engagement > own social presence > pre-event press
• compliance cost (review triggered, reversibility lost): paid ads > own mailing list > partner channels

The other four channels carry no compliance cost of their own: posting on your own accounts, showing up at a meetup, publishing a link hub and pitching a local outlet touch no consent record, no signed agreement and no spend approval.

Both ties are argued:

• Effort tie (paid ads == pre-event press): a paid-ads run and a press pitch are each a few hours of setup or writing followed by waiting on someone else's system. Neither is a standing job the way social posting is.
• Value tie (local engagement == partner channels): both put the event in front of an audience someone has already assembled and that already trusts the assembler. The difference is whether an organizer shows up in person or a partner's channel does it for them, not how much reach is bought.

Compliance cost is real on exactly three rungs:

• Paid ads need an ad account in the organization's name, platform ad-policy review and someone authorized to commit the spend.
• Own mailing list carries consent exposure: a list collected for one edition, mailed for the next, without a documented opt-in, is the one acquisition asset that can force a deletion the event cannot undo.
• Partner channels carry logo-licensing and delivery terms, handled in samber/dev-event-organizer-skills@cross-event-promotion and samber/dev-event-organizer-skills@event-media-partnerships.

Each channel in full:

• Own mailing list - announcements of ticket availability, early-bird offers, agenda releases, countdowns. DevOpsDays' guide: "Keep emails informative and limit their frequency to maintain engagement." Worth building from zero if the event has none. Where last edition's registration form recorded who said they were not available that year, re-contact that specific segment at this edition's announcement - a "not available last time, are you free now" ask converts a list segment other channels never reach.
• Comms hub - one page centralizing every channel, shareable by QR code (DevOpsDays organizer guide). One-time build. It converts reach the other channels create rather than creating reach itself, which is why it sits low on value and high on efficiency at once. This plan owns the page; samber/dev-event-organizer-skills@event-comms-channels supplies the per-channel roster (name, job, owner, hours) it publishes.
• Partner channels - cross-event swaps, media and community partners, developer-ambassador programs. Executed by samber/dev-event-organizer-skills@cross-event-promotion and samber/dev-event-organizer-skills@event-media-partnerships; this plan sets their weight and phase.
• Paid ads - targeted social ads. MLH's guide describes them as "cheap and effective" for campus audiences (note: that claim is specific to campus scale, not general).
• Local and campus engagement - meetups, local employers, business associations (DevOpsDays); in-class pitches, tabling, flyering, student groups and departments, plus the "at least 3 schools within 6 hours" invitation rule (MLH). Treat business-support networks/incubators and named school contacts as two separate referrer pools rather than one undifferentiated local list - they run on different outreach cadences and are worth tracking apart so each pool's own conversion stays legible.
• Own social presence - regular posting across the event's accounts, varying times. Weighted below its intuitive place on purpose: DevOpsDays' guide names the problem directly, "with the dispersal of tech communities from Twitter, a lot of community events are struggling to reach people."
• Pre-event press - school paper, local outlets, community media (MLH). A lighter ask than a press campaign; a real one belongs to samber/dev-event-organizer-skills@event-press-relations.

Where to start:

• Default rung: own mailing list plus comms hub, with own social presence running underneath as the baseline.
• Promotion condition: add partner channels once Q5 names properties whose audience genuinely matches, and add paid ads only after one owned channel shows a tracked referral signal worth amplifying, never as the first move against a soft checkpoint.

The starved option is local and campus engagement: high value, highest effort, so efficiency never picks it. Promote it anyway in two cases:

• A first edition with no list to mail, where the top rung is simply empty.
• A geographically concentrated audience (one campus, one metro), where in-person presence reaches a share of the target no owned channel can.

The organizer guides argue for it directly. DevOpsDays states "avoid the misconception that a great agenda alone will attract attendees. Actively promote your event," and MLH treats flyering and in-class pitches as core rather than optional.

**

...