Tickets

A ticket is a customer’s entry in a queue. The customer screen, display, and desk all use ticket information.

What a ticket contains

• Ticket number — a number shown to the customer, on printed kiosk tickets, on the display, and in the desk waiting list. Each queue has its own number sequence. Numbers always increase and never reset.
• Ticket hash — a random 22-character string. This hash gives the customer anonymous access to their ticket. 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 can move through these states:

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 means that staff passed the customer but can still call them later. Staff can return the ticket to the queue with Recall to queue in the desk lookup view. They can also press Undo within 5 seconds of the skip. Push notifications remain active for a skipped ticket, so the customer receives a notification after staff recall and call it even if the ticket page is closed.

NO_SHOW means that staff have confirmed the customer is absent. It is a terminal state, so the normal recall flow no longer includes the ticket. Analytics count it separately. Use it when you are certain the customer has left.

See Handle No-Shows for the full desk workflow.

Ticket annotations

Staff can add the following details to a ticket with the Annotate action on the desk:

• Customer name — always shown on the desk. The display shows a shortened form, such as “First L.”, only when the queue’s Call by name setting is on. It never shows the full name.
• Party size — always shown on the desk and broadcast to the display (a low-sensitivity count).
• Note — text for staff. It appears only on the desk, never on the display or customer screen.

A skip reason (entered in the Reason for skipping (optional) field when a ticket is skipped) 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

Staff can use Transfer on the desk to move a WAITING ticket to another queue in the same location. Use this when a customer joined the wrong queue or needs 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.

Position after transfer — Jonot places the ticket in the new queue using the original join time plus 5 minutes. The customer keeps most of the time they have already waited but does not move ahead of customers who have waited longer in the new 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 do not need an account or login to join a queue. Instead, the 22-character ticket hash proves that a customer owns a ticket. It is part of the ticket page URL:

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

The API uses the hash to allow these actions:

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

The customer needs only the URL. They do not need an account, app, or password.

The hash contains 128 bits of randomness, the same as a UUID v4. Current computers cannot practically guess another customer’s ticket hash.

Verification under unusual traffic

Customers normally join without verification. If one queue receives an unusually large number of join requests in a short time, customers using a QR code or link may need to complete an “I’m human” check before they receive a ticket. Most real customers pass the check without seeing it. The check appears only during these traffic spikes. It never applies to an on-site kiosk, because the kiosk uses a trusted 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. The time is an estimate, not a guarantee.

The server calculates the estimate from recent service times in that queue. If enough tickets were completed in the last 90 minutes, it uses the median. The median is the middle value, or the average of the two middle values, after sorting the service times. The server multiplies it by the customer’s queue position (people ahead + 0.5). The estimate is zero when no one is ahead. If there is not enough recent data, the server uses the queue’s configured Expected service time. The estimate includes a confidence value: high when it uses recent data or the customer is next, and low when it uses the configured time.

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. The customer joins by QR code or kiosk → Jonot issues a ticket in WAITING state.
2. The customer opens the ticket page → sees their position in the queue and, when available, an estimated wait time in real time.
3. The desk calls their number → the ticket moves to CALLED and the customer’s page updates immediately.
4. The customer approaches the counter. After service, staff mark the ticket 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.
   • 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.