Queue Tokens and Switching Devices: Keeping Your Place When You Change Screens
Why sessions trap places
Most waiting rooms identify a visitor by a cookie or session created when they join. That is simple and works until the session ends: a closed app, a cleared browser, a second device. The queue never knew a person, only a tab, so there is nothing to transfer. Every device switch is a new arrival as far as the system is concerned.
The unfairness is quiet but real. The shoppers most likely to switch devices are often those with the worst hardware or connections, the people a fair queue is supposed to protect. Session only design systematically disadvantages exactly them.
How a handoff token works
A handoff token is a short code, link, or QR generated for a specific queue place, which can be opened on another device to claim that place. Done well, the claim moves the place rather than copying it: the old session is retired when the new one activates, the position and entry time carry over, and the token then stops working.
The details decide whether it is fair. Tokens should be single use for claiming, time limited, and bound to the event and queue they were issued for. A token that can be reused, shared widely, or replayed after the event is not a handoff mechanism. It is a transferable ticket, with a market attached.
The abuse cases to design against
Transferable places invite farming: join early from many sessions, then hand the best place to one device, or sell places outright. Defences include one active place per verified account or payment identity where the event allows it, claim rates that flag rapid token use across many places, and handoff windows that open only after a place has been held for some minutes.
None of that requires punishing normal behaviour. A genuine switch is one claim, from a second device, keeping one place. Farming is many places collapsing into one buyer or many buyers. The patterns look different in the data, and rules should target the pattern, not the mechanism.
What good looks like for shoppers
The shopper facing version is simple: a keep my place on another device option, a code that works once, and a screen on the new device that confirms the same position and estimated wait as the old one showed. No countdown restart, no silent demotion, and a clear message on the old device that the place has moved.
Queues sell fairness as their product. A system that loses your place because your phone died is not running a fair queue with a technical footnote. It is running a queue whose fairness ends at the battery. Handoff is where that claim gets tested.
Keep reading
Related guides on this site: Queue Session Expiry: Keeping a Place Alive When a Phone Sleeps Bot Checks Inside Ticket Queues: Where Verification Helps and Where It Hurts https://queuekeep.com/blog/index.md.
Frequently asked questions
Why did I lose my queue place when I switched devices?
Because most queues track a browser session, not a person. A new device means a new session, which the system treats as a new arrival. Only queues with an explicit token or account based handoff can move a place between devices.
Should a handoff code copy my place or move it?
Move it. The old session should retire when the new device claims the place. A copy creates two live entries for one shopper, which is exactly the duplication fair queues exist to prevent.
Can queue places be sold if tokens exist?
Poorly designed tokens can be transferred and sold, which is why they should be single use, time limited, and watched for farming patterns, like many places collapsing to one buyer. A short claim window and one active place per identity closes most of the risk.
Is signing in the only way to keep a place across devices?
No. An account sign in is one route, but a one time token or QR handoff works for guest queues too. The account route is stronger against abuse; the token route keeps guest checkout possible. Many events should offer both.