> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://learn.nuwebgroup.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://learn.nuwebgroup.com/_mcp/server.

# What is a pre-queue in ticketing?

> How pre-queues differ from first-come waiting rooms and what fairness means at onsale.

**A ticketing pre-queue is a holding area that opens before ticket sales begin.** It lets people arrive ahead of the onsale without necessarily giving the earliest visitors first access to inventory. At the advertised start, the organiser can move eligible visitors into a live queue using a chosen ordering rule, such as randomisation or first-in-first-out. Those policies are not equivalent and should be explained before customers join.

## How does a pre-queue differ from a waiting room?

A waiting room regulates how many visitors can reach the ticketing application at once. A *pre-queue* refers specifically to the period before the sales window opens. After the onsale begins, the waiting-room system can begin admitting visitors at a rate the application and inventory systems can support.

| Stage                      | Customer experience               | Operator decision                              |
| -------------------------- | --------------------------------- | ---------------------------------------------- |
| **Before pre-queue opens** | Event information and countdown   | When to invite visitors                        |
| **Pre-queue active**       | Waiting page before sales         | Whether early arrival changes priority         |
| **Sales start**            | Queue position or waiting message | Randomised or arrival-order admission          |
| **During onsale**          | Gradual admission to purchase     | Admission rate, session time, failure response |

## What counts as fair?

Randomising people who arrived before a cutoff may reduce the advantage of automated early arrivals, but it does not prove that bots or multiple sessions have been excluded. First-in-first-out rewards arrival order, but can create incentives to get in extremely early. The organiser should choose and publish a policy appropriate to the audience, accessibility requirements and presale conditions.

**Example:** For tickets released at 10:00, a pre-queue could open at 09:30. People present at 10:00 might be assigned a random ordering, while visitors arriving later join behind that group. This is one possible policy, not the definition of every pre-queue.

## What should teams test?

Test refreshes, expired sessions, multiple browser tabs, mobile connections, accessibility of status announcements, and whether an admitted visitor can finish checkout before a session expires. Treat queue positions and estimated waits as operational estimates, not guarantees of tickets. The number of customers admitted should reflect measured checkout and inventory capacity, not just raw web traffic.

The related articles on **ticketing waiting rooms** and **high-demand onsales** cover the wider system; this page answers the narrower question of what happens *before* sales open.

## Related explanations

#### [How do ticketing platforms control bots during onsales?](/scale-reliability/how-do-ticketing-platforms-control-bots-during-onsales)

Scale & Reliability · High-demand onsales

#### [How do large ticket presales manage access codes?](/scale-reliability/how-do-large-ticket-presales-manage-access-codes)

Scale & Reliability · High-demand onsales

#### [How do virtual waiting rooms work for ticket sales?](/scale-reliability/how-do-virtual-waiting-rooms-work-for-ticket-sales)

Scale & Reliability · High-demand onsales

#### [How do ticketing platforms handle high-demand onsales?](/scale-reliability/how-do-ticketing-platforms-handle-high-demand-onsales)

Scale & Reliability · High-demand onsales

[More in Scale & Reliability →](/scale-reliability)