event-attendee-email-sequences

Event Attendee Email Sequences

You design and write the emails a technical event sends its attendees. Your inputs arrive fixed from siblings: the campaign calendar and email's channel weight from samber/dev-event-organizer-skills@event-marketing-plan, the early-bird and price-tier cutoffs from samber/dev-event-organizer-skills@event-ticket-pricing, and the on-site facts from samber/dev-event-organizer-skills@event-attendee-experience. Your output is a dated send map plus the copy for every email on it.

You never move a date to make an email land better, never set a price cutoff, and never invent what the day-of experience looks like. Your audience is the general attendee only - speakers and sponsors have their own comms, owned by samber/dev-event-organizer-skills@event-speaker-experience and samber/dev-event-organizer-skills@event-sponsor-fulfillment.

The sharpest boundary is no-shows. A reminder sequence exists to fight them.

• You own: the sequence's design and copy, in full.
• samber/dev-event-organizer-skills@event-no-show-management owns: the no-show problem itself - overbooking ratios, waitlists, paid deposits and seat-release flows.
• When a user asks "how do we stop no-shows": answer with the reminder emails, and route the structural fix there in the same breath.
• This boundary is one-sided: that sibling ships, but it was written from this side only and has not been agreed from its side - say so rather than implying an agreed handoff.

The sourced cadence

The reminder sequence you design should be much thinner than SaaS marketing norms - roughly 2 to 4 sends across the whole pre-event arc, segmented by list membership. Say that plainly whenever a user expects a longer sequence. This is not an under-built cadence; it is what organizers who run these events actually send.

Every ranking below is a default, not a law - it shifts with context and with who executes it. Re-rank all three menus after the interview against what you already know: an existing well-consented list, an organizer who already writes a popular newsletter, a volunteer with no way to filter a list, or a compressed runway each overturns a default rung.

Core principles

SaaS lifecycle drips are rejected structurally. Welcome, onboarding, re-engagement and win-back sequences assume an ongoing subscription and branch on per-recipient behaviour (opened, clicked, went quiet). An event arc is fixed, dated, and ends on one day. Every send moment here is a calendar date, never a behavioural trigger, and the branching mechanic needs marketing-automation tooling a volunteer-run event does not have.

Cold-email subject-line science is rejected entirely. Its tactics (2-4 lowercase words, no first-name token, "look like a colleague, not a vendor") exist to disguise a sender so an unsolicited message beats a stranger's spam filter. That inverts here: your recipient registered and is hunting for the email that tells them where to check in.

Name the event and the date plainly.

Interview

Ask one question at a time, multiple-choice where possible. Questions 6-8 exist because the menus below diverge sharply on time-to-effect, durability and effort - those defaults cannot be picked for the user.

1. What does the marketing plan hand you: which calendar spine, what channel weight email carries, and the fixed dates (announcement, agenda release, doors)? Take all of it as given.
2. Is there a list at all, and where did each address come from - a ticket purchase, a form with an explicit opt-in box, last year's attendees, an existing community list? Answer per source, not in aggregate.
3. Ticketed or free - and is there registration at all? A no-registration event has no list to sequence.
4. Community-run or company/vendor-run? This changes the consent posture and what the list may later be used for, not the arc.
5. Which dated cutoffs must an email react to: early-bird close, price-tier change, capacity cap, CFP close? Those dates arrive fixed; you write the email that lands against them.
6. What is the last date each send can still work? Doors, minus the week-before and day-before offsets, is fixed - a compressed runway deletes the upper rungs of the sequence-depth menu outright rather than compressing them.
7. One edition, or a list you intend to still own in three years? A compounding mandate promotes the consent-heavy and win-back rungs, because a list that survives an audit is the asset, not this edition's sends.
8. Who writes and sends these, how many hours do they have, and can they filter a list per send? A team that cannot produce a filtered list has no segmentation rungs above the role split.
9. What does the on-site day actually look like - check-in location and hours, badge policy, quiet room, dietary mechanics, accessibility provisions? Take this from samber/dev-event-organizer-skills@event-attendee-experience; never invent it to fill a section.
10. Who else receives email about this event (speakers, sponsors, volunteers, judges), and who owns those sends? You write the attendee variant only.
11. What is the rough split of first-timers versus returning attendees, and how many attendees travel internationally? Decides whether the attribute-segments rung is worth the list work.

Community-run vs company/vendor-run

An attendee whose employer pays often needs something forwardable to a manager - dates, cost, and what the company gets - which is a variant of the announcement email, not a different arc.

Every other send is identical, because the recipient is an individual developer either way and the day-of information does not care who paid. Keep the forwardable justification paragraph as a named option.

What actually changes the work is two orthogonal axes:

• Registration posture (ticketed / free-with-registration / no registration). Decides whether the arc exists at all.
  • A free event carries a sourced 30-50% signup-to-attendance drop-off, which makes the reminder cadence load-bearing rather than courteous.
  • A no-registration event (FOSDEM's published posture: "There is no registration. Just turn up!") has no list. The identity-consistent output is the practical information published once on the event's own page plus one announcement, not a sequence with nothing to gate entry into it.
  • State that as the right answer for that posture, never as a shortfall.
• Community-run vs company/vendor-run. A community event's list is an organizer-held asset with one purpose; a vendor event's list usually flows into a marketing database with a second life. The published practice behind this skill is community-side, so treat every vendor-pole adjustment as a judgment call and say which pole a recommendation assumes whenever they differ.

The arc

Fixed and dated. Each row is one email with one job. Nothing here branches on behaviour.

Send	Fires on	Its one job
Announcement	the plan's announcement date	it exists, it is dated, here is where to look
Registration confirmation	on registration (transactional)	prove it worked, say what arrives next and when
Agenda / speaker release	the plan's agenda-release date	give the undecided a concrete reason
Last call	samber/dev-event-organizer-skills@event-ticket-pricing's cutoff, a day before it	one dated fact, no manufactured urgency
Know-before-you-go	roughly one week before doors	everything needed to arrive prepared
Day-before nudge	the evening before	the one thing: when and where
Post-event thank-you	1-3 days after	thanks, recordings, and the feedback handoff

A live, checkable figure counts as the dated fact the last-call row asks for - "already 70% of seats taken" is not manufactured urgency if it is true at send time, unlike a countdown with nothing behind it. The same rule runs the other direction for the day-of send: open with the social proof that already exists ("we are sold out") before repeating the logistics, rather than burying it under the practical details the reader has already seen once.

The email-by-email breakdown - trigger, required contents, what each must not carry, and its segment - is in references/arc-and-send-map.md.

Workflow

1. Run the interview. Fix the spine and dates (Q1), the list's consent provenance per source (Q2), the registration posture (Q3), the cutoffs you react to (Q5) and the runway (Q6).
2. Restate the handed-down inputs back to the user before writing anything - dates, email's channel weight, the message and positioning - the way samber/dev-event-organizer-skills@event-social-media restates them for its own channel. Re-deriving any of them is how two channels end up disagreeing on the same event's dates.
3. Map the fixed arc above onto those dates. Every send gets a date and one job, or it does not exist.
4. Pick the sequence depth, the reminder cadence and the segmentation depth from the three menus below, in that order.
5. Write each email to its single job. The craft rules - subject and preview text, the five-part body, formatting, banned moves - are in references/email-craft-and-worked-copy.md.
6. Build the know-before-you-go email against the sourced 14-section structure in references/know-before-you-go-email.md, pulling every on-site fact from Q9 rather than inventing one.
7. Apply the role split at the week-before send. Write the attendee variant; hand the speaker, sponsor and volunteer variants to the siblings that own those audiences.
8. Check the whole plan against the sourced caps. If any segment is over, cut a send rather than justifying it.
9. Run every drafted email through a humanizer pass in your preferred humanizer skill. A model-shaped email to a room of developers reads as model-shaped, and this is the one channel where the sender's own voice is the credibility.
10. Run the consent and list-hygiene check below. A send that fails it does not go out, whatever the calendar says.
11. Show the user the full send map plus every draft before anything is scheduled. An email cannot be unsent, and a wrong date in a reminder produces a room of people arriving on the wrong day.
12. Hand the post-event survey itself to samber/dev-event-organizer-skills@event-feedback - you write the email that carries it, never the instrument inside it.

If your harness has persistent memory, record the dated send map, which list each send went to and where those addresses came from, the cadence caps you held to, the subject lines used, and anything that drew replies or complaints. That record is what makes next edition's arc yours rather than this skill's defaults.

Sequence depth

How much of the arc you actually build. Ranking (default, not a law - Q6 and Q8 re-rank it):

• effort (emails written, sends coordinated, list work per send): full arc > core arc > confirmation plus know-before-you-go > confirmation only
• value (a full room, and the people in it arriving prepared): full arc > core arc > confirmation plus know-before-you-go > confirmation only
• efficiency: core arc > confirmation plus know-before-you-go > full arc > confirmation only
• compliance cost (review triggered, reversibility lost): the full arc alone carries any; the other three rungs mail only people who registered for this edition. The full arc's win-back mails a prior edition's list, which needs a documented per-address opt-in and sign-off before it goes out - the one send here whose mistake cannot be taken back.

This menu is clean by construction, not by care: value and effort run in the same order, so no rung dominates another and any efficiency ordering is admissible. Do not read that as a pass - it means the ordering below rests entirely on the argument attached to each rung, with no dominance check available to catch a mistake. The other two menus each carry a real dominance constraint, and each says where.

• Confirmation only - one transactional confirmation at registration, nothing else. Near-zero effort, and it leaves undone the one job only email can do: telling a registered person where and when to show up. Its efficiency ratio is two near-zero numbers divided by each other, which is why it sits last rather than first.
• Confirmation plus know-before-you-go - two sends. Cheap, and it buys most of the arrival value, because the week-before email is what determines whether people reach the right building at the right hour.
• Core arc - the default: announcement, confirmation, know-before-you-go, day-before nudge, post-event thank-you. Five sends, none branching. It adds the announcement - the send that carries the own mailing list, which the marketing plan ranks first on both value and efficiency across every acquisition channel the event owns - plus a post-event send at almost no marginal cost.
• Full arc - the starved option: core plus agenda release, last call against the pricing cutoff, and a prior-year win-back. It tops value and effort together, so efficiency never picks it. Promotion conditions: a dated early-bird cutoff worth reacting to (Q5), a prior-year attendee list that exists and is consented (Q2), and someone whose actual job includes writing these (Q8) - all three, not any one.
• Deleted, not demoted: the behaviourally-branched drip. Five to ten nurture sends on one list with open/click conditional logic. It is not a heavier rung of this menu; it is a different mechanic for a different relationship, and parked at the bottom it silently returns as scope the first time someone asks for "a proper sequence".
• Conditional delete. On a free event with no registration, delete every rung of this menu and the axis lines above it: publish the practical information on the event's own page and send one announcement to whatever list already exists. There is nothing to sequence.

Reminder cadence

How many reminder passes, spaced how. Every rung keeps the week-before send and differs only in which further pass it adds on top: nothing, the day-before nudge, the registration follow-up, or all four sourced passes at once. The whole menu sits inside MLH's

...