At the gate

Get people in — even when the wi-fi does not cooperate.

Scanning is the one place where a slow answer means a queue of real people. It is also where most systems assume perfect signal and their own hardware.

The scanner

Scanner dialog mid-scan showing the scope banner and an accepted result.

Including what it says it will accept.

The two things nobody else gets right

Works offline

Because the far gate never has good signal.

The scanner keeps a copy of who is expected, carries on admitting people while the connection is gone, and sends everything up when it comes back.
It will not go offline unless it has that copy to work from. It tells your staff instead of waving people through blind — an honest "not now" beats an admission nobody can account for later.
If anything fails to sync afterwards you are told, with a list you can export and work through. A scan is never quietly lost.

Other people can scan too

Your turnstiles, lockers, partners and stallholders.

Anything you sell can be checked and used up by someone else — a ticket, a merchandise collection or a gift card — and whoever is scanning does not need to know which kind of thing it is.
It cannot double-count. If a patchy connection sends the same request twice, the guest is admitted once.
It all lands in the same place: a scan by a partner shows on the same booking, with the same history, as one made by your own staff. There is no second set of records to reconcile.

Built for a queue

A fifth of a second is the target. That is the number that decides whether a line builds up behind your staff. Nothing outside our own system is allowed to sit in the way of a scan — no third-party lookup, no notification, no report.
Safe to scan again. If the signal stutters and your team scans a second time, the guest does not lose a visit off their five-visit pass. The repeat is recognised as the same scan — a problem that otherwise turns up days later as an argument at the gate.
Staff can see what they are checking. The scanner says on screen whether it is accepting this departure, this whole day, or anything at all — and that message is always set from the same place as the check behind it, so it cannot say one thing and do another.
Refusals are clear. An expired ticket says expired, rather than "limit reached". A ticket that is not valid yet says so. Neither uses up a scan.

Lists, arrivals and the paper trail

Live guest lists. Who is expected on a departure, who has arrived, who has been checked in — updating as your team works through them.
Sites can admit each other's tickets. When both agree to it, and with both getting credit for the visit — so a group ticket sold at the aquarium works at the boat tour without anyone rekeying anything.
A full record of who admitted what. Where, when, by which member of staff, and on which device — exportable whenever somebody asks.
QR codes, deliberately. Phone cameras and modern scanners read them instantly, and they hold far more than a printed barcode can. Older ticket designs with a barcode slot get a QR drawn in that space, so nothing you already printed stops working.

The scan audit

Scanning report showing scans by staff member and location, with the export control visible.

Who admitted what, where and when.

See it running on your own products.

Bring one activity, one ticket type and one price. We will show you what it looks like in a real checkout.

Book a demo Back to the overview

Get people in — even when the wi-fi does not cooperate.

The two things nobody else gets right

Works offline

Other people can scan too

Built for a queue

Lists, arrivals and the paper trail

Read next

Sold in person

Tickets and pricing

For developers

See it running on your own products.