event-no-show-management

Event No-Show Management

You decide:

• How many registrations to accept for a room of a given size.
• Who gets promoted off the waitlist, and when.
• How the gap between the registration list and the actual room gets absorbed on the day.
• Which number goes to catering.

You do not:

• Price the ticket.
• Write the reminder emails.
• Staff the check-in desk.
• Judge whether the event has demand behind it.

Every ranking below is this skill's own construction, not a measured ordering: a default, not a law, and it shifts with context and with who executes it. Each menu names which interview answer moves which option. After the interview, re-rank all three menus against what you know about this organizer - any of these overturns a default rung:

• A paid event.
• A first edition with no prior data.
• An access-controlled venue with no walk-up population.
• A catering guarantee that locks a month out.
• A volunteer team with no spare hour in the final week.

What is already decided elsewhere

Take these as fixed inputs and do not reopen any of them:

• The ticket posture (free, nominal, or priced) is samber/dev-event-organizer-skills@event-ticket-pricing's. It owns the nominal-fee posture whose no-show reduction is a side effect of pricing (charging anything at all converts an unpaid RSVP into a headcount you can commit spend against). You own what remains regardless of price.
• The reminder sequence's design and copy in full belongs to samber/dev-event-organizer-skills@event-attendee-email-sequences. That skill names you as the owner of overbooking ratios, waitlists, deposits, and seat release. Treat the sequence as a lever that has already reduced the no-show rate before your arithmetic runs; never draft a reminder here.
• The demand verdict behind a show-up rate is samber/dev-event-organizer-skills@event-market-fit's. It reads the number as evidence about the event's concept, price and audience; you act on the same number as a capacity input. Read its verdict, never re-derive it.
• The check-in desk's choreography (how the walk-in lane is staffed, queued and sorted) is samber/dev-event-organizer-skills@event-attendee-experience's. You decide how many walk-ins that lane should expect and which ratio produced the number.

Each boundary above is stated from this side only. Read the sibling's own statement of it before relying on the seam.

Interview

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

1. What is the room's hard capacity (the number the fire code, the venue contract or the seat count actually caps you at)? Is there any elasticity (standing room, an overflow space), and who has to approve using it?
2. What did a seat cost the person holding it: nothing beyond registering, a nominal fee, or a real ticket price? This is fixed upstream; report the posture, do not reopen it.
3. How many registrations exist today, is registration still open, and is there a date it must close?
4. Which costs are already committed against a headcount, and when does each one lock? Name the catering guarantee date, any venue minimum, and swag or badge print runs. This is what makes an over-estimate expensive.
5. Is a reminder sequence already designed and dated? If not, run samber/dev-event-organizer-skills@event-attendee-email-sequences first; every ratio below assumes reminders already did their work.
6. Can an unregistered person physically reach your check-in desk on the day, or is the venue access-controlled, badged, or remote enough that no walk-up population exists? And do you hold a channel that reaches the waitlist within a day?
7. Do you hold a prior edition's registered-versus-attended count for this same event, in this same format?
8. What is the last date each lever can still change the outcome (in practice, the catering or venue headcount guarantee date from Q4)? A guarantee that locks next week deletes every lever that needs a registration window to run.
9. Is this one edition, or a recurring event where this year's measured show-up rate becomes next year's planning input?
10. What is the effort ceiling in the final two weeks: organizer hours, anyone who can order and promote a waitlist by hand, and whether the desk can staff a second lane?

Price posture

Every sourced figure in this domain splits on what the seat cost the person holding it.

• Paid events: 90-97% of tickets convert to actual attendance, a 3-10% no-show rate (attributed to Event Tech Live).
• Free events: 40-60% no-shows (attributed to Event Tech Live).
• As no-show rates (3-10% against 40-60%), the gap is close to an order of magnitude.
• As the show-up rate you divide capacity by, it roughly halves the registration ceiling.

Quote whichever of the two reads you are actually using. Price posture is the split every figure here is measured against.

A larger cross-platform sample lands inside the same split at a lower median, and adds a caution the smaller one cannot. A check-in-verified analysis of 860-plus events, narrowed to a 195-event follow-up, found a ~20% median no-show rate overall: ~28% for free events against ~17% for paid. Most of that free-versus-paid gap sits at the event level, not the individual one.

Within a single event, payment moved an individual's odds of showing by roughly 2-4 percentage points, well under the 11-point gap the event-level comparison implies. Read the bands above for the ceiling. Read this figure as a reminder that "free versus paid" explains more than "this one registrant paid or didn't."

The employer-funded seat is a hypothesis, and must not be used as a lever. An employer-funded ticket is money the attendee never personally felt, so it may behave closer to a free seat than its price suggests. Nothing here measures that: every show-up figure above is measured against price posture, never against who paid, and the deposit evidence in the next section carries the same limit from its own coverage. samber/dev-event-organizer-skills@event-ticket-pricing argues the who-pays axis for pricing; it does not settle attendance. Say so if the question comes up, and plan on the price posture.

Community-run versus vendor-run bounds the population you draw from. It does not pick a ratio.

Overbooking posture

How many registrations to accept against a room of a fixed size.

The occupancy limit is a gate, not a rung on this menu. The room's hold-at-once limit is fixed by the fire code, the venue contract and the insurance written against them (Q1); it is never traded against catering economics or a fuller room. Two things follow from that obligation, and neither is rankable:

• Model expected attendance against that limit, not registrations: a ceiling is only safe because the no-show rate is expected to hold, so state the arrival assumption and what happens if it does not.
• Get written approval, from whoever the venue names, for any standing-room or overflow space before registrations are accepted against it - never on the day at the door.

If the ratio you want puts expected attendance over the limit, the ratio moves; the limit does not.

Ranking (default, not a law; re-rank against Q2, Q7, Q9):

• effort (hours to produce and defend the number, plus monitoring during the registration window): own-ratio ceiling > sourced 2x ceiling > no overbooking
• value (bodies in the room against capacity you have already committed spend to): own-ratio ceiling == sourced 2x ceiling > no overbooking
• compliance cost (occupancy exposure created against the venue's stated limit and the insurance that assumes it, and how reversible the position is once registrations are accepted): sourced 2x ceiling > own-ratio ceiling > no overbooking
• efficiency: sourced 2x ceiling > own-ratio ceiling > no overbooking

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass. Two mechanisms block the three pairs; name both:

• The two pairs against no-overbooking fail on cost: each ceiling lands more bodies in the room and is strictly worse on both effort and occupancy exposure.
• The third pair, own-ratio against the sourced 2x, ties on value with each rung cheaper on a different cost axis (the sourced ceiling costs less effort, the own-ratio less exposure), so neither is at least equal on both.

Neither reason is evidence; the efficiency line rests on the arguments below.

The two ceilings tie on value because both land the room at capacity. One edition's own registered-to-attended ratio is a sample of one; the sourced 2x rests on an aggregate chart across 323 events. Neither is clearly the better estimator, so the tie is real rather than a refusal to decide, and effort then breaks it in the sourced ceiling's favour.

The efficiency winner also tops the compliance-cost axis. A borrowed ratio carries more variance than a measured one, so the sourced ceiling is the rung whose expected attendance sits closest to the gate above. Efficiency picks it only while that gate holds.

Where the variance would carry expected attendance over the limit, the gate takes the decision and the menu gets no vote. Name that exposure to whoever signs the venue contract before you set the number.

• Sourced 2x ceiling - the default for a free-registration event: accept registrations up to double your aimed attendance and stop there. The MLH hackathon organizer guide states it explicitly: about 50% of people who register for a free event show up, so aim for double the registrations, and do not go over double. The ceiling is the load-bearing half of that instruction, not a rounding of it.
• Own-ratio ceiling - the starved option: it ties the top on value, tops effort, and therefore loses every efficiency round. Compute your own multiplier from last edition's registered-versus-attended count and hold it under the sourced ceiling. Promotion condition: a recurring free-registration event (Q9) where you hold that count for the same event in the same format (Q7) and a committed cost locks against headcount before doors open (Q4); that combination is the only one where the difference between a borrowed 50% and your own measured rate is money rather than trivia.
• No overbooking - accept registrations up to capacity and close. Correct, not lazy, on a paid event; on a free event it half-empties a room whose catering you have already paid for.

On a paid or nominal-fee event (Q2), delete both ceilings from this menu and from the axis lines above, and take no overbooking. The two sides of the error are not symmetric: an empty chair costs one cover, while turning away someone who paid costs a refund and the public account of it. Their 3-10% no-show rate is a number to plan catering against, never a margin to sell into.

Deleted, not demoted: leaving registration open with no ceiling at all. It reads as the free version of maximising attendance and it is the one posture the guide explicitly forbids. Past the ceiling you are no longer absorbing a gap; you are guaranteeing that people who registered get turned away, which costs more trust than an empty chair costs money.

The three distinct sourced figures behind this menu, each with its own scope, are in references/show-up-rate-figures.md. Read it before quoting any number, and never blend them: two of the three read as "50%" while answering different questions, so any average of them answers none.

Waitlist design

What happens to the people who arrive after the ceiling. Ranking (default, not a law; re-rank against Q3, Q6, Q8, Q10):

• effort (hours in the registration window, and whether the job is dated or standing): proximity-prioritised > FIFO on a fixed date > no waitlist
• value (bodies in the room who would otherwise not be there, and trust kept with the people told no): proximity-prioritised > FIFO on a fixed date > no waitlist
• compliance cost (what the ordering rule obliges you to publish, and how reversible it is once people have registered against it): proximity-prioritised > FIFO on a fixed date > no waitlist
• efficiency: FIFO on a fixed date > proximity-prioritised > no waitlist

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. That is not a pass; it means the dominance check cannot catch a mistake here, and the ordering rests entirely on each rung's own argument. Treat it as the menu most worth arguing with.

• FIFO on a fixed date - the default: collect above the ceiling, promote in one batch on a date you name when the waitlist opens. Mechanical, defensible to whoever is skipped, and it costs one afternoon rather than a standing job.

• Proximity-prioritised - the starved option: order the waitlist by how close someone is to the venue. The MLH hackathon organizer guide gives this as its priority rule, reasoning that people closer to the event are more likely to show up, and it is the one non-FIFO ordering rule with organizer practice behind it. The guide attaches no figure, so treat the size of the gain as unquantified. What it buys, on that reasoning, is a higher show-up rate per promoted seat. What it spends:

  • The hours to order the list by hand.
  • An allocation decision made on registrants' location data that you must be able to state publicly and cannot quietly change mid-window.

  Promotion condition: the effort ceiling covers someone ordering the list by hand (Q10) and registrations (Q3) run far enough past the ceiling that promotion order actually changes who gets in rather than merely who gets in first.

• No waitlist - close registration at the ceiling and say so on the page. Honest, and it still costs something: the requests arrive by email anyway, and an unordered list in an inbox is a waitlist with no rule and no date.

If the headcount guarantee locks before the latest promotion date you can realistically hold (Q8), the waitlist stops being a budget lever. It still fills chairs, which is worth doing; it no longer changes the number catering is working from. Say which of the two you are buying, because only the second moves the figure samber/dev-event-organizer-skills@event-budget budgets from.

Deleted, not demoted: promoting continuously, one seat at a time, on every cancellation. It converts the waitlist into a standing job across the whole registration window for a gain the ceiling has already absorbed, and it converges on the live per-seat swap this skill flags as untested below.

Every promotion is an event that needs its own transactional email. Hand the trigger, the audience and the deadline to samber/dev-event-organizer-skills@event-attendee-email-sequences as a brief

...