KoratA queue ticket here isn't a paper slip a shop prints and then loses track of — it's a row both sides can see. One scan issues one ticket, tagged to a queue group and a party size. Staff call the next ticket from whichever counter is free, and every status change moves through the same database, not a whiteboard one employee is keeping in their head.
Getting a ticket — self-serve or staff-issued
A restaurant that seats people by queue rather than by table runs both from the same board: the ticket and the table order belong to the same session. A shop can run several queue groups (order pickup, returns, a specific counter) and choose per group whether customers scan a QR code themselves or a staff member issues the ticket for them. A ticket can carry a name, a contact number and a party size. A shop that would rather have people book a time in advance uses appointments instead. Every ticket belongs to the shop's own day, not the device clock's — a shop that stays open past midnight would get a mismatched board if the day were guessed from whatever time the phone reports. If the server can't answer what day it is for that shop, the screen says the board failed to load, rather than guessing and showing an empty board while people are actually standing in line.
Watching your own position
After getting a ticket, a customer sees their number, their group, and their current status. The position number refreshes every 10 seconds while the screen is open — it is not a second-by-second live counter. When it is actually your turn, a push notification fires immediately with which counter to go to, so there's no need to keep the screen open and staring at it the whole time you're waiting.
The shop side — calling, moving status, and capping no-shows
Staff call the next ticket for the counter they run, can re-call the same ticket if a customer didn't hear it, and can undo a call instantly if they tapped the wrong one. Each queue group sets a limit on how many times a ticket can be called and missed before it's treated as a no-show, so the whole line doesn't get stuck behind one ticket that never shows up to listen. Every write — issuing, calling, moving status, closing — runs through server functions that check permission themselves; the ticket table itself has no direct-write policy under row-level security at all, so there's no way for a ticket to exist that nothing in the system knows about.
A screenshot of a queue QR code won't work — it has to be scanned off the physical sign in front of you. The token is tied to that queue group's current issuing round, not a fixed code that can be reused indefinitely.
A parking ticket at a barrier and an event ticket at a door are issued and scanned through the same QR mechanism. A queue ticket screen also opens from the link a printed ticket slip carries (koratland.com/queue?...) — no app required to check your own position from a browser.