No turnstiles in the lane
A small node on the lane post and an industrial unit in the lift hut. Power and data over a single cable.
Validate passes in the boarding lane with the device, without turnstiles or cards

A small node on the lane post and an industrial unit in the lift hut. Power and data over a single cable.
The pass travels on the device on the board or skis: nothing to take out of a pocket to board.
Every pass is signed: the lane validates it even if the network drops and syncs on reconnection, without losing or duplicating a passage.
Challenge-response on every read, anti-passback and cancellations that reach every lift.
Passes come from your sales system via API, webhook or CSV. Ticket offices, prices and payments are untouched.
During the pilot it runs alongside your current system in shadow mode: you measure agreement and coverage before deciding.

Traditional access control is proprietary hardware in every lane. Snowlytics turns it into software running on small, standard hardware that is cheap to expand.
| Turnstile system | With Snowlytics | |
|---|---|---|
| In the lane | A turnstile with reader and barrier in every lane, with civil works and cabling | A node on the post, with power and data over a single cable |
| The pass | A card or media that is bought, handed out, lost and replaced | The device on the board or skis, linked to the pass |
| Boarding | Taking the card out or holding the pocket to the reader | Hands-free: validated as you pass |
| If the network drops | Depends on the server connection or local lists | The pass is signed: validated offline and synced on reconnection |
| The data | Stays inside the supplier's software | On the same map as queues, lift tickets, safety and radio |
| Expanding or changing | More hardware from the same supplier and its maintenance | Another node on the post; the gateway is standard industrial hardware |
Via API, webhook or a CSV from your sales system. The platform keeps only a pseudonymised reference.
Each lift receives the signed list and the cancellations, and keeps them to work offline.
The node reads the device over BLE and the gateway checks signature, validity, lift and anti-passback.
It reaches the dashboard, Lift tickets and Queues exactly once, even through outages.
We install the nodes on one or two lifts next to your turnstiles. Your system stays in charge and ours only records what it would have decided. With the shadow report (agreement, false positives and negatives, coverage) you decide with your own resort's data.
Pricing depends on the lifts and lanes: we prepare the proposal together with the pilot.
No. The pilot runs alongside them in shadow mode, and replacement is decided with the agreement and coverage data from your own resort.
Not in this version. Every read results in a record, never a command to a barrier. Actuating a boarding gate requires certified hardware and is the lift operator's decision and responsibility.
Every pass is signed, so the lane validates it offline. Passages are stored on the gateway and sent on reconnection, never lost or duplicated.
Every read is a challenge only the linked device can answer, and anti-passback prevents the same pass being used twice in a row.
No. Ticket offices, prices, online sales and payments stay as they are: the platform only validates access.
No pass reference in clear: it is stored pseudonymised with a key unique to your resort, with configurable retention and full deletion of the resort.
We will show you the platform with your resort's map. No commitment.