Lunda — sports facility software, introduction
Lunda is not another webshop module. It is a vertical SaaS that handles, in one integrated system, what a swimming pool, thermal bath, sports hall or gym does daily: sells tickets, lets guests in, hands out lockers, closes the till. Several Hungarian pool and thermal bath operators run it in production.
The four typical user roles
A mid-size venue runs four roles against the system every day:
- Cashier — sells tickets and passes, handles cash and card, prints invoices. Closes 200–400 transactions on an average Saturday.
- Reception — activates passes, takes photos, handles complaints and phone calls. Often the same person as the cashier at smaller venues.
- Security / entry — stands at the gate, watches the turnstile, resolves fail-secure situations (dead chip, broken pass).
- Operations — daily close, till report, NTAK submission, cleaning shift scheduling, locker reconciliation.
All four roles see the same Lunda backend, just with different permissions. Not four separate apps — one.
The daily flow
Morning 06:00 — opening. Cashier logs in, the cash drawer opens, yesterday's closing balance carries into today. The entry-control operator resets the turnstile server (or it auto-restarts). Pass lists sync to the gate.
Morning 06:15 — first guest. A pass-holder, walks to the gate, taps the card. Within 280 ms the green light comes on, turnstile rotates. Backend logs: who, when, which gate. This is not optional — for swimming pools it is a legal requirement (life-safety and accident traceability).
Morning 07:30 — cashier peak. The cashier doesn't get to drink coffee for 8 minutes. POS response time stays under 100 ms throughout, because the frontend keeps a local cache of the price list (background async sync).
Late morning 10:00 — locker reconciliation. Operations queries: how many lockers are currently occupied, which are over-allocated (guest left but chip is still active — a frequent bug if the exit point doesn't reset). They find 4 such lockers and reset them manually.
Afternoon 16:00 — shift change. Afternoon cashier takes over the till. The system produces a shift report: cash, card, voucher, online ticket. A 1500 HUF discrepancy — they find the cause (a guest paid extra for pool + sauna combo, but only pool was recorded).
Evening 21:30 — closing. Last guest gone, till closes, NTAK data auto-submits by 22:00. If the submission fails, a Slack alert goes to operations.
Why one system, not four
Most venues we audited started with four separate apps:
- ticketing system (often a spreadsheet or a custom PHP app),
- entry-control (the turnstile vendor's own software),
- locker system (the RFID-lock vendor's own software),
- POS (a generic point-of-sale, e.g. recommended by their bookkeeper).
The trouble is always the same: the four systems don't talk to each other. A pass-holder goes in, pays an extra fee for the sauna, the POS records it — but the entry system doesn't know, and the locker doesn't know. Or the other way: reception suspended the pass (illness), but the gate still lets the person in because the entry-control software doesn't sync.
Lunda solves it with an integrated data model: pass, ticket, locker allocation, transaction all belong to the same guest profile. One picture, four motions.
Lesson
When a pool or thermal bath buys software, the key question is not which module is best on its own, but whether the four motions can be integrated. Lunda doesn't solve that retroactively — it is the foundation.