event-attendee-email-sequences

{
  "skill_name": "event-attendee-email-sequences",
  "evals": [
    {
      "id": 1,
      "prompt": "I run marketing at Fenlock Systems and we're putting on our first developer conference, FenConf, in Lyon on June 18-19. The marketing plan hands me these fixed dates: public announcement April 2, agenda goes live May 6, doors June 18. Tickets are paid and registration opens with the announcement. We have about 1,200 addresses on our list. I've done lifecycle marketing for our product for years, so my instinct is a proper nurture sequence - something like 8-10 touches, branching on opens and clicks so engaged people get different content than quiet ones, plus a re-engagement branch for people who go cold. Can you design the full sequence and cadence?",
      "expected_output": "A dated send map built on the fixed dates, rejecting the behavioural drip in favour of the thin dated arc, with one job per send and the list's provenance checked.",
      "files": [],
      "expectations": [
        "Rejects the 8-10 touch nurture sequence instead of building it, and proposes roughly 2 to 4 reminder sends across the pre-event arc",
        "Rejects open/click branching as structurally wrong for an event (a fixed, dated arc that ends on one day), not merely as a tooling limitation",
        "Every send in the proposed plan fires on a calendar date; none is conditioned on a recipient's open, click, or inactivity",
        "Presents the thin cadence as what event organizers actually send, not as a budget or reduced version of a real sequence",
        "The default plan is the five-send core arc: announcement, registration confirmation, know-before-you-go, day-before nudge, post-event thank-you",
        "No re-engagement or win-back email appears in the plan for this edition's own registrants",
        "Asks where the 1,200 addresses came from, per source, rather than assuming the whole list is mailable",
        "Maps sends onto the fixed dates given (April 2 announcement, May 6 agenda, June 18 doors) without moving any of them",
        "Restates the handed-down dates back to the user rather than re-deriving or adjusting them",
        "If an agenda-release email is included, it is marked optional or first-to-cut, not core",
        "Each email in the send map carries exactly one stated job",
        "The know-before-you-go lands roughly one week before doors and the day-before nudge the evening before"
      ]
    },
    {
      "id": 2,
      "prompt": "Our data engineering conference TidePool Conf (Rotterdam, May 21-22) has early-bird pricing ending Sunday at 23:59. We're at about 40% of the 600-seat capacity. I want a last-call push: one email Thursday and another Sunday morning, and in both let's say tickets are almost gone to get people moving. One more thought - weekend emails perform terribly in our stats, so should we just quietly extend the early-bird to Monday and send the deadline email then? Write me the copy.",
      "expected_output": "One last-call email scheduled the day before the real cutoff, targeting only the not-yet-registered, with the true dated fact and no invented scarcity; the double send and the deadline move both refused.",
      "files": [],
      "expectations": [
        "Refuses to claim tickets are almost gone when the stated figure is 40% of capacity",
        "Distinguishes a true, checkable figure (stating the real number if anything) from manufactured scarcity",
        "Produces exactly one last-call email and declines the Thursday-plus-Sunday double send: one cutoff, one email",
        "Refuses to extend or quietly move the early-bird deadline; the cutoff is treated as fixed and owned by pricing, not by email performance",
        "Schedules the last-call for Saturday, the day before the Sunday 23:59 cutoff",
        "Targets only the not-yet-registered, cross-referenced against the registered list so no ticket holder receives it",
        "The copy states what changes and exactly when, letting the date carry the urgency - no 'last chance', 'don't miss out', countdown, or scarcity phrasing",
        "The subject names TidePool Conf and the deadline plainly, roughly in the 40-60 character range",
        "Preview text extends the subject with an additional usable fact rather than repeating it",
        "The body carries one CTA and one link",
        "The sign-off is a named human, not a team or role",
        "Does not propose a 'deadline extended' follow-up email as an alternative tactic"
      ]
    },
    {
      "id": 3,
      "prompt": "We're opening registration for CairnStack 2027, our infrastructure conference in Edinburgh, next month. I have two lists to announce it to: 1,900 addresses exported from last year's ticketing platform (everyone who bought a ticket to CairnStack 2026), and 450 people who signed up to our monthly newsletter through the form on our site, which has an opt-in checkbox for event news. Marketing wants me to merge both and send the announcement to all 2,350. There'll be an unsubscribe link obviously. Anything wrong with that plan before I hit send?",
      "expected_output": "A clear do-not-send verdict on the merged blast: the ticket-export addresses lack marketing consent, the newsletter opt-ins are mailable, provenance is recorded per address, and sign-off is required before any prior-edition reuse.",
      "files": [],
      "expectations": [
        "Evaluates the two address sources separately rather than as one merged list",
        "States that buying a ticket to CairnStack 2026 is not consent to be marketed to for 2027; the 1,900 ticket-export addresses are not mailable without a documented opt-in",
        "Treats the 450 newsletter addresses, with their explicit event-news opt-in, as mailable",
        "States what the ticket transaction did consent to: the confirmation, the practical information, and changes to it - not promotional sends",
        "Rejects the unsubscribe link as a substitute for consent",
        "Requires provenance recorded per address - which form, which edition, which box was ticked, and when - not per list",
        "Names the exposure as irreversible: the kind of mistake that can force a list deletion the event never recovers from, not merely poor practice",
        "Requires sign-off or a compliance check before any reuse of the prior-edition list",
        "Gives a clear do-not-send verdict on the merged 2,350-address send as planned",
        "Notes the announcement, being non-transactional, must carry a working unsubscribe honoured immediately",
        "Offers the compliant scope: announce now to the 450 opted-in addresses",
        "Frames the rules as jurisdiction-dependent and to be checked for where attendees are, rather than asserting one blanket regime"
      ]
    },
    {
      "id": 4,
      "prompt": "Please write the practical-info email for BarnOwl Conf, 350 attendees, Manchester, October 8-9. Here's everything from the ops team: check-in opens 8:15 both days at Whitworth Hall's main entrance on Oak Street 14, second floor via the east staircase, bring photo ID, badges are printed on site and must be worn; no cloakroom, so no large luggage; lunch and two coffee breaks are provided and dietary choices from registration are catered; wifi available; quiet room on floor 3; step-free access via the north entrance lift, and live captioning on both stages; sponsors are Datashore, Kestrel Cloud and Plinth. One thing: a separate tool called SafeDesk will email everyone about incident reporting a few days before the event - that's out of our hands. Keep the email short and skimmable: skip the code of conduct section (it's on the website and nobody reads it twice), and we have no nursing room so just leave that whole topic out.",
      "expected_output": "A complete know-before-you-go that keeps the code of conduct and accessibility sections, states the nursing-room absence, announces the SafeDesk email by name and timing, and marks missing sections as not applicable rather than inventing facts.",
      "files": [],
      "expectations": [
        "The code of conduct section is kept despite the instruction to cut it, with a link, the stated enforcement consequence, and a contact route",
        "The refusal is explained: code of conduct and accessibility decide whether someone attends at all, so they are never a length trade-off",
        "An accessibility section appears covering the given provisions (step-free north-entrance lift, live captioning), what must be requested and by when, and who to ask",
        "The nursing/parents' room absence is stated explicitly in the email rather than silently omitted",
        "The SafeDesk email is announced in advance inside this email, by name and timing",
        "The reason is present: an unannounced, differently-branded automated email gets reported as phishing or ignored as spam",
        "The email opens with event name, exact dates, and the daily opening time - no teaser or hook opener",
        "Check-in is a walked sequence: main entrance on Oak Street 14, east staircase to the second floor, photo ID ready, badges printed on site and worn",
        "The no-cloakroom / no-large-luggage restriction is included",
        "The venue address appears in plain text, not only inside a map or image",
        "Sections with no supplied facts (transit, parking, airport directions, evening events) are marked not applicable or flagged as facts to obtain - never invented",
        "The email closes with sponsor thanks naming Datashore, Kestrel Cloud and Plinth",
        "A completeness check is run or reported: every section present or explicitly not applicable, with a partial pass treated as a fail"
      ]
    },
    {
      "id": 5,
      "prompt": "Our free community event NorthStack Night runs its big annual edition on November 5 - 500 registered, the venue fits 350, and historically about 40% of free registrants don't show. I'm worried about both directions: too many people if everyone comes, too few if the usual crowd flakes. My plan is a reminder email every day of the final week to keep it top of mind, and I'd like to know how many extra registrations we should accept over 350 to compensate for the flaking. We also have the broader NorthStack community list (2,800 people, opted in) - should I keep emailing the ones who haven't registered until they do? What would you actually send?",
      "expected_output": "The daily countdown chain refused in favour of the week-before plus day-before pair, non-registered follow-ups capped at two and cross-referenced, and the overbooking arithmetic routed out as a separate structural problem.",
      "files": [],
      "expectations": [
        "Rejects the reminder-every-day final-week plan (a countdown chain) instead of adopting it",
        "Explains the cost in list terms: each extra send trains recipients to stop opening the one that matters",
        "Recommends the week-before know-before-you-go plus a short day-before nudge as the reminder pair",
        "Cites the 30-50% signup-to-attendance drop-off for free events as what makes the reminders load-bearing",
        "Does not compute or recommend an overbooking or over-registration number",
        "Reminder emails are presented as this plan's lever against no-shows, while overbooking, waitlists, deposits and seat-release are named as structural fixes owned by a separate no-show process",
        "Follow-ups to not-yet-registered community members are capped at one, maximum two",
        "Follow-ups are cross-referenced against the registered list so no registrant is asked to register",
        "Send caps are counted per segment, not across the whole list",
        "The day-before nudge carries only when-and-where plus a link back to the week-before email - no new information",
        "The 2,800-member community list receives only the capped registration follow-up, not every reminder send",
        "The follow-up to non-registered list members is treated as promotional, resting on the list's recorded opt-in, distinct from reminders to registered attendees"
      ]
    },
    {
      "id": 6,
      "prompt": "I've been brought in from an outbound sales background to help with attendee comms for TelaForge Assemble, our user conference in Austin, September 14-15. Two things I want to apply from what works in cold email: subjects should be two or three lowercase words with no name personalization, so it reads like a colleague wrote it rather than a blast; and since the ticket confirmation email has by far our best open rate, let's put a promo block for the paid workshop add-on in there. Draft the confirmation email and give me subject lines for the reminder emails on this approach.",
      "expected_output": "Both cold-email imports refused with the inversion reasoning: subjects name the event plainly, personalization is welcome, and the confirmation stays strictly transactional with the expectation-setting sentence.",
      "files": [],
      "expectations": [
        "Rejects the lowercase two-or-three-word colleague-disguise subject approach",
        "Gives the inversion reason: those tactics disguise an unsolicited sender, while a registrant is searching their inbox for this event's email",
        "Subject lines name TelaForge Assemble (and the date where relevant) plainly",
        "Subjects sit roughly in the 40-60 character range for mobile truncation",
        "States that a first-name personalization token is welcome here, inverting the cold-email finding",
        "Refuses to put the workshop promo block inside the registration confirmation",
        "Gives the reason: mixing promotional content into a transactional send is how the transactional exemption stops applying",
        "The confirmation draft carries what was registered for, the dates, a ticket or order reference, and one sentence saying a practical-information email arrives about a week before the event",
        "That forward-looking sentence is kept deliberately - it is what stops the later practical email being mistaken for marketing",
        "The workshop promo is not relocated into the know-before-you-go or the day-before nudge either",
        "Preview text extends the subject with a new usable fact instead of repeating it",
        "Each drafted email carries one primary CTA"
      ]
    },
    {
      "id": 7,
      "prompt": "For QueryCraft Conf (Berlin, March 3-4, registration is open and runs until we sell out) I want smarter email targeting. Plan A: resend every email to non-openers after 3 days with a tweaked subject. Plan B: add dietary needs, accessibility needs, and first-timer/returning fields to the registration form and use all of that to segment every email we send. Our team is me and one other volunteer, and our newsletter tool can filter lists by a field. How should we set up segmentation?",
      "expected_output": "Behavioural resends rejected structurally, the role split at the week-before send recommended as default with registration-state on top, and the attribute fields flagged as health-adjacent data with irreversible collection.",
      "files": [],
      "expectations": [
        "Rejects the resend-to-non-openers plan rather than adopting or deferring it",
        "The rejection is structural: every send moment is a calendar date, never a per-recipient behaviour",
        "Recommends the role split at the week-before send as the default segmentation",
        "Registration-state segmentation (registered / not-yet-registered) is added because both a registered list and an open registration window exist, executed as a manually filtered list",
        "Dietary and accessibility fields are flagged as health-adjacent personal data carrying retention, access and deletion obligations",
        "States that a field once collected cannot be un-collected before endorsing any collection of it",
        "Attribute segmentation (first-timer vs returning, etc.) is presented as the high-effort top rung with named promotion conditions, not the default for a two-volunteer team",
        "The recommendation is re-ranked against the stated team: two volunteers with basic filters get at most the role split plus registration-state, not full attribute segmentation",
        "Only the attendee variant of the week-before email is owned here; speaker, sponsor and volunteer variants are left to whoever owns those audiences",
        "No send in the final plan targets an opened, clicked, or gone-quiet state",
        "Behavioural segmentation is not parked as a future upgrade pending better tooling; it is treated as a different mechanic that does not belong to a dated arc",
        "If dietary or accessibility collection is endorsed at all, it is for on-site accommodation with a stated data-handling posture, not as a default email segmentation axis"
      ]
    },
    {
      "id": 8,
      "prompt": "Post-mortem numbers from last week's HollowPine Summit: the practical-info email got a 52% open rate - industry average is 21%, so I'm calling that a huge win - the day-before reminder got 48%, and we had 3 unsubscribes on the final reminder. For next year I want to set proper benchmarks: what open and click rates should a conference email program target, and how should we measure whether our attendee emails are actually working?",
      "expected_output": "The benchmark request refused - no open-rate benchmark exists for event attendee email - replaced by the two binary gates plus self-set cross-edition signals, with two signals picked and their consequences written down.",
      "files": [],
      "expectations": [
        "Refuses the industry open-rate comparison: no open- or click-rate benchmark exists for event attendee email",
        "Gives the reason: published figures are marketing-industry averages across unrelated senders and audiences, and importing one misjudges the send",
        "Does not substitute a numeric open- or click-rate target of its own for next year",
        "Names know-before-you-go completeness - every section present or explicitly not applicable - as a binary pre-send gate",
        "Names cap compliance as the second binary gate, counted per segment rather than per list",
        "Proposes counting desk questions at check-in that the email had already answered",
        "Proposes tracking late-arriving dietary and accessibility requests, read as the email asking too late rather than recipients being careless",
        "Unsubscribes and complaints per send are named as the real cadence guardrail, with any rise meaning the caps were exceeded",
        "The 3 unsubscribes are interpreted through that guardrail, not answered with a re-engagement or win-back send",
        "Proposes day-of arrival timing against the stated check-in window as a signal",
        "Self-set signals are framed as meaningful across editions, not judged inside a single edition",
        "Recommends picking two signals and writing down what each would change next edition, recorded before the event"
      ]
    },
    {
      "id": 9,
      "prompt": "Our open-source project Lintfold is throwing a free community day in Ghent on February 7 - fully open doors, no tickets, no registration, people just turn up. I want the whole email program: a signup form on the site so we can build an attendee list, then the standard sequence - announcement, reminders, know-before-you-go, day-before nudge. We already have the Lintfold release-announcements mailing list, about 4,000 addresses people joined for release notes. Lay out the sequence.",
      "expected_output": "The sequence declined: with no registration there is no list and no arc - the practical information goes on the event page once, plus a single announcement to the existing list after its consent scope is checked.",
      "files": [],
      "expectations": [
        "Does not build the requested multi-email sequence; states the arc does not apply because a no-registration event has no attendee list",
        "Declines to add the signup form whose purpose is to make a sequence possible - no constructing a list to make the arc apply",
        "Recommends publishing the practical information once on the event's own page",
        "Plus a single public announcement through channels that already exist",
        "Presents this as the correct output for the no-registration posture, not a reduced or inferior version of a real program",
        "Treats 'no registration, just turn up' as a legitimate, established posture and does not push to add registration",
        "The send to the 4,000-address release-notes list is one announcement, not the start of a reminder sequence",
        "Checks or flags the consent scope of the release-notes list - joined for release notes - before mailing it, rather than treating ownership as permission",
        "The announcement carries event name, date, city and venue, who it is for in one line, and a single link with nothing competing",
        "No reminder, day-before, or know-before-you-go email is scheduled to any list",
        "Identifies the registration posture as the deciding axis: with registration the arc would exist, without it there is nothing to sequence",
        "Does not propose collecting addresses through another mechanic (RSVP, waitlist, 'get updates' form) as a workaround to run reminders for this edition"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Write the week-before email for our 400-person Kubernetes conference", "should_trigger": true },
    { "query": "How many emails should we send attendees between now and the event?", "should_trigger": true },
    { "query": "Draft the last-call email for our early-bird deadline on Friday", "should_trigger": true },
    { "query": "Can we email last year's attendees about this year's conference?", "should_trigger": true },
    { "query": "Our free meetup gets 40% no-shows - what should the reminder emails say?", "should_trigger": true },
    { "query": "I need a know-before-you-go email for DevSummit next month", "should_trigger": true },
    { "query": "What goes in the registration confirmation email for a paid conference?", "should_trigger": true },
    { "query": "Plan the email cadence from announcement to post-event follow-up for our conference", "should_trigger": true },
    { "query": "Write the day-before reminder for tomorrow's hackathon attendees", "should_trigger": true },
    { "query": "Should the attendee reminder email use a countdown timer?", "should_trigger": true },
    { "query": "Draft the post-event thank-you email with the recording links", "should_trigger": true },
    { "query": "What subject line should our conference reminder emails use?", "should_trigger": true },
    { "query": "We're announcing our developer conference next week - write the announcement email", "should_trigger": true },
    { "query": "Segment our event emails - speakers and sponsors keep getting the wrong check-in instructions", "should_trigger": true },
    { "query": "Registration opened six weeks ago and we're at half capacity - should we send more emails?", "should_trigger": true },
    { "query": "When should the practical-info email go out relative to the event date?", "should_trigger": true },
    { "query": "Attendees keep asking where check-in is even though we told them - fix our pre-event comms", "should_trigger": true },
    { "query": "Is it OK to add a marketing paragraph to the ticket confirmation email?", "should_trigger": true },
    { "query": "Write the email telling registrants the agenda is live", "should_trigger": true },
    { "query": "How do I warn attendees that a separate tool will email them about the code of conduct?", "should_trigger": true },
    { "query": "What's a good open rate for a conference attendee email?", "should_trigger": true },
    { "query": "Our event list mixes ticket buyers and newsletter signups - who can we email what?", "should_trigger": true },
    { "query": "Give me copy for the final reminder the evening before doors open", "should_trigger": true },
    { "query": "People register for our event but never show up - what emails reduce that?", "should_trigger": true },
    { "query": "Set up the email plan for our first DevOps day - we've never emailed attendees before", "should_trigger": true },
    { "query": "What should registered folks hear from us between buying a ticket and showing up?", "should_trigger": true },
    { "query": "Write something attendees can forward to their manager to justify the ticket", "should_trigger": true },
    { "query": "How often can we email people who registered without annoying them?", "should_trigger": true },
    { "query": "The early-bird tier ends Sunday - what email should go out and when?", "should_trigger": true },
    { "query": "Do we need an unsubscribe link on event emails to our own attendees?", "should_trigger": true },
    { "query": "Checklist for the logistics email we send the week before the conference", "should_trigger": true },
    { "query": "Remind people about the meetup without sounding like a marketing robot", "should_trigger": true },
    { "query": "We use a survey tool that emails attendees afterwards - how do we introduce it beforehand?", "should_trigger": true },
    { "query": "What should the very first email about our brand-new conference say?", "should_trigger": true },
    { "query": "Nobody reads our event emails - how many should we actually be sending?", "should_trigger": true },
    { "query": "Draft the emails for a 3-day conference: confirmation, week-before, and day-before", "should_trigger": true },
    { "query": "Can I email people who started registration but didn't finish?", "should_trigger": true },
    { "query": "Our hackathon has 500 signups - build the reminder email plan", "should_trigger": true },
    { "query": "How many times can we follow up with list members who haven't registered yet?", "should_trigger": true },
    { "query": "Write the email that goes out automatically when someone buys a ticket", "should_trigger": true },
    { "query": "What info has to reach people before an in-person meetup so they actually find the room?", "should_trigger": true },
    { "query": "Help me not spam our attendees but still fill the room", "should_trigger": true },
    { "query": "Compose the sold-out morning-of message to everyone attending today", "should_trigger": true },
    { "query": "We collected emails at our booth last year - can those get this year's announcement?", "should_trigger": true },
    { "query": "Our event emails sound like ChatGPT wrote them - fix the drafts before they go out", "should_trigger": true },
    { "query": "Map every email to a date for our conference - announcement March 3, doors June 12", "should_trigger": true },
    { "query": "Should we email attendees daily during the last week before the event?", "should_trigger": true },
    { "query": "What's the difference between what ticket-holders and not-yet-registered people should receive?", "should_trigger": true },
    { "query": "Our know-before-you-go email is too long - what sections can we cut?", "should_trigger": true },
    { "query": "Write a reminder that doesn't bury the check-in time", "should_trigger": true },
    { "query": "Attendees say they never got the practical details - audit our event email plan", "should_trigger": true },
    { "query": "Send registered attendees the arrival instructions - draft it for me", "should_trigger": true },
    { "query": "How much should we overbook our free event to absorb no-shows?", "should_trigger": false },
    { "query": "Set up the waitlist and seat-release flow for our sold-out conference", "should_trigger": false },
    { "query": "Should we take a refundable deposit to cut no-shows at our free event?", "should_trigger": false },
    { "query": "Build the attendee-acquisition marketing plan for our conference", "should_trigger": false },
    { "query": "Which channels should we promote our conference on and with what budget split?", "should_trigger": false },
    { "query": "When should early-bird pricing end and how big should the price jump be?", "should_trigger": false },
    { "query": "Set the ticket price ladder for students versus employer-funded attendees", "should_trigger": false },
    { "query": "Write the cold outreach message inviting a well-known maintainer to keynote", "should_trigger": false },
    { "query": "Draft the sponsorship outreach email sequence for our conference", "should_trigger": false },
    { "query": "How many follow-ups should we send a sponsor prospect who went quiet?", "should_trigger": false },
    { "query": "Plan the speaker comms: slide deadlines, tech check, and green room logistics", "should_trigger": false },
    { "query": "What should the sponsor day-of logistics email cover - load-in, power, WiFi?", "should_trigger": false },
    { "query": "Design our conference check-in desk and badge pickup flow", "should_trigger": false },
    { "query": "Where should the quiet room go and how do we handle dietary restrictions on site?", "should_trigger": false },
    { "query": "Write the post-event feedback survey questions for attendees", "should_trigger": false },
    { "query": "Design the satisfaction survey for our hackathon participants", "should_trigger": false },
    { "query": "Draft our event's code of conduct and the enforcement process behind it", "should_trigger": false },
    { "query": "Should our event have a Discord, an app, or a status page for day-of announcements?", "should_trigger": false },
    { "query": "Keep our meetup community engaged in the months between editions", "should_trigger": false },
    { "query": "Announce the CFP on social media and plan the speaker-reveal posts", "should_trigger": false },
    { "query": "Pick a date for our conference so it doesn't clash with KubeCon", "should_trigger": false },
    { "query": "Build the months-long planning timeline working back from doors open", "should_trigger": false },
    { "query": "How do we turn the talk recordings into a publishing schedule after the event?", "should_trigger": false },
    { "query": "Structure a newsletter mention swap with a partner conference", "should_trigger": false },
    { "query": "Design a 7-email onboarding drip for our SaaS trial users", "should_trigger": false },
    { "query": "Write a cold email sequence for B2B prospecting - four touches", "should_trigger": false },
    { "query": "What's the best subject line formula for cold outreach?", "should_trigger": false },
    { "query": "Set up an abandoned-cart email flow for our store", "should_trigger": false },
    { "query": "Build a win-back campaign for churned subscribers", "should_trigger": false },
    { "query": "Write this week's edition of our developer newsletter", "should_trigger": false },
    { "query": "Improve deliverability - our marketing emails keep landing in spam", "should_trigger": false },
    { "query": "Set up DKIM and SPF records for our sending domain", "should_trigger": false },
    { "query": "Create a lead-nurture sequence in our CRM with branching on opens", "should_trigger": false },
    { "query": "Draft a product-launch email to our customer base", "should_trigger": false },
    { "query": "Write a re-engagement email for inactive app users", "should_trigger": false },
    { "query": "Email sequence to convert webinar signups into sales demos", "should_trigger": false },
    { "query": "How many nurture emails before we ask for a sales call?", "should_trigger": false },
    { "query": "Plan our Black Friday email campaign calendar", "should_trigger": false },
    { "query": "Optimize our email open rates with A/B subject-line tests", "should_trigger": false },
    { "query": "Write the transactional password-reset email copy for our app", "should_trigger": false },
    { "query": "Can we buy an email list of CTOs for outbound?", "should_trigger": false },
    { "query": "Segment our SaaS users by product activity for a targeted campaign", "should_trigger": false },
    { "query": "Invite the VIP guests to the private speaker dinner", "should_trigger": false },
    { "query": "How should we schedule social posts during the conference itself?", "should_trigger": false },
    { "query": "What goes into the sponsorship prospectus for our conference?", "should_trigger": false },
    { "query": "Set the badge privacy and lead-scanning consent policy for the expo floor", "should_trigger": false },
    { "query": "Write the minute-by-minute run of show for the day of the event", "should_trigger": false },
    { "query": "Recruit volunteers for our conference and plan their shifts", "should_trigger": false },
    { "query": "Our event landing page needs its registration CTA to switch states by date", "should_trigger": false },
    { "query": "Choose between a meetup, a hackathon, or a full conference for our launch", "should_trigger": false },
    { "query": "Announce our new open-source release to the project's GitHub watchers", "should_trigger": false },
    { "query": "Write the press release announcing our conference's keynote lineup", "should_trigger": false }
  ]
}

# The attendee email arc, send by send

Every send below fires on a **date**, never on a per-recipient behaviour. The dates themselves arrive fixed from the marketing plan and `samber/dev-event-organizer-skills@event-ticket-pricing` - this file says what goes inside each send, not when it happens.

Contents: Announcement · Registration confirmation · Agenda release · Last call · Know-before-you-go · Day-before nudge · Post-event thank-you · The no-registration collapse · What never belongs in any of them

---

## 1. Announcement

**Fires on**: the announcement date fixed by the marketing plan.
**Segment**: the whole list, plus any prior-edition list that passes the consent check.
**One job**: this event exists, it is dated, here is where to look.

Must carry: event name, exact dates, city and venue-or-online, who it is for in one line, and a single link to the landing page. Nothing else competes for the click.

The forwardable variant: when attendees typically need an employer's approval, add one short paragraph the recipient can forward without editing - dates, total cost including travel, and what the company gets from sending someone. Keep it a paragraph inside the same email, not a second send.

Must not carry: a full agenda that does not exist yet, a countdown, or a price `samber/dev-event-organizer-skills@event-ticket-pricing` has not published.

## 2. Registration confirmation

**Fires on**: registration itself. Transactional, so it goes to everyone regardless of marketing consent.
**Segment**: the individual registrant.
**One job**: prove the registration worked, and say what arrives next and roughly when.

Must carry: what they registered for, the dates, any order or ticket reference, and one sentence setting the expectation that a practical-information email arrives about a week before. That sentence is what stops the know-before-you-go being mistaken for a marketing send later.

Must not carry: a promotional block. Mixing marketing content into a transactional send is how a transactional exemption stops applying.

## 3. Agenda / speaker release

**Fires on**: the agenda-release date fixed by the marketing plan.
**Segment**: everyone, though its purpose is the not-yet-registered.
**One job**: give someone who waited a concrete reason.

Must carry: two or three specific things now confirmed - a named speaker, a track, a workshop - and the link to the full program. Specificity is the whole value; "an amazing lineup" says nothing a reader can act on.

Optional and skippable: this send is the first thing to cut when the runway is short or the cadence budget is tight.

## 4. Last call

**Fires on**: the day before a cutoff `samber/dev-event-organizer-skills@event-ticket-pricing` owns - early-bird close, a price-tier change, or a capacity cap.
**Segment**: the not-yet-registered only, cross-referenced against the registered list.
**One job**: state one dated fact.

Must carry: what changes, exactly when, and the link. The date does the work; you do not need urgency language because the deadline is real.

Must not carry: an invented deadline, a manufactured scarcity claim, or a second last-call after the first. One cutoff, one email. If there is no real cutoff, there is no last-call email.

## 5. Know-before-you-go

**Fires on**: roughly one week before doors.
**Segment**: registered attendees, split by role - you write the attendee variant.
**One job**: everything needed to arrive prepared, in one place they can find again.

Its full structure has its own reference file. Two rules belong here:

- every fact in it comes from `samber/dev-event-organizer-skills@event-attendee-experience` rather than from you
- the code of conduct and accessibility sections are not optional

## 6. Day-before nudge

**Fires on**: the evening before, or early the morning of for a full-day event.
**Segment**: registered attendees.
**One job**: the one thing - when and where.

Must carry: check-in opening time, the address, and a single link back to the know-before-you-go. Three lines is a good length. This is the email people read on a phone while walking.

Must not carry: new information. Anything that appears here for the first time was missing from the email a week ago, and a third of the recipients will never see it.

## 7. Post-event thank-you

**Fires on**: one to three days after.
**Segment**: everyone who registered, including no-shows - a no-show who receives the recordings is next edition's attendee.
**One job**: thank people, deliver what was promised, and hand off to feedback.

Must carry: thanks, links to recordings or slides when they exist (or an honest date for when they will), and the feedback survey link. The survey instrument itself belongs to `samber/dev-event-organizer-skills@event-feedback`; you write the email around it.

Optional: the next edition's date, if it is actually fixed. A "save the date" for a date that later moves costs more than the goodwill it buys.

---

## The no-registration collapse

An event with no registration has no attendee list, so this arc does not apply. The identity-consistent output is the practical information published once on the event's own page, plus a single public announcement through whatever channels the marketing plan already uses.

That is the right answer for that posture, not a reduced version of a real sequence. Do not construct a list to make the arc apply.

## What never belongs in any of these emails

- **Anything the marketing plan or `samber/dev-event-organizer-skills@event-ticket-pricing` owns.** A date you would prefer, a price you inferred, a cutoff you moved.
- **On-site facts you did not receive.** A guessed check-in time in a reminder produces a queue at the wrong hour.
- **No-show mechanics.** Overbooking, waitlists, deposits and seat-release are structural fixes owned elsewhere; the reminder email is the only lever in this skill.
- **Speaker, sponsor or volunteer instructions.** Their versions of the week-before email exist, and other skills own them.
- **A second automated email that has not been announced.** Whenever a differently-branded tool will email attendees, name it and its timing in the send before it.

# Email craft and worked copy

## Table of Contents

- [Subject lines](#subject-lines)
- [Preview text](#preview-text)
- [The body shape](#the-body-shape)
- [Formatting](#formatting)
- [Banned moves](#banned-moves)
- [The humanizer pass](#the-humanizer-pass)
- [Worked copy: the last-call email](#worked-copy-the-last-call-email)
- [Worked copy: the day-before nudge](#worked-copy-the-day-before-nudge)

## Subject lines

- **Name the event.** The recipient is searching their inbox for it. Roughly 40-60 characters, since most opens happen on a phone and the tail gets truncated.
- **Clear beats clever, specific beats vague.** "DevOpsDays Chicago: what to know before Thursday" beats "Almost time!".
- **A first name is welcome, not suspicious.** Cold-email research says a personalization token signals automation and hurts replies - that finding inverts here, because the sender legitimately holds a registration record and the recipient knows it.
- **Never disguise the sender.** Lowercase fragments and colleague-imitating phrasing exist to defeat a stranger's spam filter. Your recipient consented; hiding your identity makes their search fail.

## Preview text

Treat it as a real field, not a leftover. 40-90 characters that **extend** the subject rather than repeat it. If the subject is "What to know before Thursday", the preview carries "Doors 8:30, check-in on the 2nd floor, full details inside" - the reader gets a usable fact before opening anything.

## The body shape

Five parts, one job per email:

1. **Hook** - the first line earns the open. For an event email that means the single most useful fact, not a greeting.
2. **Context** - why this matters to _this_ recipient right now, in one sentence.
3. **Value** - the actual content: the sections, the dates, the instructions.
4. **CTA** - one primary action, one link. A second competing link halves the first one.
5. **Sign-off** - a human name and a real reply route. The organizer's own voice is the credibility in this channel.

## Formatting

- Short paragraphs, one to three sentences.
- Scannable headings and bullets for anything with more than three facts - the sourced email is almost entirely headed sections for exactly this reason.
- Mobile-first: assume a narrow screen and a thumb.
- Bold sparingly, on facts the reader will look for twice (times, addresses, deadlines).
- Put the address and the time in **text**, never only inside an image. Images are blocked by default in many clients, and the address is the one thing that must survive that.

## Banned moves

- Manufactured urgency. If the deadline is real, the date carries it. If it is not real, do not invent one.
- Two CTAs of equal weight.
- New information in the day-before nudge.
- Promotional content inside a transactional confirmation.
- Any claim about the event you have not confirmed with the sibling that owns it.

## The humanizer pass

Run every drafted email through your preferred humanizer skill before it goes anywhere. Never ship a raw first draft - a room of developers reads model-shaped prose all day, and this is the channel where the organizer sounding like a person is the entire point.

What to look for on the way out:

- Stock openers ("We're thrilled to announce", "As you may know", "In today's fast-paced world").
- Adjective inflation - "incredible", "amazing", "unforgettable" - carrying no fact.
- Rule-of-three lists that pad rather than enumerate.
- Uniform sentence length across a whole paragraph.
- Em-dash rhythm repeated in every paragraph.
- A sign-off from a role rather than a person.

Read the result aloud. If it does not sound like the organizer talking, it is not finished.

---

## Worked copy: the last-call email

Written for this skill, not a send anyone observed. The event, the names and the dates are invented; the rules they demonstrate are the ones above.

**Positive.**

> **Subject:** Early-bird pricing for PyConf Nantes ends Friday
> **Preview:** Standard tickets start Saturday; nothing else changes.
>
> Early-bird tickets for PyConf Nantes close this Friday, 14 March, at 23:59 CET. After that, standard pricing applies for the rest of the sale.
>
> That's the only change - same programme, same venue, same two days on 8-9 May. If you were already planning to come, it's worth doing before Friday.
>
> [Get a ticket]
>
> - Claire, on behalf of the organizing team

Why it works: one dated fact stated exactly, no invented scarcity, one link, and a named human. The reader can act or ignore it in five seconds.

**Negative.**

> **Subject:** ⏰ LAST CHANCE - don't miss out!!
> **Preview:** ⏰ LAST CHANCE - don't miss out!!
>
> This is your FINAL opportunity to secure your spot at the most anticipated Python event of the year. Tickets are going fast and we'd hate for you to miss this incredible experience.
>
> Spots are limited! [Register now] or [see the schedule] or [follow us on social]
>
> The Team

Why it fails:

- the event is never named in the subject, so the email is unfindable later
- the preview repeats the subject and wastes the field
- "Going fast" and "limited" are unverified claims
- three competing CTAs
- no date anywhere, the one fact the email exists to deliver
- no human signs it

## Worked copy: the day-before nudge

**Positive.**

> **Subject:** PyConf Nantes tomorrow - doors at 8:30
> **Preview:** Check-in is on the ground floor, Halle 6. See you there.
>
> PyConf Nantes starts tomorrow. Check-in opens at 8:30 on the ground floor of Halle 6, 24 boulevard de Chantenay. Bring something with your name on it; badges are printed on site.
>
> Everything else - schedule, food, transit, accessibility - is in [last week's email].
>
> - Claire

Why it works:

- three lines, one job
- time and address in text, so they survive blocked images
- one link, pointing back rather than forward
- nothing new appears here for the first time

**Negative.**

> **Subject:** See you tomorrow!
> **Preview:** We can't wait!
>
> We're so excited to welcome you tomorrow! Quick reminder that we've moved the workshop track to Room B, and there's now a pre-event breakfast at 8:00 for anyone who wants to join. Also, please remember to bring your own laptop charger as we have limited outlets.
>
> Can't wait to see everyone!

Why it fails:

- the event is unnamed, so it is unsearchable
- three pieces of genuinely new information (a room change, a new breakfast, a hardware requirement) land in the send with the lowest read rate of the whole arc
- anyone who does not open it arrives to a moved room
- no time, no address

# The know-before-you-go email

## The opening

The email opens by naming the event, the exact dates, and the daily opening time for registration, breakfast and sponsor tables. No hook, no teaser, no disguised subject line - the recipient is searching their inbox for this email, and the first three facts are what they are searching for.

## The 14 sections in order

1. **Code of Conduct** - a link to read it, the stated enforcement consequence (removal without refund, at organizer discretion), and advance notice that a separate automated email from a code-of-conduct reporting tool arrives about a week out. That advance notice is the single most transferable device in the whole email: naming a second, differently-branded email before it arrives stops it being reported as phishing or ignored as spam.
2. **Health and safety** - the event's actual policy that year, a practical tip to check any required documents before leaving home, and a named contact address for questions.
3. **Location** - venue name, full address, an embedded map image linked to a fuller location page.
4. **Registration / check-in** - a numbered, physically walked sequence: which entrance, which floor, which stairs or elevator, what to have ready, that badges must be worn. Plus stated restrictions (no large bags, no bag or coat check). Walk the route in your head while drafting; a reader who has never been in the building cannot fill a gap.
5. **Evening events** - a night-by-night list of unofficial but organizer-endorsed gatherings, each with its own RSVP link, flagged where advance registration is required. Framed as "please support them" rather than as official programming, which is what keeps the endorsement honest.
6. **Schedule** - links to the lineup and the full program, a prompt to think ahead about any participatory format the event runs, and a note that talks are live-transcribed.
7. **Social media** - the event hashtag, an explicit ask to post, the event's own handles.
8. **WiFi** - one line that it exists, plus a courtesy note that it is shared.
9. **Food and drink** - the meal schedule, confirmation that dietary restrictions collected at registration will be accommodated, where to ask, and a linked local dining guide.
10. **Directions from the airports** - named routes and approximate travel times.
11. **Transit directions within the city** - named lines, specific stations, transfers.
12. **Driving and parking** - a linked parking-finder rather than a list that goes stale.
13. **Nursing / parents' room** - the private space and its facilities, with a pointer to ask at the desk.
14. **Contact us** - how to recognise an organizer on sight (a coloured shirt), plus an address and a social route usable _during_ the event.

The email closes with **sponsor thanks** and a linked sponsor page.

## Non-negotiable sections

Two sections are never cut for length, because both decide whether someone attends at all rather than how smoothly they attend:

- **Code of conduct** - the link, the consequence, and who to contact. Content owned by `samber/dev-event-organizer-skills@event-code-of-conduct`; you link to it, you do not restate it.
- **Accessibility** - what the venue provides, what has to be requested and by when, and who to ask. The sourced email carries this across several sections (transcription, the nursing room, step-free routing inside the check-in walk-through); a smaller event can consolidate it into one section, but not omit it.

## Conditional sections

Include when true, and say plainly when not applicable rather than leaving a silent gap:

- Health and safety, when a policy exists that year.
- Evening events, when any exist and the organizers are willing to endorse them.
- Airport directions, when a meaningful share of attendees fly in.
- Parking, when driving is realistic at that venue.
- Nursing room, when the venue provides one - and if it does not, that absence is itself worth stating, because someone is planning around it.

## Adaptation for smaller events

A 40-person meetup does not need 14 sections, but it needs the same _coverage_, consolidated:

- Merge location, transit and parking into one "getting there" block.
- Merge food, WiFi and facilities into one "on the day" block.
- Keep code of conduct, accessibility, check-in and contact as their own sections regardless of size - those four are what people actually search the email for.

Consolidation is a formatting decision. Omission is a content decision, and every omission should be a stated one.

## The completeness checklist

Run before sending. Every line is either satisfied or explicitly marked not applicable to this event; a partial pass is a fail, and the fix is to get the missing fact rather than to soften the sentence.

- [ ] Event name, exact dates and daily opening time in the first three lines
- [ ] Code of conduct linked, with its consequence and its contact route
- [ ] Any separate automated email announced in advance, by name and timing
- [ ] Venue name and full address, in text and not only inside an image
- [ ] Check-in walked step by step: entrance, floor, route, what to have ready, badge rule
- [ ] Stated restrictions (bags, coat check, re-entry) or a note that none apply
- [ ] Accessibility provisions, plus what must be requested and by when
- [ ] Schedule link, and how participatory formats work if the event runs any
- [ ] Food and dietary handling, or a clear statement that food is not provided
- [ ] Getting there: transit, driving and parking, each present or marked not applicable
- [ ] Nursing or parents' facilities, present or their absence stated
- [ ] WiFi
- [ ] Hashtag and the event's own handles
- [ ] How to identify an organizer on site, plus a contact route usable during the event
- [ ] Sponsor thanks
- [ ] Every on-site fact traceable to `samber/dev-event-organizer-skills@event-attendee-experience` rather than to your own assumption

# Open-rate and click-rate benchmark evidence

What exists, what it actually measures, and why it stops short of a target figure for the confirmation, reminder and post-event sends this skill writes.

## The one named-organizer benchmark found

Eventbrite's benchmarking survey of 340-plus event organizers across the US and UK, about half running professional events, meetings and conferences, reports:

- **Open rate: 21-30%** across the surveyed organizers' event email.
- **Click-through rate: 2.1-3%**, with the top 14% of organizers reporting a CTR above 11%.
- **List unsubscribe rate: roughly 25% of a list over the course of a year.**

This is the only figure found anywhere that is scoped to event organizers sending event email, rather than a cross-industry marketing average. It still falls short of a usable target for two structural reasons:

- **It predates the 2021 change to how mail clients pre-load remote images for privacy**, which fires an "open" event whether or not a human ever saw the message. Every open-rate figure measured since reads higher for this reason alone, so the 21-30% floor is not comparable to a number pulled from a modern email platform's dashboard without adjustment.
- **It does not separate promotional list-building sends from post-registration sends.** The surveyed organizers' "event email" almost certainly blends ticket-sale marketing to prospects with the confirmation, reminder and post-event sends this skill covers, sent to people who already registered. The two audiences behave differently: a stranger deciding whether to buy a ticket and a confirmed attendee expecting logistics information are not the same open-rate population.

Read the figures as a rough sanity floor: an event send landing far below 21% open or 2% click is worth a second look. Do not read them as a pass/fail bar, and never report against them as if they measured this skill's own send types.

## What was checked and confirmed absent

- **No reply-rate figure exists for event attendee email in any source found**, published or vendor-claimed. Survey response-rate figures exist (see `samber/dev-event-organizer-skills@event-feedback`) but measure a different behavior: filling out a feedback form, not replying to an operational email.
- **Cvent and Bizzabo do not publish open-rate or click-rate figures for attendee email.** Both vendors' public "state of events" reporting covers attendance, engagement and ROI attribution; a third-party platform comparison names Bizzabo's email engagement analytics specifically as weak relative to Cvent's, which is consistent with neither vendor treating this as a benchmark they compete on.
- **Sender-industry benchmarks (MailerLite, Mailchimp, GetResponse and similar "entertainment and events" categories) do not isolate attendee email.** These figures bucket by the sending business's self-declared industry, not by email type, so they mix any company that happens to sell tickets or run venues with the specific confirmation/reminder/post-event sends this skill is about. Importing one would repeat the exact mistake this skill's measurement section warns against.
- **Transactional-versus-marketing email benchmarks (Omnisend, Experian and similar) confirm that a triggered, expected send outperforms a promotional one by a wide margin**, which supports treating a confirmation email differently from a cold marketing blast in principle. The underlying data is e-commerce order and shipping confirmations, not event registrations, so it is directional support for the general shape of the argument, not a number to cite as an event figure.

---
name: event-attendee-email-sequences
description: Design and write the attendee email arc for a technical event - the sequence, the cadence, and the actual copy. Covers the dated arc from announcement to post-event follow-up, a sourced reminder cadence with per-segment caps rather than a SaaS drip, the know-before-you-go email, role and registration-state segmentation, consent and list hygiene, and a humanizer pass before anything sends. Use whenever asked to write an event announcement email, registration confirmation, week-before or day-before reminder, know-before-you-go, day-of or post-event follow-up, or to decide how many emails to send and when. Do NOT use for overbooking, waitlists or seat release - use samber/dev-event-organizer-skills@event-no-show-management.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.0"
---

# 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](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](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](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 sourced caps; the top rung _is_ the ceiling, not permission to exceed it. Ranking (default, not a law - Q3 and Q8 re-rank it):

- effort (sends composed, lists filtered per send, coordination): `full sourced ceiling > two-pass registration follow-up > week-before plus day-before > single week-before`
- value (bodies in the room on the day): `full sourced ceiling > week-before plus day-before == two-pass registration follow-up > single week-before`
- efficiency: `week-before plus day-before > single week-before > two-pass registration follow-up > full sourced ceiling`
- compliance cost (review triggered, reversibility lost): `full sourced ceiling > two-pass registration follow-up`; the week-before and day-before sends go to registered attendees about the event they registered for and carry none. The ceiling's win-back reuses a prior edition's list, the one reuse § Consent names as irreversible; the follow-up mails people who have _not_ registered, which is promotional rather than transactional and needs its own recorded opt-in per address.

The `==` is genuine and worth the sentence: the day-before nudge converts an already-registered person into someone who turns up, while the registration follow-up converts an interested person into a registration that still faces the sourced 30-50% drop-off. Comparable expected bodies in the room, bought from opposite ends of the funnel. That tie plus the effort gap is what forces the day-before pair above the follow-up on efficiency - the one dominance constraint this menu carries, and it is respected.

- **Single week-before reminder** - one send, one week out, split by role. MLH's own minimum, and the send its guide treats as the essential one.
- **Week-before plus day-before** - the default: the know-before-you-go at one week, then a short evening-before nudge carrying one fact. **Promotion condition**: add the two-pass registration follow-up on top when the registration curve is behind its checkpoint on the plan's spine - a capacity problem, not a cadence preference.
- **Two-pass registration follow-up** - MLH's capped "1 or a maximum of 2" follow-ups to people who have not registered, cross-referenced against the registered list so no registrant is asked to register. Costs real list work per send, which is why efficiency puts it below the cheaper pair it ties with on value.
- **Full sourced ceiling** - the starved option: all four sourced passes at once (registration follow-up capped at two, prior-year win-back, one engagement update, the week-before role split). Tops value and effort, so efficiency never picks it. **Promotion conditions**: a free event where the drop-off is the binding constraint (Q3), a consented prior-year list (Q2), and someone who owns list filtering (Q8).
- **Deleted, not demoted: the countdown chain.** Seven days, three days, two days, tomorrow, this morning. It exceeds every sourced cap, it is the exact behaviour MLH's anti-spam instruction names, and each send trains the recipient to stop opening the one that matters.
- **Conditional delete.** When the audience is a single standing community list with no separate registration step - a recurring meetup where the list _is_ the audience - delete the two-pass registration follow-up and the full sourced ceiling from this menu and from the axis lines above. There is no "not yet registered" segment to write to.

## Segmentation depth

Who gets which version. Ranking (default, not a law - Q8 and Q10 re-rank it):

- effort (list filtering per send, copy variants written, tooling required): `attribute segments > registration-state segments > role split at the week-before send > one list one send`
- value (each recipient gets the one instruction that applies to them): `attribute segments > role split at the week-before send == registration-state segments > one list one send`
- efficiency: `role split at the week-before send > registration-state segments > one list one send > attribute segments`
- compliance cost (review triggered, reversibility lost): attribute segments alone carry any; the other three rungs slice a list you already hold and add none beyond its own consent record. Dietary and accessibility flags are health-adjacent personal data, so holding them per recipient is a retention, access and deletion decision - and a field once collected cannot be un-collected.

The `==` is genuine: both rungs remove a wrong-message-to-wrong-person error of comparable size. The role split stops an attendee's check-in time being buried under sponsor load-in instructions; registration-state stops "register now" landing on someone who already paid. One error at the door, one at the top of the funnel.

Because the role split costs less to produce, it dominates registration-state outright - and efficiency respects that, which is the one dominance constraint here.

- **One list, one send** - everyone receives the same email. Near-zero effort, and everyone does still get the know-before-you-go, which is why it is not last on efficiency.
- **Role split at the week-before send** - the default and MLH's sourced minimum: attendees, speakers, sponsors, volunteers and judges each get their own check-in instruction. You write the attendee variant only. **Promotion condition**: add registration-state segments the moment the event has both a registered list and an open registration window.
- **Registration-state segments** - registered / not yet registered / last year's attendees, filtered manually per send. MLH assumes exactly this: a filtered list, not behavioural tooling.
- **Attribute segments** - the starved option: first-timer vs returning, local vs travelling, workshop ticket vs conference only, dietary and accessibility flags. Tops value and effort, so efficiency never picks it. **Promotion conditions, keyed to Q11**: a large first-timer share where orientation is a stated goal, or international attendees whose visa-letter and travel lead times differ enough that one email cannot serve both.
- **Deleted, not demoted: behavioural segments.** Opened, clicked, did not open. It needs tooling the pole this collection sources from does not have, and it targets a per-recipient behaviour when every send moment here is a fixed date.
- **Conditional delete.** When the only tool is a plain announce list with no per-recipient filtering, delete registration-state and attribute segments from this menu and from the axis lines above. Keep the role split by maintaining separate lists per role and sending to each.

## Consent and list hygiene

The mailing list is the event's highest-value acquisition channel and the one asset whose loss cannot be undone. A list collected for one edition and mailed for the next without a documented opt-in is the single exposure in this whole skill that can force a deletion the event never recovers from.

- **A ticket purchase is not consent to be marketed to.** It is consent to receive what the transaction requires: the confirmation, the practical information, and the changes to it. Anything promotional needs its own recorded opt-in, taken at the moment the address was collected.
- **Record provenance per address, not per list** - which form, which edition, which box was ticked, and when. Q2 asks this per source for that reason. A merged list whose provenance is "we think most of them opted in" is not auditable.
- **Every non-transactional send carries a working unsubscribe**, honoured immediately rather than at the next scheduled send.
- **Announce a second, differently-branded automated email before it arrives.** The sourced devopsdays email does exactly this, warning attendees a week ahead that a separate tool would email them about the code of conduct. An unannounced email from a name the recipient does not recognise reads as phishing and gets reported, which costs the sending domain more than the email was worth.
- **The rules differ by jurisdiction and by list.** Consent, retention and unsubscribe obligations for an attendee list are a real compliance question, not a style preference - check the current rules for where your attendees are, and get sign-off before reusing a prior edition's list.

## Failure modes

- **Importing a SaaS drip cadence.** Five to ten sends with behavioural branching, dropped onto a dated arc. It roughly triples the sourced organizer norm and needs tooling the event does not have. The cadence is thin on purpose.
- **Exceeding the sourced caps because the room is not full.** A soft registration curve is a diagnosis for the marketing plan, not a licence for a fifth reminder. More sends to a list that is already ignoring you converts a soft curve into a burned list.
- **A know-before-you-go missing the code of conduct or the accessibility line.** Both are in the sourced structure, and both are exactly the information that decides whether someone attends at all. Omitting them is not a length trade-off.
- **Treating consent as implied by the ticket purchase.** See above; this is the one failure with an irreversible outcome.
- **Solving no-shows here.** Writing overbooking ratios, waitlist mechanics or deposit rules into the reminder plan. Answer with the reminder emails, then route to `samber/dev-event-organizer-skills@event-no-show-management`.
- **Moving a date so an email lands better.** The announcement, agenda release and early-bird cutoff arrive fixed. An email that wants a different date is an email written to the wrong date.
- **Inventing the on-site facts.** Check-in location, badge policy, quiet room, dietary mechanics - all of it belongs to `samber/dev-event-organizer-skills@event-attendee-experience`. A confidently wrong check-in time in a reminder is worse than no reminder.
- **Writing the speaker or sponsor variant of the week-before email.** The role split is yours; the other roles' content is not.
- **Borrowing cold-email subject-line tactics.** Lowercase two-word subjects and hidden sender identity, aimed at a recipient who is searching their inbox for your event's name.
- **Shipping raw model output.** A first draft that skipped the humanizer pass reads as one, in the one channel where the organizer's own voice is the product.
- **Announcing nothing about the second automated email.** The recipient reports it as phishing, and the report lands on your sending domain.

## Measurement

**Treat any published open-rate or click-rate figure as a rough sanity floor, never a target.** Most figures you will find are marketing-industry averages blending unrelated senders and audiences with the post-registration sends this skill covers, and importing one as a pass/fail bar is how a healthy send gets declared a failure. The closest available figure sits at 21-30% open rate and 2.1-3% click-through rate, and even that one predates a since-2021 measurement shift and blends promotional sends with the confirmation, reminder and post-event sends this skill actually writes; no reply-rate figure exists at all. Sourcing and the full caveats: [references/open-click-benchmark-evidence.md](references/open-click-benchmark-evidence.md). Refuse a hard target built on any of this, say why, and measure the two things that are actually binary here plus a few self-set signals.

Two binary gates, both checkable before sending:

- **Know-before-you-go completeness** - every section of the sourced 14-section structure is either present or explicitly noted as not applying to this event. Iterate until this passes; a partial pass is a fail.
- **Cap compliance** - no segment receives more sends than the sourced caps allow. Count per segment, not per list.

Self-set signals, meaningful only across editions:

- **Desk questions the email already answered** - count at check-in, by question. The cheapest and most honest measure of whether the know-before-you-go worked, and this skill's own construction rather than anything sourced.
- **Late arrivals of dietary and accessibility requests** - replies to the pre-event email asking for something that needed two weeks' notice mean the email asked too late, not that people were careless.
- **Unsubscribes and complaints per send** - the only real cadence guardrail available. Any rise is the caps being exceeded, whatever the calendar said.
- **Day-of arrival timing against the stated check-in window** - a crowd at the wrong hour is an email problem before it is a desk problem.

Pick two of the self-set signals, write down what each would change next edition, and record both before the event.

## Invocation examples

- "Write the week-before email for our 300-person conference - first edition, we have no idea what to put in it."
- "How many emails should we send between now and the event? Registration opened six weeks ago and we're at half capacity."
- "Draft the last-call email for the early-bird deadline on Friday."
- "We collected emails at last year's event. Can we mail that list about this one?"
- "Our free meetup gets 40% no-shows. What should the reminder emails say?"

Expected output: a dated send map with one job per email, the chosen cadence stated against the sourced caps, the segment each send goes to, humanized copy for every email including a complete know-before-you-go, a consent check per address source, and an explicit routing of anything structural to the sibling that owns it.

## References

- [references/arc-and-send-map.md](references/arc-and-send-map.md) - every send in the arc: trigger date, its one job, required contents, what it must not carry, its segment, and the no-registration collapse.
- [references/know-before-you-go-email.md](references/know-before-you-go-email.md) - the sourced 14-section structure in its real order, which sections are conditional, adaptation rules for smaller events, and the completeness checklist the measurement gate uses.
- [references/email-craft-and-worked-copy.md](references/email-craft-and-worked-copy.md) - subject and preview-text rules, the five-part body shape, mobile formatting, the humanizer checklist, and worked positive and negative copy for the last-call and day-before emails.
- [references/open-click-benchmark-evidence.md](references/open-click-benchmark-evidence.md) - the one named-organizer open/click benchmark found, why it falls short of a target figure, and what was checked and confirmed absent.
- `samber/dev-event-organizer-skills@event-marketing-plan` - the umbrella. Hands down the calendar spine, email's channel weight and every fixed date; also the source of the consent discipline this skill enforces.
- `samber/dev-event-organizer-skills@event-ticket-pricing` - owns the early-bird and price-tier cutoffs the last-call email reacts to and never sets.
- `samber/dev-event-organizer-skills@event-attendee-experience` - the source of truth for every on-site fact the pre-event and day-of emails describe.
- `samber/dev-event-organizer-skills@event-no-show-management` - owns the no-show problem's structural fixes; this skill's reminder cadence is one input into that model, not a substitute.
- `samber/dev-event-organizer-skills@event-feedback` - owns the post-event survey instrument this skill's final email carries.
- `samber/dev-event-organizer-skills@event-code-of-conduct` - owns the content the code-of-conduct section of the know-before-you-go email links to.