Queues

A queue is a named waiting list within a location. When a customer joins a queue, they receive a ticket with a sequential number. Staff at a desk call tickets from the queue one by one. The display screen announces each call.

Queue anatomy

Each queue has:

Name — the human-readable label shown to customers and staff (e.g. "Walk-ins", "Appointments").
Slug — a URL-safe identifier used in the customer join URL. Generated automatically from the queue name.
Customer join URL — the full URL customers visit to join this queue:
```
https://customer.jonot.io/{org-slug}/{location-slug}/{queue-slug}/
```
This URL is also encoded in the QR code you share at the entrance.
Capacity cap (optional) — the maximum number of tickets that may be in WAITING state simultaneously. When the queue is full, new join attempts are rejected with a "queue full" message. Leave blank for unlimited.
Expected service time — the typical minutes to serve one customer (1–1440), set in the queue create/edit form. It seeds the customer wait-time estimate before the queue has enough live history to measure its own pace (see Wait-time estimate).

Multiple queues per location

A location can have any number of queues. This lets you run separate service lines in parallel — for example:

A clinic with "General Consultation" and "Pharmacy Pick-up" queues
A government office with "Passport" and "ID Renewal" queues
A bank with "Personal Banking" and "Business Banking" queues

Each queue has its own independent waiting list. A desk is paired to a specific queue at pairing time, so desks serving "Walk-ins" do not see tickets from "Appointments".

Queue as the unit of management

The queue is the central unit around which devices and staff are organised:

Kiosks are paired to a queue — customers who tap the kiosk join that specific queue.
Desks are paired to a queue — staff call tickets from that queue.
Displays show all active calls for a location, or the calls from a specific desk's queue, or a combined board of up to 5 queues.

Creating and managing queues is done in admin under the location's Queues tab. See Create a Queue for the step-by-step instructions.

Capacity cap

You can limit how many customers can wait in a queue at once by setting a capacity cap (the Max waiting field in the queue create/edit form). When the cap is reached:

The customer join flow shows a "queue full" message.
The kiosk shows a queue-full state.
The queue is not joinable until a waiting ticket exits (is called, cancelled, or moved).

The cap is enforced atomically — two customers attempting to join at exactly the same time cannot both push the count over the limit. Leave the field blank for an unlimited queue (the default).

Queue status

Every queue has a manual status that staff control independently of operating hours:

Active — the normal state. Customers can join, and desks can call tickets.
Paused — temporarily stop intake. New joins are refused, but everyone already waiting keeps their place. Use it for a short break or a backlog you want to clear before letting more people in.
Closed — stop intake like a pause, but signalling the queue is done for now. Waiting tickets are retained rather than cancelled. Reopening a closed queue is an admin action — a desk cannot reopen it on its own.

When a queue is paused or closed, a customer who is already waiting sees a status banner on their ticket, and anyone trying to join is turned away with a matching message rather than a generic error. A paused banner reassures the customer their place is kept and the queue will resume; a closed banner is more cautionary — the ticket is retained but may not be served, so the customer is asked to check with staff.

Setting the status:

In admin, an org-manager or location-manager sets the status (Active / Paused / Closed) from the queue's edit form.
At the desk, staff can toggle between Active and Paused with a single Pause queue / Resume queue button — the fast path for a momentary break without leaving the desk. Closing (and reopening from closed) stays in admin.

Status changes take effect immediately and are pushed live to every connected desk, display, and customer.

Operating hours

A location's operating hours act as a time-based gate on all its queues. When the location is outside its configured hours, join attempts are rejected with an "outside hours" message and the customer-facing queue picker shows a "Closed — opens at [time]" state. The desk and display show a Closed (hours) pill.

Hours are configured on the location (not per queue) in Admin → [Location] → Hours:

Timezone — IANA timezone (e.g. Europe/Helsinki). All hours are evaluated in this timezone, DST-correct.
Weekly schedule — open/close intervals for each day of the week. A day with no intervals is fully closed. Multiple intervals per day are supported (e.g. to model a lunch break: 08:00–12:00 and 13:00–17:00).
Cross-midnight hours — an interval where closing time is past midnight (e.g. Friday 20:00–02:00) is supported. Enter the close time using a normal clock value (02:00); when the close time is at or before the open time the editor automatically treats it as the following day and shows a next day hint next to the close field.

Date overrides

Single-date exceptions (holidays, special hours) are managed in the Overrides section of the hours editor:

Closed override — marks a specific date as fully closed regardless of the weekly schedule (e.g. a public holiday).
Custom hours override — replaces the weekly schedule for a specific date with a different set of intervals. A closure override on a given date takes precedence over a previous day's cross-midnight spill.

Overrides appear in a list below the weekly schedule and can be added, edited, or deleted at any time.