A Place Opens Up: How Should Your Booking App Handle a Waiting List?

A waiting list should record interest, not quietly create a booking. Before commissioning one, choose how a newly available place is offered: privately to one eligible person for a limited time, or to several people who compete to book it. Tell customers which rule applies. A message saying “a place is available” must not sound like “your place is confirmed” when it is not.

This guide is about allocating cancelled or newly released capacity for classes, workshops and similar services. It is not a guide to walk-in queue displays, appointment time zones or stock reservations. The workflow recommendations below are choices for a project brief, not claims that every booking product already supports them.

Start with what the person is waiting for

“Join the waiting list” is incomplete unless the system records the relevant session and type of place. Someone waiting for a beginner class on Tuesday is not necessarily interested in an advanced class on Friday. Decide whether people can choose alternative sessions, and whether they join each list separately or submit one request with several acceptable options.

There is a useful concrete example in the pretix waiting-list API documentation. An entry identifies the item being awaited, an optional variation and, for an event series, an optional event date. Its record also includes a creation time and the waiting person's locale. Those fields illustrate that interest can be scoped rather than attached vaguely to an email address. They do not establish what your business's priority policy should be.

Ask for only the information needed to make the offer. If a request is for a group, decide whether it may be satisfied partially. Do not offer one place as though a family request has been fulfilled. Nor should staff assume that every person who joined several lists wants several bookings.

Choose an allocation promise you can explain

There are two substantially different designs.

With a sequential offer, the next eligible person receives a private opportunity to claim the place before a deadline. Decide whether capacity is held for that person during the offer. If it is, ordinary bookings and other lists must respect the same hold. If it is not, the message must say the place may be taken before the recipient responds.

With a broadcast, several people are told capacity is available and the first successful booking wins. That can be a reasonable choice, but it is not a reserved invitation. Avoid wording that suggests priority you are not providing.

For either design, write down the selection rule. Is it oldest eligible request first, a staff decision, or another published criterion? Define what happens when a request cannot fit the available capacity. Skipping a group because only one place opened is different from removing it from the list altogether. Record a reason for an override so staff can explain what happened without reconstructing it from inboxes.

Separate waiting, an offer and a completed booking

A customer-facing status should answer a practical question: “Do I need to do anything, and do I have a place?” Useful states may include waiting, offer available, offer expired, withdrawn and booked. Choose the actual set for your workflow rather than displaying one ambiguous “active” label.

The pretix documentation provides a caution about interpreting supplier data: its voucher field distinguishes someone still waiting from someone who has been sent a voucher and is no longer waiting. That field alone is not a statement that the recipient completed a purchase. If a supplier integration is used, ask the developer how an issued offer is reconciled with an actual booking.

Define the response deadline and display its date, time and time zone. A customer should be able to decline without having to ignore the message. Decide whether expiry returns the request to its original position, moves it to the end or closes it. Explain that rule before the offer, particularly when response times are short.

Test the awkward transitions, not just the happy email

Consider this hypothetical workshop: one place is released, a staff member offers it to a waiting customer, and another person tries to book from the public page. Your acceptance test must demonstrate the chosen capacity rule. Sending a polished invitation is not enough if both people can be confirmed for the same place.

Also ask what happens when an offer is accepted just as it expires. The booking system should give one definitive outcome and prevent competing actions from creating conflicting confirmations. Reopening a closed browser tab or clicking an old email must not revive an expired offer.

Email delivery needs its own status. Preserve the offer and its deadline separately from delivery attempts. A delivery retry should not silently create a second entitlement or extend the deadline. If the outcome of sending is uncertain, investigate the existing attempt rather than repeatedly issuing new offers. Give staff a way to spot an undelivered invitation while there is still time to act.

Finally, decide what happens after a booking. Close or update the relevant waiting request, and handle other requests only according to the customer's stated preferences. Do not quietly cancel unrelated interest.

What to ask the developer to demonstrate

Use synthetic customers and a test session, not real customer bookings. Include these cases in your acceptance criteria:

• A request names the correct session, place type and group-size requirement.
• Duplicate submissions follow a defined rule and do not improve queue position accidentally.
• Staff can explain the selection order and see intentional overrides.
• A private hold or broadcast behaves exactly as described to customers.
• Decline, expiry and withdrawal each have a defined effect on capacity and queue position.
• Two simultaneous acceptance attempts cannot obtain the same single place.
• A sent offer is distinguishable from a completed booking and from a failed notification.
• An old offer link gives an accurate explanation instead of a fresh confirmation.

Before adding this to a custom web-app project, settle the allocation promise in a few plain sentences. “We notify you when something opens” and “we hold the next suitable place for you” are different services. The application should implement the one you actually intend to provide.

Source and limits

The pretix developer documentation cited above supports the described entry fields and the waiting-versus-voucher distinction. It is a supplier-specific API reference, not a universal waiting-list standard or evidence of tested behaviour in your implementation. Priority, group matching, hold duration, expiry, concurrency and notification handling in this article are proposed requirements to agree and test. They are not promises about pretix configuration, legal entitlement or delivery guarantees.