First on the waitlist: should a cancelled seat be confirmed automatically?

What did joining the queue actually promise?

Imagine a free workshop with all 20 seats confirmed and three members waiting in order: A, B and C. When someone cancels, should A immediately become an attendee? Availability may have changed since A joined. Before deciding what to automate, establish what the waiting-list application meant and whether attendance intent needs another check.

The aim here is to refill cancelled seats while giving earlier applicants the first opportunity. Queue entry, seat offer and confirmation therefore need different states. Position is an order for receiving offers, not admission. Calling a successful waitlist entry a completed booking would contradict that promise before any allocation code runs.

Ask for the original application wording, when cancellations happen, how long people need to respond and when operations needs a final list. This fixture uses existing member identities, one seat per member and one free workshop. Group requests, payment and priority allocation are outside its scope; the people and numbers are fictional.

Do not copy another product’s release button blindly

Bevy’s public guide describes different behavior by ticket type: its paid-ticket section has the recipient claim an offer, while RSVP-only release registers the attendee. The same word, release, does not define the same user commitment. It is a useful policy contrast, not evidence that Bevy implements the design below.

Immediate automatic confirmation is the shortest initial idea, but it does not recheck intent. Broadcasting to everyone and taking the first click instead changes priority from intake order to reaction speed. For this case, reserve one seat for the queue head and ask that person to accept within the stated period.

That choice has a tradeoff: the seat remains held while the person decides, and a late cancellation may remain empty. This example prefers the promised opportunity over suddenly shortening someone’s response window. Automatic confirmation could suit a different service if the original application clearly agreed to that transition.

A 24-hour promise also applies to the last person

Set the event to 12 October 2026 at 14:00 and registration close to 11 October at 18:00, both Asia/Seoul. Every new offer lasts 24 hours from creation. The last possible offer is therefore 10 October at 18:00. After that, stop new offers and general registration even when seats open; do not quietly give the last waiter ten minutes.

Order entries by server-accepted intake, using a server sequence to break equal timestamps. A member can have only one active waiting, held or confirmed entry for this event. While a queue exists, new applicants join its tail rather than taking a seat through a still-open general-registration screen.

Counting only confirmed people is insufficient. Confirmed seats plus valid holds must stay at or below 20. General registration must not take the seat currently offered to A. Checking capacity, selecting the queue head and creating the hold must succeed together or leave no partial assignment.

Sending the message does not confirm the seat

Before a new offer, check the free seat, an active waiter and a full 24-hour window together. Persist an offer with one hold for the queue head, then send its email. Slow delivery must not create another offer or a second hold for the same person. The offer is the record to retry notification against.

Acceptance is a separate decision. Check the recipient, event, current offer and valid hold. The server time checked inside the atomic state transition must be strictly before offer expiry and registration close; equality is already too late. A client-side click timestamp must not override that decision.

First recognize a retry for an offer that is already confirmed and return its existing result. Otherwise someone whose success response was lost could retry and receive an expiry error. Acceptance and expiry cleanup also need one atomic decision boundary. Disabling a screen button cannot enforce these rules by itself.

Expiry and delivery failure are different outcomes

Decline, withdrawal and expiry end the particular entry or offer and release only its associated hold once. Cancelling a confirmed registration releases that confirmed seat once. Receiving a cancellation twice must not create two vacancies. After a release, assess new-offer eligibility against the current time and queue again.

Email failure is not a decline. Flag it for operations and resend the same offer without another hold or a new deadline. Stop resending once it expires. Keep send attempts, delivery failures, opens and acceptance separate so operations can see what failed. A successful send neither confirms A nor makes the held seat available to B.

Do not automatically requeue someone after expiry. If the new-offer window remains open, that person may explicitly reapply at the tail. Their old link continues to show the old closed offer and must never act on the new application. The examples below compare fixed messages; they do not create registrations or send email.

Ask AI for cases that break the ordering promise

A broad request to build a waitlist can produce an email feature and a rank display before the policy is clear. Supply capacity, intake ordering, the 24-hour offer, registration close and rejoining rules first. Delegate finding contradictions and drafting test inputs within those decisions, rather than silently letting the answer choose a new policy.

If a proposal says to notify the next person after delivery failure, check when the original hold ends. Offering the same seat again while the first offer is live is unacceptable. An operator extending the deadline is also a policy change, not a detail to import into the specification without a decision.

The prompt below is unexecuted. Review any answer by tracking seat counts: 19 confirmed plus one held becomes 20 confirmed and zero held on acceptance. A repeated cancellation must not create another vacancy. Carry corrections into QA and operating instructions as well as the screen specification.

Example prompt: A free workshop has 20 seats, one per member. Offer cancelled seats in intake order, holding one seat for 24 hours until acceptance. With less than 24 hours until registration closes, stop new offers and general registration. Find ordering or capacity failures involving concurrent cancellations, acceptance exactly at expiry, a lost success response, failed email and rejoining after expiry. Give before/after seat counts, messages, engineering conditions and QA expectations. Do not invent outcomes or external policies.

Specify what each person needs to start implementation

The planning document should record why an offer was chosen over automatic confirmation and why late vacancies are acceptable. The screen specification connects waiting, offered, confirmed and closed states to messages and actions. Include event time and the full response deadline with its zone in email; tomorrow alone is ambiguous for a message read late.

Engineering needs the one-time seat transition conditions, not just visible states. Operations needs linked intake order, offer deadline, end reason, seat changes and notification results. Do not give operators a bypass around capacity, priority or expiry. A necessary exception should become a separate documented policy decision.

W3C’s status-message guidance supports making processing feedback recognizable to assistive technology without moving focus. In this design, distinguish accepting, confirmed and unable to verify using text and appropriate status feedback. Validate the visible message and accessibility behavior together rather than relying on a color change.

One successful acceptance is not sufficient QA

Specify starting states and request order, not only button names. Two concurrent cancellations from 20 confirmed attendees free exactly two seats, then offer one to each of the first two waiters. Check that competing jobs cannot both choose the same queue head or return a cancelled seat twice.

Test just before, exactly at and after expiry. Because the authoritative time is checked inside the state transition, also delay requests before that point. These are acceptance cases to execute after implementation. Clicking the fixed article demonstration is not an integration test of a workshop service.

Change the assumptions before reusing the handoff

The material below assumes existing member identities, a free single event, one seat per member and intake-order priority. Group seats or priority allocation require a new rule about skipping the queue head. A service that must fill seats until the event begins cannot reuse the 24-hour guarantee and cutoff without reconsidering both.

Walk one fixture together before handoff. If engineering does not hold a seat when creating the offer, design cannot tell the applicant that a seat is held. Update the decision sheet, screen wording and QA inputs together so the next person does not have to ask which version to trust.

For first release, duplicate holds, over-capacity confirmation, expired acceptance and old links changing new applications are blocking defects. After release, inspect offer and notification failure records to locate stalled processing. Email opens are not attendance outcomes; confirmations and cancellations need their own records.

Free workshop — waitlist seat-offer handoff
Fixture: capacity 20; one seat per existing member identity. Event: 12 Oct 2026, 14:00 Asia/Seoul. Registration closes 11 Oct, 18:00 in that zone. Payment, groups, priority access and capacity reductions are out of scope.
Purpose: offer cancelled seats in accepted queue order and reconfirm attendance intent. Joining the queue, receiving an offer and confirmed attendance are different states. Do not promise a vacancy date or admission.
Order: server-accepted registration order; break equal timestamps by the server intake sequence. A member has only one active waiting, held or confirmed entry for this event. Do not expose other applicants.
Capacity: confirmed seats + valid holds must never exceed 20. Held seats are unavailable to general registration. While an active queue exists, newcomers join its tail. Re-evaluate changed conditions before assignment.
New offer: only with a free seat, an active waiter and at least 24 hours before registration closes. Atomically hold one seat for the queue head. Expiry is offer creation + 24 hours. Latest new offer here: 10 Oct, 18:00. After that, stop both new offers and general registration, even if a seat is free.
Accept: verify recipient, event, current offer and valid hold. The server time checked inside the atomic transition must be strictly before both offer expiry and registration close. Client click time is not authoritative. Convert one hold into one confirmed seat.
Duplicates: acceptance retried for that already-confirmed offer returns the existing confirmation. Never create a hold from an expired offer or redirect its action to another active entry.
End: decline, withdrawal and expiry end the specific entry/offer and release its associated hold once. A confirmed cancellation releases its confirmed seat once. Expiry processing and acceptance use the same atomic decision boundary.
Rejoin: never restore old priority automatically. A person may explicitly apply again during the new-offer window and joins the tail with a new intake order. Old links continue to show the old closed state.
Notification: persist the offer first, then send email tied to it. Send request, delivery failure, opening and acceptance are separate records. Flag failures or unknown outcomes for operations; resend only the same offer without another hold or an automatic extension. Never treat successful sending as acceptance; do not resend after expiry.
Screen: show event/date, full response deadline with zone, current state and allowed actions together. Active offer: Accept/Decline. Confirmed: View registration/Cancel. Closed: reason and rejoin availability. Unknown acceptance outcome: query current registration; do not claim confirmation.
Audit: connect intake order, offer creation/expiry/end reason, seat counts before/after, acceptance decision time, notification results and operator actions. Operators cannot bypass order, capacity or expiry. Policy changes require a separate decision and document update.
Handoff: planning owns ordering/boundaries; design owns messages/actions and accessible status feedback; engineering owns atomic seat/offer transitions and notification retries; QA records inputs/expected/observed results for 12 cases; operations records delivery failures and inconsistent capacity.
Release gate: block release for duplicate holds, over-capacity confirmation, expired acceptance or old links acting on a new entry. Retest the same sequence. This fictional design has not been integration-tested against a live event service.

Sources and example conditions

A fictional free-workshop design. Bevy provides a contrast between product policies; W3C supports the status-feedback principle. Capacity, priority, the 24-hour window and cutoff are choices for this example, not live event outcomes. AI prompts are unexecuted examples. English and Chinese localize the same Korean case.

Bevy — Waitlist Registration

W3C — Understanding SC 4.1.3: Status Messages