Tickets

A ticket is an entry in a queue issued to a customer when they join. It is the core unit of the queue system — everything from the display screen to the desk interface revolves around tickets.

What a ticket contains

• Ticket number — a sequential integer visible to the customer, displayed on the kiosk receipt, shown on the display screen, and visible in the desk waiting list. Numbers are scoped to a queue and increment monotonically — they never reset.
• Ticket hash — a 22-character random string with 128 bits of entropy. This hash is the customer's anonymous bearer credential (see below).
• State — one of six values (see below).
• Queue — the queue the ticket belongs to.
• Timestamps — when the ticket was created, called, completed, etc.
• Annotations (optional) — staff-entered metadata: customer name, party size, and a free-text note. See Ticket annotations.

Ticket states

A ticket moves through the following states during its lifecycle:

State	Terminal?	Meaning
WAITING	No	The customer is in the queue, waiting to be called.
CALLED	No	A desk has called this ticket; the customer should approach the counter.
SKIPPED	No	The desk passed this ticket. Recallable — staff can move it back to WAITING.
COMPLETED	Yes	The desk marked the service as done.
CANCELED	Yes	The customer cancelled their own place in the queue.
NO_SHOW	Yes	The desk confirmed the customer is absent. Counted separately in analytics from SKIPPED.

State transitions

WAITING  → CALLED   → COMPLETED
                    ↘ SKIPPED   → WAITING  (desk recalls the customer)
                               ↘ NO_SHOW  (desk confirms absence)
                               ↘ CANCELED (customer cancels their deferred spot)
WAITING  → CANCELED  (customer-initiated)
CALLED   → CANCELED  (customer-initiated)
SKIPPED  → CANCELED  (customer-initiated — removes from recallable pool)

SKIPPED vs NO_SHOW

SKIPPED is a recallable deferral — the customer was passed but the ticket is still live. Staff can call the customer back using the Recall to queue action in the desk's look-up view, or by pressing Undo within 5 seconds of the skip. A skipped customer's push notification subscription is kept warm, so the recall → call push notification reaches them even if the ticket page has been closed.

NO_SHOW is a confirmed, terminal absence. The ticket is removed from the recallable pool and is counted separately in analytics. Use this when you are certain the customer has left.

See Handle No-Shows for the full desk workflow.

Ticket annotations

Staff can attach lightweight metadata to any ticket using the Annotate action on the desk:

• Customer name — shown on the desk at all times. Shown on the display only if the queue's Call by name setting is on, and then only as a minimised form ("First L.") — never the full name.
• Party size — always shown on the desk and broadcast to the display (a low-sensitivity count).
• Note — free-text back-office note. Desk only; never sent to the display or customer.

A skip reason (entered when pressing Skip with reason) is stored in the ticket's note field and is visible on the desk look-up view.

Annotations can be added or updated at any point while the ticket is non-terminal.

Transferring a ticket

A WAITING ticket can be transferred to a different queue in the same location using the Transfer button on the desk. This is useful when a customer has joined the wrong queue or when triage reveals they need a different service.

Transfer rules:

• Only WAITING tickets can be transferred. CALLED tickets must be completed, skipped, or no-showed first.
• The source and destination queues must be in the same location.
• The destination queue must be ACTIVE.
• The desk must be assigned to both the source and the destination queue.
• An active subscription is required.

Positioning after transfer — the ticket retains the customer's original join time plus a 5-minute penalty. This preserves the wait they have already served while preventing them from jumping ahead of customers who have been waiting longer in the destination queue.

The ticket hash is preserved — the customer's ticket page URL remains valid. The ticket receives a new sequential number in the destination queue. Realtime updates are broadcast to both queues immediately.

See the Transfer a ticket to another queue section of the desk guide for step-by-step instructions.

The ticket hash as a credential

Customers are anonymous — there is no login or account required to join a queue. Instead, the 22-character ticket hash serves as the customer's proof of ownership. It is embedded in the ticket page URL:

https://customer.jonot.io/{org}/{location}/{queue}/{ticket-hash}/

Knowing the hash proves you own that ticket. The API uses the hash to authorise:

• ticketByHash — look up your ticket and position
• cancelTicket — cancel your own ticket (works for WAITING, CALLED, and SKIPPED tickets)

This design is intentional: it removes all friction from joining a queue. No account, no app, no password — just a URL.

The hash has 128 bits of entropy (equivalent to a UUID v4), making it computationally infeasible to guess another customer's ticket hash.

Verification under unusual traffic

Joining stays frictionless in normal use. As an anti-abuse safeguard, if a single queue receives an abnormally high burst of joins in a short window, customers joining over the web (QR code or link) may be asked to complete a quick "I'm human" verification before their ticket is issued. Most legitimate visitors pass it invisibly. This only appears during floods — under normal traffic no verification is shown — and it never applies to the on-site kiosk, whose joins are trusted by device credential.

Wait-time estimate

When a ticket is in WAITING state, the customer's ticket page shows an estimated wait time. The same estimate is shown on the kiosk's post-join confirmation screen so the customer leaves the kiosk with a number to remember. This is a best-effort estimate, not a guarantee.

The estimate is computed from recent service intervals at that queue: if enough completed tickets exist in the last 90 minutes, the server derives a median service time and multiplies it by the customer's position in the queue (people ahead + 0.5). When the customer is next in line (zero people ahead) the estimate is reported as zero. When recent history is sparse, the queue's configured Expected service time is used as the fallback. The estimate carries a confidence indicator (high when derived from live data or when the customer is next, low when falling back to the configured default).

The estimate is only shown for WAITING tickets in an ACTIVE queue. It is not shown when the queue is paused, and it disappears once the ticket is called.

Customer experience

1. Customer joins via QR code or kiosk → ticket issued in WAITING state.
2. Customer opens the ticket page → sees their position in the queue and, when available, an estimated wait time in real time.
3. When the desk calls their number, the ticket moves to CALLED → the customer's page updates immediately.
4. Customer approaches the counter. After service, the desk marks it COMPLETED.
5. If the customer doesn't respond, the desk can:
   • Skip → ticket moves to SKIPPED (recallable deferral). The customer's screen shows they were passed, with options to wait or rejoin.
   • Mark no-show → ticket moves to NO_SHOW (terminal). Analytics count this separately from skipped tickets.
6. A skipped customer can be recalled by staff (moves back to WAITING at the front of the line), or can cancel their spot and rejoin at the back.